Re: Last pending wannabe erratum: Invalid <target-name>

Julian Mehnle wrote:

> how does 2821bis change the rules with regard to this?

Back in 2004 IIRC the USEFOR WG had an issue about legacy
(UUCP) names like "demon" vs. FQDNs like "example.com",
and RFC 2821 has a rule that a <domain> contains at least
one dot.  

Later (February 2004) RFC 3696 confirmed this, and before
I sent a mail to the author of RFC 2821 and asked if the 
"1" in  domain = subdomain 1*( "." subdomain )  is a typo,
or intentional against "bare" (unqualified) host names. 

He wrote it was intentional - at that time I had no idea
that "author of RFC 2821" was one of the Internet gods ;-)

I-D.klensin-2821bis removes the "dot required" syntax, in
essence it strips the "1", allowing TLDs, and with MUSTard
against "bare" hosts in prose.

RFC 4408 (and the approved Netnews RFC) ended up with the 
"old" 2821 and 3696 one-dot-only rules.  That's no serious
problem, let alone an erratum.  If say TLD "cat" decides
to start a news server they'll have to fight it out with
any legacy (UUCP) "cat", and nobody is in trouble if a:cat
won't fly in an SPF policy.

>> -----------------------------------------------------------------
>> The last pending erratum:  What do real implementations if the
>> <target-name> has a form unsuited for DNS queries, e.g. adjacent
>> dots ?  Just ignore the <target-name> as "no match" ?
 
> - From a design theoretical PoV, that should be a PermError 
>   because it won't go away on retrying.

Partially I agree:  A TempError certainly won't cut it.  You could
however treat it like a (literal) "invalid", a reserved pseudo-TLD
without IP or MX, nowhere, never (unlike "localhost" or "test").

> since RFC 4408 does not specify behavior in this case, there's
> little point in retroactively codifying observed behavior in the
> spec or in an erratum.

Makes sense.  But we normally _try_ that PermError is predictable,
mainly used for syntax errors.  If Scott picks "invalid" (ignore),
and you pick PermError, it's hard to find out what's wrong for an
affected user.

> As for real implementation behavior, Mail::SPF currently treats
> "a:foo..bar" as a simple mismatch.

Wait a moment, I was talking about <target-name> foo..bar, are you
talking about a <directive> a:foo..bar ?  Adjacent dots before the
macro expansion step directly written in a policy are a PermError,
aren't they ?

>> For the test suite:  With "v=spf1 exists:%{l}.%{d}" and mail from
>> "ugly..dots"@valid.domain.test what are implementations supposed
>> to do ?  A dot (like any other octet) is permitted in a label, of
>> course that's no host name, and it might be tricky to construct
>> a DNS query, but maybe "ugly\.\.dots.valid.domain.test" works.
 
> Following RFC 4408, behavior would have to be the same as for a 
> literal "exists:ugly..dots.valid.domain.test".

Interesting, you (kind of) ignored the quoted-string "ugly..dots".
You could also treat it as "ugly\.\.dots", AFAIK semantically the
same for RFC 2822:  Unnecessary quoted-pairs \. in this context,
but for DNS queries <liaden> necessity exists </liaden>.

> I have thought about defining (in a new specification -- SPFv3,
> 4408bis, whatever) macro expansion to treat any expanded macro
> as an atomic and opaque value when constructing a <target-name>,
> which would enable "ugly..dots" to be considered as a domain
> label of its own in "%{l}.%{d}".

Yes, I'm in the same position wrt EAI, I kind of promised that I
submit an "UTF8SMTP considerations for SPF" draft.  After I lost
the Last Call battle against the weird "experimental MIME update"
in EAI will be soon enough... <eg>

> That, however, would break "%{ir}._spf.%{d}" and similar cases.

Not necessarily, you could transform dots within a <quoted-string>
local part to <quoted-pair>, and leave a sound <dot-atom-text> as
is.  Of course you'd also keep <quoted-pair> \. in <quoted-string>,
we don't want \\\. in this case.

> We can support that in our next spec easily simply by allowing
> 8-bit bytes in SPF records and defining that localparts have to
> be encoded as UTF-8

It should work directly with RFC 4408, nobody needs to spell out
local parts, ASCII or otherwise, in a policy, %{l} is good enough.

JFTR, RFC 4408 also doesn't allow to spell out "embedded dots" in
a policy, we only can do VCHAR + SP - "." directly or with macros.

For IDN (internationalized domain names) in a policy we can use a
form with A-labels ("punycode").  For U-labels ("unencoded UTF-8")
in an UTF8SMTP envelope sender address we need the draft mentioned
above, that would also explain some fine print about <alt-address>:

Inconsistent policies for an "I18N address" and the corresponding
(optional) <alt-address> won't work as expected from the POV of a
sender trying this stunt.  No SPF issue, only a new caveat.

The DKIM folks are in far worse troubles with the EAI experiment.

 Frank

-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/1007/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/1007/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=6959932&id_secret=71592163-65ba87
Powered by Listbox: http://www.listbox.com