Mailing List Archive

Stuart D. Gathman wrote:

> HELO anomaly

> The mechanism "A:%{h}" could be useful to match when the HELO name
> is valid (a FQDN that resolves to the connect IP). However, I believe
> that an invalid HELO name (e.g. "JUPITER") must then cause a permerror.

I think that SPF expects syntactically valid input for the macros. The
infamous OEMCOMPUTER is an SMTP syntax error for 2821, you could reject
it before the SPF Permerror.

> it is an error in the SMTP client, not in the SPF record.

For HELO-related pieces of a policy that's a bit academic, isn't it ?
The person to get the HELO right should know who's responsible to get
the SPF policy right, and vice versa, a typical HELO policy is "a -all".

Or is OEMCOMPUTER a misconfigured box of a user in your network ? What
is then the idea, do you want him or her to get in ESMTP / SPF troubles,
or do you want that this somehow works ?

> Using "A:%{h}._helo.example.com" and duplicating all your MTA names
> would help, but I'm not sure it would remove all the permerrors.

Why not simply fix these HELO names at the MTAs with corresponding
"a -all" HELO-policies ? Apparently I miss a clue in your scenario.

> a best_guess policy of "a/24 a:%{h} mx/24 ptr" will pass if a valid
> helo name is given.

The connecting IP is not necessarily an IP of the HELO name under 2821
rules. Even if it is, do you really want an SPF PASS for anybody who
manages that the connecting IP is one of the a:%{h} IPs ? Any dynamic
DNS host like xyzzy.h3c.de could manage that.

> However, I want to pass only if the valid helo name also ends in the
> mailfrom (i.e. as if %{h} were added to the PTR RRs).

Sorry, I never really understood PTR. How far away is "ptr:%{h}" from
what you want ? Something like "ptr:%{h2}" is probably not what you'd
try as "best guess" for say .co.uk

MAIL FROM user@xyzzy.claranet.de won't fly for HELO relais.claranet.de,
let alone HELO relais.de.clara.net. "Best guess" is black magic... :-)

Frank



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

On Fri, 6 Oct 2006, Frank Ellermann wrote:

> Stuart D. Gathman wrote:
>
> > The mechanism "A:%{h}" could be useful to match when the HELO name
> > is valid (a FQDN that resolves to the connect IP). However, I believe
> > that an invalid HELO name (e.g. "JUPITER") must then cause a permerror.
>
> I think that SPF expects syntactically valid input for the macros. The
> infamous OEMCOMPUTER is an SMTP syntax error for 2821, you could reject
> it before the SPF Permerror.

Unfortunately, way too many of my clients customers send their email
with OEMCOMPUTER as the HELO name. Rejecting on invalid HELO in general is
regrettably not an option at this late stage of RFC2821 apostasy.
However, a sender policy can tell you to reject on invalid HELO
for a particular domain via A:%{h} - except for the PERMERROR anomaly which
could cause you to accept invalid HELOs instead!

> > it is an error in the SMTP client, not in the SPF record.
>
> For HELO-related pieces of a policy that's a bit academic, isn't it ?
> The person to get the HELO right should know who's responsible to get
> the SPF policy right, and vice versa, a typical HELO policy is "a -all".
>
> Or is OEMCOMPUTER a misconfigured box of a user in your network ? What
> is then the idea, do you want him or her to get in ESMTP / SPF troubles,
> or do you want that this somehow works ?
>
> > Using "A:%{h}._helo.example.com" and duplicating all your MTA names
> > would help, but I'm not sure it would remove all the permerrors.
>
> Why not simply fix these HELO names at the MTAs with corresponding
> "a -all" HELO-policies ? Apparently I miss a clue in your scenario.

You want the SPF record to require a valid HELO record. You want
spammers with invalid HELO to get FAIL, not permerror.

> > a best_guess policy of "a/24 a:%{h} mx/24 ptr" will pass if a valid
> > helo name is given.
>
> The connecting IP is not necessarily an IP of the HELO name under 2821
> rules. Even if it is, do you really want an SPF PASS for anybody who
> manages that the connecting IP is one of the a:%{h} IPs ? Any dynamic
> DNS host like xyzzy.h3c.de could manage that.

