> -----Original Message-----
> From: Tren Blackburn [mailto:t...@eotnetworks.com]
> Sent: Monday, March 30, 2009 11:55 AM
> To: vchkpw@inter7.com
> Subject: RE: [vchkpw] vdelivermail stdout to Dovecot deliver
>
> I have a question about this. When I first implemented dSPAM I used
the
> same method of nested pipes to handle delivery through .qmail-default.
> However the problem I ran into was if there was a problem in the first
> pipe that caused an error mail was lost due to the broken pipe. Is
that
> something that could happen here? Is the pipe intelligent enough to
see a
> failure and notify the previous process?
>
> And with regards to the environment variables, if you export them in
the
> parent process shouldn't they be part of the environments of the child
> processes? Another possibility is piping through maildrop. That's the
> solution I ended up moving to for dSPAM since it was able to handle
errors
> properly through an exception and xfilter clause. Based on the error
codes
> dspamc sent I could re-queue or do other things. And to ensure that
> chkuser still functioned properly for "bounce-no-mailbox" you just
setup
> the .qmail-default like this:
>
> | /usr/local/bin/maildrop /etc/maildroprc # bounce-no-mailbox
>
> Because chkuser only checks for the existence of "bounce-no-mailbox"
> in .qmail-default. It doesn't care about vdelivermail so adding it as
a
> comment works perfectly.
>
> I'm not sure if this method would be worth doing in the case of
dovecot,
> but it helped me get around some of the same issues with dSPAM, and
ensure
> that mail was never lost.
>
> Regards,
>
> Tren
[Cleaver, J.C.]
One option is patching vdelivermail to not see the final delivery
through. At a previous location I was at, we had it leave files in
Maildir/tmp and trigger an external script. If that exited successfully,
vdeliermail left it in Maildir/tmp and exited OK -- presumably leaving
that file there for later processing by some other script. If it didn't,
back out of the delivery with a tempfail.
Ideally, you would have that external script record an entry in a DB
queue somewhere. Later on ("later" meaning a few async seconds later),
the queue is polled and the final delivery process does whatever it
wants with that guaranteed-safe file, it being responsible for dropping
it in Maildir/new when it's complete.
If everything goes according to plan, you should be guaranteed not to
drop mail. The only drawback is that your final delivery script can't
generate a bounce back out through the mail stream automatically, it
would have to re-inject.
Regards,
Japheth Cleaver
!DSPAM:49d11a8032681616791409!
