The MAIL FROM parameter does not tell us where the mail is from, only
the bounce address for that email. The assumption is that whoever is the
bounce address is, is probably the sender, but in many cases especially
mailing lists, that is not true. As a matter of fact in some protocols
such as SMTP AUTH, the sender's identity is passed in an SMTP extension
separate from the bounce address.
The only other problem I have with the idea of overloading, then, is support
of non-ESMTP clients and servers. The ESMTP extension proposed has a
prerequisite of ESMTP, and there are still many upgradable traditional SMTP
systems in use.
All the *ix crowd can jeer if they want, but I'm interested in seeing
ancient things like EMWAC IMS supporting a LMAP-type system. The venerable
IMS is still supported by a grassroots movement who've gone and rewritten
components of IMS to modernize it. To keep the project lightweight I think
they'd rather not have to parse ESMTP.
Requiring ESMTP of a verification system but still requiring to support
non-ESMTP also leaves a hole big enough for a spam truck to drive through.
Spammers could just revert to traditional SMTP to avoid this particular
ESMTP extension, and (unless the server overloads an existing SMTP command)
the ESMTP server still has to accept mail from the non-ESMTP client by ESMTP
defenition. (RFC 2821 2.2.1 to start with). Aren't most virus SMTP engines
using traditional SMTP rather than ESMTP to keep the code small?
<<attachment: winmail.dat>>