# Qmail won't send to outside addresses [Oops!]

## lazloman

I solved an earlier problem, but this one has me vexed. When I try to send mail outside my network, the qmail-send/current log shows that qmail-remote crashed. No other explanation is logged. I've looked at all my configuration files and compared them to my current working qmail server and can't find anything wrong. Does anyone have any ideas? Yes, I did look at Life With Qmail.

----------

## skunkworx

Can you post the log entries showing qmail-remote crashing, and also your configuration files under /var/qmail/control (except for servercert.cnf and all files ending in .pem, if they exist).  Also, which version of the ebuild are you using?

----------

## lazloman

I'm using qmail-1.03-r13

Here the qmail-send log for the last two attempts

@40000000400f25282440922c starting delivery 6: msg 50087 to remote outside@address.com

@40000000400f2528244149c4 status: local 0/10 remote 1/20

@40000000400f25282583726c delivery 6: deferral: qmail-remote_crashed./

@40000000400f252825840eac status: local 0/10 remote 0/20

@40000000400f263625ab8ff4 starting delivery 7: msg 50086 to remote outside@address.com

@40000000400f263625ac478c status: local 0/10 remote 1/20

@40000000400f263626f09314 delivery 7: deferral: qmail-remote_crashed./

@40000000400f263626f12b6c status: local 0/10 remote 0/20

My /var/qmail/control files

conf-common:

# Common Configuration file for all qmail daemons

# $Header: /home/cvsroot/gentoo-x86/net-mail/qmail/files/1.03-r13/conf-common,v 1.1 2003/10/27 09:42:54 robbat2 Exp $

# Qmail User IDS to run daemons as

QMAILDUID=`id -u qmaild`

NOFILESGID=`id -g qmaild`

# Qmail Control Dir (this is actually set in /etc/env.d/99qmail)

#QMAIL_CONTROLDIR=/var/qmail/control

# Host and port to listen on

# We listen on the IPv4 local ip by default

TCPSERVER_HOST=0.0.0.0

TCPSERVER_PORT=${SERVICE}

# you do not need to specify -x, -c, -u or -g in this variable as those are

# added later

TCPSERVER_OPTS="-p -v"

# we limit data and stack segments to 8mbytes, you may need to raise this if

# you are using a filter in QMAILQUEUE

SOFTLIMIT_OPTS="-m 800000000"

# We don't have anything to set QMAILQUEUE to at the moment, so we leave it alone

#QMAILQUEUE=""

# tcpserver maximum concurrency, defaults to 40 in tcpserver

# this controls the maximum number of incoming connections that it will accept

[ -e ${QMAIL_CONTROLDIR}/concurrencyincoming ] && MAXCONN=$(<${QMAIL_CONTROLDIR}/concurrencyincoming) || MAXCONN=40

conf-smtpd:

# Configuration file for qmail-smtpd

# $Header: /home/cvsroot/gentoo-x86/net-mail/qmail/files/1.03-r13/conf-smtpd,v 1.2 2003/11/30 03:00:20 robbat2 Exp $

# Stuff to run before tcpserver

#QMAIL_TCPSERVER_PRE=""

# Stuff to run qmail-smtpd

#QMAIL_SMTP_PRE=""

# Stuff to after qmail-smtpd

QMAIL_SMTP_POST="sage.thethurmans.com"

# this turns off the IDENT grab attempt on connecting

TCPSERVER_OPTS="${TCPSERVER_OPTS} -R"

# You might want to use rblsmtpd with this, but you need to fill in a RBL server here first

# see http://cr.yp.to/ucspi-tcp/rblsmtpd.html for more details

#QMAIL_SMTP_PRE="${QMAIL_SMTP_PRE} rblsmtpd -r blackholes.mail-abuse.org"

# If you are interested in providing POP or IMAP before SMTP type relaying,

# emerge relay-ctrl, then uncomment the next 2 lines

#QMAIL_TCPSERVER_PRE="${QMAIL_TCPSERVER_PRE} envdir /etc/relay-ctrl relay-ctrl-chdir"

