Mailing List Archive

Re: domain literals
Stuart D. Gathman wrote:

>> For an SPF policy using a:%{h} the mechanism should match for
>> IP 195.7.77.17 - please correct me if that's wrong.

> That's wrong, because there is no A record. In fact, .17 is
> not even a legal TLD.

Hi, obviously it was unclear, I was talking about HELO museum or
HELO museum. (with dot), with `host museum` museum = 195.7.77.17

Frank


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007
Re: domain literals [ In reply to ]
Stuart D. Gathman wrote:

>> the correct SPF result for the IP literal is NONE.

Yes, that's what I said, no "error" as far as SPF HELO
checks are concerned (in Wayne's drafts up to RFC 4408).

>> I believe it's the same for your museum cases too.

I don't think so. An a:%{h} after "HELO museum" should
match the IP of TLD "museum". While the HELO is an SMTP
syntax error it's otherwise a host with an IP, if you'd
try `host museum` or `nslookup -q=a museum.` you'll find
an IP.

> The test suite covers the cases listed in the RFC (long
> label, empty label, OEMCOMPUTER, RCODE 3). It does not
> check domain literals in particular, so I'll add that.

Good.

> Although it is a pretty wierd programmer that would
> return None for "foo..bar" and throw permerror for
> "[1.2.3.4]".

Yeah, a bug while trying to implement draft-lentczner :-)

Please add also the a:%{h} cases after "HELO museum" or
"HELO museum." (of course s/museum/test/ or similar, for
a match of its IP), it's not the same as "oemcomputer".

Frank


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007
Re: Re: domain literals [ In reply to ]
On Sat, 17 Mar 2007, Frank Ellermann wrote:

> Please add also the a:%{h} cases after "HELO museum" or
> "HELO museum." (of course s/museum/test/ or similar, for
> a match of its IP), it's not the same as "oemcomputer".

The correct result is not at all clear in this case.
4.8/1 says the result of macro expansion for a domain-spec
is a FQDN. It does not specify what to do when the
expansion is, in fact, *not* a FQDN.

Choices offered so far:

a) treat as a TLD (Frank Ellerman)
b) don't match
c) permerror (rejected after discussion)

The test suite does not currently distinguish between a and b, but it
does check to make sure it does not permerror.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007
Re: Re: domain literals [ In reply to ]
On Saturday 17 March 2007 12:09, Stuart D. Gathman wrote:
> On Sat, 17 Mar 2007, Frank Ellermann wrote:
> > Please add also the a:%{h} cases after "HELO museum" or
> > "HELO museum." (of course s/museum/test/ or similar, for
> > a match of its IP), it's not the same as "oemcomputer".
>
> The correct result is not at all clear in this case.
> 4.8/1 says the result of macro expansion for a domain-spec
> is a FQDN. It does not specify what to do when the
> expansion is, in fact, *not* a FQDN.
>
> Choices offered so far:
>
> a) treat as a TLD (Frank Ellerman)
> b) don't match
> c) permerror (rejected after discussion)
>
> The test suite does not currently distinguish between a and b, but it
> does check to make sure it does not permerror.

Given that at the beginning of the process (in the paragraph I cited a few
messages back) the SPF result for a non-FQDN is None, I think that don't
match is the only result that's consistent with that.

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007
Re: domain literals [ In reply to ]
Stuart D. Gathman wrote:

> 4.8/1 says the result of macro expansion for a domain-spec
> is a FQDN. It does not specify what to do when the
> expansion is, in fact, *not* a FQDN.

TLD "museum" is a FQDN in the DNS sense of RFC 4408 4.8/1,
it even has an IP. If it's good enough for ICANN it's
also good enough for SPF's a:%{h} and the SPF test suite :-)

Frank


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007
Re: domain literals [ In reply to ]
Scott Kitterman wrote:

