Re: confirm looping. How to stop it? SOLVED - Yes!

On Wed, 2006-09-20 at 23:59 -0500, Rich Duzenbury wrote:
> On Wed, 2006-09-20 at 20:09 -0600, Stephen Warren wrote:
> > Rich Duzenbury wrote:
> > > Ha, I thought it was solved.
> > > 
> > > Now, the user confirms the message.  It gets delivered.  Perfect.  Just
> > > as it should be.
> > > 
> > > Next time they send another message, the are asked to confirm again!
> > 
> > You probably didn't set the CONFIRM_APPEND variable, or your incoming
> > filter doesn't check that file (or the filenames don't match).
> > 
> 
> Stuff was erroring out because I wasn't calling preline bofore trying to
> call tmda-filter.  So, no return path.
> 
> I think I'm really close now, but still one nasty hairball.  Foreign
> email comes in, generates the confirm e-mail.  Confirm e-mail is replied
> to.  The original message gets delivered, and a 'confirmation accepted'
> message is received by the foreign sender.  Just as things should be.
> 
> Everything seems great - until a few minutes go by and the original
> sender gets a 'Mail delivery failed: returning message to sender", and
> it's a copy of the confirm e-mail.
> 
> Also, the receiver gets the same mail over and over and over every few
> minutes.
> 
> I think the problem is a mismatch in error codes.  If you recall I'm
> running courier -> preline -> dspam -> maildrop -> tmda.  
> 
> Now, tmda returns a 99 when an email needs to be confirmed, and I
> believe that it goes back up the chain to maildrop.  When dspam gets it,
> it must return it, or perhaps TEMPFAIL to courier.  I think dspam only
> accepts 0 for success.
> 
> I have a number of these in the maillog:
> dspam[15404] Delivery agent returned exit code
> 99: /usr/lib/courier/bin/maildrop -d rduz
> 
> Or, I could be completely wrong.
> 
> Advice greatly appreciated!


This seems to be a correct diagnosis.  I plowed through the maildrop man
pages for a bit, and googled some.  Note that this is filter chain of

courier -> preline -> dspam -> maildrop -> tmda-filter

Here is my solution, which I think, is working:

# ~/.mailfilter

# sender, recipient, ext needed for TMDA
# maildrop does not automatically import external environment variables
# import copies them from the external environment into 
# internal variables.  Courier MTA sets these for us.
import SENDER
import RECIPIENT
# note that the correct variable for courier is EXT, not EXTENSION
# not knowing this was _bad_
# couier will ask for confirm, and then ask for a confirm of the confirm
# and so on, forever.  It needs the extension part of the email address
# to process correctly.
import EXT

# deliver through tmda-filter
# exception means it won't just die off, but it will give us the 
# opportunity to recover from a non-zero exit code.
exception {
  to "| /usr/local/bin/tmda-filter"
}

# tmda-filter returns 99 in some cases. This is normal.
# However, dspam hates it.  99 causes it to 
# re-queue/bounce the message.  So, return 0 in that case.
# If the mail is legitimately deferred, tmda-filter exits
# with code 75.  Allow it back up the chain, or mail will
# get lost
if ($EXITCODE == 99)
{
   EXITCODE = 0
}

# bail.  All delivery is handled by tmda-filter.
exit



Hopefully, this is a good and proper way to use tmda-filter.  If you
have any helpful suggestion, don't hesitate to send them along.  

I still need to get ofmipd working, and really understand the outgoing
filter setup...

Thank you.

Regards,
RIch