No I don't. I want a PASS only if the HELO name can be verified and
ends with the MFROM domain. Of course, I can hack this in outside of
SPF, but it is *so* clean to just reuse SPF machinery to evaluate
a generic "SPF" record, that I hate to abandon that approach. Hence
my wish.

> > However, I want to pass only if the valid helo name also ends in the
> > mailfrom (i.e. as if %{h} were added to the PTR RRs).
>
> Sorry, I never really understood PTR. How far away is "ptr:%{h}" from
> what you want ? Something like "ptr:%{h2}" is probably not what you'd
> try as "best guess" for say .co.uk

I am not talking about HELO SPF (the SPF record evaluated for the HELO
name). I am talking about MFROM SPF, but using the HELO name.
As the administrator of many of those unfortunate sites who have no
way to install proper PTR records (thanks to incompetent and monopolistic
IPSs), HELO can provides a verifiable FQDN in the context of an SMTP
transaction. It would be nice if that FQDN were added to those provided
by RDNS.

--
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/?listname=spf-devel@v2.listbox.com

On Thursday 05 October 2006 22:50, Stuart D. Gathman wrote:
> On Fri, 6 Oct 2006, Frank Ellermann wrote:
> > Stuart D. Gathman wrote:
> > > The mechanism "A:%{h}" could be useful to match when the HELO name
> > > is valid (a FQDN that resolves to the connect IP). However, I believe
> > > that an invalid HELO name (e.g. "JUPITER") must then cause a permerror.
> >
> > I think that SPF expects syntactically valid input for the macros. The
> > infamous OEMCOMPUTER is an SMTP syntax error for 2821, you could reject
> > it before the SPF Permerror.
>
> Unfortunately, way too many of my clients customers send their email
> with OEMCOMPUTER as the HELO name. Rejecting on invalid HELO in general is
> regrettably not an option at this late stage of RFC2821 apostasy.
> However, a sender policy can tell you to reject on invalid HELO
> for a particular domain via A:%{h} - except for the PERMERROR anomaly which
> could cause you to accept invalid HELOs instead!

Except RFC 4408 says:

4.3. Initial Processing

If the <domain> is malformed (label longer than 63 characters, zero-length
label not at the end, etc.) or is not a fully qualified domain name, or if
the DNS lookup returns "domain does not exist" (RCODE 3), check_host()
immediately returns the result "None".

As I read that, OEMCOMPUTER as HELO gets NONE for a result. My recollection
is that we went round on this several times during the development of the RFC
and decided that rejecting because HELO isn't FQDN isn't SPF's job.

Scott K

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

On Thu, 5 Oct 2006, Scott Kitterman wrote:

> > Unfortunately, way too many of my clients customers send their email
> > with OEMCOMPUTER as the HELO name. Rejecting on invalid HELO in general is
> > regrettably not an option at this late stage of RFC2821 apostasy.
> > However, a sender policy can tell you to reject on invalid HELO
> > for a particular domain via A:%{h} - except for the PERMERROR anomaly which
> > could cause you to accept invalid HELOs instead!
>
> Except RFC 4408 says:
>
> 4.3. Initial Processing
>
> If the <domain> is malformed (label longer than 63 characters, zero-length
> label not at the end, etc.) or is not a fully qualified domain name, or if
> the DNS lookup returns "domain does not exist" (RCODE 3), check_host()
> immediately returns the result "None".

> As I read that, OEMCOMPUTER as HELO gets NONE for a result. My recollection
> is that we went round on this several times during the development of the RFC
> and decided that rejecting because HELO isn't FQDN isn't SPF's job.

You are all missing the point. I am *not* talking about doing SPF
for the HELO domain. I am talking about publishing and evaluating an SPF
record for the MFROM domain, that gives FAIL when HELO is invalid.

Perhaps some test scenarios will make it clear:

tests:
require-valid-helo:
helo: OEMCOMPUTER
host: 1.2.3.4
mailfrom: test@example.com
result: fail
zonedata:
example.com:
- SPF: v=spf1 -include:_spfh.%{d} ip4:1.2.3.0/24 -all
_spfh.example.com:
- SPF: v=spf1 -a:%{h} +all

