On Tue, 12 Jun 2007, Renaud Allard wrote:
> Well, if I summarize RFC
> RFC1912 section 2.1, paragraph 2
> Also,
> PTR records must point back to a valid A record, not a alias defined
> by a CNAME.
>
> RFC2821 section 3.6
> 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.
>
> RFC2821 section 4.1.1, paragraph 6
> An SMTP server MAY verify that the domain name parameter in the EHLO
> command actually corresponds to the IP address of the client.
> However, the server MUST NOT refuse to accept a message for this
> reason if the verification fails
>
> That means if a mail server has a PTR of
> 123.123.123.123.dynamic.example.net, that
> 123.123.123.123.dynamic.example.net resolves to its IP, and server
> HELOes with www.google.com. The remote mail server MUST NOT reject the
> message based on this info.
>
> Can someone cancel this by citing another RFC?
This may be by-the-by for this discussion, however ...
RFCs do not dictate local site policy. If you do not wish to accept email
from anyone with the letter "e" in their email address, then you may
choose to do so. No RFC compels you to accept any message.
If your site policy says that a connecting mail server's IP must have a
PTR that points to a name which resolves to (at least) that IP address,
and that the name is used in the HELO parameter, then this overrides any
statement in the RFCs and you are perfectly free to implement such a rule.
You have to be in a position to justify this to the recipients affected by
this site policy, of course, and deal with the problems it introduces; but
on balance, you might decide the cost of that is less than the cost of not
implementing the rule. You might also have to be prepared to be shouted
at by people who believe that technical compliance with the RFCs overrules
every other consideration, and accept that you are rejecting mail that is
otherwise 'legitimate' on the basis of this policy.
I suppose the other point is that if you are deploying techniques to
reduce the amount of Bad Mail (you might read this as "spam") you receive,
and you have observed that the only legitimate connections which HELO as
something.google.com (even the rather unlikely example quoted above
"
www.google.com") are those which come from IPs with PTR to
something-else.google.com, then you may well choose to implement local
policy that refuses to accept messages from
something-else.obviouslynotgoogle.com which try to HELO as
something.google.com.
The common case is that you refuse to accept a connection where the HELO
is your own host's name. If the HELO is your own host's name, the PTR of
the connecting IP probably does not point to the same name as used in the
HELO. Technically, in refusing this connection, it could be claimed you
have violated this part of the RFC, although in actual fact you have
refused it for another reason (local site policy: "I have reason to
believe the connecting host is lying to me, therefore I will not place any
faith in the legitimacy of messages that it tries to send me"). How far
you take this is up to you, your conscience, and your customers.
In this regard, RFC 2821 is somewhat lacking, and has not kept step with
the times.
http://homepages.tesco.net/J.deBoynePollard/FGA/smtp-avoid-helo.html
is interesting reading, whatever your position.
Jethro.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Jethro R Binks
Computing Officer, IT Services
University Of Strathclyde, Glasgow, UK