#QMAIL_SMTP_PRE="${QMAIL_SMTP_PRE} relay-ctrl-check"

# In /etc/courier-imap/authdaemonrc add the next line to the end:

#authmodulelist="${authmodulelist} relay-ctrl-allow"

# Then in /etc/courier-imap/{imapd,imapd-ssl,pop3d,pop3d-ssl}

# Add this at the end

#PRERUN="${PRERUN} envdir /etc/relay-ctrl relay-ctrl-chdir"

# This next block is for SMTP-AUTH

# This provides the LOGIN, PLAIN and CRAM-MD5 types

# the 'cmd5checkpw' used in $QMAIL_SMTP_AUTHCHECKPASSWORD supports CRAM-MD5

# and reads it's data from /etc/poppasswd

# see the manpage for cmd5checkpw for details on the passwords

# uncomment the next four lines to enable SMTP-AUTH

#QMAIL_SMTP_AUTHHOST=$(<${QMAIL_CONTROLDIR}/me)

#[ -z "${QMAIL_SMTP_POST}" ] && QMAIL_SMTP_POST=/bin/true

#QMAIL_SMTP_CHECKPASSWORD="/bin/cmd5checkpw"

#QMAIL_SMTP_POST="${QMAIL_SMTP_AUTHHOST} ${QMAIL_SMTP_CHECKPASSWORD} ${QMAIL_SMTP_POST}"

defaultdelivery:

# Uncomment the next line for .forward support

#|dot-forward .forward

| spamassassin -P | maildir ./maildir/

defaultdomain:

thethurmans.com

locals:

thethurmans.com

internal.thethurmans.com

me:

thethurmans.com

plusdomain:

thethurmans.com

rcpthosts:

thethurmans.com

internal.thethurmans.com

smtproutes:

internal.thethurmans.com:

:mail.mindspring.com

Thanks for helping

----------

## skunkworx

 *lazloman wrote:*   

> Here the qmail-send log for the last two attempts...

 

Thank you.  I know it doesn't look like the logs show anything you haven't already mentioned, but it's always good to show them, just in case they yield a clue to someone.

Everything looks in order in your configuration files.  Have you modified the scripts under /var/qmail/supervise at all?  You shouldn't have to with 1.03-r13, and tweaking those scripts could lead to unexpected behavior.

The only other thing I can think of is that the qmail-remote binary itself was hosed somehow.  If that's the case, a remerge of qmail might do the trick.  /var/qmail/control is one of Portage's protected configuration directories, so remerging shouldn't wipe out any changes you've made there.  You may want to make a back-up of it before remerging anyway, just to be anal and paranoid.

If you really feel like trying to debug the current problem, this message from the qmail mailing list (archives available here) might help:

 *Quote:*   

> Is a core dump created?
> 
> Do they crash immediately or after some delay?
> 
> If the latter can you do a truss or strace?
> ...

 

You might also try searching the list archives for other clues.

Hope this helps.  I can tell you I've been running 1.03-r13 without any trouble, so it is possible!

----------

## lazloman

Thanks for the reply, I'll try what you've suggested and see what happens. 

It crashes immediately and no core dump is left. 

One thing I should add though, is that since I'm migrating from one machine to another, any appropriate network settings like MX records are still pointing to my current mail server, so if there is anything outside of qmail's config files that might be a factor feel free to add. 

Thaks again

----------

## skunkworx

Network problems or misconfigurations would cause mail to be deferred or delivered incorrectly, but they wouldn't cause qmail-remote to crash.  The qmail executables are pretty solid, usually even under a mountain of patches.

Good luck!

----------

## Derringer

I'm a fairly seasoned qmail admin in both corporate and private settings and this kind of has me vexed.  I'd be very interested in hearing how you fix it when you do, if you wouldn't mind, for future reference.

One of the problems with administering qmail is not entirely evident when you initially set it up... and that is that it is so damn solid that it might be an entire year before you have an issue you have to troubleshoot, and by that time you have forgotten how (hehe, thought a joke was in order).

