Mailing List Archive

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

Frank Ellermann wrote:
> Julian Mehnle wrote:
> > the test suite should not require any specific behavior.
>
> Well, so far nobody proposed that "crash" or "TempError" is acceptable.

Why would an implementation crash on "a:%{h}" with <helo> = "OEMCOMPUTER"?

Why do you want to test _that_ case for crashes and not a million other
weird cases?


> I've tracked this issue directly below your similar problem with invalid
> domains:
>
> http://www.openspf.org/RFC_4408/Errata#permerror-invalid-domains

Who proposed that one??

I certainly did not propose that for v=spf1. I said I'd agree that v=spf3
should work this way, but that v=spf1 cannot be changed retroactively like
this.

> There's yet no problem statement for your case,

It's not _my_ case. Whose is it really?

> > the spec doesn't say "MUST be an FQDN" or anything to
> > that effect.
>
> <target-name> is clearly underspecified, and as that has confused several
> developers it's also a clear erratum.

Unspecifiedness is NOT generally a bug, and confused developers aren't a
good enough justification for specifying _new_ behavior in v=spf1.

Unspecifiedness is a bug only when it harms interoperability. Is this the
case here?

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

iD8DBQFGBk4uwL7PKlBZWjsRAhxyAKDRzGgDv65KSxHrGWeBBITDLEpAWgCg6ZB6
bb0ZyA4qOpYJUoJKuOKr7Hw=
=hYez
-----END PGP SIGNATURE-----

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

Julian Mehnle wrote:

> Why do you want to test _that_ case for crashes and not a million
> other weird cases?

I don't know a million other weird cases, I know that one: At the
moment "oemcomputer" is no TLD under ICANN's root, unlike "museum",
"aero", "arpa", "travel", "asia", "mobi", "coop", etc. For a less
volatile test I'd replace "oemcomputer" by "invalid".

>> http://www.openspf.org/RFC_4408/Errata#permerror-invalid-domains
> Who proposed that one??

Dunno, thought it was you.

> v=spf1 cannot be changed retroactively like this.

Implementations have to do something with an invalid <target-name>,
"ignore, no match, move on" is another possibility.

>> There's yet no problem statement for your case,
> It's not _my_ case. Whose is it really?

It's a Wiki, it has an edit history, and whoever added it likely
tried to track one of those convoluted test suite threads. If it's
bogus we can throw it out.

> confused developers aren't a good enough justification for
> specifying _new_ behavior in v=spf1. Unspecifiedness is a bug
> only when it harms interoperability. Is this the case here?

If some implementations can handle a:%{h} for an existing A record
for say "museum", others treat it as "ignore, no match, move on",
and some throw PermError, then it obviously harms interoperability.

Frank


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

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

Frank Ellermann wrote:
> Julian Mehnle wrote:
> > Why do you want to test _that_ case for crashes and not a million
> > other weird cases?
>
> I don't know a million other weird cases, I know that one: At the
> moment "oemcomputer" is no TLD under ICANN's root, unlike "museum",
> "aero", "arpa", "travel", "asia", "mobi", "coop", etc. For a less
> volatile test I'd replace "oemcomputer" by "invalid".

Now what does _that_ have to do with testing for crashes?

> > v=spf1 cannot be changed retroactively like this.
>
> Implementations have to do something with an invalid <target-name>,
> "ignore, no match, move on" is another possibility.

In RFC 4408, there is no such thing as an "invalid <target-name>". It says
that <t-n> "is an FQDN", but it doesn't say anything else, in particular
it doesn't say what should happen if <t-n> isn't an FQDN.

Sure "implementations have to do something". But that doesn't mean that it
_has_ to be specified at all costs. And the cost of rendering certain
implementations incompliant because they chose to do something other than
what _you_ want to specify retroactively, is simply too high.

> > > There's yet no problem statement for your case,
> >
> > It's not _my_ case. Whose is it really?
>
> It's a Wiki, it has an edit history, and whoever added it likely
> tried to track one of those convoluted test suite threads. If it's
> bogus we can throw it out.

