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