----- Original Message -----
From: "Graham Murray" <graham(_at_)gmurray(_dot_)org(_dot_)uk>
"Hector Santos" <spf-discuss(_at_)winserver(_dot_)com> writes:
Have you written SMTP server or in this case SMTP client software?
My mistake, I should have said client as it is the client which sends
EHLO to the server. There is no need for the client's IP address to
have a PTR record. All that is required is that either the client has
an A record, in which case it sends its FQDN as the parameter to EHLO,
or it does not, in which case it sends its IP address literal in the
EHLO. In particular there is no requirement for the FQDN in the EHLO
sent by the client to match any PTR records for the IP address which
connects to the server.
I guess all this really tells you is why EHLO/HELO is unreliable :-)
We are not talking about what is required, but how the world molded and
evolved over 20+ years of operations. Some might call that "Intelligent
Design" <g>
Lets look at RFC 2821, section 3.6 domains:
- 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.
This tells a developer that he needs to put a DOMAIN that the SERVER can use
with a A record request. That would mean:
1) A hard corded known FQDN, or
2) A A/PTR record set the DOMAIN/IP address
Alternatively, he can
3) Use a BRACKETED domain literal.
Lets look at RFC 2821, section
4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO)
These commands are used to identify the SMTP client to the SMTP
server. The argument field contains the fully-qualified domain name
of the SMTP client if one is available. In situations in which the
SMTP client system does not have a meaningful domain name (e.g., when
its address is dynamically allocated and no reverse mapping record is
available), the client SHOULD send an address literal (see section
4.1.3), optionally followed by information that will help to identify
the client system.
So here it is telling you that it is possible to have a dynamically
allocation where no PTR record is available, a domain literal should be
used. But it doesn't NOT say that a PTR could be available which could be
checked for.
In other words, it does not say:
"Don't bother checking for PTR."
The reality is that there is a LEGACY market of software that do use a PTR
lookup for dynamic OPERATIONS, not just because it is DYNAMICALLY
allocations.
The reality is that RFC 2821 is only 5 years (April 2001) and RFC 821 is
still a prevailing document with little information on how the DOMAIN is
defined in DNS. Beyond RFC 821 and before 2821, a very important 1989
Hosting Requirement Document, RFC 1123, was considered the "HandBook" for
many developers, including myself.
RFC 1123 helped clean up things for SMTP operations. For HELO, it says:
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.
And this statement above is very prevailing. It means that you can PUT junk
and your system MUST NOT reject. This is a 17 years old document. RFC
2821 is only a 5 year old document.
The reality from a developer standpoint is that there is still legacy
behavior to:
1) Use a HARD corded value,
2) Use a SOCKET layer call, NOT, I repeat NOT DNS PTR LOOKUP
to obtain the domain name, gethostbyaddr().
and it is highly probable the gethostbyaddr() will return:
a) The computer netbios name, or whats in the HOSTS file, or
b) A round-robin, rotated PTR lookup result.
In other case, it is quite possible to obtain a DOMAIN that will not result
in a A record match for the RECEIVER.
The proper way (more reliable) is *not* to use the socket call,
gethostbyaddr(), since this has historical implementation to use local or
local network caching or hosting machine information - NOT DNS information.
In other words, until there is 100% mandate that enforces HELO/EHLO must
always be correct and allows an enforcement for RECEIVERS to reject based on
it, there is little incentive to change it. There is no need too.
If this was enforced 100% today, the odds are VERY high, that many MUAs and
MTAs, will instantly fail, that includes, millions of MTAs deploywed in the
market place, and love'em or hate'em Microsoft popular Outlook MUA and I'm
sure many others.
So we all know the "rules" as they are TODAY, and Yes, I agree that "each
day" the odds are better and better that the HELO is followed to the letter,
and that the BAD guys still uses legacy ideas, but we are not at a point
yet, IMO, where it can be a 100% trigger to detect bad malicious senders.
--
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