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/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] DKIM and EAI
If I may once again change the topic for a moment ... https://datatracker.ietf.org/doc/draft-levine-appsarea-eaiauth/ I pushed out a new version that says something about SPF macros, attempting to say that if you try to expand a UTF-8 local part, it doesn't match anything. I figure this is consistent with what would happen if your local part was something like foo..bar which won't match anything either. I would appreciate if people would take a look and see if anything seems obviously wrong. I'm doing some EAI whitepapery things for ICANN and it would be nice if, for a change, the advice they offer matches reality. 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?
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] DKIM and EAI
On Friday, February 09, 2018 05:02:00 PM John R. Levine wrote: > > If I may once again change the topic for a moment ... > > > > https://datatracker.ietf.org/doc/draft-levine-appsarea-eaiauth/ > > I pushed out a new version that says something about SPF macros, > attempting to say that if you try to expand a UTF-8 local part, it doesn't > match anything. I figure this is consistent with what would happen if > your local part was something like foo..bar which won't match anything > either. > > I would appreciate if people would take a look and see if anything seems > obviously wrong. I'm doing some EAI whitepapery things for ICANN and it > would be nice if, for a change, the advice they offer matches reality. Thanks. I think that's a reasonable resolution of the SPF macro issue that I raised. Not ideal, in theory, but plenty good enough for the corner case it is. Does this need to update RFC 7208 since there are SPF related MUST requirements? Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM and EAI
In article <1707398.kN3rUcK64s@kitterma-e6430> you write: >Does this need to update RFC 7208 since there are SPF related MUST >requirements? I would think so, also 6376, 7489, 7601 since it updates DKIM, DMARC, and A-R specs. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] DKIM and EAI
On Fri, Feb 9, 2018 at 3:22 PM, John Levine wrote: > In article <1707398.kN3rUcK64s@kitterma-e6430> you write: > >Does this need to update RFC 7208 since there are SPF related MUST > >requirements? > > I would think so, also 6376, 7489, 7601 since it updates DKIM, DMARC, and > A-R specs. > Since 7601bis is now a live DMARC WG document, you might want to make some suggestions over there since 7601 will be obsoleted. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
