----- Original Message -----
From: "Alex van den Bogaerdt" <alex(_at_)ergens(_dot_)op(_dot_)het(_dot_)net>
Newsgroups: spf.-.sender.policy.framework.discussion
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Wednesday, November 23, 2005 5:49 PM
Subject: Re: [spf-discuss] Re: SPF adoption statistics
I'll see your statement without proof, and raise you RFC1033 which
tells me otherwise:
Great. So we have RFCs from 1987 and 1996 pointing out how to manage
DNS and now, at the end of 2005, people are still saying it doesn't
work that way because windows and {aol|yahoo|tele2|wannado|...} cannot
cope with it.
Nonsense. You know, as long as you keep blaming Windows for his particular
issues, you are simply not going to get anyone to take you serious.
This problem PRE-DATES WIndows entry into the EMAIL world with Outlook and
the PROBLEM started on UNIX for that matter. See the EXIM notes I posted.
Sometimes I wonder why we are trying to make things better, if people
will not be adjusting anyway. Almost everyone wants fraud to go away,
but not a single big organisation is willing to put their money where
their mouth is and do things right. Some are worse than others, granted,
but they are all saving a few bucks at the expense of other netizens.
You are not going to find a must more stickler to rules and promoter of
following SMTP compliancy as one of the key ways to address the bad actors
of the email world, than myself.
However, you are talking as a single site administrator. You are not
talking about the components that make it all happen that were designed for
over 20+ years. The bottom line is that there are still a SIGNIFICANT
amount of GOOD actors with operations that may not produce a valid HELO
domain. Windows's Outlook is one of the legacy systems. But it did not, I
repeat, it did not begin with Windows. I never used Outlook in 1989. I
don't think it existed back then. But guess what, RFC 1123, still considered
on the most significant handbook for hosting developers, clearly said in
1989:
From RFC 1123 - Requirements for Internet Hosts
5.2.5 HELO Command: RFC-821 Section 3.5
The sender-SMTP MUST ensure that the <domain> parameter in a
HELO command is a valid principal host domain name for the
client host. As a result, the receiver-SMTP will not have to
perform MX resolution on this name in order to validate the
HELO parameter.
The HELO receiver MAY verify that the HELO parameter really
corresponds to the IP address of the sender. However, the
receiver MUST NOT refuse to accept a message, even if the
sender's HELO command fails verification.
How more explicit can it get? it says "MUST NOT" not "SHOULD NOT"
Now, you can choose to IGNORE the specification. You have that right as a
LOCAL POLICY administrator.
But don't expect the SMTP developers to change anytime soon to enforce what
you think across the board. It isn't going to happen.
The only way it will change is with TIME and with augmented technology like
SPF who have specifications that further requires a correct FQDN for
HELO/EHLO. As more and more specs do this, then over time, more systems
will be expected to be correct and then maybe, quite maybe, the RFC 2821
specifications can be updated to ALLOW local policies to REJECT.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
-------
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/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com