[RFCI-Discuss] about FQDN for our smtp servers (was RFCI-Discuss
Digest, Vol 39, Issue 4)
Administrative Account
hostmaster at Plectere.com
Thu Apr 13 12:27:39 EDT 2006
>Message: 2
>Date: Wed, 12 Apr 2006 22:14:47 +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 3)
>To: rfci-discuss at lists.megacity.org
>Message-ID: <20060412201447.GM7275 at ergens.op.het.net>
>Content-Type: text/plain; charset=us-ascii
>
>On Wed, Apr 12, 2006 at 09:00:33AM -0700, Administrative Account wrote:
>
>[snip]
>
>Dear Administrative Account,
>
>We were talking about HELO, and you seem to claim the argument
>is allowed to be an MX domain string.
>
>You are wrong.
>
>regards,
>Alex
Alex,
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.
If you check, you will find that most MTAs (e.g. sendmail, Postfix,
Exim, qmail and probably others) will all accept an argument that resolves
to an MX, even if you enable the appropriate "strict checking" options of the
particular MTA. The wording has even more loopholes into (enough to drive a
large truck through), but using a 'MX' works in greater than 99.9% of all the
cases I've ever seen and I don't know of any option to the above listed MTAs
to cause it to be refused (though other RR types will be refused with some
common configurations).
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.
Paul Shupak
hostmaster at plectere.com
More information about the RFCI-Discuss
mailing list