In article <20180209202621.31355.qm...@f3-external.bushwire.net>, Mark Delany <sx6un-fc...@qmda.emu.st> wrote:
Oh I dunno. The precedent of RFC822 - the very standard we rely on - has survived numerous upgraded and enhancements over a 36 year period and managed to do just fine without a version.
RFC 822 may not have versions but 821/2821/5321 sure do. As soon as 2821 added EHLO, SMTP got service extensions and pretty much by their nature, those extensions are not backward compatible. Well-known examples are 8BITMIME and SMTPUTF8. If you have a message that needs one of those and the server you're trying to send it to doesn't support the extension, you lose, the message bounces. (A sending host might try to rewrite MIME bodies to avoid 8BITMIME but it's a long time since I've seen anyone try that, and it'd break DKIM signatures, so it probably wouldn't help.) Nonetheless, we seem to have survived. The DKIM v=2 hack I proposed is a lot like SMTP extensions in that if your signature doesn't need the new semantics, don't ask for them, so you should sign with v=1, so the old and new will coexist forever. Since they can easily be handled by the same signing and verifying libraries, that's not a problem. -- Regards, John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