I suggest that whoever added it either explain whose idea it was, adopt the
idea as their own, or remove it from the proposed errata list.

> > confused developers aren't a good enough justification for
> > specifying _new_ behavior in v=spf1. Unspecifiedness is a bug
> > only when it harms interoperability. Is this the case here?
>
> If some implementations can handle a:%{h} for an existing A record
> for say "museum", others treat it as "ignore, no match, move on",
> and some throw PermError, then it obviously harms interoperability.

Note that this is a very cornery corner case. It happens only if <helo> is
in some way "not an FQDN" (as the spec says), and then what's the problem
with some implementations making a (potentially bogus) TLD query (which is
likely to fail), some mismatching the mechanism, and some throwing
PermError? The only real type of case I can see is the "legit TLD used as
host or MX domain name" one, and as far as I can see, no TLD actually does
it.

Besides, throwing PermError in this case is hardly justifiable from what
the spec says.

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

iD8DBQFGBu14wL7PKlBZWjsRAt+aAKCNnKKGiXdIlSIv03jEv97V2rtL3wCgjZAd
ubZo9GVcmaO+sCAHcuR8l4U=
=sIsE
-----END PGP SIGNATURE-----

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

Julian Mehnle wrote:

>> I don't know a million other weird cases, I know that one: At the
>> moment "oemcomputer" is no TLD under ICANN's root, unlike "museum",
>> "aero", "arpa", "travel", "asia", "mobi", "coop", etc. For a less
>> volatile test I'd replace "oemcomputer" by "invalid".

> Now what does _that_ have to do with testing for crashes?

I don't know, it's your point. I only said that some outcomes like
crash / dead loop / NONE / SOFTFAIL for "v=spf1 a:%{h} -all" are
wrong, and certified SPF implementations must not do that, no matter
what the HELO identity referenced by %{h} is.

> In RFC 4408, there is no such thing as an "invalid <target-name>".
> It says that <t-n> "is an FQDN", but it doesn't say anything else

What, did it forget to update RFC 1035 ? Seriously, it says very
clearly what to do with an invalid <target-name> wrt exp= modifiers,
and for affected mechanisms it offers at least _some_ instructions
how to deal with DNS problems.

> the cost of rendering certain implementations incompliant because
> they chose to do something other than what _you_ want to specify
> retroactively, is simply too high.

I say bull. Predictable and deterministic results were a goal for
SPF since Wayne took over, and the "add new mechanisms to 'embrace
and extend' new ideas whenever they emerge" fraction was thrown out.

>> It's a Wiki, it has an edit history, and whoever added it likely
>> tried to track one of those convoluted test suite threads. If
>> it's bogus we can throw it out.

> I suggest that whoever added it either explain whose idea it was,
> adopt the idea as their own, or remove it from the proposed errata
> list.

+1 If nothing happens with it until say May let's move to kick it.

>> If some implementations can handle a:%{h} for an existing A record
>> for say "museum", others treat it as "ignore, no match, move on",
>> and some throw PermError, then it obviously harms interoperability.

> Note that this is a very cornery corner case. It happens only if
> <helo> is in some way "not an FQDN" (as the spec says)

NAK, it happens for _any_ <target-name> resulting in a single label,
with any mechanism or modifier allowing a <target-name>. The %{h}
is only the simplest example to nail it. %{l} etc. also can result
in single labels. Taking a part of an IPv6 can do it (DE, AF, ...).

> what's the problem with some implementations making a (potentially
> bogus) TLD query (which is likely to fail), some mismatching the
> mechanism, and some throwing PermError? The only real type of
> case I can see is the "legit TLD used as host or MX domain name"
> one, and as far as I can see, no TLD actually does it.

> Besides, throwing PermError in this case is hardly justifiable
> from what the spec says.

Fine, we're making progress, so you consider PermError as bad idea.
That leaves "ignore single labels" or "try to match as always".

