On Sun, Feb 29, 2004 at 10:59:14AM -0500, Theo Schlossnagle wrote:
I think that this disagreement is confused. No one is undervaluing
checking the EHLO/HELO argument (or at least they shouldn't be). The
argument is if and why it belongs in SPF.
If, why and how.
o Many legacy systems do not use FQDNs, but local labels.
o many use names with underscores
o some send IPs purposefully as they don't believe (or want) their
FQDN to be meaningful.
All of these: No problem. But there's another one:
o Some systems use spoofed but otherwise correct HELO information
What if
Received: from longsword.omniti.com (ip-66-80-117-3.nyc.megapath.net
[66.80.117.3])
by portent.listbox.com (Postfix) with ESMTP id 53A16B1DF
for <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>; Sun, 29 Feb 2004
10:59:22 -0500 (EST)
would have read
Received: from aol.com (ip-66-80-117-3.nyc.megapath.net [66.80.117.3])
by portent.listbox.com (Postfix) with ESMTP id 53A16B1DF
for <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>; Sun, 29 Feb 2004
10:59:22 -0500 (EST)
(If this is important to the reader: Substitute aolr-v4.evip.aol.com
for aol.com in all of my examples).
SPF's goal it to prevent fraud by interpreting the policies of the
sending domain. So, any decision to refuse the message based on that
is a _local_ policy decision and doesn't fit "well" in SPF -- hence all
of these arguments.
"helo aol.com" from a host not having anything to do with aol, is fraud.
"helo localhost", "helo my_windows_box" and "helo [66.80.117.3]" are not.
Making a policy decision based on EHLO arguments is also against the
RFC:
Not really.
4.1.4 Order of Commands
[Paragraph 6]
An SMTP server MAY verify that the domain name parameter in the EHLO
command actually corresponds to the IP address of the client.
However, the server MUST NOT refuse to accept a message for this
reason if the verification fails: the information about verification
failure is for logging and tracing only.
Note the MUST NOT actually means a lot here. I personally think it
should be a "SHOULD NOT", but I didn't write the scripture. So, adding
this into SPF would make SPF explicitly break RFC 2821 which I don't
believe it currently does.
This section forbids to reject messages when hostname->IP->hostname does
not match. For instance, multi-homed hosts could use the name associated
with one interface while connecting to you using another interface.
The section does _NOT_ forbid you to reject period.
One host, two interfaces, a.b.c.d and e.f.g.h and both are setup correctly
in DNS.
hostA.example.tld A a.b.c.d
hostB.example.tld A e.f.g.h
and the reverse DNS for those two.
Connection from e.f.g.h to you.
case#1: HELO hostA.example.tld
case#2: HELO hostB.example.tld
case#3: HELO ip-66-80-117-3.nyc.megapath.net
case#4: HELO no.valid.hostname.here
First three MUST NOT be rejected as far as RFC 2821 4.1.4 paragraph 6 is
concerned. However, nothing in RFC2821 tells you one cannot reject
case#3 on other grounds (such as SPF). Case#4 may be rejected.
Let's reverse the reasoning: If nothing allows me to reject on the basis
of the HELO command, paragraph 4 of that same section would not have been
included in the RFC.
I also don't understand what we loose by leaving this out. I think
that SPF should _not_ be the end-all, be-all of a mail validation
system. It will ultimately be used in conjunction with a variety of
other tools and domains will still implement arbitrary ad-hoc policies
that suit them -- pedantic EHLO checking is one of those.
"Received: from aol.com ...".
Hey aol, you have relayed this message. Fix that!
In here, "aol.com" presumably is the sender (sending host). Asking aol
if they think ip-66-80-117-3.nyc.megapath.net is allowed to use aol.com
as an HELO parameter, is IMHO worth considering for SPF.
cheers,
Alex
--
begin sig
http://www.googlism.com/index.htm?ism=alex+van+den+bogaerdt&type=1
This message was produced without any <iframe tags