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.
: "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? Or, what recipe will do this?
: Why am I using sendmail? Because that's the way it was set up with
SuSE
: Linux 11.1, which is what I'm running here.
No, no, why are you SENDING the mail you just received, rather than
delivering it directly to the recipient's mailbox? IE:
:0
*(conditions)
$USER/inbox
I'm confused. I think the delivery process is
Do fetchmail to get mail from ISP
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])
Mail finally lands in file for pickup (/var/mail/username)
All I think I'm doing is tuning a filter at the end of the delivery
process.
Understand that at the moment procmailrc has nothing in it but
VERBOSE=ON
# 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
That's it. Nothing else. V. plain vanilla. :-) And, yes, it's
broken, and yes, it's commented out except for testing.
: Again, keep in mind that however strange things may have been here
(with
: sendmail and procmail), until very recently, it all worked as it
should.
Any time I encounter *this* condition, I always ask, "what changed?"
Look in your logs for *anything* being updated around that time.
Remember it is the recipient's shell invoked for things like
'formail', so
even if you changed permissions or the 'path' for a user shell, it could
have an impact... ANYTHING that changed....
If I knew what was different I'd try to back it out. In the mean time,
I'm looking for a workaround.
Cheers,
Rick Emerson
- C
____________________________________________________________
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