Frank


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Sunday 25 March 2007 19:02, Frank Ellermann wrote:
> Julian Mehnle wrote:
> > what's the problem with some implementations making a (potentially
> > bogus) TLD query (which is likely to fail), some mismatching the
> > mechanism, and some throwing PermError? The only real type of
> > case I can see is the "legit TLD used as host or MX domain name"
> > one, and as far as I can see, no TLD actually does it.
> >
> > Besides, throwing PermError in this case is hardly justifiable
> > from what the spec says.
>
> Fine, we're making progress, so you consider PermError as bad idea.
> That leaves "ignore single labels" or "try to match as always".
>
I'm surprised this has caused so much traffic. I think that this whole issue
us reasonably clear from an SPF perspective...

SPF only has something to say if HELO/EHLO is an FQDN. The accept/reject
decision for non-FQDN HELO/EHLO is not an SPF question. If asked the SPF
result for a non-FQDN HELO/EHLO, the only possible answer is NONE.

Where things get mushy is the definitition of FQDN. We didn't define it and
we can't fix that mushiness.

Here is what I think the range of reasonable interpretation is:

musuem.123. - NOT FQDN (All numeric TLDs not allowed)
musuem - Could go either way, but unless an application is specifically
designed to need to find TLDs, NOT FQDN should be preferred, but FQDN is an
acceptable alternate.
museum. - FQDN.

I don't recall which RFC (I'm pretty sure it's the same one that says no all
numeric TLDs), but applications are specifically discouraged from hardwiring
the current list of actual TLDs and so for an implementation, I think this is
the best we can do. Anyone actually wanting to put a TLD in an SPF record
would be well advised to include the trailing dot.

Scott K

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

Scott Kitterman wrote:

> I'm surprised this has caused so much traffic. I think that this
> whole issue is reasonably clear from an SPF perspective...

Don't get me wrong, but I think you missed the point. HELO museum
(or similar) triggered the thread, but the point is a single label
<target-name> after _any_ macro expansion, not only %{h}, it can be
anything, e.g. %{l}

The topic "is HELO museum an SMTP syntax error" is also interesting,
and in fact discussed on the SMTP list [.starting again Wednesday,
after a moratorium trying to stop "two posters" from getting into
a flamewar - okay, one of the two is me, the other is the author :-]

> I don't recall which RFC (I'm pretty sure it's the same one that
> says no all numeric TLDs), but applications are specifically
> discouraged from hardwiring the current list of actual TLDs

Yes, 3696, same author, said that 3696 might be wrong if it's not
compatible with 2821, I said both are right, etc., that will be
solved in 2821bis and/or 3696bis, not directly a SPF problem, we
don't support a "dotless" <domain-spec> because it's too complex
for the syntax.

But a "dotless" <target-name> is something that you can get when
normally evaluating perfectly harmless SPF records "v=spf1 a:%{L}"

> Anyone actually wanting to put a TLD in an SPF record would be
> well advised to include the trailing dot.

Doesn't help, "a:museum" and "a:museum." are both syntax errors,
they get a PermError. OTOH a:%{L} might even work for a domain
where all local parts "happen" to be existing FQDNs.

Frank


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

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

Frank Ellermann wrote:
> Julian Mehnle wrote:
> > what's the problem with some implementations making a (potentially
> > bogus) TLD query (which is likely to fail), some mismatching the
> > mechanism, and some throwing PermError? The only real type of
> > case I can see is the "legit TLD used as host or MX domain name"
> > one, and as far as I can see, no TLD actually does it.
> >
> > Besides, throwing PermError in this case is hardly justifiable
> > from what the spec says.
>
> Fine, we're making progress, so you consider PermError as bad idea.
> That leaves "ignore single labels" or "try to match as always".

