Re: Quoted pairs in the test suite

Julian Mehnle wrote:
 
> There's a difference between the _value_ of the localpart
> in a RFC 2821 e-mail address and its _representation_ in
> the e-mail address.

Yep, I know the fine print, 2822upd has this as "semantical
content" IIRC.  But in practice these things tend to vary:

RFC 2617 (HTTP AUTH) and its predecessors strip the quotes
from a quoted-string, leaving quoted-pairs alone.  RFC 2831
inherited this oddity.

RFC.ietf-usefor-usefor defines a canonical Message-ID, that
boils down to "use a quoted-pair only if you must, and after
that leave it alone, i.e. keep quotes, case, and backlashes
as is no matter what you're up to".  The news + nntp URI I-D
sticks to that dogma, unsurprisingly ;-)

The mailto-bis I-D and AFAIK the RFC about tag: URI scheme
also follow a "keep as is" dogma.  Of course none of these
I-Ds and RFCs are remotely relevant for SPF - I just want
to point out that "doing the right thing" isn't always the
same thing in different contexts.

IIRC you said here that SPF implementations strip the quotes
from <quoted-string> in a discussion about "embedded dots".

After that they can't escape "embedded dots" even if DNS in
theory supports any octet.  After that it's also logical to
get rid of backslashes introducing <quoted-pair>, and so I
arrived at the same result as you, again unsurprisingly. :-)

***BUT*** 

> this is exactly what MTAs should pass to SPF implementations.

I don't see why MTAs should suddenly start to be smart.  They
get an address with a <quoted-string> as local part, and they
pass this on to SPF with a clear directive "now do your magic,
I want PASS or FAIL, a.s.a.p.".

MTAs have no reason to figure an odd "semantical content" out,
that's hardcore standardista stuff, not practical programming.

SPF has to do this - something above checkhost() is fine, but
not so far above checkhost() that it is outside of SPF.  There
is no "duty" for MTAs or other SPF users to parse a MAIL FROM
address into its "semantical content".

I'd even fear that nothing removes the reverse route in cases
where it's present.  RFC 4408 clearly says "strip it".  It's
the job of SPF to strip a reverse route, therefore it's also
the job of SPF to deal with <quoted-string> + <quoted-pair>.

And it's not something that still works if done twice, if an
MTA really already did it SPF must not try it again, example:

MAIL FROM:<@example.com:"\"back\\slash\""@example.org>

The semantical content of the local part is "back\slash" with
the quotes and the backslash.

 Frank