Mailing List Archive

Stuart D. Gathman wrote:

> http://www.openspf.org/svn/project/test-suite/rfc4408-tests.yml

Looking for the weird a:%{h} stuff I think it's not yet completely
covered under the "macro expansion rules".

Test hello-domain-literal covers an upper case %{H}, please correct
me if I get that wrong: The result is FAIL because whatever the
URL expansion of "[192.168.218.40]" might be, it's certainly no
FQDN, let alone a host with IP 192.168.218.40.

I think you need a similar case with an ordinary lower case %{h},
here's a proposal copying what you have:

hello-domain-literal-2:
spec: 8.1/2
description: |-
HELO is a domain literal reflecting the IP of the client
helo: "[192.168.218.40]"
host: 192.168.218.40
mailfrom: test@e11.example.com
result: fail
hello-museum-1:
spec: 4.8/1
description: |-
TLDs can be hosts and SPF does not check SMTP syntax errors
helo: test
host: 192.168.218.40
mailfrom: test@e11.exampe.com
result: pass
hello-museum-2:
spec: 4.8/1
description: |-
TLDs can be hosts and SPF does not check SMTP syntax errors
helo: "test."
host: 192.168.218.40
mailfrom: test@e11.exampe.com
result: pass

zonedata:
e11.example.com:
- SPF: v=spf1 a:%{h} -all
test:
- A: 192.168.218.40

I hope you get the idea, I can't tell if "test." must be, may be,
or must not be quoted.

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 Sat, 17 Mar 2007, Frank Ellermann wrote:

> hello-museum-1:
> spec: 4.8/1
> description: |-
> TLDs can be hosts and SPF does not check SMTP syntax errors
> helo: test
> host: 192.168.218.40
> mailfrom: test@e11.exampe.com
> result: pass

It is not all clear that your interpretation of the museum case has
any concensus. The RFC doesn't say anything explicit either.

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

> It is not all clear that your interpretation of the museum case has
> any concensus. The RFC doesn't say anything explicit either.

So far I didn't note that anybody disputes that some TLDs have IPs
for whatever reason, and that they are of course FQDNs. As far as
RFC 4408 is concerned it clearly says in 4.8/1:

Several of these mechanisms and modifiers have a <domain-spec>
section. The <domain-spec> string is macro expanded (see Section 8).

Obviously %{h} matches <macro-expand> in <domain-end>, and therefore
<domain-spec> after an empty <macro-string> consisting of zero parts.

The resulting string is the common presentation form of a fully-
qualified DNS name: a series of labels separated by periods.

TLDs are in the common presentation form of labels separated by dots,
as there's only one label there's of course no separating dot.

This domain is called the <target-name> in the rest of this document.

In other words the <target-name> is "museum" (or rather "test") in
hello-museum-1, and "test." in hello-museum-2. There's no proviso to
fix the trailing dot issue in a <target-name> I'm aware of.

Actually that should be tested too, %{h}%{h} is testtest for "test"
but test.test. for "test.".

You'll need additional zonedata e12.example.com with a:%{h}%{h} and
test.test. with the relevant IP. Get FAIL for helo: test (because
testtest has no IP) but PASS for helo: "test." (test.test. IP match).

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 Sat, 17 Mar 2007, Frank Ellermann wrote:

> TLDs are in the common presentation form of labels separated by dots,
> as there's only one label there's of course no separating dot.

I'm not convinced that a label with no dot is a FQDN. I'll have to
look up the definition. I've seen a lot of code that tests for
FQDN by testing for a dot. Perhaps all that code is wrong.
Perhaps not.

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

> I'm not convinced that a label with no dot is a FQDN.
> I'll have to look up the definition.

You really think TLDs are no FQDNs ? The best explanation
I know (and for that reason also an informative reference
in RFC 4408) is http://tools.ietf.org/html/rfc3696#section-2

