Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

["John R. Levine" <[e-mail]>]

In article <[e-mail]>,
Mark Delany <[e-mail]> 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, [e-mail], 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