spf-discuss
[Top] [All Lists]

[spf-discuss] Re: SPF-EAI

2008-07-27 07:38:53
Alessandro Vesely wrote:
 
I think %{L} is good enough for the purpose of URIs in an
explanation.
 
Yes, it is. Since there is a script that receives such 
parameter, it can always work out whatever transformation
it needs to do its job.

ACK, I add a section about explanations to the draft, with
a summary of what we discussed here some weeks ago wrt i18n
in SPF *outside* of EAI.  Plus a RFC 3987 reference for the 
small step to i18n explanations in conjunction with EAI.

When spf-eai says "The local part MUST NOT be transformed"
it implies that %{l} cannot be used for DNS lookups if
internationalized local parts are present. 
 
No, it implies "use the local part octets as is", because
that's also what happens outside of EAI in SPF.
 
if a site suitably restricts the local parts that users can
choose, then it will be able to use %{l} for actual DNS
queries. 

Sure, however the necessary restrictions are not obvious:

1a: %{l} can expand into a <dot-atom-text> (2822upd term),
    that's one or more dot-separated <Atom>s.  As long as
    each <Atom> has length 1..63 SPF has no problem with it.

1u: For EAI it can also expand into dot-separated <uAtom>s,
    with the same length restriction for SPF.  However now
    we are talking about octets:  A single UTF-8 character
    consists of 1..4 octets.

2a: Simplified DNS treats ASCII letters as case insensitive,
    therefore you can have only one policy with an <Atom> 
    xyz.  If the variants xyZ, xYz, Xyz, XYz, XyZ, xYZ, XYZ
    are treated as different users (mailboxes) DNS and SPF
    cannot handle this.

2u: DNS does not support case-insensitive <UTF8-non-ascii>:
    äöü, äöÜ, ..., ÄÖÜ are eight different UTF-8 <uAtom>s
    as far as DNS + SPF are concerned.   There are actually
    *far* more more variants of the äöü-strings if you can't
    guarantee NFC (normalization form C).  Sites supporting
    EAI hopefully limit this äöü-zoo to one äöü-mailbox.  

    A piece of software doing this will affect UTF8SMTP and
    final delivery, but it won't do anything for DNS + SPF
    queries.  DNS and UTF8SMTP can be different departments,
    nobody is going to "canonicalize" incoming SPF queries.

3a: There are various issues if %{l} is a <Quoted-string>.
    It begins with removing quotes and the backslashes of 
    quoted pairs, leading to an "embedded dot" erratum and
    a bunch of missing test cases.

3u: EAI has no effect on 3a, neither better nor worse.  BTW,
    nobody supported to get rid of the moronic concept of a
    quoted pair for <UTF8-non-ascii>.  You still have about
    seven weeks to appeal it as hopeless nonsense.  Because
    it doesn't affect SPF-EAI I won't appeal it, but the EAI
    folks are aware what I think about this "feature"... :-(

4:  I think 1a+1b+2a+2b+3a+3b also affect %{L} if used in a
    <domain-spec>.  Ditto %{s} and %{S} containing the local
    part.  Maybe that's another missing test case:  For %{s}
    in a <domain-spec> SPF implementations get an "@" within
    a label of <target-name>, and have to treat this "as is".

Otherwise local parts may not be used in, say, exist 
mechanisms -with or without EAI.

Note that it is no MUST NOT, publishers can try it, but they
are in trouble if they do.  And spammers could intentionally 
try say "do..ts" as local part, if they find receivers where
this helps them to avoid a FAIL.

it makes little sense to widen the set of DNS-querable 
local parts by including U2A transformations. Is that 
correct?

U2A in IDNAbis means "U-label to A-label", and an A-label is
in essence "xn--" followed by a punycoded normalized U-label.
An A-label has the form of a traditional LDH-label.  

We are already outside of LDH-labels in 1a + 2a + 3a, without
EAI.  Therefore talking about "U2A" for 1u + 2u + 3u makes no
sense, it misses the point.  And if that was your question we
agree, "U2A" is undefined for arbitrary <uAtom> labels.  

In theory punycode doesn't have this limitation.  It can take
any Unicode input and transform it into ASCII, but that's not
how punycode is used in IDNA(bis).

the deeper analysis in your I-D shouldn't be directed toward
library implementors rather than policy publishers.

The draft could be better organized, but I'm to lazy to change
it.  A radical summary for implementors would be "get U2A magic
for the RHS, but you MUST NOT not touch the LHS, have fun".

For publishers the summary is "stay away from local part and
sender macros in <domain-spec>, or read and understand the
fine print".

For UTF8SMTP MSA operators the summary is "maybe transform the
RHS to A-labels, that should work 'as is' with SPF everywhere".

For Sender ID fans the summary is always the same "DON'T CHECK
PRA, IT DOES NOT WORK AS EXPECTED, ESPECIALLY NOT WITH v=spf1".

 Frank



-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com