In all seriousness, I'm unfamiliar with setting it up under Gentoo, but have always done it from source following Life with Qmail in other distributions.  Is the Gentoo build patched with the patches to qmailqueue, for instance ?

----------

## kashani

Yep, Gentoo includes all the major patches. As of 1.03-r13 the patches you get by default are

qmailqueue

big-todo

qmail-link-sync

big-concurrency

qmail-0.0.0.0

sendmail-flagf

qmtpc

qmail-smtpd-relay-reject

qmail-local-tabs

qmail-maildir++

qmail-date-localtime

qmail-limit-bounce-size

as well as 7 or 8 more. I'm still running r8 myself as I didn't see the need to get r13 as it mostly adds user type functionality. I'd also install qmhandle and supervise-scripts as well. I do recall having some issues building r10 or r13 recently, but I evenutally got around the problem. 

I would recommend trying a different qmail ebuild, such as r8, with much less patches to see if the problems go away. Assuming the problems do disappear, you might try r10 and then r13 to see if you can pin point where things have gone wrong. Also it's not hard to drop some fo the stranger patches out the ebuild. r8 has about the minimum set of patches I recommend using.

kashani

----------

## skunkworx

Going to an earlier, less-patched ebuild of qmail is a good idea if r13 continues to give problems, but I would recommend going back to r10, not r8.  r8 is not compatible with the latest glibc packages (the errno issue for those who know what that means).

I have a complete list of all the patches r13 applies to the qmail sources, with a little bit of explanation about what each one does.  This should help anyone who is looking to prune their qmail installation.  Go here and scroll down to appendix C.

----------

## WHiZZi

Sorry for this bump, but it's worth it.

I had the same problem on one of my mailservers with qmail-1.03-r13 while other mailservers (exact the same configuration, except for hostname) just worked flawless.

After a long search on this forum, newsgroups and lots of other places I just couldn't find a solution. So I was preparing to downgrade to r10 and hoping that will work. I was preparing a fall back server in case everything went wrong. While the server was transferring it's configfiles, mailfiles and database I was looking to find a way to start qmail-remote from the command line.. you know, reading man pages..

At this manpage I found the following:

 *Quote:*   

> 
> 
>      helohost
> 
>           Current host name, for use solely in  saying  hello  to
> ...

 

Well, I only have a /var/qmail/control/me file with the hostname which is readable by qmail. 

But, because I was waiting anyway I just figured to try that. So I copied the me file to helohost. Next thing I did was qmHandle -a to send all mail (there were like 150 remote messages which crashed all the time). And you know what?! The whole queue just started to flush and the server was sending mail to all servers. Qmail-remote just didn't crash anymore!   :Laughing: 

So, this was my solution to this problem. But I still don't get it why it has stopped working so suddenly. The server has run for quite a while without any problems and suddenly it started doing this. I can't remember any updates that could harm the qmail-installation or whatsoever. 

Anyway, it's fixed now.

----------

## mcj2a

I am getting the same error on my ppc machine...qmail-remote works fine with no smtproutes specified, whereas it dies when there is one.  I've gotten an strace running qmail-remote from the command line, but I am not a programmer and I have no idea what this output means...anyone smarter than me have any ideas?

The command line:

```
echo test|strace qmail-remote yahoo.com [myemailaddress] [myaccount]@yahoo.com
```

And the output:

