[RFCI-Discuss] about FQDN for our smtp servers

[Alex van den Bogaerdt]

On Thu, Apr 13, 2006 at 09:09:27PM -0700, Administrative Account wrote:

> >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.

> 	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").

(in no particular order:)
1: Yes, I think this may be one of such cases ("...if possible...").
   Emphasis on may. This depends on what is considered possible; I
   think it will be interpreted as 'practicable'.  If 'possible' is
   to be taken literally, this would be a bug in the RFC.  Not that
   there aren't any...
2: When you NAT, you're NOT on the NET.  You have to deal with many
   problems, the one you describe is just one of them.
3: One could also argue that this technology may not have been the most
   optimal choice to make.  Perhaps even an incompatible one.

With a bit more effort, and maybe with a bit more pressure from the rest
of the Internet, it is easy to see how one could have made a different
choice, one that would be compatible.

Maybe you shouldn't use many to many mapping when processing outbound mail.
How do you cope with inbound mail?

> 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.

Have I ignored this?  When?  I haven't mentioned it explicitly, but there
will be lots more I haven't mentioned.

I wrote "...(and most have!)...".  I think I very well considered the odd
cases that can be found on the net.  Otherwise I would have written 'all'
where I wrote 'most'.

> 	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.

Now *that* is against the RFCs.  But yes, I understand that you want to
work around this.  Still, there are other ways to work around that than
ignoring the RFC yourself.  In stead of working around the problem, you
are contributing to it (!).

> 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.

I believe you have.  And I believe you got away with it in many cases.
That doesn't make it right.  It most certainly does not alter the RFC
from "must be host name" into "SHOULD resolve to an 'A' or 'MX' RR" and
the rest of your claims.  Especially the part where you talk about MX
is weird.  You are reading the part about email addresses and somehow
claim that part to be valid for HELO arguments.

The basic rule is: must be a valid host name for the client.  Exceptions
do occur, these exceptions lead to 'SHOULD' and 'address literal'.  The
intention is not to provide a free pass to all.