hmdmhdfmhdjmzdtjmzdtzktdkztdjz at gmail
Jul 27, 2008, 7:37 AM
Post #16 of 20
(3245 views)
Permalink
|
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
|
smime.p7s