The difference is, I am _interpreting_ the spec, whereas you are proposing
to _change_ it (by specifying things that weren't previously specified).

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

iD8DBQFGB/MiwL7PKlBZWjsRAjQBAKCn/D1us7U1vyOiCHy7eRjV136dOACgtMIw
uLhr3qeK/e7Jr62cwNgqZaM=
=5ZJ8
-----END PGP SIGNATURE-----

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Sunday 25 March 2007 23:27, you wrote:
> Scott Kitterman wrote:
> > I'm surprised this has caused so much traffic. I think that this
> > whole issue is reasonably clear from an SPF perspective...
>
> Don't get me wrong, but I think you missed the point. HELO museum
> (or similar) triggered the thread, but the point is a single label
> <target-name> after _any_ macro expansion, not only %{h}, it can be
> anything, e.g. %{l}

Sure. Agreed.

> The topic "is HELO museum an SMTP syntax error" is also interesting,
> and in fact discussed on the SMTP list [.starting again Wednesday,
> after a moratorium trying to stop "two posters" from getting into
> a flamewar - okay, one of the two is me, the other is the author :-]

Right, but not an SPF concern. SPF (per RFC 4408) only deals in FQDN.

> > I don't recall which RFC (I'm pretty sure it's the same one that
> > says no all numeric TLDs), but applications are specifically
> > discouraged from hardwiring the current list of actual TLDs
>
> Yes, 3696, same author, said that 3696 might be wrong if it's not
> compatible with 2821, I said both are right, etc., that will be
> solved in 2821bis and/or 3696bis, not directly a SPF problem, we
> don't support a "dotless" <domain-spec> because it's too complex
> for the syntax.

That sounds right to me.

> But a "dotless" <target-name> is something that you can get when
> normally evaluating perfectly harmless SPF records "v=spf1 a:%{L}"
>
> > Anyone actually wanting to put a TLD in an SPF record would be
> > well advised to include the trailing dot.
>
> Doesn't help, "a:museum" and "a:museum." are both syntax errors,
> they get a PermError. OTOH a:%{L} might even work for a domain
> where all local parts "happen" to be existing FQDNs.

Yes.

My main point is that SPF should limit itself to HELO/EHLO arguments that are
FQDN, whatever that it. I'm not focused on the macro for HELO/EHLO, but the
actual HELO/EHLO name given to the SPF library by the calling program.

Scott K

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

Julian Mehnle wrote:

>> Fine, we're making progress, so you consider PermError as bad idea.
>> That leaves "ignore single labels" or "try to match as always".

> The difference is, I am _interpreting_ the spec, whereas you are proposing
> to _change_ it (by specifying things that weren't previously specified).

My wish to decide this issue is based on an interpretation of the
spec.: IMO the spec. tries hard to get predictable deterministic
results as far as using DNS allows this.

Under this interpretation a situation where implementation X says
PASS and implementation Y says FAIL for the same input (and no DNS
problems) is highly undesirable. It's against the spirit of the
spec.

Clearly there are corner cases where we don't care: If somebody
wants 2000 leading zeros in a place where that's not forbidden -
tough, don't do that, it's an obviously stupid idea.

But a:%{h} and similar cases are not obviously stupid, or rather
not as bad as those leading zeros.

Frank


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

On Sun, 25 Mar 2007, Frank Ellermann wrote:

> It's a Wiki, it has an edit history, and whoever added it likely
> tried to track one of those convoluted test suite threads. If it's
> bogus we can throw it out.

Permerror on invalid domain after macro expansion was added by
Mark Shewmaker as the 2nd revision.

I thought we had rejected that notion. It would make %{h} useless
because all the bogus HELOs would cause permerrors.

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

-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735

Stuart D. Gathman wrote:

> Permerror on invalid domain after macro expansion was added by
> Mark Shewmaker as the 2nd revision.

I think I finally recall that this was triggered by a thread on
the devel list about "domain" foo..bar. What's the test suite
doing at the moment with a direct "a:foo..bar" (no macro) ?

And _why_ is it doing whatever it does ? <g>

> I thought we had rejected that notion. It would make %{h}
> useless because all the bogus HELOs would cause permerrors.

If folks would simply reject PERMERROR it's fine. But if they
don't reject PERMERROR ignoring a macro-expanded <target-name>
foo..bar and moving on to the next mechanism(s) could be better,
if they at least reject FAIL (triggered by a later directive).

Frank


-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?list_id=735