Re: Quoted pairs in the test suite

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frank Ellermann wrote:
> 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:
>
> [...]  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".

Just out of curiosity: do you have a reference to me saying that?
I suspect that this was in a different context.

> ***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.

Well, let's just say that it is in the interface between SPF and the 
outside world.  I see no reason at all for the SPF spec to describe the 
specific steps for determining the semantical value of its input 
parameters.  (Actually, doing that would rather be bad specification 
design and a layer separation violation.)  This is the duty of RFCs 2821 
and 2822(bis/upd/whatever), as they define the on-the-wire / on-the-disk 
representation.

At best I can see adding an erratum saying that input parameters have to 
be fully parsed, per RFCs 2821/2822(bis/upd/whatever), into their 
semantical values before being passed to the SPF implementation.

> There is no "duty" for MTAs or other SPF users to parse a MAIL FROM
> address into its "semantical content".

Perhaps not, but there certainly isn't one for the SPF specification to 
define how to do it.

> 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>.

There's a difference between saying "strip it!" and saying "strip it, and 
this is how you must do it".

If anyone wants to know how to do it, they must begin interpreting RFCs 
2821/2822, not the SPF spec.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkil/CoACgkQwL7PKlBZWjvXIQCgnx3HaH7VhYS4cdV1USinZoaD
L8sAn13PlrHjuKjDC9Gv+pjDEkHNruix
=njtV
-----END PGP SIGNATURE-----