> -----Original Message-----
> From: Cleaver, Japheth [mailto:jclea...@soe.sony.com]
> Sent: Monday, March 30, 2009 12:16 PM
> To: vchkpw@inter7.com
> Subject: RE: [vchkpw] vdelivermail stdout to Dovecot deliver
>
> > -----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.
Hmmm...it seems to me like that wouldn't scale very well, and could
possibly get messy if you're dealing with a cluster of SMTP delivery
nodes. But it's another way for sure. Maildrop doesn't require any
hacking of vdelivermail as it's a drop-in replacement for it since
vdelivermail is called at the end of maildrop after all the filtering is
done inside. This guarantees no loss of mail, without needing extra
external processes.
>
> 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.
>
How much additional overhead is caused due to re-injection over
re-queuing? It seems like this requires on quite a few additional pieces
that are outside of the qmail delivery path and if any of them break or
not work as expected, could delay final delivery infinitely due to
messages gathering in the tmp folder. I'm unsure how you would handle
remote delivery with this method as it seems to assume the final mailbox
is on the same server/cluster as the delivery process.
Ideally we shouldn't need *any* of these hacks, maildrop or otherwise.
It'd be nice to plug in a different delivery method to qmail. However,
that's not really an option, so we build what we can to do what we need,
and we all have different needs usually. :)
Regards,
Tren
!DSPAM:49d1215832689616257855!
