Seth Goodman wrote:
Return-path: secretary(_at_)example(_dot_)com
From: boss1(_at_)example(_dot_)com, boss2(_at_)example(_dot_)com
Sender: secretary(_at_)example(_dot_)com
This is what I believe the standards say to do, and it's no
different from Bill's case.
They certainly _allow_ to do it this way, I could even find
the precise point where 1123 (or maybe also 821) mumble
something about deriving the envelope addresses from the mail
header. But they don't _guarantee_ it, it's perfectly okay
if secretary@ uses mail-wizard@ in the Return-Path.
It's also okay if secretary posts it as news, where it might
hit a news2mail gateway later (using its own Return-Path).
Or to a mailing list, with Return-Path list-bounces(_at_)(_dot_) Or it's
sent via UUCP / Fido / IM / ... transformed to SMTP-mail much
later on behalf of the receiver, using its own Return-Path.
I'm too lazy to check it again, but AFAIK the Sender should be
the mailbox of a humanoid, the Return-Path could be a mailbot,
and it probably is for list-bounces@
If that's correct (please check it) a Sender: list-bounces@ is
not allowed / dubious.
Calling Bill a gateway is not correct, as user(_at_)church did not
submit a specific message to Bill for relay to another
transport system.
Didn't (s)he ? Then his service might be a mailing list. Who
determined the recipients (To, CC, Bcc) translated into the
corresponding RCPT TO by Bill's service ? If it was Bill it's
like a mailing list, if it was user(_at_)church it's like a gateway.
In the latter case user@ is clearly the Sender, the party who
determined te recipients. For a mailing list it's the known
problem, what should it do if there is already a Sender in the
mail arriving for redistribution ?
If Bill's service is a kind of MSA the Sender is again user@,
but in that case we'd say that the owner of church.example
should add Bill to his sender policy and use his own Return-
Path. But that's clearly not the case, it's too simple. IIRC
somebody in this thread already proposed this MSA-solution.
If Bill wants to offer this solution (pretending to be an MSA
for those of his users who want it) he only needs a simple SPF
policy ready for an include:bills.service in the sender policy
of church.example.
In other words, the whole issue is irrelevant as long as there
is no sender policy for church.example. But when they have a
sender policy Bill could either convince them to include his
policy, or he just uses his own Return-Path (maybe with a SRS
version allowing him to sort and forward later bounces to the
relevant user(_at_)church(_dot_)example).
Many ways to get it right. Playing games with the Sender is
unnecessary. One evil idea I had to avoid all problems with
Sender-ID PRA, add a Resent-Sender: pra(_at_)is(_dot_)invalid
If he were just a gateway, whoever submitted the message to
Bill should be the return-path.
For bidirectional gateways in the times of source routes that
might work. Otherwise I'd say that a gateway is responsible
for all technical problems including bounces. With your idea
it's like an ordinary relay or MSA, see above.
I think we have to accept both roles, as the collection of
citations from standards and proposed standards that we both
produced seemed to use both when describing return-path.
Yes, "responsible to solve any future trouble with this SMTP
transmission" is my concept for this beast. Bounces and abuse
reports, legal enforcement wanting to know who really initiated
the transmission, the whole admin package.
You appear to be arguing that return-path only means
"bounces-to" and not "originator".
No, the "bounces-to" fraction led by Dave, Doug, and others
allows to use a (pseudo-) Return-Path that's _unrelated_ to
the route used for the transmission. Including the known
issue of changing the RCPT TO keeping the old MAIL FROM -
something that in theory never happened before they killed
the source routes in 1123... :-(
I can't buy that, given how many places the standards refer
to return-path in the "originator" context.
Don't worry, finding me as new member of the "bounces to" fans
is unlikely. But your concept of Return-Path is apparently
too narrow for my tastes, where "bounces-to" is too broad.
[unethical]
Better to avoid this kind of statement.
Intentionally conflicting mail experiments with non-voluntary
participants, what adjective do you propose ? Senderid-core
is "only" erroneous or abusive, trying to steal the installed
v=spf1 base for the dubious PRA scheme. But sanctioning this
error / abuse / theft as "experiment", that's no engineering
in my book. They have only one excuse, Meng is the co-author
of both drafts.
Bye, Frank