At 14:57 2003-04-15 -0700, Derrick Bass wrote:
I have the classic "two accounts" situation described in the procmailex
man page. So I have the following rule (from the procmailex page)
.procmailrc on both accounts:
I'm not so sure there are many people using the "classic" situation. I
don't know how you retrieve email from your accounts, but it may make a
*LOT* more sense to set either account up with a FETCHMAIL setup and
RETRIEVE the messages, thus generally avoiding delivery bounces altogether.
Now one day, one of the accounts broke in such a way that the mail
receiving computer thought my account did not exist.
Bummer that.
duplicates of all email on both accounts. It has been suggested to me that
it is a bad idea to ever forward mail from daemons. Maybe so,
Is so.
but it is important to me that the two accounts end up with, as far as is
possible, the same email, including that from daemons.
I think it is also important that the two accounts be properly configured
as well...
Is there a simple way to handle this that will not stop legitimate,
non-loopy, daemon email from being forwarded?
Daemon messages come in all forms - some return the headers of the bounced
message, others return the headers and body, and some don't provide much of
anything at all. They come from postmaster, mailer-daemon, less often from
some nonstandard "mdaemon" or some antivirus alias (sometimes without a
domain qualifier, which will usually result in your MTA inserting the local
domain).
From: Mail Delivery Subsystem <MAILER-DAEMON(_at_)its(_dot_)caltech(_dot_)edu>
:0:
* ^FROM_MAILER
* B ?? ^X-Loop: derrick(_at_)caltech(_dot_)edu
/local/bounce/file
You might even supplement the above (or replace the ^FROM_MAILER condition)
with:
* ^From:.*MAILER-DAEMON@([-_.a-z0-9]+\.)caltech\.edu
But this would only catch bounces which occurred at the SMTP transaction
between your sending host and the final destination host -- if a message is
passed to a backup MX, that host will not necessarily know that the user
account does or does not exist (although it may fail the message for a
variety of reasons anyway - such as "we do not relay", etc). At the point
which the message is relayed from the backup MX to the final MX, THEN the
user unknown bounce would be generated - but it won't be From: caltech.edu...
You could also attempt to deal with the mailer-daemon loop by setting the
envelope sender to a different address such as a plussed version of your
own (if supported), which you'd use to check for the bounced forward
condition. In place of your sendmail invocation:
| $SENDMAIL forwardaddress -f youraddr+bounce(_at_)caltech(_dot_)edu
and as a condition of forwarding:
* ! ^TO_youraddr\+bounce(_at_)caltech\(_dot_)edu
could work - messages to your bounce address (which you should use ONLY for
the forwarding process), would not be reforwarded.
Date: Thu Nov 21, 2002 2:37:44 AM America/Los_Angeles
It seems that some MTAs apparently use totally nonstandard Date: lines as well.
---
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(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail