Applicable versions:

vpopmail 5.2.1 and 5.2.2
maildrop 1.6.3
MySQL 4.0.16

I don't have a test server set up to use 5.4.0-pre1 but I may get around
to that sometime this next couple of weeks.  (By which time we'll have a
new 5.4.0-pre# version probably.)

The basic issue is one that had been reported before on this mailing
list... If I call vdelivermail in maildrop to handle aliases, it spawns
vdelivermail and says it handles an alias...  But it just simply does not
forward the message.

An example set of lines from my mail log is:
(I have changed the domain names for various reasons)

Dec  8 17:33:15 devmail qmail: 1070922795.117969 new msg 49247
Dec  8 17:33:15 devmail qmail: 1070922795.118076 info msg 49247: bytes 1073 from 
<[EMAIL PROTECTED]> qp 13756 uid 211
Dec  8 17:33:15 devmail qmail: 1070922795.122280 starting delivery 222: msg 49247 to 
local [EMAIL PROTECTED]
Dec  8 17:33:15 devmail qmail: 1070922795.122377 status: local 1/100 remote 0/100
Dec  8 17:33:15 devmail qmail: 1070922795.162617 delivery 222: success: 
vdelivermail:_valiases_processed/did_0+0+1/
Dec  8 17:33:15 devmail qmail: 1070922795.162727 status: local 0/100 remote 0/100
Dec  8 17:33:15 devmail qmail: 1070922795.162746 end msg 49247

At the time, [EMAIL PROTECTED] was supposed to forward back to
[EMAIL PROTECTED]

After a bit of playing around (including changing vdelivermail to use a
Perl script rather than qmail-inject), I decided that the problem was
that, for whatever reason, qmail-inject was stopping before it had the
opportunity to finish.  My guess is that a signal was being passed to it
that caused it to terminate.  Unfortunately, I don't know what signal that
is since I didn't think to try to add signal handlers to my Perl script.
Also, unfortunately, I don't know if the signal is being issued by (or as
a result of) vdelivermail or maildrop.  (I seem to recall reading
somewhere that a child process is passed a signal if the parent dies.)

I came up with a fix, but it's rather a quick kludge and really should be
replaced with something better.  My fix was to add a sleep(2) after
vdelivermail.c closes the write file descriptor to the qmail-inject child.
So the 'if (inject == 1)' block looks like this:

    if ( inject == 1 ) {
        close(write_fd);
        sleep(2);
        return(0);
    }


(In 5.2.2, the sleep(2) is line 599.)

The theory is that after two seconds, qmail-inject should be done and then
vdelivermail returns.

This works on both the development and production mailservers I run
without issue.

As I said, it's a nasty kludge, but it may be useful for those of you who
experience this issue.

If you have any better suggestions or think I'm chasing the wrong bug, do
let me know.

Sincerely,


Chris Ess
System Administrator / CDTT (Certified Duct Tape Technician)

Reply via email to