Mailing List Archive: SPF: Devel

domain literals [was: The require-valid-helo test]

Index | Next | Previous | View Threaded

nobody at xyzzy

Mar 16, 2007, 2:33 AM

Post #1 of 10 (3404 views)
Permalink

domain literals [was: The require-valid-helo test]

Roberto Alsina wrote:

> what's one supposed to do on the mail server if a client uses
> that kind of HELO? Not important, but I am a curious guy :-)

As far as SPF is concerned a:%{h} after HELO [127.2.3.4] doesn't
match because domain literals don't have A-records - same idea
as for HELO oemcomputer

For a "receiver policy" unrelated to SPF you could decree that
you're willing to talk with "HELO [127.2.3.4]" if the client IP
actually is 127.2.3.4 because domain literals are allowed in
SMTP. But you could refuse to talk with it if the IP differs.

Your question inspired me to new (maybe) test case proposals:

HELO museum and HELO museum. (with a trailing dot)

Both are SMTP syntax errors (2821 or 2821bis alike), but of
course receivers are free to accept it anyway like oemcomputer.

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

For the test suite s/museum/test/ or similar.

Frank

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

ralsina at kde

Mar 16, 2007, 6:23 AM

Post #2 of 10 (3269 views)
Permalink

Re: domain literals [was: The require-valid-helo test] [In reply to]

On Fri 16 Mar 2007 06:33:06 Frank Ellermann wrote:
> Roberto Alsina wrote:
> > what's one supposed to do on the mail server if a client uses
> > that kind of HELO? Not important, but I am a curious guy :-)
>
> As far as SPF is concerned a:%{h} after HELO [127.2.3.4] doesn't
> match because domain literals don't have A-records - same idea
> as for HELO oemcomputer

I was thinking abut the RFC's strong suggestion to check the HELO identity.
If the HELO identity is a literal IP (which is legal), that can't be done.

