[RFCI-Discuss] about FQDN for our smtp servers (was RFCI-Discuss Digest, Vol 39, Issue 5)

[Administrative Account]

>Message: 4
>Date: Thu, 13 Apr 2006 22:01:36 +0200
>From: Alex van den Bogaerdt <alex at ergens.op.het.net>
>Subject: Re: [RFCI-Discuss] about FQDN for our smtp servers (was
>	RFCI-Discuss	Digest, Vol 39, Issue 4)
>To: rfci-discuss at lists.megacity.org
>Message-ID: <20060413200135.GW7275 at ergens.op.het.net>
>Content-Type: text/plain; charset=us-ascii
>
>On Thu, Apr 13, 2006 at 09:27:39AM -0700, Administrative Account wrote:
>
>> 	I'm claiming much worse than that;  In the face of the contradictions
>> in RFC2821 and other RFCs, the only clear requirement is that the HELO argument
>> must resolve (to anything whatsoever).  And given the MUST requirement that
>> mail can not refused to the basis of a non-match between the argument and the
>> client, the argument needn't even be related to the client.  For the worst
>> possible case one could even use the root as an argument and meet all of the
>> stated requirements.
>
>2821, which isn't a standard, section 4.1.1.1 means: if the host has a
>host name available (and most have!) this host name must be used.  Only
>when such a name is not easely available, this rule does not apply.
>
>_Its_ host name.  Not _a_ host name.  Not any random valid domain.
>
>> 	There are two different things here - the likely intent of the RFCs
>> and the actual wording;  Your statement is unsupported and you do not offer
>> any argument to back it up.
>
>Excuse me.  We were not talking about what is happening in the wild.
>We were discussing the RFCs.
>
>Yes, people drive too fast.  That does not make it legal, and you cannot
>get away with it by saying "but everybody does it".
>
>
>You got lost in your own arguments.  You have proven that a MX record
>is a FQDN.  I don't have a problem with that.  But this does not make
>it a valid EHLO parameter.
>
>
>You:
>> Now regarding RFC1123 section 5.2.5, again there is no requirement
>> here (despite that in RFC2821) to resolve to an 'A' RR
>
>rfc1123, section 5.2.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.
>
>A valid principal _host_ domain name.  Not a random valid domain name.
>_For_the_client_host. Not just any host domain name.  Not my host name,
>not an MX record, etc.

	Alex,

	For a an example of why the *host* name of the server simply will
not work in some cases, I ask that you consider NAT as described in RFC1631
and RFC2663 and in particular consider section 4.4 of RFC2663 (and yes, this
is not a standard, but is only "Informational").

	The client as seen by the "foreign" MTA is defined by the IP of
the source packets in the SMTP transaction, but in the case of NAT, these
do not have the same IP as the actual sending machine *knows* itself to have
and in the situation described in RFC2663 section 4.4 there is no one to one
mapping, so no particular hostname can be chosen that will provide any way
to successfully perform a check of HELO/EHLO argument == rDNS of client IP.

	Simply put, in this case (even without "private" RFC1918 IP addresses)
any use of the actual *host* name will fail exactly the test you claim to be
trying to make to validate the HELO/EHLO argument.  Would you prefer host name
arbitrarily constructed to match all possible client IPs (as seen by the MX
receiving MTA)?  i.e. a hostname constructed purely to suit your stated goal
which had 'A' RRs for all possible externally visible IPs and, of course, then
similar 'PTR' RRs for every IP also - It seems that this is a far worse case
since the "check" now has lost most of its value.  Of course, this just might
fall into the category of "if possible" as used in RFC2821, and such a case
is one where it is *not* possible.  Notice that this is a very real case you
have ignored (or refused to consider), where neither a mapping from client to
hostname can be performed *and* an address literal can not be constructed.

	The other informational RFCs regarding NAT (i.e. 2993, 3022 and 3235)
don't speak of any equivalent situation, and so don't affect the argument
above.

	Are you willing to simply state that RFC2821 is incompatible with
RFC2663, or is there some solution to the issues above that have simply never
been written down (at least that I can find)?  Or the other option is to act
exactly as the recommendation in your repeatedly cited RFC1123 section 5.2.5
and add a notation in the "Received:" line.  It seems you can't have it both
ways, if you choose to reject instead, then you are disallowing the situation
described in RFC2663 section 4.4 - Which RFC do you want to ignore, one that
is not yet a standard (and provides the "if possible" clause), or one that is
informational?

	Unfortunately "in the wild" does count for something;  If a hostname
is used which does not map back to the client IP, many servers will refuse
the transaction.  The only *functional* choice in an enviroment such as is
described in RFC2663 section 4.4 is to use a FQDN which does not have an 'A'
RR.  I've been there and done that.

	Paul Shupak
	hostmaster at plectere.com

we refer to as