Aaron Schrab said last Wednesday,
| 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).
That's why I said that one should put in some loop detection at the
forwarding point.
| 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.
Exactly. Mail that already has the loop marker (even in the body) or which
matches ^FROM_DAEMON should stay at the forwarding point and not be sent to
the destination.
| [illustration of such a loop problem]
| The only problem here is that the envelope sender was set to the
| forwarding address.
No, there was an additional problem: no detection implemented for looping
messages or NDNs so as not to forward them.
| 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.
If you can arrange the following, Aaron, more power to you:
If a forwarded message cannot be delivered to its destination, the NDN
should go to the forwarding account (or the postmaster at the forwarding
site) but a note should also be sent to the original sender to the effect
that, "Your message reached the address to which you sent it, but that
address is currently forwarding to another address, and the final desti-
nation could not be reached. Those in control of the forwarding have been
notified."
But until then, there can be only one address in a return path, so the NDN
can be sent to only one place. Wanting to know whether mail that got where
it was addressed also made it the rest of the way wherever it was forwarded
is a little like wanting to know whether mail didn't make it all the way to
the addressee's mind (for example, it was deleted unread or stared at but
ignored); it would be nice for the sender to know that but the current model
doesn't support it.