Stuart D. Gathman wrote:
> You could argue that a sender (who controls valid localparts)
> should avoid such quoted localparts to avoid any inconsistencies
> in receivers.
Oh yes, we all support the relevant "SHOULD avoid" in 2821bis,
and it is exactly the same "SHOULD avoid" as in RFC 2821.
> However, it *is* our job to specify the correct behaviour in
> the test suite
Yep. And get this right in the FAQ, the errata, and I-D.spf-eai.
From Julian's *old* line of arguments it was clear that removing
quotes while keeping backslashes makes no sense. Removing both
and then say "oops" to .do..ts. is acceptable (or maybe not, see
below).
Keeping both and then do the right thing for ".do..ts." as well
as "d\.o\\t\s" might be tricky. IOW I've no clue how to do the
right thing in these cases - but it is clearly possible, because
DNS permits any octet in a label.
So far all errata etc. went for .do..ts. and "oops". That does
not mean that "unquoting" + "unescaping" happens outside of SPF,
it only means that it happens pecisely once.
So "d\.o\\t\s" somehow arrived as d.o\ts in checkhost(), treated
as two labels "d" and "o\ts", and how implementations managed to
query DNS for a domain with label "o\ts" was their problem.
IMO they MUST get this right for conformance, there have to be
tests in the test suite checking that local part "d\.o\\t\s"
(or similar) works.
> I think you are saying that all quoting should be completely
> removed for %{l}
Well, actually I thought that's what you guys were saying after
I mentioned that "embedded dots" are allowed in DNS. You and
Julian among others did not like this, and from there we went
in the opposite direction, something already removed the quotes
from ".do..ts.", and an empty label in .do..ts. won't fly with
res_mkquery().
You cannot have quotes removed or kept as you see fit, if they
are ugly for ".do..ts."@ they are also ugly for "okay"@ or for
"back\\slash"@
Removing quotes while keeping quoted pairs is RFC 2617 magic,
one of several factors why RFC 2831 will be moved to HISTORIC,
the 2831bis author was annoyed, google for qdstr-val.
Therefore we got "remove quotes and unquote <quoted-pair>" -
until yesterday, before Julian found that this of course also
has some drawbacks. It was a shaky decision, but you did not
want "embedded dots", for a "keep as is" approach.
> The spec. says, "The 's' macro expands to the <sender>
> argument. It is an E-Mail address ...", which says to me that
> it should remain a valid email address and preserve quoting.
Yes, and 'l' is supposed to be the original local part, and
'h' the original helo, as broken as it might be if receivers
accept syntactically invalid (SMTP syntax) HELOs.
> It is possible that you have uncovered yet another errata
> (fortunately just another obscure corner case).
IMO this is the same old set of errata as it always was. If
we now want ".do..ts."@example as is for 's', and ".do..ts."
as is for 'l', then SPF implementations have to deal with
%{l}.%{d} in DNS queries, because that is perfectly possible.
But it's tricky, in "qu\"ot"@example the \" is a quoted-pair
because that is the only way to get a quote in a local part.
The obscure "semantical content" is <label>qu"ot<\label>.
I don't know how a resolver can be convinced to make a query
containing label qu"ot. It could well be "qu\"ot" as it was.
For combinations like "\u\n\n\e\c\e\s\s\a\r\y"@example or
"okay"@example the SPF implementations have to know that
this is unnecessary and okay, resp. The DNS API can't know
it, just double or insert backslashes everywhere to see why.
And the SPF test suite better checks that implementations
get this right, it is no rocket science, but obviously also
not trivial.
Frank
-------------------------------------------
Sender Policy Framework:
http://www.openspf.org Modify Your Subscription:
http://www.listbox.com/member/ Archives:
http://www.listbox.com/member/archive/1007/=now RSS Feed:
http://www.listbox.com/member/archive/rss/1007/ Powered by Listbox:
http://www.listbox.com