Yakov Shafranovich writ:
Please understand that I am not against using the envelope from, but the
fact that its meant for something else needs to be stated. If my consent
is required in order to use my address as a bounce address, that's a
useful addition for the mail system. But if we want to do that, AND pass
authentication information on the original sender, that's two different
purposes.
The MAIL FROM argument is a sender identifier. I don't believe that the RFC
is in any way ambiguous on this point.
In my understanding the RFC appears to be ambigious since it does state
that the sender's address is only used for error reporting.
<quote>
the source mailbox (between "<" and ">"
brackets), which can be used to report errors
</quote>
That's "can".
My
understanding of the RFC that its only meant for error reporting is
based on a conversation with Pete Resnick who edited it.
I appreciate that you may have extra knowledge, but unfortunately, the rest
of us have only got the RFCs / standards to go on. If you think it would be
useful to clarify the intention of the published specs then you should go
ahead :-)
Additionally, the analogy on which its based is the real world postal
system where the sender's address on the envelope indicates the return
address but not necessarily the person that send it.
And yet we call it "sender" - but that's just an analogy.
Also, RFC 2554 defines an additional parameter in MAIL FROM:
"5. The AUTH parameter to the MAIL FROM command
AUTH=addr-spec
Arguments:
An addr-spec containing the identity which submitted the message
to the delivery system, or the two character sequence "<>"
indicating such an identity is unknown or insufficiently
authenticated.
"
Apparently the MAIL FROM command was not sufficient for this purpose
since it indicates the bounce address. This parameter was added in order
to pass authentication information.
No, not really. This parameter provides for passing on the "authenticated
identity". i.e. not information that a subsequent agent will use to
authenticate, but rather the identity that this agent has *already*
authenticated.
This might be a suitable way of passing on an authenticated sender
identifier, but it doesn't seem to be intended for carrying an
unauthenticated identifier. That *would* be overloading.
Yakov
P.S. The description from RFC 2554 eerily reminds me of some of the text
describing LMAP.
Neccessarily, I guess. It's a similar problem. LMAP via an extension
certainly seems "cleaner" and avoids arguments about MAIL FROM
"overloading" - but use of the MAIL arg has a lower deployment hurdle.
An realistic position would be to acknowledge MAIL as useable, but perhaps
recommend transition to an extension.
Of course a lot of this hangs on the fuzzy definition of a sender.
If I inject a message to the MTS, I'm the sender... but if the messages
passes through a forwarder / exploder, am I the sender of the message
received at the far end? The message can have the same body,
but will have a new envelope. For me, the entity that constructed the
envelope is the sender. This is why I don't have a problem with some
requrement for a forwarder to supply a new sender address. I think this is
a clarification. Others differ.
Regards,
JK
--