| Consequently, purported DNS names to be used in applications
| and to locate resources generally must contain at least one
| period (".") character. Those that do not are either invalid
| or require the application to supply additional information.
| Of course, this principle does not apply when the purpose of
| the application is to process or query TLD names themselves.

Better read the complete section, it's rather interesting,
with historical explanations, good and bad heuristics, and
why hardwiring lists of TLDs into applications won't work
anymore.

> I've seen a lot of code that tests for FQDN by testing for a
> dot. Perhaps all that code is wrong. Perhaps not.

For SMTP as specified in 2821 and the (01) 2821bis draft it's
fine. SMTP intentinally doesn't support TLDs, because it tries
to get rid of "bare labels", as that used to be the name of a
host _without_ the labels to get a fully qualified domain.

Applications tried some black magic, adding ".domain.example"
on the fly for a host "test" to get FQDN test.domain.example.

For obvious reasons that magic didn't always work as expected,
and therefore "plan B" was to disqualify it as syntax error
in ESMTP. And also in the <domain-spec> of SPF, or in USEFOR,
for this and other reasons. IIRC we needed it in SPF only to
eliminate an ABNF ambiguity.

Otherwise, no compatibility issues, TLDs are domains like any
other domain, and the spec. doesn't say that <target-name> has
to have at least one dot.

But I think the spec. forgot to mention that a trailing dot
has to be removed for the purpose of "macro expansion". I'll
add this to the errata: The meaning of a:%{h}%{h] should not
depend on the presence or absence of a trailing dot in HELO
(just an example, other macros are also affected).

For something like MAIL FROM:<"dot."@example> and %{l} screw
it, it's too rare to be taken seriously. Or should any "dot-
pruning" be limited to h, d, o ?

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, 18 Mar 2007, Frank Ellermann wrote:

> Stuart D. Gathman wrote:
>
> > I'm not convinced that a label with no dot is a FQDN.
> > I'll have to look up the definition.
>
> You really think TLDs are no FQDNs ? The best explanation
> I know (and for that reason also an informative reference
> in RFC 4408) is http://tools.ietf.org/html/rfc3696#section-2
>
> | Consequently, purported DNS names to be used in applications
> | and to locate resources generally must contain at least one
> | period (".") character. Those that do not are either invalid
> | or require the application to supply additional information.
> | Of course, this principle does not apply when the purpose of
> | the application is to process or query TLD names themselves.

Since the purpose of SPF is *not* to process or query TLD names
themselves, I'd say I'm more convinced than ever that TLDs are no
FQDNs in the context of SPF. Thanks for quoting that.

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

On Monday 19 March 2007 11:52, Stuart D. Gathman wrote:
> On Sun, 18 Mar 2007, Frank Ellermann wrote:
> > Stuart D. Gathman wrote:
> > > I'm not convinced that a label with no dot is a FQDN.
> > > I'll have to look up the definition.
> >
> > You really think TLDs are no FQDNs ? The best explanation
> > I know (and for that reason also an informative reference
> > in RFC 4408) is http://tools.ietf.org/html/rfc3696#section-2
> >
> > | Consequently, purported DNS names to be used in applications
> > | and to locate resources generally must contain at least one
> > | period (".") character. Those that do not are either invalid
> > | or require the application to supply additional information.
> > | Of course, this principle does not apply when the purpose of
> > | the application is to process or query TLD names themselves.
>
> Since the purpose of SPF is *not* to process or query TLD names
> themselves, I'd say I'm more convinced than ever that TLDs are no
> FQDNs in the context of SPF. Thanks for quoting that.

Interesting. Elsewhere there is guidance that says not to assume you have a
complete/correct list of TLDs and that the only thing that should parse as
invalid for a TLD is all numeric (I'll dig out the reference if anyone
cares).

Since we now allow a trailing dot and the purpose of an SPF library is most
definitely not to process or query TLD names themselves, it seems to me that
the reasonable approach would be to use the dot test for FQDN (has a dot and
TLD is not all numeric). Thus:

museum - Not a TLD, SPF result is always none.

museum. - Is a TLD, lookup the TXT record.

This allows TLDs to do SPF if they so choose, but doesn't force us to treat
OEMCOMPUTER as a TLD and thus cause lots of unnecessary DNS lookups.

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

On Mon, Mar 19, 2007 at 11:52:02AM -0400, Stuart D. Gathman wrote:
> On Sun, 18 Mar 2007, Frank Ellermann wrote:
>
> > Stuart D. Gathman wrote:
> >
> > > I'm not convinced that a label with no dot is a FQDN.
> > > I'll have to look up the definition.
> >
> > You really think TLDs are no FQDNs ? The best explanation
> > I know (and for that reason also an informative reference
> > in RFC 4408) is http://tools.ietf.org/html/rfc3696#section-2
> >
> > | Consequently, purported DNS names to be used in applications
> > | and to locate resources generally must contain at least one
> > | period (".") character. Those that do not are either invalid
> > | or require the application to supply additional information.
> > | Of course, this principle does not apply when the purpose of
> > | the application is to process or query TLD names themselves.
>
> Since the purpose of SPF is *not* to process or query TLD names
> themselves, I'd say I'm more convinced than ever that TLDs are no
> FQDNs in the context of SPF. Thanks for quoting that.

for the museum. example:

The machine with IP address 195.7.77.17 has name musedoma.museum.
It ought to say "HELO musedoma.museum" (if sending mail at all, dunno).

Should its PTR record point to "museum.", the situation would be
different IMHO.