--
("\''/").__..-''"`-. . Roberto Alsina
`9_ 9 ) `-. ( ).`-._.`) ralsina [at] kde
(_Y_.)' ._ ) `._`. " -.-' KDE Developer (MFCH)
_..`-'_..-_/ /-'_.'
(l)-'' ((i).' ((!.' Buenos Aires - Argentina

Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it. --Brian W. Kernighan

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

scott at kitterman

Mar 16, 2007, 7:54 AM

Post #3 of 10 (3271 views)
Permalink

Re: domain literals [was: The require-valid-helo test] [In reply to]

On Fri, 16 Mar 2007 10:23:19 -0300 Roberto Alsina <ralsina [at] kde> wrote:
>On Fri 16 Mar 2007 06:33:06 Frank Ellermann wrote:
>> Roberto Alsina wrote:
>> > what's one supposed to do on the mail server if a client uses
>> > that kind of HELO? Not important, but I am a curious guy :-)
>>
>> As far as SPF is concerned a:%{h} after HELO [127.2.3.4] doesn't
>> match because domain literals don't have A-records - same idea
>> as for HELO oemcomputer
>
>I was thinking abut the RFC's strong suggestion to check the HELO identity.
>If the HELO identity is a literal IP (which is legal), that can't be done.

IIRC, RFC 4408 says "if HELO is a FQDN". A literal IP is not a FQDN and so
HELO check is a no-op.

Scott K

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

stuart at bmsi

Mar 16, 2007, 7:59 AM

Post #4 of 10 (3277 views)
Permalink

Re: domain literals [was: The require-valid-helo test] [In reply to]

On Fri, 16 Mar 2007, Frank Ellermann wrote:

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

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

--
Stuart D. Gathman <stuart [at] bmsi>
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

ralsina at kde

Mar 16, 2007, 8:10 AM

Post #5 of 10 (3278 views)
Permalink

Re: domain literals [was: The require-valid-helo test] [In reply to]

On Fri 16 Mar 2007 11:54:47 Scott Kitterman wrote:
> On Fri, 16 Mar 2007 10:23:19 -0300 Roberto Alsina <ralsina [at] kde> wrote:
> >On Fri 16 Mar 2007 06:33:06 Frank Ellermann wrote:
> >> Roberto Alsina wrote:
> >> > what's one supposed to do on the mail server if a client uses
> >> > that kind of HELO? Not important, but I am a curious guy :-)
> >>
> >> As far as SPF is concerned a:%{h} after HELO [127.2.3.4] doesn't
> >> match because domain literals don't have A-records - same idea
> >> as for HELO oemcomputer
> >
> >I was thinking abut the RFC's strong suggestion to check the HELO
> > identity. If the HELO identity is a literal IP (which is legal), that
> > can't be done.
>
> IIRC, RFC 4408 says "if HELO is a FQDN". A literal IP is not a FQDN and so
> HELO check is a no-op.

Well, it's understood it should do that, but it's not explicit, unless I am
reading wrong (or at the wrong place):

2.1. The HELO Identity

The "HELO" identity derives from either the SMTP HELO or EHLO command
(see [RFC2821]). These commands supply the SMTP client (sending
host) for the SMTP session. Note that requirements for the domain
presented in the EHLO or HELO command are not always clear to the
sending party, and SPF clients must be prepared for the "HELO"
identity to be malformed or an IP address literal. At the time of
this writing, many legitimate E-Mails are delivered with invalid HELO
domains.

It is RECOMMENDED that SPF clients not only check the "MAIL FROM"
identity, but also separately check the "HELO" identity by applying
the check_host() function (Section 4) to the "HELO" identity as the
<sender>.

--
("\''/").__..-''"`-. . Roberto Alsina
`9_ 9 ) `-. ( ).`-._.`) ralsina [at] kde
(_Y_.)' ._ ) `._`. " -.-' KDE Developer (MFCH)
_..`-'_..-_/ /-'_.'
(l)-'' ((i).' ((!.' Buenos Aires - Argentina

Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it. --Brian W. Kernighan

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

nobody at xyzzy

Mar 16, 2007, 9:33 AM

Post #6 of 10 (3279 views)
Permalink

Re: domain literals [In reply to]

Roberto Alsina wrote:

> it's understood it should do that, but it's not explicit, unless I am
> reading wrong (or at the wrong place):

> 2.1. The HELO Identity
[...]

That might be a part of "oral history" (hidden in the list archives :-)
that you've missed. At some point in time there was a draft saying
that "weird" HELOs (also including domain literals) should be handled
as PermError (or similar) because nobody wants them anyway.

After some discussions that was dropped for several reasons:

- The S in SPF is for "sender", not "receiver"
- It's perfectly okay if a receiver accepts HELO [127.2.3.4] coming
from a client with IP 127.2.3.4
- It's also okay if a receiver accepts domain literals where the IP
doesn't match
- And some receivers claim that they're even forced to accept crap
like "oemcomputer"
- As there is no "sender policy" for an IP, matching or otherwise,
let alone for a "domain" oemcomputer, SPF is moot about this.
- Receivers are free to do whatever they like, but they can't claim
that IP literals or weirder HELOs are "SPF errors"

Frank (still interested in two "HELO museum" test cases :-)

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

jacob at internet24

Mar 16, 2007, 10:00 AM

Post #7 of 10 (3271 views)
Permalink

Re: Re: domain literals [In reply to]

> - And some receivers claim that they're even forced to accept crap
> like "oemcomputer"

Isn't everybody?

Unless you are not dealing with customers or
your customers are a very special bread, rejecting email
on the basis of helo strings is a recipe for desaster....

Some highlights from today's log:

"Acountants" (sic!), "OFFICE", "asp-server"...

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

Attachments:

signature.asc (0.19 KB)

scott at kitterman

Mar 16, 2007, 12:46 PM

Post #8 of 10 (3275 views)
Permalink

Re: Re: domain literals [In reply to]

On Friday 16 March 2007 12:33, Frank Ellermann wrote:
> Roberto Alsina wrote:
> > it's understood it should do that, but it's not explicit, unless I am
> > reading wrong (or at the wrong place):
> >
> > 2.1. The HELO Identity
>
> [...]
>
> That might be a part of "oral history" (hidden in the list archives :-)
> that you've missed. At some point in time there was a draft saying
> that "weird" HELOs (also including domain literals) should be handled
> as PermError (or similar) because nobody wants them anyway.
>
> After some discussions that was dropped for several reasons:
>
> - The S in SPF is for "sender", not "receiver"
> - It's perfectly okay if a receiver accepts HELO [127.2.3.4] coming
> from a client with IP 127.2.3.4
> - It's also okay if a receiver accepts domain literals where the IP
> doesn't match
> - And some receivers claim that they're even forced to accept crap
> like "oemcomputer"
> - As there is no "sender policy" for an IP, matching or otherwise,
> let alone for a "domain" oemcomputer, SPF is moot about this.
> - Receivers are free to do whatever they like, but they can't claim
> that IP literals or weirder HELOs are "SPF errors"
>
> Frank (still interested in two "HELO museum" test cases :-)

No, it's in the RFC:

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

So the correct SPF result for the IP literal is NONE. I believe it's the same
for your museum cases too. If the test suite doesn't cover this, it should
IMO.

Scott K

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

stuart at bmsi

Mar 16, 2007, 2:32 PM

Post #9 of 10 (3266 views)
Permalink

Re: Re: domain literals [In reply to]

On Fri, 16 Mar 2007, Scott Kitterman wrote:

> 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".
>
> So the correct SPF result for the IP literal is NONE. I believe it's the same
> for your museum cases too. If the test suite doesn't cover this, it should
> IMO.

The test suite covers the cases listed in the RFC (long label, empty label,
OEMCOMPUTER, RCODE 3). It does not check domain literals in particular,
so I'll add that. Although it is a pretty wierd programmer that would
return None for "foo..bar" and throw permerror for "[1.2.3.4]".

--
Stuart D. Gathman <stuart [at] bmsi>
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

nobody at xyzzy

Mar 17, 2007, 7:32 AM

Post #10 of 10 (3267 views)
Permalink

Re: domain literals [In reply to]

Thomas Jacob wrote:

> Some highlights from today's log:
> "Acountants" (sic!), "OFFICE", "asp-server"...

If it would be at least spam you could insist on
"SMTP syntax error"... <sigh /> One thing's sure,
they've to do better if they want to get on some
kind of "forwarder white list".

Frank

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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads