-----Original Message-----
From: Hector Santos [mailto:spf-discuss(_at_)winserver(_dot_)com]
Sent: donderdag 24 november 2005 1:22
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Re: SPF adoption statistics
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"
Yes it does. It also specifies a clear boundary for which this MUST
NOT is valid. You have just shown an example that does not help
your case.
Exactly.
Attacking me is not going to excuse your moronic behavior. It clearly
says "MUST NOT" reject.
Please show where "MUST NOT" is relaxed to:
"SHOULD NOT"
"MAY NOT"
"SHOULD CONSIDER NOT"
"ITS UP TO YOU"
"ROLL A DICE"
"SPF PEOPLE ARE THE EXCEPTION"
"ONLY IF SENDER IS USING WINDOWS"
"OH LOOK, I USE UNIX. I MUST BE GEEK! THEREFORE I CAN"
A "receiver MUST NOT refuse to accept a message, even if the
sender's HELO command fails verification" refers ONLY
to the failure to "verify that the HELO parameter really corresponds
to the IP address of the sender." It does not mean: "Hector
can use 'hdev1' for HELO/EHLO name."
Have a look at RFC 2821, section 3.6:
3.6 Domains
Only resolvable, fully-qualified, domain names (FQDNs) are permitted
when domain names are used in SMTP. In other words, names that can
be resolved to MX RRs or A RRs (as discussed in section 5) are
permitted, as are CNAME RRs whose targets can be resolved, in turn,
to MX or A RRs. Local nicknames or unqualified names MUST NOT be
used.
Your 'hdev1' is a local nickname. Please show where "MUST NOT" is relaxed
to:
"MAY NOT"
"EXCEPT IF SENDER IS USING GETHOSTBYADDR()"
"ITS UP TO YOU"
"ROLL A DICE"
"OH LOOK, I USE WINDOZE. THE RULES DON'T APPLY TO ME"
And further:
... The domain name given in the EHLO command MUST BE
either a primary host name (a domain name that resolves to an
A RR) or, if the host has no name, an address literal as
described in section 4.1.1.1.
Please show where "MUST BE" is relaxed to:
"MAY BE"
"EXCEPT IF SENDER IS USING GETHOSTBYADDR()"
"ITS UP TO YOU"
"ROLL A DICE"
"OH LOOK, I USE WINDOZE. THE RULES DON'T APPLY TO ME"
When I reject your "HELO hdev1", then you are thoroughly mistaken in
thinking the "MUST NOT refuse to accept" of RFC 821, section 3.5, protects
you from such a REJECT. Because that section exclusively deals with the
failure to "verify that the HELO parameter really corresponds to the IP
address of the sender." Nothing more.
The ONLY instance where RFC 821, section 3.5, would protect you from a
REJECT, is when you said, say, "HELO hdev1.com".
What remains is RFC 2821, which dictates that you cannot use names like
"hdev1" for HELO/EHLO name. Period.
- Mark
System Administrator Asarian-host.org
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx
-------
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