Re: IPv6 isn't SMTP

[Blake Hudson <blake () ispn net>]

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