[saag] draft-moore-smtp-addrquery-01 (was: IETF 93 Agenda Request - Key Discovery)

[Keith Moore <[e-mail]>]

> I'm kind of astonished that people still think that extending email
> protocols is a good idea for things like this.  For example:
>
> "BASE64 is used to avoid the need for the server to produce JSON text
> which conforms to SMTP line-length restrictions."
>
> Why, in 2015, would we continue to choose modalities that come with
> these arcane restrictions?

Because there's a huge, worldwide investment in a mail protocol that 
works well, and replacing SMTP would not only be disruptive but also 
have the potential to introduce huge operational difficulties. That's 
not to say that such a replacement should never, ever be considered, but 
that it's not worth replacing SMTP for such a simple change as key 
discovery.

And as others have pointed out, trying to sync between an SMTP server 
and some other key discovery server is fraught with operational peril.   
The idea that interpretation of the local-part of an email address is 
determined solely by the MTA processing that domain's inbound mail is 
not only an explicit part of the email architecture (and has been since 
at least RFC 821), it's also deeply embedded in every SMTP server in 
existence.   (This would likely remain true even if we changed from SMTP 
to some other protocol, as there's too much investment in existing 
address syntax and conventions.)

So extending SMTP appears to make more sense than having a separate 
protocol for discovery of email public keys.   And to maximize 
deployability of this extension it makes sense to design the extension 
in such a way that it can be easily added to existing SMTP servers, 
whether or not they have things like fixed-sized buffers (hopefully 
bounds-checked) for response lines.   BASE64 may seem like overkill as a 
way to do line wrapping, but it's simple, mature, robust, familiar to 
mail system implementors, and already widely implemented in both 
libraries and SMTP servers (e.g. those that do downgrading from 8BITMIME 
mail to 7bit ASCII).

Also, these days I place a high value on designing protocols in such a 
way that it's easy to implement them correctly.   As far as I can tell, 
this aspect of AQRY is hard to botch.

Keith