In <404EA88F(_dot_)4080403(_at_)solidmatrix(_dot_)com> Yakov Shafranovich
The one major objection I had to what was said in the LMAP document
is all the vague references to "changing semantics". I don't see
how any of the LMAP proposals seriously change any semantics, and
this phrase seems to have been latched onto and blown out of
proportion by various people.
I believe that your refering to the following quotes:
I suggested to add those comments originally based on something Pete
Resnick brought up. In particular, I am basing this on section 4.4 of
" The primary purpose of the Return-path is to designate the address to
which messages indicating non-delivery or other mail system failures
are to be sent.
I still don't see a change in semantics of the return-path. The
primary purpose remains as the location to send DSNs.
In addition, as Hector Santos recently pointed out on the SPF-discuss
mailing list, section 3.3 of RFC is quite relevant:
3.3 Mail Transactions
The first step in the procedure is the MAIL command.
MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
[...] The <reverse-path> portion of the first or
only argument contains the source mailbox (between "<" and ">"
brackets), which can be used to report errors (see section 4.2 for a
discussion of error reporting). If accepted, the SMTP server returns
a 250 OK reply. If the mailbox specification is not acceptable for
some reason, the server MUST return a reply indicating whether the
failure is permanent (i.e., will occur again if the client tries to
send the same address again) or temporary (i.e., the address might be
accepted if the client tries again later). Despite the apparent
scope of this requirement, there are circumstances in which the
acceptability of the reverse-path may not be determined until one or
more forward-paths (in RCPT commands) can be examined. In those
cases, the server MAY reasonably accept the reverse-path (with a 250
reply) and then report problems after the forward-paths are received
and examined. Normally, failures produce 550 or 553 replies.
This is quite clear that the reverse-path can be validated and
rejected if the receiving MTA doesn't like it.
Validating the envelope-from via callbacks has been around for years
and has been used by a non-trivial number of MTAs.
Again, any "changed semantics" is both minor and irrelevant.