Should this return fail or 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/?listname=spf-devel@v2.listbox.com

On Thu, 5 Oct 2006 23:48:02 -0400 (EDT) "Stuart D. Gathman"
<stuart@bmsi.com> wrote:
>On Thu, 5 Oct 2006, Scott Kitterman wrote:
>
>> > Unfortunately, way too many of my clients customers send their email
>> > with OEMCOMPUTER as the HELO name. Rejecting on invalid HELO in
general is
>> > regrettably not an option at this late stage of RFC2821 apostasy.
>> > However, a sender policy can tell you to reject on invalid HELO
>> > for a particular domain via A:%{h} - except for the PERMERROR anomaly
which
>> > could cause you to accept invalid HELOs instead!
>>
>> Except RFC 4408 says:
>>
>> 4.3. Initial Processing
>>
>> If the <domain> is malformed (label longer than 63 characters,
zero-length
>> label not at the end, etc.) or is not a fully qualified domain name, or
if
>> the DNS lookup returns "domain does not exist" (RCODE 3), check_host()
>> immediately returns the result "None".
>
>> As I read that, OEMCOMPUTER as HELO gets NONE for a result. My
recollection
>> is that we went round on this several times during the development of
the RFC
>> and decided that rejecting because HELO isn't FQDN isn't SPF's job.
>
>You are all missing the point. I am *not* talking about doing SPF
>for the HELO domain. I am talking about publishing and evaluating an SPF
>record for the MFROM domain, that gives FAIL when HELO is invalid.
>
>Perhaps some test scenarios will make it clear:
>
>tests:
> require-valid-helo:
> helo: OEMCOMPUTER
> host: 1.2.3.4
> mailfrom: test@example.com
> result: fail
>zonedata:
> example.com:
> - SPF: v=spf1 -include:_spfh.%{d} ip4:1.2.3.0/24 -all
> _spfh.example.com:
> - SPF: v=spf1 -a:%{h} +all
>
>Should this return fail or permerror?

Permerror I think. Because the target of the include is not an FQDN, the include returns None
which for include is a permerror.


Scott K

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

Stuart D. Gathman wrote:

>> Apparently I miss a clue in your scenario.

Okay, s/Apparently I miss/Obviously I still miss/ :-)

> You want spammers with invalid HELO to get FAIL, not permerror.

How about rejecting all HELOs you consider as "invalid", making
exceptions for your own users ? Or are you talking about unknown
strangers sending direct-to-your-MX ?

> I want a PASS only if the HELO name can be verified and ends
> with the MFROM domain.
[...]
>> How far away is "ptr:%{h}" from what you want ?

> I am not talking about HELO SPF (the SPF record evaluated for
> the HELO name). I am talking about MFROM SPF, but using the
> HELO name.

"ptr:%{h}" is a directive, it doesn't care what you try to check,
MAIL FROM or HELO, and its result doesn't depend on what you try
to check. If the connecting IP has a verified domain matching
the HELO domain you get a PASS, otherwise you get no match.

It matches for HELO example.net and GetHostByAddr xyz.example.net
- please correct me, I'm lost with PTR - but probably not for a
HELO smtp.example.net and host xyz.example.net.

With %{h2} you could strip the smtp of smtp.example.net, but that
would fail for domains like example DOT me DOT uk or domains with
more labels.

> It would be nice if that FQDN were added to those provided by
> RDNS.

Sorry, I really don't get what you want. Maybe post an example
(wanted PASS), and one or two near misses (no PASS expected).

Input is IP, its hosts (gethostbyaddr) if any, the MAIL FROM,
its IPs (gethostbyname) if any, the HELO, and its IPs if any.

Frank


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

Stuart D. Gathman wrote:

> tests:
> require-valid-helo:
> helo: OEMCOMPUTER
> host: 1.2.3.4
> mailfrom: test@example.com
> result: fail
> zonedata:
> example.com:
> - SPF: v=spf1 -include:_spfh.%{d} ip4:1.2.3.0/24 -all
> _spfh.example.com:
> - SPF: v=spf1 -a:%{h} +all

> Should this return fail or permerror?

You try to get the IP of OEMCOMPUTER. With `nslookup oemcomputer`
I get "not found". With `host oemcomputer` I get "unknown host".

[section 5, last paragraph]
| If the server returns "domain does not exist" (RCODE 3), then
| evaluation of the mechanism continues as if the server returned
| no error (RCODE 0) and zero answer records.

You get no match (and no FAIL) for "-a:%{h}". Therefore you get
a PASS for the next directive "+all". That's turned into a match
by the "include: _spfh.%{d}". The policy maps this match into an
overall FAIL for the "-" qualifier of "-include:_spfh.%{d}". IMO
you should get a FAIL as specified in your expected test result.

Frank


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

On Fri, 6 Oct 2006, Frank Ellermann wrote:

> > It would be nice if that FQDN were added to those provided by
> > RDNS.
>
> Sorry, I really don't get what you want. Maybe post an example
> (wanted PASS), and one or two near misses (no PASS expected).
>
> Input is IP, its hosts (gethostbyaddr) if any, the MAIL FROM,
> its IPs (gethostbyname) if any, the HELO, and its IPs if any.

decription:
These are not real RFC tests, but illustrate what I
wish would happen for a better "guessed" SPF record.
tests:
wishful-thinking-pass:
description: >-
Valid HELO ending in MFROM domain.
comment: >-
The MFROM for this example does not have an SPF record, so this test
invents the 'spf' test attribute to supply the guessed SPF record.
helo: smtp.example.com:
host: 1.2.3.4
mailfrom: user@example.com
result: pass
spf: v=spf1 a/24 mx/24 ptr
wishful-thinking-neutral
description: >-
Valid HELO not ending in MFROM domain.
comment: >-
The MFROM for this example does not have an SPF record, so this test
invents the 'spf' test attribute to supply the guessed SPF record.
helo: smtp.spammer.com:
host: 1.2.3.5
mailfrom: user@example.com
result: neutral
spf: v=spf1 a/24 mx/24 ptr
zonedata:
example.com:
- A: 5.6.7.8
- MX: [0,mx.example.com]
mx.example.com:
- A: 5.6.7.9
smtp.example.com:
- A: 1.2.3.4
smtp.spammer.com:
- A: 1.2.3.5

--
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/?listname=spf-devel@v2.listbox.com

On Fri, 6 Oct 2006, Frank Ellermann wrote:

> Stuart D. Gathman wrote:
>
> > tests:
> > require-valid-helo:
> > helo: OEMCOMPUTER
> > host: 1.2.3.4
> > mailfrom: test@example.com
> > result: fail
> > zonedata:
> > example.com:
> > - SPF: v=spf1 -include:_spfh.%{d} ip4:1.2.3.0/24 -all
> > _spfh.example.com:
> > - SPF: v=spf1 -a:%{h} +all
>
> > Should this return fail or permerror?
>
> You try to get the IP of OEMCOMPUTER. With `nslookup oemcomputer`
> I get "not found". With `host oemcomputer` I get "unknown host".
>
> [section 5, last paragraph]
> | If the server returns "domain does not exist" (RCODE 3), then
> | evaluation of the mechanism continues as if the server returned
> | no error (RCODE 0) and zero answer records.
>
> You get no match (and no FAIL) for "-a:%{h}". Therefore you get
> a PASS for the next directive "+all". That's turned into a match
> by the "include: _spfh.%{d}". The policy maps this match into an
> overall FAIL for the "-" qualifier of "-include:_spfh.%{d}". IMO
> you should get a FAIL as specified in your expected test result.

Excellent observations. RFC para 5/10 says no match when DNS
lookup fails. Contrast that, however, with para 8.1/2, where
"OEMCOMPUTER" is not a legal domain spec. By the latter, the
result should be permerror (4.6/2). Arguing that syntax checking should
take place *before* macro expansion is rather ambiguous.

Heh. Test suite *before* RFC. Repeat after me...

--
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/?listname=spf-devel@v2.listbox.com

Stuart D. Gathman wrote:

> RFC para 5/10 says no match when DNS lookup fails.

How are those d****d paragrahs counted, text after
the 10th block of blank lines excluding page headers ?
Works for 5/10, testing 8.1/2 I arrive at:

