Gordon Fecyk wrote:
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.
That is correct. With LMAP you have to change the receiver's MTA
software and the sender's DNS records. With this SMTP extension, you
also have to change the sender's SMTP software. It does impose a higher
burden which might or might not be justified. This might be one of the
things we will end up discussing here.
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?
Even with regular LMAP, spammers that do not publish LMAP records are
essentially doing the same thing, and you have a range of ways to deal
with it.
Yakov