The problem I see with the harvesting issue is that it is very easy to lose
sight of the objective and end up rejecting viable anti-spam measures in
persuit of what is at best a palliative.
I don't want to have to keep my email address secret. Nor is it practical
for me to attempt to do so, my address can be harvested very easily from
mailing list archives (including this one).
Preventing dictionary attacks against a mail server is probably only
worthwhile for the purpose of avoiding the cost of dealing with the
immediate attack. If you can detect the dicitionary attack effectively you
can also detect the spam.
If we were going to redesign the email system ALL connections would be
authenticated and the ONLY transaction supported would be 'deliver email'.
SMTP is like FTP a very conversational protocol. It comes from the days when
people thought of Internet protocols in a very different way, as a human log
in to a different machine, rather than as transferring data between
machines. The design innovation of HTTP was to eliminate the inefficient and
unnecessary multiple round trips imposed by FTP and fetch data with a sinple
request/response protocol.
There is actually a rationale for a multiple round trip protocol for email.
Legitimate parties do not want to send a long message body that is going to
be junked. The rest of SMTP is simply noise. Why for example do we give the
adressees of the email twice, first in the SMTP protocol, then again in the
RFC822 message? Why does it take a separate round trip to validate each
individual recipient?
A more logical email protocol would have only two phases, in the first phase
the servers would perform mutual authentication and the sender would pass
the message header. The recpient would then respond OK to send, Not OK, etc.
It is possible that a message would succeed for some recipients but not for
others, the mail server might respond that an address was permanently
forwarded. This is pretty much like what SMTP does today, except that the
protocol would be a single request followed by a single response to get all
the negotiation done at once.
The second phase would be transfer of the message body itself. After that
shut down the TCP connection and go home. Given the probablility of very
large message sizes in the future it might even be reasonable to add in some
form of support for incremental message transfer, so that retry on failure
becomes possible.
Now consider the delta between an idealized mail protocol and what we have.
I don't see how the delta is big enough to get excited about. SMTP is
distinctly sub optimal, it is somewhat unreliable, but the main source of
unreliability these days is mail filtering. Protocol and mail server errors
are much rarer.
I cannot see the delta as being big enough to merit the cost of a
transition.
As for the push/pull issue. A pull protocol would presumably break the
protocol into two so that after the initial first phase the TCP connection
would shut down and the recipient would attempt to re-establish the
connection in reverse to obtain the message body. It is not possible to make
the first phase a pull protocol. Email is by its nature initiated by the
sender, not the receiver. We could imagine a 'subscription' first phase
which would cause the recipient to regularly poll for updates.
I do not see how that design is at all practical. The reliability would be
abysmal. Any TCP issue when setting up the TCP connection for the second
phase would result in the mail being lost. The sender would have to be much
more complex in order to track whether the body had been retreived or not.
All the 'pull' phase does is to perform a lightweight authentication of the
TCP connection. If that is what we want to achieve there are cheaper and
more reliable ways to achieve the same result, LMAP for example.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg