Mailing List Archive

Stuart D. Gathman 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.

SMTP syntax is somewhat unrelated to the question "does it have an
address" (A or AAAA), and that's the purpose of the "a" mechanism.

"HELO _spf.example.com" is also an SMTP syntax error, and it will
stay an SMTP syntax error (underscore isn't LDH), nevertheless the
domain _spf.example.com can have an address.

Something that's definitely no SMTP syntax error is e.g.

MAIL FROM:<ws@example.com>

If the example.com policy uses "v=spf1 a:%{l} -all" you should get
the address of %{l}, here "ws", if it has an address, and match it.

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

Stuart D. Gathman wrote:

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

Won't fly, we get into the same trouble with a:%{l} for a local part
"museum" (without dot, but actually it doesn't matter). There are
also SPF constructs to select a single label out of several labels,
and eventually you've to check if it (whatever it is) has an address.

The only place to fix this would be the definition of <target-name>,
we could demand that it must have a trailing dot if it has only one
label, independent of the used macro(s), %{h}, %{l}, or what else.

And by "demand" I mean a very shaky "erratum", RFC 4408 obviously
doesn't do what Scott and you propose. At least "protecting the
DNS root servers" is a good excuse. I hope.

Add it anyway to the test suite, and let implementations do what
they like for the moment until that's resolved. One thing they
shouldn't do is crash.

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:
> Alex van den Bogaerdt wrote:
> > One doesn't need to receive mail in order to send mail. No 2821bis
> > needed for that.

Well, based on the notion that the receiver should always be able to
deliver a bounce to the return path, return paths that don't accept mail
could be considered unacceptable.

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

I don't think this is correct. A strict interpretation of RFC 2821
requires only the "EHLO" command -- not the "HELO" command -- to have an
FQDN. (This is obviously due to RFC 821 _not_ requiring an FQDN with
"HELO", and due to many legacy implementations not giving one.)

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

iD8DBQFGBbc/wL7PKlBZWjsRAv3mAJsFJfVT7HNDLyBGZlbMhKa6p8WZkQCbBYwb
fDb98j16yT+LnSrv7CXcZ9g=
=L7Sk
-----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

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

Frank Ellermann wrote:
> Stuart D. Gathman wrote:
> > I am now even more commited to the interpretation that museum needs
> > a trailing dot to be a FQDN.
>
> Won't fly, we get into the same trouble with a:%{l} for a local part
> "museum" (without dot, but actually it doesn't matter). There are
> also SPF constructs to select a single label out of several labels,
> and eventually you've to check if it (whatever it is) has an address.

- From a theoretical PoV, in a context that doesn't allow local name inter-
pretations (e.g. SPF records), "museum" -- with or without a trailing dot
- -- is an FQDN. No questions about it.

- From a practical PoV, SPFv1 doesn't support it, and this isn't something we
can fix with minor tweaks to the v=spf1 grammar.

There's also the issue of erroneous DNS queries to the root servers. We
don't want "OEMCOMPUTER" or the value of %{l} to be verified as a TLD,
effectively spamming the root servers. However, there's no conceptually
consistent way to distinguish "OEMCOMPUTER" from "museum" (without a
trailing dot).

Ergo, for SPFv3 a more sophisticated approach is needed:

* A literal "a:museum" mechanism (with or without a trailing dot) should
be allowed, as should "a:%{h}" with <helo> = "museum." (with a trailing
dot).

* On the other hand, <helo> = "museum" (without a trailing dot) should be
an input validation error, as should <sender-domain> = "museum"
(without a trailing dot), or, for that matter, <helo> = "1.2.3.4",
<helo> = "[1.2.3.4]", and <sender-domain> = "42".

* Input identity domains (<helo>, <sender-domain>) should get normalized
in a consistent way before policy processing (but after TLD valida-
tion), probably by stripping trailing dots and lower-casing them (so
expansion of "%{h}.%{h}" or "%{h}%{h}" is predictable).

> The only place to fix this would be the definition of <target-name>,
> we could demand that it must have a trailing dot if it has only one
> label, independent of the used macro(s), %{h}, %{l}, or what else.

<target-name> isn't an element of the v=spf1 grammar. It's a semantic
variable.

It seems obvious to me (now) that in RFC 4408 we should have differentiated
between syntactic validation (which is omnipresent in RFC 4408) and
semantic validation (which is almost completely absent). However, again,
this isn't something we can fix in v=spf1.

SPFv3 should do both syntactic and semantic validation, the latter
specifically including input value validation (see above) as well as the
validation of macro string expansion results (against the context in which
the macro string was used, i.e. requiring FQDN characteristics, etc.).

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

iD8DBQFGBb/qwL7PKlBZWjsRAqE7AKD/K5TOYwz/L4Au8uE6Dv4w5d14eACfYM2T
P0ten3DUZJHc5JkMJdOz30Y=
=tWMa
-----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

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

Stuart D. Gathman wrote:
> Ok, based on that, I might be convinced that "A:%{h}" should
>
> not match for "HELO museum"
> match (with appropriate IP) for "HELO museum."

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

Desirable, but not doable without majorly revolving RFC 4408. As unfor-
tunate as it may be, the concept of <target-name> (i.e. macro string
expansion result) validation is entirely unknown to RFC 4408. We cannot
graft it onto RFC 4408 retroactively, as that would be a major change.

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

I strongly object to a test-driven approach for amending/fixing RFC 4408.
We should not make the official(!) test suite "more current" than the
spec. If you want to propose an erratum to the spec, please propose it as
a wording change.

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

The best we can do with RFC 4408 is being "slightly stricter" or "slightly
more lenient". Grafting semantic validation or input value normalization
onto it is out of the question.

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

iD8DBQFGBcM2wL7PKlBZWjsRAkAJAJ9vdTDNhfbjgR1z92GWxeBfJ6FScACgtKoH
TKSVtpzgi6wuIvfZhLfJELA=
=DZuf
-----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:

> the concept of <target-name> (i.e. macro string expansion result)
> validation is entirely unknown to RFC 4408. We cannot graft it
> onto RFC 4408 retroactively, as that would be a major change.

Of course we can, it's obviously a corner case upsetting developers,
and we'll find a reasonable solution for it, erratum and/or 4408bis.

> I strongly object to a test-driven approach for amending/fixing
> RFC 4408. We should not make the official(!) test suite "more
> current" than the spec.

It's the job of the test suite to check relevant corner cases. As
long as there's no single "correct" outcome based on the spec. (or
more precisely the interpretaton of the spec. represented by the
test suite) or an approved erratum, there will be still completely
unacceptable results like saying PASS for "v=spf1 -a:%{h} ?all".

The test suite supports it to have more than one acceptable result,
but less than "any" outcome. Implementations should not crash for
such corner cases. Somebody just reported a potential dead loop
on the devel list. I think there's no "checkhost() MUST return a
result after at most one hour" or similar in the spec., but we'd
still say that it's a bug if a certified implementation simply
refuses to return a result in some corner cases.

If that's a conformance-FAIL or INCONCLUSIVE, who cares, but it's
certainly no conformance-PASS.

> If you want to propose an erratum to the spec, please propose
> it as a wording change.

Done, see separate article. BTW, there's now a new area director
for the IETF APPS area, Chris Newman.

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

Julian Mehnle wrote:

> From a theoretical PoV, in a context that doesn't allow local name inter-
> pretations (e.g. SPF records), "museum" -- with or without a trailing dot
> - -- is an FQDN. No questions about it.

+1

> From a practical PoV, SPFv1 doesn't support it, and this isn't something
> we can fix with minor tweaks to the v=spf1 grammar.

We could decree that it's invalid in chapter 4.8 for consistency with
the <domain-spec> construct always requiring more than one label (in
the absence of macros).

We could also decree that a single trailing dot found in <target-name>
is silently removed, and after that it's always added for proper DNS
FQDN queries (bypassing any local "search lists"). But actually I
think that's understood, and nobody needs it in prose somewhere.

> There's also the issue of erroneous DNS queries to the root servers.

The 2821 author (John) apparently thinks that this problem is slightly
exaggerated, and nothing that needs to be addressed in 2821bis. I've
asked him if he's sure, or if he should better ask the DNSOP folks.

This is however an issue where I won't take the next 2821bis draft as
gospel, for that I want something that survived IETF and IESG review.

Of course we could also ask them, the Council decided to contact two
DNSOP contributors anyway about an unrelated issue, and maybe asking
also for advice about this relatively harmless detail helps to break
the ice. BTW, we could also ask Stephane, also a DNSOP regular.

> <target-name> isn't an element of the v=spf1 grammar. It's a semantic
> variable.

Yes, with a somewhat underspecified semantic. We like predictable
deterministic results as far as DNS allows it, and so I'd say that
"use /dev/random to pick PermError or TempError" isn't in the spirit
of v=spf1... :-)

BTW, just a thought, we can also post an I-D with "updates 4408".
In fact we can post the errata as I-D, for a recent example see
<http://tools.ietf.org/html/draft-fajardo-dime-diameter-errata>:

| Diameter Specification Errata and Issues
| draft-fajardo-dime-diameter-errata-00.txt
[...]
| Abstract
|
| This document is a compilation the defects found in the DIAMETER
| protocol specification based on interoperability event(s) and
general
| implementation discussions. This document is meant to be a
companion
| document to RFC3588 and provides a historical reference to the
| changes that will incorporated in RFC3588's BIS document.

I like that approach (as a model for us).

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, Mar 24, 2007 at 11:41:44PM +0000, Julian Mehnle wrote:

> Frank Ellermann wrote:
> > Alex van den Bogaerdt wrote:
> > > One doesn't need to receive mail in order to send mail. No 2821bis
> > > needed for that.
>
> Well, based on the notion that the receiver should always be able to
> deliver a bounce to the return path, return paths that don't accept mail
> could be considered unacceptable.

out01.example.com. A 192.0.2.1
out01.example.com. MX 0 in01.example.com.
out01.example.com. TXT "v=spf1 ip4:192.0.2.1 -all"


There's no need for out01.example.com. to accept mail (from the outside
anyway). And that's what I meant.

HTH
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

Alex van den Bogaerdt wrote:

> out01.example.com. A 192.0.2.1
> out01.example.com. MX 0 in01.example.com.
> out01.example.com. TXT "v=spf1 ip4:192.0.2.1 -all"

> There's no need for out01.example.com. to accept mail
> (from the outside anyway). And that's what I meant.

Isn't "if it can't receive mail it has no business to
send mail" an axiom in the e-mail architecture ? If
there's a problem with a sender you'd wish to contact
them, and if that doesn't work you could block them.

Any system that includes an SMTP server supporting mail relaying or
delivery MUST support the reserved mailbox "postmaster" as a case-
insensitive local name. This postmaster address is not strictly
necessary if the server always returns 554 on connection opening (as
described in section 3.1). The requirement to accept mail for
postmaster implies that RCPT commands which specify a mailbox for
postmaster at any of the domains for which the SMTP server provides
mail service, as well as the special case of "RCPT TO:<Postmaster>"
(with no domain specification), MUST be supported.

Without "always returning 554" not accepting mail to
<postmaster> could be enough for an RFCI listing...
as an example see the old RFCI-entry listing RFCI :-)

I think the listing rules are now more pragmatic.

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:
> > From a theoretical PoV, in a context that doesn't allow local name
> > inter- pretations (e.g. SPF records), "museum" -- with or without a
> > trailing dot - -- is an FQDN. No questions about it.
>
> +1
>
> > From a practical PoV, SPFv1 doesn't support it, and this isn't
> > something we can fix with minor tweaks to the v=spf1 grammar.
>
> We could decree that it's invalid in chapter 4.8 for consistency with
> the <domain-spec> construct always requiring more than one label (in
> the absence of macros).
>
> We could also decree that a single trailing dot found in <target-name>
> is silently removed,

You didn't understand what I said. We cannot add this to v=spf1, EVER.
Such additions would be semantic changes and existing implementations
would have to undergo significant changes in order to remain compliant.

> and after that it's always added for proper DNS FQDN queries (bypassing
> any local "search lists"). But actually I think that's understood, and
> nobody needs it in prose somewhere.

Yeah, I'd expect that none of the existing SPF implementations performs DNS
lookups with local search lists. It would be like applying a local search
list to "MX 0 museum." RRs...

> > There's also the issue of erroneous DNS queries to the root servers.
>
> The 2821 author (John) apparently thinks that this problem is slightly
> exaggerated, and nothing that needs to be addressed in 2821bis. I've
> asked him if he's sure, or if [we] should better ask the DNSOP folks.

Please tell us his response when he gives you one.

> This is however an issue where I won't take the next 2821bis draft as
> gospel, for that I want something that survived IETF and IESG review.
>
> Of course we could also ask them, the Council decided to contact two
> DNSOP contributors anyway about an unrelated issue, and maybe asking
> also for advice about this relatively harmless detail helps to break
> the ice. BTW, we could also ask Stephane, also a DNSOP regular.

I (being quite busy right now) haven't contacted them yet, but I will.

> > <target-name> isn't an element of the v=spf1 grammar. It's a semantic
> > variable.
>
> Yes, with a somewhat underspecified semantic.

True, but we cannot introduce post-macro-expansion validation into v=spf1.
It would be an entirely new concept.

> BTW, just a thought, we can also post an I-D with "updates 4408".

No, we cannot change v=spf1 in this manner, EVER.

Let's just begin work on v=spf3 instead.

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

iD8DBQFGBkqmwL7PKlBZWjsRAs2cAJ96u1n8k3DT0jLE1PrpYOKdShBMbgCg/Eit
h908vHqNJwdRaJzjY1V6Sp0=
=lElp
-----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 Sun, Mar 25, 2007 at 06:03:03AM +0200, Frank Ellermann wrote:
> Alex van den Bogaerdt wrote:
>
> > out01.example.com. A 192.0.2.1
> > out01.example.com. MX 0 in01.example.com.
> > out01.example.com. TXT "v=spf1 ip4:192.0.2.1 -all"
>
> > There's no need for out01.example.com. to accept mail
> > (from the outside anyway). And that's what I meant.
>
> Isn't "if it can't receive mail it has no business to
> send mail" an axiom in the e-mail architecture ? If

In the architecture: yes. On the same server: no.

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