Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
Sorry. Where is the version number for SMTP? MAIL FROM:<Борис@пример.ru> SMTPUTF8<-- These are not 'version' flags. They are feature indicators. They're both. If you use the feature, you're using the new version of the message. R's, John___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
On 2/9/2018 2:31 PM, John R. Levine wrote: In article <20180209202621.31355.qm...@f3-external.bushwire.net>, Mark Delany 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. Sorry. Where is the version number for SMTP? Which is to day, thanks for demonstrating my point: the 'version' flag is implicit with the features that are added. If they are present, you have the 'newer' version. These are not 'version' flags. They are feature indicators. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
On Fri 09/Feb/2018 23:31:41 +0100 John R. Levine wrote: > > 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. Assuming that that hack would have been way more befitting than any other idea discussed on dmarc-ietf ever since, one may wonder how much of its fading away was due to its version bumping instead of, say, introducing a new header field. Ale ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
On 09Feb18, John R. Levine allegedly wrote: > 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. I'm not sure whether this an argument for or against versioning. Or an argument that sometimes bad engineering choices are made regardless of the upgrade mechanism. In any event, 822 is an existence-proof that decades-long upgrades are entirely possible without the scorched-earth approach of versioning. I hope it would take a very strong argument to suggest that we shouldn't (or can't) follow the 822 strategy. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
In article <20180209202621.31355.qm...@f3-external.bushwire.net>, Mark Delany 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
Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
On 2/9/2018 12:26 PM, Mark Delany wrote: On 08Feb18, Michael Thomas allegedly wrote: I dunno, it's not like there isn't precedent for this. oh say, like ipv4 vs. ipv6? 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. and SMTP... I might add that RFC822 seems to have adapted a lot better than the v4 vs v6 crowd. Not sure you picked the best example of success there, Michael :-) What's rather impressive is how aggressively the general Internet technically has worked to avoid learning any lessons from this disparity... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
On 08Feb18, Michael Thomas allegedly wrote: > I dunno, it's not like there isn't precedent for this. oh say, like ipv4 > vs. ipv6? 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. I might add that RFC822 seems to have adapted a lot better than the v4 vs v6 crowd. Not sure you picked the best example of success there, Michael :-) > Besides if you wanted to go from DKIM to EKIM, you'd be opening > pandora's box imo. Indeed. As mentioned previously MIME-Version: 1.0 has set the standard for us to emulate. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
On 2/8/18 4:45 PM, Dave Crocker wrote: On 2/8/2018 4:42 PM, Michael Thomas wrote: Besides if you wanted to go from DKIM to EKIM, you'd be opening pandora's box imo. The pandora's box is creating an incompatible new version. All the rest is just engineering and operations tradeoffs. Thankfully nobody's seriously talking about that from what i can tell, so this strikes me as so many angels on a pinhead. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
On 2/8/2018 4:42 PM, Michael Thomas wrote: Besides if you wanted to go from DKIM to EKIM, you'd be opening pandora's box imo. The pandora's box is creating an incompatible new version. All the rest is just engineering and operations tradeoffs. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
On 2/8/18 12:32 PM, Mark Delany wrote: I think this is the biggest flaw with the whole v= rationale. There is never going to be a v=2 change that doesn't leave everyone continuing to generate/validate a v=1 header. Is a new header by stealth better engineering than formalizing a new header? I dunno, it's not like there isn't precedent for this. oh say, like ipv4 vs. ipv6? Besides if you wanted to go from DKIM to EKIM, you'd be opening pandora's box imo. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
In article <20180208203207.26575.qm...@f3-external.bushwire.net> you write: >After all, what are most senders going to do? They will not want their >signatures to be suddenly unrecognized by 99% of the planet so they'll continue >to generate a v=1 header and they will also want to reap the bennies of your >fantastic SpamAssassin feature so they'll additionally generate a v=2 header. In my application, the feature that requires v=2 is double signing, i.e. this signature is valid only if there's also a signature from X. It was intended as a workaround for the DMARC mailing list problem The idea is that in addition to your regular v=1 signature, you'd also put a weak v=2 signature that requires re-signing by the mailing list. If you don't use conditional signing (or something else subsequently added that depends on v=2 semantics), then v=1 signatures are fine forever. The reason to make then both DKIM-Signature headers is that there is code, some of which I've written, that looks for DKIM-Signature headers in a message and calls a DKIM verifier library if it sees them. DKIM is slow, do you don't want to waste time verifying messages with nothing to verify. If you don't change the DKIM-Signature header, all of this code keeps working when you upgrade your DKIM library. If you invent a new header, it doesn't. >The end result is two DKIM-Signature headers with different versions for >decades >to come. This will no doubt tweak some receiver is a negative way. Only if their validators are broken. I realize that's likely to be the case now and then but I can't feel too sorry for them. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
> True, but not very interesting. In my spamassassin example, the outside > code knows nothing about DKIM versions, it just sees a dkim-signature > header and sends it to the DKIM library. > > The point of a v=2 flag is to ensure that old v=1 code doesn't As a practical matter haven't you effectively invented a new header? After all, what are most senders going to do? They will not want their signatures to be suddenly unrecognized by 99% of the planet so they'll continue to generate a v=1 header and they will also want to reap the bennies of your fantastic SpamAssassin feature so they'll additionally generate a v=2 header. The end result is two DKIM-Signature headers with different versions for decades to come. This will no doubt tweak some receiver is a negative way. I think this is the biggest flaw with the whole v= rationale. There is never going to be a v=2 change that doesn't leave everyone continuing to generate/validate a v=1 header. Is a new header by stealth better engineering than formalizing a new header? Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
True, but not very interesting. In my spamassassin example, the outside code knows nothing about DKIM versions, it just sees a dkim-signature header and sends it to the DKIM library. Oh. So v= doesn't dispatch to different code. BTW, this topic tends to eventually produce a claim that the fact that the different versions share so much code justifies the versioning mechanism. Except that code sharing happens in many circumstances that don't require conflating incompatible protocols and then using an internal demultiplexing switch. The larger topic is the choice between high-level switching versus low-level, and the long-term costs of transition mechanisms. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
On 2/8/2018 10:03 AM, John R. Levine wrote: The code that knows to dispatch to v=2 can, just as easily, parse for the strings associated with the new features. True, but not very interesting. In my spamassassin example, the outside code knows nothing about DKIM versions, it just sees a dkim-signature header and sends it to the DKIM library. Oh. So v= doesn't dispatch to different code. The point of a v=2 flag is to ensure that old v=1 code doesn't accidentally misinterpret new features. "Accidentally misinterpret new features" seems to be synonymous with not being upward compatible. In other words, the new features make the new version incompatible with the old. Hence, the new features define a new protocol. In my example, I made a semantic change: in v=1 DKIM, verifiers ignore tags they don't understand. In v=2, there's a new tag type that fails if a verifier can't handle it. Change to basic semantics of the protocol. Hence, new protocol. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
The code that knows to dispatch to v=2 can, just as easily, parse for the strings associated with the new features. True, but not very interesting. In my spamassassin example, the outside code knows nothing about DKIM versions, it just sees a dkim-signature header and sends it to the DKIM library. The point of a v=2 flag is to ensure that old v=1 code doesn't accidentally misinterpret new features. In my example, I made a semantic change: in v=1 DKIM, verifiers ignore tags they don't understand. In v=2, there's a new tag type that fails if a verifier can't handle it. The new tags have new syntax that, in an ideal world, would make v=1 verifiers fail with a syntax error, but we all know that parse errors are often not well debugged. I did look at a bunch of DKIM libraries and they all check for v=1 and fail if they don't find it. 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
Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
On 2/8/2018 9:45 AM, John R. Levine wrote: Huh? v=1 code doesn't know what the new features would be. Re-read what I wrote. The code that knows to dispatch to v=2 can, just as easily, parse for the strings associated with the new features. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
the DKIM library. If it passes a v=2 signature to a library that only knows about v=1, the library will say it's invalid, which isn't ideal but isn't wrong. the code that tests for the v= parameter could, just as easily, check for the presence of the new features. Huh? v=1 code doesn't know what the new features would be. 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
Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
On 2/8/2018 9:09 AM, John R. Levine wrote: They seek to distinguish important differences in processing for what is claimed to be the /same/ protocol. Except really they don't. Except when they do. I'm thinking, f'rinstance, that there is a bunch of code in things like Spamassassin that looks at headers and switches out to routines to do stuff with them. There is nothing in Spamassassin that needs to care whether a DKIM signature is v=1 or v=2, that's all inside the DKIM library. If it passes a v=2 signature to a library that only knows about v=1, the library will say it's invalid, which isn't ideal but isn't wrong. the code that tests for the v= parameter could, just as easily, check for the presence of the new features. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
On 08Feb18, John R. Levine allegedly wrote: > On Thu, 8 Feb 2018, Mark Delany wrote: > > Heh. I'm still waiting to hear a good reason as to why "v=" exists at all - > > apart > > from exposing brittle parsers which mistakenly expect it to show up as the > > first > > tag. > > I had a draft that invented v=2, for headers with a tag syntax that is not > quite backward compatible with the current spec. I realize that we could > change the header to DKIM-Improved-Signature but the change was small and > it smelled to me like the same header. Yes, one can certainly contrive a situation in which they prefer a v=2 solution, but as you say, the requirement can be just as easily satisfied in a number of other ways too. A new header is one as is the presence of a new tag and v= is a third. There are other ways as well. Given we're talking about standards, it's de rigueur that we end up with at least three competing ways of achieving the same outcome without any guidance whatsoever as to which mechanism to choose when and why. Underlying all this of course is the assumption that programmers intuit the possibility of change inherent in these non-essential mechanisms and code and test accordingly. Now that's a goodun. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
They seek to distinguish important differences in processing for what is claimed to be the /same/ protocol. Except really they don't. Except when they do. I'm thinking, f'rinstance, that there is a bunch of code in things like Spamassassin that looks at headers and switches out to routines to do stuff with them. There is nothing in Spamassassin that needs to care whether a DKIM signature is v=1 or v=2, that's all inside the DKIM library. If it passes a v=2 signature to a library that only knows about v=1, the library will say it's invalid, which isn't ideal but isn't wrong. 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
Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
On 2/8/2018 8:52 AM, John R. Levine wrote: On Thu, 8 Feb 2018, Mark Delany wrote: Heh. I'm still waiting to hear a good reason as to why "v=" exists at all - apart from exposing brittle parsers which mistakenly expect it to show up as the first tag. I had a draft that invented v=2, for headers with a tag syntax that is not quite backward compatible with the current spec. I realize that we could change the header to DKIM-Improved-Signature but the change was small and it smelled to me like the same header. What you realized goes to the heart of the reason we don't need version numbers. The issue falls into the category of how to specify a processing fork. At each protocol layer, there is a mechanism for specifying which processing engine is appropriate for the next layer up. Ethertype, Protocol ID, Port, etc. Version numbers serve that purpose /within/ a protocol layer. They seek to distinguish important differences in processing for what is claimed to be the /same/ protocol. Except really they don't. If modifications to a protocol are upward compatible, the the new features, themselves, self-identify and version numbers aren't needed. If no new features are present, you have the old 'version' of the protocol. If new features are present, you have the new 'version'. If modifications are /not/ upward compatible, you really have a new protocol. Make a new entry in whatever forking mechanism was used to get to the previous version. As you note, a new header-field would be appropriate here. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?
On Thu, 8 Feb 2018, Mark Delany wrote: Heh. I'm still waiting to hear a good reason as to why "v=" exists at all - apart from exposing brittle parsers which mistakenly expect it to show up as the first tag. I had a draft that invented v=2, for headers with a tag syntax that is not quite backward compatible with the current spec. I realize that we could change the header to DKIM-Improved-Signature but the change was small and it smelled to me like the same header. See https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ 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