> Given that at the beginning of the process (in the paragraph I cited a few
> messages back) the SPF result for a non-FQDN is None, I think that don't
> match is the only result that's consistent with that.

That's not directly related. Of course the result for "HELO museum"
is NONE because "nslookup -q=txt museum." doesn't find an SPF policy.

I think... checking... yes, no policy => NONE.

But for a:%{h} you'd ask for q=a (or q=aaaa), not q=txt (or q=spf),
and they really have an IP. How good that idea is is a separate
question, they (ab)use it for a wildcard.

But "museum" isn't the only TLD with an IP. There might be even a
TLD with an SPF policy... <shudder />

SPF policies can't talk about such domains _directly_ because they
don't have the reqired dot before a <toplabel>. But that doesn't
affect indirect references like "a:%{h}", "mx:%{d}", or "ptr:%{o}".

Frank


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007
Re: Re: domain literals [ In reply to ]
On Saturday 17 March 2007 13:05, Frank Ellermann wrote:
> Scott Kitterman wrote:
> > Given that at the beginning of the process (in the paragraph I cited a
> > few messages back) the SPF result for a non-FQDN is None, I think that
> > don't match is the only result that's consistent with that.
>
> That's not directly related. Of course the result for "HELO museum"
> is NONE because "nslookup -q=txt museum." doesn't find an SPF policy.
>
> I think... checking... yes, no policy => NONE.
>
> But for a:%{h} you'd ask for q=a (or q=aaaa), not q=txt (or q=spf),
> and they really have an IP. How good that idea is is a separate
> question, they (ab)use it for a wildcard.
>
> But "museum" isn't the only TLD with an IP. There might be even a
> TLD with an SPF policy... <shudder />
>
> SPF policies can't talk about such domains _directly_ because they
> don't have the reqired dot before a <toplabel>. But that doesn't
> affect indirect references like "a:%{h}", "mx:%{d}", or "ptr:%{o}".
>
I'll buy that.

All numeric toplables are still not FQDN and so those should still be a no
match.

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007
Re: domain literals [ In reply to ]
Scott Kitterman wrote:

> All numeric toplables are still not FQDN and so those should
> still be a no match.

Yes. No match for a:%{h} after HELO [127.2.3.4] even if the
IP happens to be 127.2.3.4 That could be one test case.

A second test could try a:%{h} after HELO test where TLD test
has the required IP, then a:%{h} should match.

And a third test could verify this behaviour for "HELO test."
with a trailing dot. My nslookup won't let me look at test
without the dot, and the question of trailing dots is always
interesting with RFCs 2821, 4408, 2821bis (depending on the
version of the draft, sometimes... ;-)

Frank


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007
Re: domain literals [ In reply to ]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stuart D. Gathman wrote:
> On Sat, 17 Mar 2007, Frank Ellermann wrote:
> > Please add also the a:%{h} cases after "HELO museum" or "HELO museum."
> > (of course s/museum/test/ or similar, for a match of its IP), it's not
> > the same as "oemcomputer".
>
> The correct result is not at all clear in this case. 4.8/1 says the
> result of macro expansion for a domain-spec is a FQDN. It does not
> specify what to do when the expansion is, in fact, *not* a FQDN.
>
> Choices offered so far:
>
> a) treat as a TLD (Frank Ellerman)
> b) don't match
> c) permerror (rejected after discussion)
>
> The test suite does not currently distinguish between a and b, but it
> does check to make sure it does not permerror.

It's obviously unspecified (as unfortunate as it may be), so the test suite
should not require any specific behavior. However, I agree that PermError
should not be thrown because the spec doesn't say "MUST be an FQDN" or
anything to that effect.

IOW, I agree with the current state of the test suite in this regard.

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

iD8DBQFGBcl2wL7PKlBZWjsRAgqLAJ9Q3QaryU9gAAb7sgVCgnER40jBhQCgq/rX
lJZ6sAfDOx7xnDpGXiObs/E=
=E7QU
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=1007