Frank Ellermann wrote:
Hector Santos wrote:
This changes CODE!!! My code!!
Pardon ? Users of a server using your code certainly expect that
there is precisely one Return-Path, reflecting the MAIL FROM as
seen by the final delivery MTA.
No. Users historically and generally did not have that expectation, and
no MUA, including our own mail readers has that expectation.
Return-Path: is a network level consideration.
Your consideration now has to do with the growing need to supply
off-line RFC based systems a greater say in EMAIL authentication concepts.
This is not a SMTP issue and should remain out of scope. If a SMTP
system wants to implement logic to keep the final MTA return-path, that
is an implementation specific consideration.
Since it is NOT common practice to maintain the return-path for MDAs
(for local recipient) your call for this change will CHANGE code.
I'd bet that your code already does this, or do you keep crappy
Return-Paths inserted by prior hops in the header ?
No, and its none of my business what prior routing transactions took
place. I still adhere to the old age principle of "Thou shall not
tamper with mail."
> What would
users do with that, where "user" can be anything from a stupid
vacation script and other auto-responders up to gateways.
Thats outside the scope of SMTP. What you are basically implying is that
all SMTP systems must implement 3834. Thats changing code.
What does this have to to with SMTP?
SMTP specifies who, when. what, and how for the Return-Path. In
RFC 2822 you also find that there's at most one Return-Path, not
more.
That still does not say I have to store one, nor does it say I have to
massage the mail to clean it up. Thats changing code.
If RFC 3834 requires it, thats fine. But you don't need 3834
to create bounces.
It's needed to create other auto-responses:
| If the response is to be generated after delivery, and there is no
| Return-Path field in the subject message, there is an implementation
| or configuration error in the SMTP server that delivered the message
| or gatewayed the message outside of SMTP. A Personal or Group
| responder SHOULD NOT deliver a response to any address other than
| that in the Return-Path field, even if the Return-Path field is
| missing. It is better to fix the problem with the mail delivery
| system than to rely on heuristics to guess the appropriate
| destination of the response. Such heuristics have been known to
| cause problems in the past.
That's all fine Frank, but you don't need 3834 to accomplish auto-responses.
But lets be clear, its a non-delivery auto-response A.K.A bounce, the
return-path is required independently of 3834.
3834 is more about a STYLE of the message - not really what is already a
requirement regarding the Return-Path.
Are we trying to nail that the MAIL FROM = reverse path = envelope
sender = return path = "bounces to" <shudder /> is "the real thing"
everywhere, or do we need to discuss this emulation known as "PRA" ?
Well, we can get lost in that debate. But what really interest me, is
this, why is this being considered when this OBVIOUSLY it is something
that changes functionality and hence code?
I'll tell you what, you give your VOTE for the reply code issues and
I'll give you my vote for return-paths in local final destination? :-)
Jokes to the side, this changes code. I think the compromise in what we
both want is this:
- its a valid format,
- its verifiable, and
- its ideally verifiable at the time it is presented, not
in some belated future date and time and space.
Its a chicken and egg thing Frank. If you can't solidify the strong
requirement for a valid return path, then any of the other EMAIL
authentication considerations become a moot point.
Any HELO/EHLO domain validation idea is based on the idea that it is
valid at the moment it is provided.
Similarly, CBV and SPF is based on the idea that the return-path
address and domain respectively, are valid at the moment it is provided.
Any MAIL content based technology will suffer in adoption if its
MANDATED to be performed at the POST SMTP level only. If applicable, it
is already a proven concept that it best to do this at the DATA level.
But all this is really implementation specific and should be out of scope.
The only thing developers can hope for is that SMTP provides the
endorsed framework that is already possible for new advances to continue.
--
HLS