> -----Original Message-----
> From: Greg A. Woods [mailto:woods@most.weird.com]
> Sent: Monday, June 30, 2003 6:12 PM
> To: Troy Settle
> Cc: Exim Users Mailing List
> Subject: RE: Now well off-topic - was Re: [Exim] how to
> configure HELO/EHLO and DNS for multi-homed hosts
>
>
> [ On Monday, June 30, 2003 at 17:19:42 (-0400), Troy Settle wrote: ]
> > Subject: RE: Now well off-topic - was Re: [Exim] how to
> configure HELO/EHLO and DNS for multi-homed hosts
> >
> > My overpriced mail server sends HELO/EHLO of 'psknet.com'
> which is what I
> > defined as the parimary_hostname in the exim configuration. This is
> > innaccurate, however, as 'psknet.com' is currently on a
> machine that does
> > not listen for incoming SMTP traffic. No biggy though,
> it's a FQDN, it
> > resolves forward and backward, and has appropriate MX
> records in place.
>
> Actually it is a "biggy".
>
> Your SMTP server, when acting as a client-SMTP, is required
> to ("MUST")
> use a canonical host domain name that will resolve back to the IP
> address its outbound connection originates from.
>
> Your mail server is lying about its identity.
Not at all. If you tell someone that your name is 'Woods,' are you
lying about your identity? How about if you claim to be 'Greg Woods?'
Even the name you use in your From: line isn't quite true, is it?
Doesn't the A expand out to something? Oh wait, it's Gregory, not Greg,
right?
My domain is 'psknet.com,' which is all the information needed to make
sense of a log file if another admin needs to figure out where something
is coming from. Now, if I were a larger organization with multiple mail
servers, I would take care to make sure each of my outgoing SMTP hosts
were configured with a proper primary_hostname so that I would be able
to identify the offending system more readily.
>
> > Here's what it looks like:
> >
> > Received: from kennedy.psknet.com ([63.171.251.9] helo=psknet.com)
>
> $ host psknet.com
> psknet.com A 63.171.251.4
>
> 63.171.251.4 does not match 63.171.251.9
>
> Your received header example proves that your mailer is lying
> about its
> identity. (your received header example is also incorrectly formatted
> as per the rules defined in RFC 2821 :-)
Section 3.8.2 seems to be the only one talking about Received Lines, but
I don't see anything about the format of such. Is there another section
that does explicitly describe the format of the Recevied Lines in the
header information?
If you have a problem with the way that particular received line is
formatted, I suggest you take it up with the author of Exim, as that is
the default format. I only claim responsibility for the first Received
line, which follows the same default format.
>
> It is irrelevant that your server happens to use the same name as the
> parent zone of the PTR its actual address resolves to.
> Sub-domain games
> are not allowed -- only fully qualified canonical host domain
> names (or
> address literals) may be used, and they "MUST" resolve to an A record
> matching the client address.
>
> Also, MX records are irrelevant for the greeting name.
>
I just re-read section 5.2.5 of RFC 1123, which states:
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.
Ok, I fess up. I'm in violation here.
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.
If you're rejecting because a HELO command fails verification, then you
too are in violation of RFC and this great big huge long thread has been
for nothing. Furthermore, I find nothing in RFC 1123 about reverse IP
lookups matching the forward. In conclusion, if the hostname given in
the HELO command resolves to the IP from which the SMTP session
originated from, then the client host is not in violation of the RFC at
all, which removes the foundation for your original argument that you
were within your rights to refuse mail from an unverifiable HELO command
(which you are, but not while remaining RFC compliant).
PS: Thanks for responding to me, I needed a bit of mental exercise after
dealing with brain-damaged vendors all day.
--
Troy Settle
Pulaski Networks
http://www.psknet.com
540.994.4254 ~ 866.477.5638
Pulaski Chamber 2002 Small Business Of The Year
