Re: Broken mass mailings - Delivered-To: issue

Bart Schaefer wrote:

On Fri, Jan 8, 2010 at 11:52 AM, Richard B. Emerson
<system(_at_)pinefields(_dot_)com> wrote:
  

Looking at this matter further, I'd like to focus on the bounce loop
problem.  That is, why does a bounce loop form here?
    

I think there's a missing bit of information here.

Your mail actually arrives at an ISP (Verizon, I think, from looking
at Received: feilds?) in a single mailbox.  You then download it from
the ISP using fetchmail and have fetchmail invoke procmail to explode
the mail out again to local users.  (Note that this is NOT a
recommended use of procmail, because of issues similar to the one
you're experiencing.)
  

Actually mail goes out via Verizon and comes back via Network Solutions (domain and POP host).  It's ugly and a legacy from earlier work that has since ended. 

Yes, the mail is collected via fetchmail.  Frankly, at this point I don't know for sure who gets their hands on the mail queue after fetchmail delivers it.  I have always assumed that sendmail sees messages queued up and munches through the queue, passing the individual messages through procmail as sendmail processes each incoming message.  Given how sparse procmailrc is, I doubt it's the next app to see the mail after fetchmail. 

So the new recipe attempts to discern the local user by examining the
delivered-to header because there is no local user in any of the
headers matched by the ^TO_ macro.
  

Er, that's not my intent.  My plan is to look at each message after it's been collected and fine tune the destination based on either the problem with the Delivered-To field or to duplicate mail for one address to another address.  It seems to me this is at the end of the mail handling process, not the front. 

Question:  What procmail recipe is used to perform final delivery of
the mail when the To: header actually does have the local user address
in it?
  

AFAIK, that's sendmail's job. 

# Send bulk mail with DeliveredTo to the intended recipient
:0
* ^Delivered-To: pavilion(_at_)pinefields(_dot_)com
* !^X-Loop: Delivered-To Forward Control
 | formail -A "X-Loop: Delivered-To Forward Control" | \
   $SENDMAIL -oi pavilion(_at_)pinefields(_dot_)com

Why doesn't the test for X-Loop succeed?
    

Not enough information yet to say, but I suspect the loop is being
detected by the MTA (e.g., it notices that you're trying to deliver
again to the same address to which the message has already been
delivered once).  This might be happening in spite of the fact that
the first delivery was on Verizon's server and the second one is via
your local sendmail.
  

I agree that the problem may well be caused by sendmail.  The short-term goal is building a workaround for a special case (ill-formed mail list mailings).

# Duplicate all mail to pavilion on u100
#:0 c
#* ^TO_pavilion(_at_)pinefields(_dot_)com
#* !^X-Loop: Forwarding Loop Control
#  | formail -A "X-Loop: Forwarding Loop Control" | \
#    $SENDMAIL -oi u100(_at_)pinefields(_dot_)com

Aside from the "c" copy flag, and the replacement of testing for TO: for
Delivered-To:, aren't these recipes equivalent?
    

No, they're not equivalent, because pavilion != u100 ... there's no
appearance of the same user being involved twice, as happens in your
problem case.
  

Very good point! 

Cheers,
Rick Emerson

____________________________________________________________
procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)de
http://mailman.rwth-aachen.de/mailman/listinfo/procmail


  

____________________________________________________________
procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)de
http://mailman.rwth-aachen.de/mailman/listinfo/procmail