Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work
+1 on adopting On Mon, Dec 10, 2018 at 7:50 AM Kurt Andersen wrote: > Now that the charter update has gone through the necessary processing, I'd > like to ask the WG to adopt John Levine's > https://tools.ietf.org/html/draft-levine-appsarea-eaiauth-05 document as > an official WG item. > > This doc is a normative reference in both the ARC protocol doc and 7601bis. > > --Kurt Andersen > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work
support +1 Jiankang Yao From: Kurt Andersen Date: 2018-12-10 23:50 To: dmarc@ietf.org Subject: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work Now that the charter update has gone through the necessary processing, I'd like to ask the WG to adopt John Levine's https://tools.ietf.org/html/draft-levine-appsarea-eaiauth-05 document as an official WG item. This doc is a normative reference in both the ARC protocol doc and 7601bis. --Kurt Andersen___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work
In article you write: >> AIUI, local parts don't get puny-coded. > >Even when attempting to look them up via the macro mechanism? No, never. There is no way to re-code a UTF-8 local part. Don't even ask. If it sounds like I've had this argument before, I have and I really don't want to have it again. R's, John PS: even if we were to invent some crock like turning UTF-8 into hex, it would not work because there are a vast number of ways to encode strings in UTF-8 that look identical, and there is no plausible way to normalize them all. It's not like ASCII case folding. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work
In article you write: >> what was already implicit; s and l macros will never match if the local >> part of the email address contains non-ascii characters. >> > >Why not? If the non-ASCII (or non-7bit) characters are puny-coded, it seems >like they should be able to match without any problems. No. No, no, no, no. In EAI mail, e-mail address local parts are UTF-8. You cannot translate them into anything else and you very specifically cannot "punycode" them. Using the term punycode in IDNA2003, which is obsolete, was a serious mistake, since it led people to all sorts of bogus conclusions. In IDNA2008 domain names, and only in domain names, there are U-labels which contain a large subset of UTF-8 encoded Unicode, and there are A-labels which consist of ASCII starting with XN--. There is a two-way algorithm to convert between U-labels and A-labels. There is no punycode. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work
On December 10, 2018 5:02:30 PM UTC, "Kurt Andersen (b)" wrote: >On Mon, Dec 10, 2018 at 8:58 AM Scott Kitterman >wrote: > >> >> >> On December 10, 2018 4:31:03 PM UTC, "Kurt Andersen (b)" > >> wrote: >> >On Mon, Dec 10, 2018 at 8:28 AM Scott Kitterman > >> >wrote: >> > >> >> >> >> Since I'm most familiar with RFC 7208, I took a more detailed look >at >> >the >> >> SPF updates. Much of the current text is a restatement of what >RFC >> >7208 >> >> says. I don't know that we need that. The difference is to make >> >explicit >> >> what was already implicit; s and l macros will never match if the >> >local >> >> part of the email address contains non-ascii characters. >> >> >> > >> >Why not? If the non-ASCII (or non-7bit) characters are puny-coded, >it >> >seems >> >like they should be able to match without any problems. >> > >> AIUI, local parts don't get puny-coded. >> > >Even when attempting to look them up via the macro mechanism? It seems >like >that encoding should be a part of the macro processing. We discussed this during spfbis and concluded this was enough of a corner case not to make an incompatible protocol change over it. Almost no one uses SPF macros and even fewer use use the 'l' and 's' macros. If such a change were introduced, every SPF library would need an update to help approximately no one. I don't we should relitigate this here. Between non-ascii local parts and SPF records using with the 'l' or 's' macros, you get to pick one. Documenting this clearly is a good idea. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work
On Mon, Dec 10, 2018 at 8:58 AM Scott Kitterman wrote: > > > On December 10, 2018 4:31:03 PM UTC, "Kurt Andersen (b)" > wrote: > >On Mon, Dec 10, 2018 at 8:28 AM Scott Kitterman > >wrote: > > > >> > >> Since I'm most familiar with RFC 7208, I took a more detailed look at > >the > >> SPF updates. Much of the current text is a restatement of what RFC > >7208 > >> says. I don't know that we need that. The difference is to make > >explicit > >> what was already implicit; s and l macros will never match if the > >local > >> part of the email address contains non-ascii characters. > >> > > > >Why not? If the non-ASCII (or non-7bit) characters are puny-coded, it > >seems > >like they should be able to match without any problems. > > > AIUI, local parts don't get puny-coded. > Even when attempting to look them up via the macro mechanism? It seems like that encoding should be a part of the macro processing. --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work
On December 10, 2018 4:31:03 PM UTC, "Kurt Andersen (b)" wrote: >On Mon, Dec 10, 2018 at 8:28 AM Scott Kitterman >wrote: > >> >> Since I'm most familiar with RFC 7208, I took a more detailed look at >the >> SPF updates. Much of the current text is a restatement of what RFC >7208 >> says. I don't know that we need that. The difference is to make >explicit >> what was already implicit; s and l macros will never match if the >local >> part of the email address contains non-ascii characters. >> > >Why not? If the non-ASCII (or non-7bit) characters are puny-coded, it >seems >like they should be able to match without any problems. > AIUI, local parts don't get puny-coded. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work
+1 On Mon, Dec 10, 2018 at 08:28 Scott Kitterman wrote: > > > On December 10, 2018 3:50:00 PM UTC, Kurt Andersen > wrote: > >Now that the charter update has gone through the necessary processing, > >I'd > >like to ask the WG to adopt John Levine's > >https://tools.ietf.org/html/draft-levine-appsarea-eaiauth-05 document > >as an > >official WG item. > > > >This doc is a normative reference in both the ARC protocol doc and > >7601bis. > > +1 > > I do think it needs to be tightened up to make it clearer what the updates > are. > > Since I'm most familiar with RFC 7208, I took a more detailed look at the > SPF updates. Much of the current text is a restatement of what RFC 7208 > says. I don't know that we need that. The difference is to make explicit > what was already implicit; s and l macros will never match if the local > part of the email address contains non-ascii characters. > > I think explicit is better than implicit, so I'm in favor of the update. > > Scott K > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work
On Mon, Dec 10, 2018 at 8:28 AM Scott Kitterman wrote: > > Since I'm most familiar with RFC 7208, I took a more detailed look at the > SPF updates. Much of the current text is a restatement of what RFC 7208 > says. I don't know that we need that. The difference is to make explicit > what was already implicit; s and l macros will never match if the local > part of the email address contains non-ascii characters. > Why not? If the non-ASCII (or non-7bit) characters are puny-coded, it seems like they should be able to match without any problems. --Kurt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work
On December 10, 2018 3:50:00 PM UTC, Kurt Andersen wrote: >Now that the charter update has gone through the necessary processing, >I'd >like to ask the WG to adopt John Levine's >https://tools.ietf.org/html/draft-levine-appsarea-eaiauth-05 document >as an >official WG item. > >This doc is a normative reference in both the ARC protocol doc and >7601bis. +1 I do think it needs to be tightened up to make it clearer what the updates are. Since I'm most familiar with RFC 7208, I took a more detailed look at the SPF updates. Much of the current text is a restatement of what RFC 7208 says. I don't know that we need that. The difference is to make explicit what was already implicit; s and l macros will never match if the local part of the email address contains non-ascii characters. I think explicit is better than implicit, so I'm in favor of the update. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work
+1 Michael Hammer On Mon, Dec 10, 2018 at 10:50 AM Kurt Andersen wrote: > Now that the charter update has gone through the necessary processing, I'd > like to ask the WG to adopt John Levine's > https://tools.ietf.org/html/draft-levine-appsarea-eaiauth-05 document as > an official WG item. > > This doc is a normative reference in both the ARC protocol doc and 7601bis. > > --Kurt Andersen > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work
+1 On 12/10/2018 10:50 AM, Kurt Andersen wrote: Now that the charter update has gone through the necessary processing, I'd like to ask the WG to adopt John Levine's https://tools.ietf.org/html/draft-levine-appsarea-eaiauth-05 document as an official WG item. This doc is a normative reference in both the ARC protocol doc and 7601bis. --Kurt Andersen ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc -- HLS ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work
+1 on adopting this. I will sign up for review, etc. Tim On Mon, Dec 10, 2018 at 10:50 AM Kurt Andersen wrote: > Now that the charter update has gone through the necessary processing, I'd > like to ask the WG to adopt John Levine's > https://tools.ietf.org/html/draft-levine-appsarea-eaiauth-05 document as > an official WG item. > > This doc is a normative reference in both the ARC protocol doc and 7601bis. > > --Kurt Andersen > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] Recommend adoption of draft-levine-appsarea-eaiauth as WG work
Now that the charter update has gone through the necessary processing, I'd like to ask the WG to adopt John Levine's https://tools.ietf.org/html/draft-levine-appsarea-eaiauth-05 document as an official WG item. This doc is a normative reference in both the ARC protocol doc and 7601bis. --Kurt Andersen ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