```
[...]

mprotect(0xfcf1000, 4096, PROT_READ)    = 0

mprotect(0xfe33000, 8192, PROT_READ)    = 0

mprotect(0xffec000, 4096, PROT_READ)    = 0

mprotect(0x30020000, 4096, PROT_READ)   = 0

munmap(0x30018000, 12086)               = 0

open("/dev/urandom", O_RDONLY)          = 3

read(3, "\225\"\254\21", 4)             = 4

close(3)                                = 0

rt_sigaction(SIGALRM, {0x100026f0, [], 0}, NULL, 8) = 0

rt_sigaction(SIGPIPE, {SIG_IGN}, NULL, 8) = 0

chdir("/var/qmail")                     = 0

open("control/me", O_RDONLY|O_NONBLOCK) = 3

read(3, "kuro\n", 64)                   = 5

close(3)                                = 0

open("control/timeoutremote", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)

open("control/timeoutconnect", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)

open("control/helohost", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)

open("control/smtproutes", O_RDONLY|O_NONBLOCK) = 3

read(3, ":mail.messagingengine.com bWNqQG"..., 64) = 60

read(3, "", 64)                         = 0

close(3)                                = 0

open("control/tlsclientciphers", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)

socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3

ioctl(3, SIOCGIFCONF, {64, {{"lo", {AF_INET, inet_addr("127.0.0.1")}}, {"eth0", {AF_INET, inet_addr("192.168.1.20")}}}}) = 0

ioctl(3, SIOCGIFFLAGS, 0x1001b8a8)      = 0

ioctl(3, SIOCGIFADDR, 0x1001b8a8)       = 0

ioctl(3, SIOCGIFFLAGS, 0x1001b8c8)      = 0

ioctl(3, SIOCGIFADDR, 0x1001b8c8)       = 0

close(3)                                = 0

time(NULL)                              = 1109622378

getpid()                                = 12166

--- SIGSEGV (Segmentation fault) @ 0 (0) ---

+++ killed by SIGSEGV +++
```

----------

## lazloman

Is still have not solved the problem, but I did find that I can use the qmail-remote binary from r10 with r13, so I keep a copy and then replace the newly compiled one with it.

----------

## mcj2a

 *lazloman wrote:*   

> Is still have not solved the problem, but I did find that I can use the qmail-remote binary from r10 with r13, so I keep a copy and then replace the newly compiled one with it.

 

Unfortunately, I need r13 with the remote-auth patch, as I am trying to use a smarthost that requires authentication.  I may have to give exim a go, I guess.

----------

## paulhart

I'm getting the same problem as previous posters, using r15 on PPC. This is the end of my strace output:

```
[...]

socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3

connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("206.191.0.140")}, 28) = 0

fcntl64(3, F_GETFL)                     = 0x2 (flags O_RDWR)

fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK)  = 0

gettimeofday({1118660783, 564826}, NULL) = 0

poll([{fd=3, events=POLLOUT, revents=POLLOUT}], 1, 0) = 1

send(3, "\277\32\1\0\0\1\0\0\0\0\0\0\5gmail\3com\0\0\17\0\1", 27, 0) = 27

poll([{fd=3, events=POLLIN, revents=POLLIN}], 1, 5000) = 1

recvfrom(3, "\277\32\201\200\0\1\0\5\0\4\0\t\5gmail\3com\0\0\17\0\1"..., 513, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("206.191.0.140")}, [16]) = 386

close(3)                                = 0

--- SIGSEGV (Segmentation fault) @ 0 (0) ---

+++ killed by SIGSEGV +++

```

I have no idea what's causing this, but it wasn't happening prior to my last sync and update in the middle of March.

----------

## lazloman

Unfortunately, I'm still having the same problem. No one responded to my strace post. The helohost fixed noted earlier in the thread did not work for me, so I'm still using the r-10 qmail-remote although technically, I'm running r-15. If find a fix a fix, I'll post back here.

----------

## lazloman

This one sure took a while, it was compiler flags. These settings work:

CFLAGS="-O2 -pipe -mmultiple -mstring"

I'm good now.

----------

## lazloman

Actually, I was wrong about this. The compliler flags did not help. I ended up getting the source for netqmail, compiling the source and using the qmail-remote from there. This one works. It does not have all the patches the portage version has, but it does have a few. From what I can find out about this on the internet, it may be the patches that are the problem, but only time will tell. Anyway, after making sure things were working this time, I ran an strace of the working qmail-remote and compared it to the bad version (posted earlier). Here's the output from that. If you compare the two, you see the failed version seg faults just after a call to getpid() which to appears to return successfully. Maybe one day I'll take a look at the source and see if I can find the problem.

