Bruce Lilly wrote:
The guiding principle is (or at least should be) that the
transport return mailbox (SMTP MAIL FROM or equivalent)
should point to a means of contacting a person who can do
something, or who at least might be presumed to care about,
transport problems.
So far that's "bounces to", but not necessarily "return path".
I think you're getting hung up on old terminology in 821
True, the same attitude as with "References" or "TLD .invalid",
where I tend to interpret these terms literally. That's not
always a good idea, and in the case of "References" it fails,
but at least it's interesting.
that happens not to match the intended original use (prior
to DSNs) for delivery trouble notifications.
IBTD. The original use of a "Return-Path" was a reverse path,
the same path backwards. If I'm a member of organization A,
with a mailbox me(_at_)A, and use the infrastructure of A to send
mail to a user(_at_)B, then it's a "mail from me(_at_)A".
If I also have another mailbox me(_at_)C, then I still must not say
"mail from me(_at_)C" in a mail set via the smart host of A. Even
if that could help to solve problems more quickly, e.g. if I'd
check the me(_at_)C mailbox more often.
With the "bounces to" concept it would be okay to use me(_at_)C as
the originator of a mail sent via A. But that's a triangle,
and not a "return path":
user(_at_)B
/ \
/ \
me(_at_)A me(_at_)C
Adding a 3rd party C generally does not help to find and fix
problems between A and B. C has nothing to do with this issue,
and in the worst case C has its own problems. The "bounces to"
concept is not good enough.
Bye, Frank