A quick scan (i.e. not necessarily complete or correct) reveils the following
hostnames being in use when resolving TLDs
(dig +short $tld; dig -x $result # not compensating for timeouts and ignoring $x.root-servers.net.)

ip100-35.thdo.ncuk.net.
offshore.ai.
ns.nic.bi.
sound.dk-hostmaster.dk.
ip100-38.thdo.ncuk.net.
17.0-26.77.7.195.in-addr.arpa.
musedoma.museum.
tedside.pitcairn.net.pn.
pwregistry.pw.
234-31-251-64.serverpronto.com.
ip100-37.thdo.ncuk.net.
ws.


The host with name "ws." should, if it sends mail, say "HELO ws".
It should probably list policy "v=spf1 ip4:63.101.245.10 -all" or "v=spf1 a -all"
at domain "ws.".

There does not seem to be running a mailserver at this domain, at least
not one I can reach.

Alex

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

> Since the purpose of SPF is *not* to process or query TLD names
> themselves, I'd say I'm more convinced than ever that TLDs are no
> FQDNs in the context of SPF. Thanks for quoting that.

The purpose of SPF is to divine permitted and forbidden IPs based
on a "hello" domain or envelope sender address.

One of the mechanism it offers for this purpose is "a" specifying
IPs "by name" for an A or AAAA query.

Querying TLD "museum" I get an IP:
http://vweb.nass.com.au/cgi-bin/dnslookup?data=museum

Using "museum" as host in an http URL also works: http://museum

Other protocols might also work, but as far as SPF is concerned
we're only interested in A, AAAA, CNAME, MX, PTR, SPF, and TXT
records in DNS, or "ANY" record to distinguish it from NXDOMAIN.

TLD "museum" has the needed A record for SPF's "a" mechanism when
checked in conjunction with an IPv4 connection.

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

Alex van den Bogaerdt wrote:

> for the museum. example:

> The machine with IP address 195.7.77.17 has name musedoma.museum.
> It ought to say "HELO musedoma.museum" (if sending mail at all, dunno).

If it wishes to survive a reverse DNS test. The DNSOP WG has
just discussed an I-D in this direction:

http://tools.ietf.org/html/ietf-dnsop-reverse-mapping-considerations

This I-D is already watered down to the "you could at least try
to arrange reverse DNS" level in version 02, and there's still
some opposition... :-(

> Should its PTR record point to "museum.", the situation would be
> different IMHO.

See below.

> The host with name "ws." should, if it sends mail, say "HELO ws".

Arguably, it would be an SMTP (2821) syntax error. The 2821bis
changelog is fascinating:

| G.1. Changes from RFC 2821 to the initial (-00) version of this draft
[...]
| o syntax for "domain" corrected to permit user@x.y.z. and user@tld.
| references
[...]
| G.2. Changes from version -00 to -01
[...]
| 2. Syntax for, and discussion of, domains changed to permit single-
| label domain names, but only (with a SHOULD) if the trailing
| period is specified.
[...]

With that the state of the art might be what Scott and you said.

Don't look at the 2821bis ABNF too critical, it isn't ready, the
prose is in section 2.3.5 "Domain Names":

| A domain name (or often just a "domain") consists of one or more dot-
| separated components. In the case of a top-level domain used by
| itself in an email address, a single subdomain is used followed by a
| dot (a single-component name, without any dots, SHOULD NOT be
| supported: these are too easily confused with partial names. These
| components ("labels" in DNS terminology, RFC1035 [5]) are restricted
| for SMTP purposes to consist of a sequence of letters, digits, and
| hyphens drawn from the ASCII character set [1]. Domain names are
[...]

> It should probably list policy "v=spf1 ip4:63.101.245.10 -all" or
> "v=spf1 a -all" at domain "ws.".

Yes. Topic drift, for months (years ?) we said that "v=spf1 a -all"
is the "typical" HELO policy. But actually it doesn't reflect what
you talked about at the begin, reverse DNS.

Should we better propose "v=spf1 ptr -all" as typical HELO policy ?

> There does not seem to be running a mailserver at this domain, at
> least not one I can reach.

If somebody has already implemented 2821bis draft 01 that would be
very fast... :-)

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 Mon, 19 Mar 2007, Frank Ellermann wrote:

> Using "museum" as host in an http URL also works: http://museum

It doesn't work if local DNS configuration specifies a domain or
search path. E.g. for /etc/resolv.conf on unix systems:

domain example.com

Windows has a similar configuration.

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

On Mon, 19 Mar 2007, Frank Ellermann wrote:

> Don't look at the 2821bis ABNF too critical, it isn't ready, the
> prose is in section 2.3.5 "Domain Names":
>
> | A domain name (or often just a "domain") consists of one or more dot-
> | separated components. In the case of a top-level domain used by
> | itself in an email address, a single subdomain is used followed by a
> | dot (a single-component name, without any dots, SHOULD NOT be
> | supported: these are too easily confused with partial names. These
> | components ("labels" in DNS terminology, RFC1035 [5]) are restricted
> | for SMTP purposes to consist of a sequence of letters, digits, and
> | hyphens drawn from the ASCII character set [1]. Domain names are
> [...]

Ok, based on that, I might be convinced that "A:%{h}" should

not match for "HELO museum"
match (with appropriate IP) for "HELO museum."

> Should we better propose "v=spf1 ptr -all" as typical HELO policy ?

Only if you want to verify that the domain owner also controls
the IP address. This is in general true for large companies,
but almost never true for small companies and individuals.

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

On Mon, Mar 19, 2007 at 08:55:22PM +0100, Frank Ellermann wrote:

> Should we better propose "v=spf1 ptr -all" as typical HELO policy ?

Absolutely not.

This would match any subdomain of "museum.", including domains in
a different zone. Perhaps this example is not suited well, but
imagine a similar hostname "de." with such a policy ... Your suggestion
would allow your host to say "HELO de".

> > There does not seem to be running a mailserver at this domain, at
> > least not one I can reach.
>
> If somebody has already implemented 2821bis draft 01 that would be
> very fast... :-)

?

One doesn't need to receive mail in order to send mail. No 2821bis
needed for that.

Alex

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

>> Using "museum" as host in an http URL also works: http://museum

> It doesn't work if local DNS configuration specifies a domain or
> search path. E.g. for /etc/resolv.conf on unix systems:

> domain example.com

Interesting, I use "domain invalid" for this purpose on OS/2 in
file d:\mptn\etc\resolv (OS/2 uses TCP/IP stacks with BSD roots.)

Do you have the same issue for the following URLs:

1: http://museum/ (that's where I arrive when using "museum")
2: http://museum.
3: http://museum./ (that's where I arrive when using "museum.")

For the nslookup "searchpath" (only used by nslookup on my box) I
finally got rid of the bogus TLD "invalid" with "set nosearch" in
.nslookuprc

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 Monday 19 March 2007 16:54, Frank Ellermann wrote:
> Stuart D. Gathman wrote:
> >> Using "museum" as host in an http URL also works: http://museum
> >
> > It doesn't work if local DNS configuration specifies a domain or
> > search path. E.g. for /etc/resolv.conf on unix systems:
> >
> > domain example.com
>
> Interesting, I use "domain invalid" for this purpose on OS/2 in
> file d:\mptn\etc\resolv (OS/2 uses TCP/IP stacks with BSD roots.)
>
> Do you have the same issue for the following URLs:
>
> 1: http://museum/ (that's where I arrive when using "museum")
> 2: http://museum.
> 3: http://museum./ (that's where I arrive when using "museum.")
>
> For the nslookup "searchpath" (only used by nslookup on my box) I
> finally got rid of the bogus TLD "invalid" with "set nosearch" in
> .nslookuprc

For me the first two get me to a .com site (Firefox has a guessing function
that's on by default). Only the last one gets me to the museum TLD site.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070302
Ubuntu/dapper-security Firefox/1.5.0.10

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

Stuart D. Gathman wrote:

[I-D.klensin-rfc2821bis-01 section 2.3.5 "Domain Names"]
> based on that, I might be convinced that "A:%{h}" should

> not match for "HELO museum"
> match (with appropriate IP) for "HELO museum."

Apparently Scott also supports this approach. His reason
was to protect the DNS root servers and SPF checkers from
bogus queries for "oemcomputer" (no dot).

It's a compromise not directly related to anything I find
in the SPF spec., but in practice it makes sense.

Do we need that as erratum (or wannabe-erratum) wrt the
interpretation of a <target-name> when it only contains
a single label ?

What I have in mind is this:

1: MAIL FROM:<user@test>
2: MAIL FROM:<user@test.>

test. IN SPF "v=spf1 a:%{o}%{d}%{d} -all"

Is that testtestest (1) and test.test.test.test. (2), and
if yes, is it "our" problem to be addressed in the spec.,
and while that's not the case in an erratum ? Or should
we say WTF, getting trailing dots right is the problem of
the sender, and using %{o}%{d}%{d} is anyway a bad idea ?

>> Should we better propose "v=spf1 ptr -all" as typical
>> HELO policy ?

> Only if you want to verify that the domain owner also
> controls the IP address. This is in general true for
> large companies, but almost never true for small
> companies and individuals.

Okay, forget my stupid question. It's not the business
of a sender policy to express its support for a DNSOP I-D.

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

Scott Kitterman wrote:

>> 1: http://museum/ (that's where I arrive when using "museum")
>> 2: http://museum.
>> 3: http://museum./ (that's where I arrive when using "museum.")
[...]
> For me the first two get me to a .com site (Firefox has a guessing
> function that's on by default). Only the last one gets me to the
> museum TLD site.

Fascinating, how did Firefox end up with a "worse" guessing function
than my vintage '98 "mozilla 3" (aka netscape 3) ? When Stuart
reported his observation I first thought that it's a hallucination
on my side, and that museum.com redirects to museum, but the sites
are very different.

OTOH for http://google I arrive at http://google.com Apparently my
older guessing works by first trying it literally, and only if that
fails it tries to add com.

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

Alex van den Bogaerdt wrote:

>> Should we better propose "v=spf1 ptr -all" as typical HELO policy ?

> Absolutely not.

Yeah, Stuart already convinced me that this idea wasn't good. But I
don't get your reasoning:

> This would match any subdomain of "museum.", including domains in
> a different zone. Perhaps this example is not suited well, but
> imagine a similar hostname "de." with such a policy ... Your
> suggestion would allow your host to say "HELO de".

At the moment my host is xyzzy.dnsalias.org = 80.171.252.210
When I try nslookup -q=ptr 80.171.252.210 I get
210.252.171.80.in-addr.arpa name = d252210.dialin.hansenet.de

But "host" de doesn't have IP 80.171.252.210, it shouldn't match.
Besides TLD de also has no SPF policy using "v=spf1 ptr -all".

Something with your counterexample is wrong or I miss a clue.

[TLD ws]
>>> There does not seem to be running a mailserver at this domain,
>>> at least not one I can reach.

>> If somebody has already implemented 2821bis draft 01 that would
>> be very fast... :-)

> ?

> One doesn't need to receive mail in order to send mail. No 2821bis
> needed for that.

Strict 2821 implementations could reject "HELO ws" and "HELO ws."
as SMTP syntax errors.

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 Mon, 19 Mar 2007, Frank Ellermann wrote:

> Stuart D. Gathman wrote:
>
> >> Using "museum" as host in an http URL also works: http://museum
>
> > It doesn't work if local DNS configuration specifies a domain or
> > search path. E.g. for /etc/resolv.conf on unix systems:
>
> > domain example.com
>
> Interesting, I use "domain invalid" for this purpose on OS/2 in
> file d:\mptn\etc\resolv (OS/2 uses TCP/IP stacks with BSD roots.)
>
> Do you have the same issue for the following URLs:
>
> 1: http://museum/ (that's where I arrive when using "museum")
> 2: http://museum.
> 3: http://museum./ (that's where I arrive when using "museum.")

Trailing dot works. On linux systems (e.g. FC4), the plain museum
works only if there is no local name 'museum' (i.e., if it doesn't
find the relative name on the search path, it tries it as absolute).

I am now even more commited to the interpretation that museum needs a
trailing dot to be a FQDN.

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

On Mon, 19 Mar 2007, Frank Ellermann wrote:

> Strict 2821 implementations could reject "HELO ws" and "HELO ws."
> as SMTP syntax errors.

That's evidence that A:%{h} should never match in either case.
A:%{h} should not match something that should be an SMTP syntax error.

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

On Mon, 19 Mar 2007, Scott Kitterman wrote:

> On Monday 19 March 2007 16:54, Frank Ellermann wrote:
>> Stuart D. Gathman wrote:
>>>> Using "museum" as host in an http URL also works: http://museum
>>>
>>> It doesn't work if local DNS configuration specifies a domain or
>>> search path. E.g. for /etc/resolv.conf on unix systems:
>>>
>>> domain example.com
>>
>> Interesting, I use "domain invalid" for this purpose on OS/2 in
>> file d:\mptn\etc\resolv (OS/2 uses TCP/IP stacks with BSD roots.)
>>
>> Do you have the same issue for the following URLs:
>>
>> 1: http://museum/ (that's where I arrive when using "museum")
>> 2: http://museum.
>> 3: http://museum./ (that's where I arrive when using "museum.")
>>
>> For the nslookup "searchpath" (only used by nslookup on my box) I
>> finally got rid of the bogus TLD "invalid" with "set nosearch" in
>> .nslookuprc
>
> For me the first two get me to a .com site (Firefox has a guessing function
> that's on by default). Only the last one gets me to the museum TLD site.
>
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20070302
> Ubuntu/dapper-security Firefox/1.5.0.10

Interesting, but strange. I just tried it and all 3 get me to museum site.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2pre) Gecko/20061023
SUSE/2.0.0.1-0.1 Firefox/2.0.0.2pre

--
William Leibzon
Elan Networks
william@elan.net

-------
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 Mon, 19 Mar 2007, Stuart D. Gathman wrote:

> On Mon, 19 Mar 2007, Frank Ellermann wrote:
>
>> Strict 2821 implementations could reject "HELO ws" and "HELO ws."
>> as SMTP syntax errors.
>
> That's evidence that A:%{h} should never match in either case.
> A:%{h} should not match something that should be an SMTP syntax error.

This is one of the aspects of SMTP that can be considered a protocol bug.
2821bis is supposed to be discussed soon so we can ask about that.

--
William Leibzon
Elan Networks
william@elan.net

-------
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 Mon, Mar 19, 2007 at 06:50:42PM -0400, Stuart D. Gathman wrote:

> Trailing dot works. On linux systems (e.g. FC4), the plain museum
> works only if there is no local name 'museum' (i.e., if it doesn't
> find the relative name on the search path, it tries it as absolute).
>
> I am now even more commited to the interpretation that museum needs a
> trailing dot to be a FQDN.

Any domain needs a trailing dot; it is just that it becomes obvious
in cases where guessing fails if the FQDN has just one label.

That, or don't guess and just assume every entered domain is a FQDN
unless proven otherwise (i.e. first try to resolve, and only if that
fails try to append .com. and so on).

Alex

-------
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 Mon, Mar 19, 2007 at 10:37:27PM +0100, Frank Ellermann wrote:

> >> Should we better propose "v=spf1 ptr -all" as typical HELO policy ?

> > This would match any subdomain of "museum.", including domains in
> > a different zone. Perhaps this example is not suited well, but
> > imagine a similar hostname "de." with such a policy ... Your
> > suggestion would allow your host to say "HELO de".
>
> At the moment my host is xyzzy.dnsalias.org = 80.171.252.210
> When I try nslookup -q=ptr 80.171.252.210 I get
> 210.252.171.80.in-addr.arpa name = d252210.dialin.hansenet.de

So, the official name of 80.171.252.210 is d252210.dialin.hansenet.de.
but only if there is also a `forward' lookup possible. There is.

> But "host" de doesn't have IP 80.171.252.210, it shouldn't match.
> Besides TLD de also has no SPF policy using "v=spf1 ptr -all".

> Something with your counterexample is wrong or I miss a clue.

As you can see in my counter example, I suggested that __if__ "de."
had such a policy, __then__ the following would happen:

As per RFC4408 section 5.5, the official name is looked up for "ptr"
mechanisms. Start with the connecting IP address 80.171.252.210, lookup
the corresponding name "d252210.dialin.hansenet.de." and verify it using
an A(d252210.dialin.hansenet.de.) lookup which should return an address
of 80.171.252.210 (maybe more).

Domain "de." SPF policy (in either a TXT record, an SPF record, or both)
"v=spf1 ptr -all", would mean: any host with a name ending in "de."
would match on "ptr", the rest would match on "all".

In your hostname's case: All validated names (d252210.dialin.hansenet.de.)
are then compared against the target name "de." and a match does occur on
the "ptr" mechanism! This means your host would be allowed to "HELO de"

> Strict 2821 implementations could reject "HELO ws" and "HELO ws."
> as SMTP syntax errors.

Ah, yes, yet another RFC2821 bug. But we can't rely on bugs in other
protocols to help RFC4408. As soon as 2821 is fixed, my example would
work.

Besides, when has 2821 become a standard? 821 has this to say:
<domain> ::= <element> | <element> "." <domain>
<element> ::= <name> | "#" <number> | "[" <dotnum> "]"
<name> ::= <a> <ldh-str> <let-dig>

and thus "museum" is a valid domain. "de" is not, but I think there's
an update somewhere (or I found a bug in 821?)

Alex

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