| domain-spec = macro-string domain-end
| domain-end = ( "." toplabel [ "." ] ) / macro-expand

> Contrast that, however, with para 8.1/2, where
> "OEMCOMPUTER" is not a legal domain spec.

OEMCOMPUTER is certainly no ( "." <toplabel> [ "." ] )

But %{h} is a valid <macro-expand>, not a syntax error.

> By the latter, the result should be permerror (4.6/2).

IMO %{h} is no syntax error. Its dubious content is a
different issue. And besides I don't believe in this
optional trailing dot nonsense introduced by the Council
without consensus.

It's junk that should be removed in an IETF Last Call
for 4408bis. While adding the lost SMTP error code for
optional PermError rejects, but I digress.

> Arguing that syntax checking should take place *before*
> macro expansion is rather ambiguous.

There is no syntax for <target-name>, the expanded form
of <domain-spec> specified in 4.8/1. Without syntax for
<target-name> it only says "a series of labels separated
by periods". Maybe that's an omission, or it needs an
explanation that the expanded stuff can be rather weird,
in essence any octets - minus dots within a label, that
can't fly without a way to escape "embedded dots".

Maybe add some tests with mad HELO identities referenced
by %{h}, the OEMCOMPUTER is a start, a <target-name> with
no dot. How about HELO "hello\ world!" ? It's a clear
2821 syntax error, but if you try SPF anyway it's a %{h}.

Frank


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

Stuart D. Gathman wrote:

> decription:
> These are not real RFC tests, but illustrate what I
> wish would happen for a better "guessed" SPF record.
> tests:
> wishful-thinking-pass:
> description: >-
> Valid HELO ending in MFROM domain.
> comment: >-
> The MFROM for this example does not have an SPF record, so this test
> invents the 'spf' test attribute to supply the guessed SPF record.
> helo: smtp.example.com:
> host: 1.2.3.4
> mailfrom: user@example.com
> result: pass
> spf: v=spf1 a/24 mx/24 ptr
> wishful-thinking-neutral
> description: >-
> Valid HELO not ending in MFROM domain.
> comment: >-
> The MFROM for this example does not have an SPF record, so this test
> invents the 'spf' test attribute to supply the guessed SPF record.
> helo: smtp.spammer.com:
> host: 1.2.3.5
> mailfrom: user@example.com
> result: neutral
> spf: v=spf1 a/24 mx/24 ptr
> zonedata:
> example.com:
> - A: 5.6.7.8
> - MX: [0,mx.example.com]
> mx.example.com:
> - A: 5.6.7.9
> smtp.example.com:
> - A: 1.2.3.4
> smtp.spammer.com:
> - A: 1.2.3.5

I'm not sure if I can interpret the YAML correctly, an attempt:

In the first case the connecting IP is 1.2.3.4. The mechanisms
"a/24 mx/24" don't match: 1.2.3.4 doesn't belong to 5.6.7.0/24.

For PTR you'd check 4.3.2.1.in-addr.arpa, find smtp.example.com,
verify that smtp.example.com has an IP 1.2.3.4, and then you'd
check if smtp.example.com "ends in the <target-name> domain".

Here <target-name> is the RHS of the mailfrom: user@example.com.

That's the case, you get a PASS. And the same procedure for IP
1.2.3.5 results in a verified smtp.spammer.com, but spammer.com
doesn't equal example.com, you get a NEUTRAL (as default because
there's nothing after the "ptr" in your best guess record).

Apparently that works as you want it, where's the problem ?

Frank


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

On Sat, 7 Oct 2006, Frank Ellermann wrote:

> IMO %{h} is no syntax error. Its dubious content is a
> different issue. And besides I don't believe in this
> optional trailing dot nonsense introduced by the Council
> without consensus.
>
> It's junk that should be removed in an IETF Last Call
> for 4408bis. While adding the lost SMTP error code for
> optional PermError rejects, but I digress.
>
> > Arguing that syntax checking should take place *before*
> > macro expansion is rather ambiguous.
>
> There is no syntax for <target-name>, the expanded form
> of <domain-spec> specified in 4.8/1. Without syntax for
> <target-name> it only says "a series of labels separated
> by periods". Maybe that's an omission, or it needs an
> explanation that the expanded stuff can be rather weird,
> in essence any octets - minus dots within a label, that
> can't fly without a way to escape "embedded dots".

We agree then that "a:oemcomputer" is a syntax error,
however, you claim the "a:%{h}" is NOT a syntax error, even
when %{h} expands to "oemcomputer", because %{h} COULD expand to
something valid. Please give me the precise rules whereby one draws the line
between these two poles, so that I can add appropriate test cases around that
line. I'm sure implementors will have as much trouble pulling these rules from
the penumbras of the RFC as I do - and the test cases will come in handy.

Example rules:

easy to implement rule: Any domain spec containing a macro
is never a syntax error. (The macro might expand to something that
makes it valid.)

hard to implement rule: A domain spec containing macros is a syntax error
when no possible macro expansion could ever make it a valid.

--
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/?listname=spf-devel@v2.listbox.com

On Sat, 7 Oct 2006, Frank Ellermann wrote:

> In the first case the connecting IP is 1.2.3.4. The mechanisms
> "a/24 mx/24" don't match: 1.2.3.4 doesn't belong to 5.6.7.0/24.
>
> For PTR you'd check 4.3.2.1.in-addr.arpa, find smtp.example.com,
> verify that smtp.example.com has an IP 1.2.3.4, and then you'd
> check if smtp.example.com "ends in the <target-name> domain".

You wouldn't find anything for 4.3.2.1.in-addr.arpa, because no
such PTR records are provided in the test case. If any PTR records
are to be found, the test case provides them.

> Apparently that works as you want it, where's the problem ?

The problem is when you can't actually add PTR records (because you
have less than 256 ips with an incompetent monopoly).

P.S. Actually, you can *always* get T1 service from a competent ISP
that provides PTR service (e.g. AT&T). However, this can be very
expensive for a small business. Getting a full T1 to an arbitrary
location can run $900/mo. (The price gets as low as $300/mo where you
don't need it because of competent cable/fiber/DSL alternatives.)

--
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/?listname=spf-devel@v2.listbox.com

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

Sorry for replying to this thread that late, but I was busy with
implementing Mail::SPF, among other things.

Stuart D. Gathman wrote:
> HELO anomaly
>
> The mechanism "A:%{h}" could be useful to match when the HELO name
> is valid (a FQDN that resolves to the connect IP). However, I believe
> that an invalid HELO name (e.g. "JUPITER") must then cause a permerror.
> I don't think that was intended, since it is an error in the SMTP
> client, not in the SPF record. [...]

Please, let's not consider "PermError" an error that can only result from
errors in the SPF record. At least not when thinking outside the "RFC
4408" box. In the long term (RFC 4408bis and SPFv3), "PermError" should
be the equivalent to SMTP's 5xx error code, i.e. an error condition that
will re-occur given the same input data -- which should include not only
the SPF record but also the other SPF input parameters (such as the HELO
identity). If we want a "SPF record faulty"-only error code, let's call
it "PolicyError" or something and make it a sub-code of "PermError".

See below.

> Unfortunately, way too many of my clients customers send their email
> with OEMCOMPUTER as the HELO name. Rejecting on invalid HELO in general
> is regrettably not an option at this late stage of RFC2821 apostasy.

That shouldn't be an issue. End-user software should never be allowed to
connect to recipient MTAs directly. Instead, they should be channeled
through a sender-side submission server (MSA) with authentication. The
MSA can then ignore any brain-dead input data and override it when
relaying the mail.

Frank Ellermann wrote:
> There is no syntax for <target-name>, the expanded form of <domain-spec>
> specified in 4.8/1. Without syntax for <target-name> it only says "a
> series of labels separated by periods". Maybe that's an omission, or it
> needs an explanation that the expanded stuff can be rather weird, [...]

Stuart D. Gathman wrote:
> We agree then that "a:oemcomputer" is a syntax error, however, you claim
> the "a:%{h}" is NOT a syntax error, even when %{h} expands to
> "oemcomputer", because %{h} COULD expand to something valid.

Frank hit the nail on the head, and you drove it in the rest of the way.
The problem is that no validation behavior has been specified in RFC 4408
for expanded macro values.

> Please give me the precise rules whereby one draws the line between these
> two poles, so that I can add appropriate test cases around that line.
> I'm sure implementors will have as much trouble pulling these rules from
> the penumbras of the RFC as I do - and the test cases will come in handy.

I think what needs to be done, specification-wise, is to create another
type of error -- let's call it "input error". So "a:oemcomputer" would be
a PolicyError, "a:{h}" would be generally legal, but if the HELO identity
is malformed, a InputError would be thrown during evaluation. If the
input data (e.g. the HELO identity) to a macro expansion is in itself
correctly formed but the macro expansion yields an invalid expanded value
(because the macro was used in a hazardous way in a domain-spec), it would
again be a PolicyError.

PermError
|
+-PolicyError
|
+-InputError

I'll remind you that I said that this is just a broader view on the issue,
_beyond_ the narrow RFC 4408 box. Perhaps we can draw conclusions for how
to read between the lines of RFC 4408 without maneuvering outselves into a
nonsensical corner with regard to future specifications (RFC 4408bis or
SPFv3).

Frank Ellermann wrote:
> Maybe add some tests with mad HELO identities referenced by %{h}, the
> OEMCOMPUTER is a start, a <target-name> with no dot. How about HELO
> "hello\ world!" ? It's a clear 2821 syntax error, but if you try SPF
> anyway it's a %{h}.

Now of course we cannot change RFC 4408, so the question is: do we want to
have the test-suite cover issues in the first place that RFC 4408 is
silent about? I'm not sure we can do that with a good conscience.

If we want to read between the lines of RFC 4408 and extend the test-suite
accordingly, given the broader perspective from above, I'd say that "a:
%{h}" with HELO = "OEMCOMPUTER" should throw a PermError during evaluation
(obviously not during record parsing).

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

iD8DBQFFW0wZwL7PKlBZWjsRAglzAKCYWGH4NDkvJmmd27lPKNCNXgIsxQCfeefw
6tSmZlslYBGymwXVlSSzFuE=
=RTtU
-----END PGP SIGNATURE-----

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

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

Frank Ellermann wrote:
> [...] And besides I don't believe in this optional trailing dot nonsense
> introduced by the Council without consensus.
>
> It's junk that should be removed in an IETF Last Call for 4408bis.

... _if_ there will be a 4408bis as such. (I'm not strictly against it,
but I think the same amount of work better ought to be invested into an
SPFv3, given the fact that we can't change a lot of things in another
SPFv1 spec anyway.)

> [Also] adding the lost SMTP error code for optional PermError rejects
> [...]

I added that to the errata page <http://new.openspf.org/RFC_4408/Errata>.

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

iD8DBQFFW07mwL7PKlBZWjsRAhGhAJ4naC41TWjAfDSehwVItZaVdgQBLACeLBTu
8J2ngzxY/TNMzENu/X/sne4=
=GL6w
-----END PGP SIGNATURE-----

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

Hi,
I have been a lurker on this list up until now, but I have a common use
case that seems to contradict what Julian has said below. Unless I am
missing some subtlety here, whenever I send email to another user on my
mail server my end-user software is connecting directly to my recipient
MTA, using the same mechanism that a remote mail server would use to
deliver mail to my mail server. The validation mechanism is different
in that a login is required, but that is the only difference I know of.
Since I administer a small organization I can enforce proper HELO names,
but in general this is not true.

Cheers,
Art

Julian Mehnle wrote:
> <snip>
>> Unfortunately, way too many of my clients customers send their email
>> with OEMCOMPUTER as the HELO name. Rejecting on invalid HELO in general
>> is regrettably not an option at this late stage of RFC2821 apostasy.
>>
>
> That shouldn't be an issue. End-user software should never be allowed to
> connect to recipient MTAs directly. Instead, they should be channeled
> through a sender-side submission server (MSA) with authentication. The
> MSA can then ignore any brain-dead input data and override it when
> relaying the mail.
>
> <snip>
> -------
> To unsubscribe, change your address, or temporarily deactivate your subscription,
> please go to http://v2.listbox.com/member/?list_id=1007
>

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

Julian Mehnle wrote:

> PermError
> |
> +-PolicyError
> |
> +-InputError

Nice concept, the "inputerror" part should cover all cases of
"impossible" queries caused by bogus input like adjacent dots.

> Perhaps we can draw conclusions for how to read between the
> lines of RFC 4408 without maneuvering outselves into a
> nonsensical corner with regard to future specifications (RFC
> 4408bis or SPFv3).

They forced us to use "status experimental". It's perfectly
okay if we use this bug (wrong status) as feature (for fixes).

> do we want to have the test-suite cover issues in the first
> place that RFC 4408 is silent about?

The test suite can contain test cases where the expected result
is unclear, but at least some results are definitely wrong.
Implementations shouldn't reboot or crash if confronted with
adjacent dots (example). And implementors should think about
what they do (up to the cases where you said you'd ignore the
spec. intentionally).

Ideally you can limit "intentionally" to violating a SHOULD or
similar, without touching a MUST. If you cannot let's start
4408bis a.s.a.p., waiting until late 2007 is anyway a bad plan:

4408bis drafts over some serious iterations could take months.

Frank


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

On Wed, 15 Nov 2006, Julian Mehnle wrote:

> > Unfortunately, way too many of my clients customers send their email
> > with OEMCOMPUTER as the HELO name. Rejecting on invalid HELO in general
> > is regrettably not an option at this late stage of RFC2821 apostasy.
>
> That shouldn't be an issue. End-user software should never be allowed to
> connect to recipient MTAs directly. Instead, they should be channeled
> through a sender-side submission server (MSA) with authentication. The
> MSA can then ignore any brain-dead input data and override it when
> relaying the mail.

I'm not talking about end-user software. Believe it or not, MTAs for
groups of people use, not "OEMCOMPUTER", but "JUPITER" or other other
meaningless garbage.

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

On Wed, 15 Nov 2006, Arthur Kahlich wrote:

> I have been a lurker on this list up until now, but I have a common use
> case that seems to contradict what Julian has said below. Unless I am
> missing some subtlety here, whenever I send email to another user on my
> mail server my end-user software is connecting directly to my recipient
> MTA, using the same mechanism that a remote mail server would use to
> deliver mail to my mail server. The validation mechanism is different
> in that a login is required, but that is the only difference I know of.
> Since I administer a small organization I can enforce proper HELO names,
> but in general this is not true.

You don't need to enforce proper HELO names with SMTP AUTH. That is
an "internal" (within same administrative boundary) connection. PCs
connecting to a company SMTP relay can use OEMCOMPUTER or whatever.

Public MTAs, on the other hand, should ALWAYS have a correct HELO name.

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

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

Stuart D. Gathman wrote:
> On Wed, 15 Nov 2006, Julian Mehnle wrote:
> > > Unfortunately, way too many of my clients customers send their email
> > > with OEMCOMPUTER as the HELO name. Rejecting on invalid HELO in
> > > general is regrettably not an option at this late stage of RFC2821
> > > apostasy.
> >
> > That shouldn't be an issue. End-user software should never be allowed
> > to connect to recipient MTAs directly. Instead, they should be
> > channeled through a sender-side submission server (MSA) with
> > authentication. The MSA can then ignore any brain-dead input data and
> > override it when relaying the mail.
>
> I'm not talking about end-user software. Believe it or not, MTAs for
> groups of people use, not "OEMCOMPUTER", but "JUPITER" or other other
> meaningless garbage.

And you have to accept mail from them? Sorry to read that. :-(

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

iD8DBQFFW5ibwL7PKlBZWjsRAiAkAJ99ObPYdJGpaMVDzhJOEEylI+qBYwCfUhx0
J0nm1h9kwccJAAj00qG9p4k=
=EnHe
-----END PGP SIGNATURE-----

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

On Wed, 15 Nov 2006, Julian Mehnle wrote:

> > I'm not talking about end-user software. Believe it or not, MTAs for
> > groups of people use, not "OEMCOMPUTER", but "JUPITER" or other other
> > meaningless garbage.
>
> And you have to accept mail from them? Sorry to read that. :-(

Yeah, and my clients already think of me as the email nazi. They don't
see why anyone should care...

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