At 16:55 2001-01-25 +0900, kevin(_at_)interq(_dot_)or(_dot_)jp wrote:
What can happen is the remote host's mailbox gets full, too, and then with
header additions, each successive mail gets larger and larger and
eventually, a postmaster has to do manual queue deletions of messages that
started out being 3-4KB and end up growing to over 1MB each.
That sounds remarkably like a mail loop - not to mention a real waste of
bandwidth.
Search the procmail list archives and FAQs for "X-Loop:" for _related_
documentation. I say related, because since bounces are postmaster
messages, what you really want to home in on are ^FROM_MAILER messages -
messages from a postmaster type account (most forwarding X-Loop rules check
for that as well). Check for that and probably the body the address you're
forwarding to or something like that.
Basically, if you're bouncing on a message which you've forwarded, there is
little to be gained from forwarding that again, OR of storing the bounce
itself. If the local account hasn't already gone over quota, then you
should have the original UNBOUNCED message which was stored, so the user
isn't LOSING anything by you not storing the bounce itself. If the local
account was already over quota, then it isn't as if trying to add the
bounced message is going to work.
5. forward to remote address is bounced because either the forward
address' mailbox is full or the address is blocked
Uh, the user may be blocking their OWN mail? Duh...
Or is this forwarding to various other accounts, not just to the user?
6. bounce due to full mailbox or bad address comes back and we repeat
steps 1-6
I understand bouncing on full mailbox, but within your own ruleset, there
shouldn't be an issue with bouncing from a bad address. If there is, fix
things - and if it is intermittent, tell the user that until they switch to
a more reliable ISP at the far end that you won't allow forwarding.
How can we craft a much more intelligent forward recipe such that this
endless bouncing doesn't happen more than 3-4 times? I say 3-4 times
If it is a blanket forward, then you could do it at the MTA level - via a
sendmail alias for instance. Then delivery bounces would go to the
original sender. Of course, that may not be desireable (if the forwarded
address is supposed to be secret), since the bounces will reveal the
forwarded address.
because there's a chance that the problem might fix itself with the user
getting a clue and downloading both their local and remote mailboxes.
Somewhat unlikely in a very short span of time on today's networks - the
bounces all happen very quickly (unless their mail server is down and you
end up delivering to a backup MX, which eventually passes it off to their
mail server which THEN bounces it - if this is occurring on a regular
basis, see the solution offered above for bad addresses).
a certain limit? Something like, if you see "X-Forwarded-To: <address>",
The very idea behind "X-Loop: thisaddress" -- procmail would check for that
BEFORE forwarding. If it sees that, it says "gee, *I* added that, so we're
in a loop condition - I shouldn't forward this again". If it doesn't see
it, then the message is new, and can be handled normally - which includes
adding the header (via a filter rule through formail), then copying it to
the local mailbox and forwarding it.
HOWEVER, bounces from postmasters won't retain the headers you add --
X-Loop, X-forwarded, X-bounce-count, whatever. Those *MAY* (depending on
the MTA that is doing the bouncing) be included in the bounced BODY, but
you shouldn't expect them to be (some bounces are abbreviated, wheras
others include the entire original message - mutli-megabyte attachments and
all).
If you take FROM_MAILER messages:
:0
* ^FROM_MAILER
{
Then check the body (you'll need to compare against the actual bounces
you're getting from the other server) for addresses and bounce codes:
:0
* B ^550(_dot_)*username(_at_)domain\(_dot_)tld
/dev/nul
(or similar - add as many of these as is necessary for the variants you
might expect to deal with)
then close the brace:
}
So, that leaves us with something basically like:
:0
* ^FROM_MAILER
{
# no mailbox, or typical mail refusal
:0
* B ^550.*forwardedusername
/dev/nul
# Mailbox full
:0
* B ^552.*forwardedusername
/dev/nul
# .. etc.
}
Note that there are some morons out there using "Postmaster" and
"Administrator", etc accounts as their regular mail ("whoo-hoo, I've got a
domain, and I'm da postmaster!"), and these idiots will have their mail
nabbed by simple ^FROM_MAILER checks (though the further checks for bounce
codes should protect you from ditching these people's mail outright).
Also note that if the bounces include the hostname portion of the email
address you really do want to include that in the forwardedusername spec,
but some so-called "isps" (AOL among them), send bounces with just the
local portion of the username (sans FQDN) in the result line. You'll need
to write your rules accordingly (OTOH, chances are you're not going to get
a lot of bounces for a user with the same username portion who ISN'T your
forwarduser).
I really abhor the SMTP agents which do not bounce with result codes on the
SAME line as the complete address (and some that don't even include the
address in the bounce) - MS mailers and other cheezy mail solutions are
prone to returning addresses on separate lines from their result
codes. With any luck, you won't be dealing with that, but you should check
to make sure.
If your host supports plussed addresses (or you can set up an alias for the
account, which might be nominally better because of iffy support for
plussed addressing by other MTAs), you might instead try changing the
address which you deliver the forwarded message from to point to a plussed
version of the sending address -- and then you could have a rule which
checks for messages coming to the plussed address (which should only be
bounces) and simply trashbin them:
# something addressed to our forward bounce address.
:0
* ^TO_ourplussedbounceaddr
/dev/nul
After your edited version of either or both of the above recipes, one would
then conduct normal rules as you have them, excepting that if you use the
plussed bounce, you should replace simple forwards with something which
will make the message be delivered FROM that address (so that bounces will
go to it):
:0
* ^somecondition
| sendmail -fourplussedbounceaddr forwardaddr
You might instead filter it through formail to add a sender: field with the
plussed address:
:0
* ^somecondition
| formail -I "Sender: ourplussedbounceaddr" | sendmail
-fourplussedbounceaddr forwardaddr
It isn't a simple problem to solve, not with the various nonstandard MTAs
out there.
Disclaimer: recipes are untested and are intended merely to convey the
basic principles, not offer forth a complete solution (this is your
problem, not mine, unless you want to pay contract rate).
---
Please DO NOT carbon me on list replies. I'll get my copy from the list.
Sean B. Straw / Professional Software Engineering
Post Box 2395 / San Rafael, CA 94912-2395
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail