On December 10, 2018 5:02:30 PM UTC, "Kurt Andersen (b)" <kb...@drkurt.com>
wrote:
>On Mon, Dec 10, 2018 at 8:58 AM Scott Kitterman <skl...@kitterman.com>
>wrote:
>
>>
>>
>> On December 10, 2018 4:31:03 PM UTC, "Kurt Andersen (b)"
><kb...@drkurt.com>
>> wrote:
>> >On Mon, Dec 10, 2018 at 8:28 AM Scott Kitterman
><skl...@kitterman.com>
>> >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