```

14374 rt_sigaction(SIGPIPE, {SIG_IGN}, NULL, 8) = 014374 chdir("/var/qmail")           = 014374 open("control/me", O_RDONLY|O_NONBLOCK) = 314374 read(3, "Sage2.internal.thethurmans.com\n", 64) = 3114374 close(3)                   = 014374 

open("control/timeoutremote", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)14374 

open("control/timeoutconnect", O_RDONLY|O_NONBLOCK) = -1 ENOENT (No such file or directory)14374 

open("control/helohost", O_RDONLY|O_NONBLOCK) = 314374 

read(3, "Sage2.internal.thethurmans.com\n", 64) = 3114374 close(3)                   = 014374 

open("control/smtproutes", O_RDONLY|O_NONBLOCK) = 314374 

read(3, "internal.thethurmans.com:\n:mail."..., 64) = 4714374 

read(3, "", 64)                   = 014374 

close(3)                          = 014374 socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 314374 ioctl(3, SIOCGIFCONF, {64, {{"eth0", {AF_INET, inet_addr("192.168.2.16")}}, {"lo", {AF_INET, inet_addr("127.0.0.1")}}}}) = \014374 ioctl(3, SIOCGIFFLAGS, {ifr_name="eth0", ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_MULTICAST}) = 014374 ioctl(3, SIOCGIFADDR, {ifr_name="eth0", ifr_addr={AF_INET, inet_addr("192.168.2.16")}}) = 014374 ioctl(3, SIOCGIFFLAGS, {ifr_name="lo", ifr_flags=IFF_UP|IFF_LOOPBACK|IFF_RUNNING}) = 014374 ioctl(3, SIOCGIFADDR, {ifr_name="lo", ifr_addr={AF_INET, inet_addr("127.0.0.1")}}) = 014374 

close(3)                          = 014374 time(NULL)                        = 112251883614374 

getpid()                          = 1437414374 

gettimeofday({1122518836, 608030}, NULL) = 014374 

getpid()                          = 1437414374 brk(0)                            = 0x1001a00014374 brk(0x1003b000)                   = 0x1003b00014374 

open("/etc/resolv.conf", O_RDONLY) = 314374 

fstat64(3, {st_mode=S_IFREG|0644, st_size=54, ...}) = 014374 

mmap(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x3002c00014374 read(3, "search internal.thethurmans.com\n"..., 131072) = 5414374 read(3, "", 131072)               = 014374 close(3)                          = 014374 munmap(0x3002c000, 131072)

```

----------

## SweepingOar

I had this problem and this message seems to have fixed it, but only for one day!  For newbies like me, here is the only thing I did:

```
cd /var/qmail/control/

cp me helohost
```

After I did this, all the mail started going out.  People who hadn't gotten our mail all week started getting all the messages that hadn't gone.  Today we've got "qmail-remote_crashed" in the current qmail-send log all over.  What a world.

 *WHiZZi wrote:*   

> Sorry for this bump, but it's worth it.
> 
> I had the same problem on one of my mailservers with qmail-1.03-r13 while other mailservers (exact the same configuration, except for hostname) just worked flawless.
> 
> After a long search on this forum, newsgroups and lots of other places I just couldn't find a solution. So I was preparing to downgrade to r10 and hoping that will work. I was preparing a fall back server in case everything went wrong. While the server was transferring it's configfiles, mailfiles and database I was looking to find a way to start qmail-remote from the command line.. you know, reading man pages..
> ...

 

----------

## lazloman

I tried this myself and it did not work. I have both "me" amd "helohost" with the same contents.

----------

## SweepingOar

Sorry, yeah, it only worked for us for a day!  I edited that post so as to not give out false hope anymore.  I don't know what to do.  Developers, gurus veterans, please help!

 *lazloman wrote:*   

> I tried this myself and it did not work. I have both "me" amd "helohost" with the same contents.

 

----------

## SweepingOar

You also might want to look at this thread I started.  One of the veterans suggested a simple fix that appears to have worked.

https://forums.gentoo.org/viewtopic-p-2818055.html

----------

## lazloman

Thanks, I just re merged QMail without SSL support and it seems to be just fine.

----------

