At 16:41 -0500 13 Oct 1999, Philip Guenther <guenther(_at_)gac(_dot_)edu> wrote:
Aaron Schrab <aaron+procmail(_at_)schrab(_dot_)com> writes:
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.
Nothing was doing that in the situation I was talking about. Here's what
happened:
1) Bounce goes to the forwarding address and is accepted.
2) The forwarding site then forwards the message, using the forwarding
address as the envelope sender rather than <>.
3) Bounce gets to the site that had hosted the real mailbox, and is
accpted by one of the MX hosts (which don't have a list of users).
The message is then sent on to the internal mail server which
responds "550 User unknown". The MX host can't just return an error
and has no way to know that the message it was trying to send was a
bounce, so a new bounce is generated.
4) Back to step 1. (infinite loop)
The only problem here is that the envelope sender was set to the
forwarding address.
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.
Yes, that sounds like the best address to use.
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?
That would definitely be nice. I'll try to look into doing that myself.
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.
That was more of a minor point. My main point there was that *someone*
will get the bounce message even though that person may not be able to
do anything about it. When I send a message, I'd like to know if it
couldn't be delivered; even if I can't do anything about the problem.
--
Aaron Schrab aaron(_at_)schrab(_dot_)com http://www.execpc.com/~aarons/
Profanity is the one language all programmers know best.