----- Original Message -----
From: "Stuart D. Gathman" <stuart(_at_)bmsi(_dot_)com>
On Tue, 22 Nov 2005, Hector Santos wrote:
Ok, but what about the client side? I was talking about the
client software and how many are designed to work. I'm sure you
can figure it out. There is a reason for not being reliable. :-)
The client side (I assume you mean MUAs) should not be sending mail
directly. They should go through a proper MTA. That MTA can be at an
ISP for Windows users, or on the same machine for users of a real OS.
The MTA will of course accept funky HELO names from internal clients. But
that doesn't translate into accepting funky HELO names from external MTAs.
Ok, Stuart.
First, HELO/EHLO is unreliable for a reason. If it wasn't unreliable,
LMAP, SPF, etc, etc, will probably not need to exist. Ideals like CSV/CSA
would of mostly likely be the standard by name many moons ago.
Second, I agree with you, that in these days, HELO can not be ignored.
So, then you as a SERVER, you ask yourself, why it is unreliable? why can I
not trust the client domain name to be reliable?
The main historical reasons are:
1) Hard coded domain names not matching true IP machine
- single configuration used for multiple machines.
2) Dynamic domain names retrieved using one of two methods based
on the connecting SOCKET IP address:
- OS Socket Layer API function, gethostbyaddr()
- DNS Query, PTR record lookup.
I would be totally surprise if someone did not state or wasn't thinking:
"Whoaaaaa! Hold on there! Hector, gethostbyaddr() uses DNS queries!"
and I will say,
"True, if it doesn't resolve first to anything in already in cache,
ARP, HOSTS tables, or in the case of Windows' WINS database"
So for the server to assumed a valid A record, it is presuming the client
has a proper PTR record setup and that may not be the case.
The bottom line is this, if the client uses a DNS API function call to
perform a PTR query on the socket IP address, then it will most likely get
the proper client name. If it uses the socket layer gethostbyaddr()
function, it may not.
Finally, we have the probably of learned behavior. Since it is known not to
be a checked entity, the behavior is to just use anything you want. It
doesn't matter. This is what the SPAMMERS learned as one of the exploits of
SMTP. In short, the tradition is that no one checks it.
We are changing this, new email security methods are mandating compliants
and no doubt, the industry is increasingly learning how vital it is to have
a proper setup these days.
So these days, there *might* be a safe correlation that a HELO mismatch is
associated with a bad client. I think so, but not strong enough, YET, to
make this a hard coded rule. There is too much legacy reasons to make this
reliable.
However, if the CLIENT raises the BAR, "I USE SPF, I USE DKIM" and asserts a
higher intelligence, then in this case, YES, without a doubt, I believe a
HELO match is required. A good example is this:
HELO mail.domain1.com
MAIL user @ domain1.com
if domain1.com has a SPF record, then someone can make a STRONG case that
the client domain name, mail.domain1.com must have A record or put another
way, not FAIL under any idea. This is not a strong case with:
HELO mail.domain2.com
MAIL user @ domain1.com
because of the forwarding issues.
--
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