At 15:14 2010-01-08 -0500, Richard B. Emerson wrote:
Charles Gregory wrote:
>
> Please reply to list. This reply is to list...
>
> On Fri, 8 Jan 2010, Richard B. Emerson wrote:
> : Actually, the example note has To: baba-l(_at_)yahoogroups(_dot_)com not To:
> : chris(_at_)pinefields(_dot_)com(_dot_)(_dot_)(_dot_)
>
> The To header is irrelevant. Mail to this list is addressed "To:" the
> list. But the *envelope* (which is captured in your system as a
> header "Delivered-To:" is the real recipient.
>
> : ... The intent of the recipe below is to take a message containing
> : Delivered-To: and send it to the addressee in that header entry.
>
> The 'Delivered-To' means it is ALREADY being delivered to that address!
> Your MTA (sendmail) should have invoked procmail on behalf of the
> 'Delivered-To' user. And this should *not* depend on the "To:" header in
> any way....
OK, I can go with that. However, my test for "delivered-ness" is "is
message in /var/mail/recipient?" And the answer is no. The messages,
instead, go to system's mailbox (the postmaster addy). Something is
broken.
Suggestion: find out what is broken and why, rather than tinkering with
finding new ways to break things.
> : "if X-Loop:..." is present, don't forward the It should keep a
> : forwarding loop from forming. Why this isn't the case is part of my
> : problem.
>
> Unless the forwarding loop is occurring *outside* of procmail!
Well, OK, but... don't the conditions "matched Delivered-To and matched
X-Loop" keep the message from going anywhere?
Your MTA is seeing something in the message indicating that it's a looped
message. Quite possibly, the pre-existing Delivered-To: header. Uppling
the diagnostic logging level of your MTA would help to identify this,
provided you understand how to do that.
I'm confused. I think the delivery process is
Do fetchmail to get mail from ISP
Ah, new information - when you FORWARD the message, the MX for the domain
IS NOT YOUR HOST? So you're forwarding it off to an ISP mailbox, and then
you're retrieving the message from them?
Wow.
Okay, so your UPLINE mail provider is probably the one generating the
bounce, and it's probably because they see their own host in the headers
someplace.
Again, the solution is to not attempt ham-fisting it. You shouldn't need
to forward it back into the mail system.
Sendmail examines intake from fetchmail
Sendmail passes mail through procmail filtering (e.g., spam checks via
spamassassin [now commented out entirely - SA is too quick to reject
good mail])
Then configure SA to merely mark the messages up, not dispose of
them. Over time, you can find the attributes marked on valid messages that
are being high-scored, and then adjust the scoring for those tests.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
____________________________________________________________
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