----- Original Message -----
From: "Mark" <admin(_at_)asarian-host(_dot_)net>
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."
Huh? Mark, you're in denial! :-)
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.
That isn't a rejection policy. If you don't believe me, why don't you ask
the author John Klensin, john-ietf(_at_)jck(_dot_)com(_dot_) I'm sure he will
set you
straight.
Your 'hdev1' is a local nickname.
Again, you fail to see the key issue here. You are an administrator which I
can understand. So I don't fault you. Really, but I know where you coming
from, from a mile away.
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.
You will be laugh out of the IETF forums with that thinking. However, since
you are administrator, a customer of SMTP software, we cater people like you
so that can have your own local policy. You probably have small social
network of friends anyway, so overall, you are no threat to the internet.
Sort of like dust mite. They exist, but they don't really bother anyone.
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.
It is said, that being in denial also makes you very good in illusional
justifications.
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.
Yet, it still happens and that's only one form of an incorrect HELO. There
are many forms of getting an incorrect domain, even if its fully qualified.
Just like you should above.
But overall, you fail the grasp the overall key issue here. It is understood
why you can't comprehend this rather detailed, system-wide oriented thinking
and its my fault to expect more of you. I don't blame you. Really. SMTP
authors have to write software that caters to people like you. SMTP authors
need to make it possible for administrators to do what they want - WITHIN
certain guidelines.
Today, the SPAM issue mandates greater scrutiny of all SMTP parameters. We
are one of the first vendors to move towards a strong SMTP compliancy OUT OF
THE BOX - (shrink wrapped, $3000 to $245 editions).
So we engineer the system to be STRONGER, yet offer an optimal backward
compatible system. That is important.
The HELO domain issue remains the SINGLE entity in SMTP that lack strength.
Out of the box (default on), we do a SYNTAX check for domain literals:
- Domain Literal must be bracketed
- Bracketed Domain Literal must match IP address
There is NO rejection policy again, but from a SYNTAX standpoint, this as
good as it can get.
One can say the "HDEV1" fails a syntax check since there is no TLD, but what
about "LocalHost"?
The problem is that it is FAR too broken of a legacy issue.
If you apply a no TLD check, then you risk losing many end user software and
not just WINDOZE users. Again, I can understand you don't care about
WINDOZE or whatever software the user is using. They must comply too.
But its all about your mindset. A legitimate business won't reject on a NO
TLD format. It just won't. But small and reclusive sites with little email,
small social network of friends, sure, you can get away with it.
But it isn't a standard.
Finally, just consider this.
I wish that was the standard and everyone followed it. Why?
Because once we have a STRONG HELO system, the chain of trust email security
methodologies are now possible. This would be bad news for SPF because
Dave's Crocker CVS/CSA protocol would now have a STRONG reason for living.
But there would be a MAJOR new suite of inventions based on HELO only if
this was a REQUIRE with a STRONG rejection policy behind it.
Why do you think CVS/CSA never got any traction? Why it wasn't able to beat
SPF? Why it isn't a standard today?
Because HELO checking is unreliable and the world-wide standard is a MUST
NOT reject policy. CVS/CSA is a "Ideal" concept that will probably work
with 4-5 years or more when one can finally say EVERYONE is using modern
software and every administrator is not lazy.
Hope this helps you see this alittle better.
--
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