Aaron Schrab <aaron+procmail(_at_)schrab(_dot_)com> writes:
At 10:04 -0500 13 Oct 1999, "David W. Tamkin" <dattier(_at_)Mcs(_dot_)Net>
wrote:
No, that is a bad thing, and I'm sure that after I explain, you won't want it
any more. The way ~/.forward works is wrong. Very likely there is a better
isn't working [because mail will just bounce back to him/her]. You can fix
the forwarding (or turn it off until the destination address is accepting
mail again), but with the bounces going back to the original senders you
don't find out; you just wonder why nobody is writing to you any more.
Well, if the envelope sender is changed to the account with the
.forward, then the bounce will probably bounce as well and nobody will
know that there was a problem. I've even seen situations similar to
this cause bounce loops (very ugly).
Any system that sends a bounce message in response to a bounce message
that was sent with the null return-path is completely broken, violates
several RFCs and cannot be trusted with _any_ e-mail in my book.
Bouncing it to postmaster is reasonable, but extra care must be taken
to handle the case of _that_ bouncing.
So anyway, the question is what should be done when a .forward file is
forwarding to a bad address. Should be bounce go back to the original
sender -- someone who can do nothing about it -- to the forwarded address
-- a mailbox that is probably not checked -- or somewhere else? I would
argue that bounces for .forward files should go to the local postmaster as
that's the only address that is a) likely to be checked and b) likely to
be able to do anything about it. Hmm, maybe I'll hack that into sendmail.
If nothing else, the MTA should update the ESMTP ORCPT, if it isn't
already set, to point to the address being forwarded. Then the bounce
message will at least have a chance of making sense to whomever gets it.
I've looked at hacking sendmail to add an ORCPT to all addresses that
don't already have one when they are forward through aliases without
owner- variants, but I can't find the right place in the call-chain
inside sendmail to do this?
However, if the forwarding site doesn't change the sender at least
someone should find out about the problem, and the person doing the
forwarding can find problems by sending mail to {him,her}self.
How is the person doing the forwarding ever going to know something
is wrong? If the bounce is due to overly strict SPAM filters, for
instance, they may never have reason to suspect.
Now, this isn't as big of a concern when doing conditional forwarding
with procmail, since conditions can be put in to work around the
problems that I stated.
Bingo. Each recipe that forwards a message should decide how bounces
should be handled and be written to direct them correctly.
As for how to preserve the envelope sender when forwarding with
procmail, here's an example:
:0
* ^^From \/[^ ]+
! -f "$MATCH" address(_at_)other(_dot_)domain
This breaks if the original sender address contains a space. If your
sendmail adds a Return-Path: header then the following is to be prefered:
:0
* ^Return-Path:\/.*
! -f "$MATCH" address(_at_)other(_dot_)domain
But *THINK*, dammit, before blindly using that recipe.
Philip Guenther