Jimmy Hess wrote the following on 3/26/2014 7:12 PM:
The problem is with SMTP and is probably best addressed in the
application layer through updates to SMTP or required bolt-ons
(e.g SPF or similar); it was just simpler
SPF is useful, but not a complete solution.
I'm curious what form you think these updates to SMTP would take?
What changes to SMTP protocol itself could really have a meaningful
impact,
without frustrating, confusing, or terribly complicating the lives of
millions of mail users?
The primary issues I see with SMTP as a protocol related to the lack of
authentication and authorization. Take, for instance, the fact that the
SMTP protocol requires a mail from: and rcpt to: address (more or less
for authentication and authorization purposes), but then in the message
allows the sender to specify a completely different set of sender and
recipient information that gets displayed in the mail client.
SMTP is simple, it is reliable, and it works well for delivering a
message, but it does not address authentication or authorization of
remote users (to my knowledge). An extension to SMTP that provides some
form of authentication and authorization for remote users could address
the abuse concerns. For example, one could utilize a public key
infrastructure through previously shared vcard or similar contact
information to both authenticate and authorize a sender to be allowed to
send email to a recipient. There are probably a few ways to accomplish
the same goal, a PKI is just one example. This would allow one to
configure his or her email as either 'default allow' to receive email
from anyone at any time or 'default deny' to only allow authorized
senders. There are some folks doing this today outside of SMTP, but
without a mass effort these schemes will probably not take a strong
foothold.
Implementing something like this takes some work in the mail client to
be able to generate a private key and hold the public key info of
others. Realistically, the key information could be exchanged and
verified simply between clients at the remote ends without any SMTP
server involvement, but that seems like a waste for servers to process
and store messages that are going to be junked in the end that it would
make sense that the SMTP servers could also be able to make these
decisions server side. On the other hand, putting spam filtering in the
hands of the end users could really untie the server operators from
costly or cumbersome anti-SPAM efforts.
Any open source email clients want to take this task on and build an
industry consensus? I'm all for having my emails tagged as
trusted/authorized or untrusted/unauthorized in my email client. Once
the level of untrusted, yet legitimate, messages drops to a low enough
level I can stop accepting untrusted messages altogether.
--Blake
