[RFCI-Discuss] about FQDN for our smtp servers (was RFCI-Discuss
Digest, Vol 39, Issue 5)
Administrative Account
hostmaster at Plectere.com
Fri Apr 14 18:32:46 EDT 2006
>From alanb at digistar.com Fri Apr 14 09:25:34 2006
>Date: Fri, 14 Apr 2006 12:25:22 -0400 (EDT)
>From: Alan Brown <alanb at digistar.com>
>To: Discussion about the RFC-Ignorant Project <rfci-discuss at lists.megacity.org>
>Cc: hostmaster at Plectere.com
>Subject: Re: [RFCI-Discuss] about FQDN for our smtp servers (was RFCI-Discuss
> Digest, Vol 39, Issue 5)
>In-Reply-To: <200604140409.k3E49R0o017878 at Plectere.com>
>References: <200604140409.k3E49R0o017878 at Plectere.com>
>...
>On Thu, 13 Apr 2006, Administrative Account wrote:
>
>> 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)
>
>And if the NATed host _is_ in RFC 1917 space, its canonical hostname by
>definition must not appear in global namespace.
>
>Which is why any attempt to define a FQDN as "must resolve" in HELO
>checks is doomed to failure in a high enough percentage of cases to
>cause mail problems.
>
>Some _very_ large organisations equipped with historically ancient /8
>allocations force all traffic onto the net via gateways. Until recently
>the entire country of Vietnam did so too.
>
>(Not to mention all those winblows boxen which are going to give
>non-resolvable HELOs when their MUAs connect, necessitating exeception
>lists for "local" IP ranges on port 25 connections, or some way of
>forcing all users to use MSA/smtps connections.)
>
>
>--
> If a person, or organisation, starts to play on your fears
> it may be that person or organisation that you should fear.
>
Alan,
Actually my own situation for most of the past decade had been (please
excuse the bad ascii art).
Provider1 Provider2 Provider3 ProviderN
BGP4
Static CIDR Static CIDR Dynamic IPs Dynamic IP(s)
^ ^ ^ ^
| | | ... |
| | | |
---------------------------------------------------------
| |
| Load balancing Redundant Router/Firewall |
| |
---------------------------------------------------------
|
|
V
Internal Net using Legacy Class C IPs
with many subnets, internal routers and firewalls
So my actual outgoing mail server/MTA does have a static IP which is
a legal internet address, has an 'A' record and a 'PTR' RR, but which would
only be visible when output from just one pipe. The pricing here in the US
is such that bandwidth is cheap, but BGP4 announcements are generally quite
expensive, *and* my old ASN seems to have been reclaimed by ARIN.
So for any site wishing to be multi-homed for redundancy, the costs
would include an ASN (which are still stuck at 16-bits and are a very limited
resource), multiple BGP4 announcements (which many providers will only sell
on "4-wire" interfaces - i.e. T1 or higher, not DSL). In the case of different
providers even SMARTHOST connections don't help, because a HELO argument deemed
acceptable to Provider1 is not likely to be acceptable to Provider2! For local
machines I have no problem - most machines use allocated IPs and those few
whith are MS boxes or use DHCP, are configured to use legal hostnames (not the
MS default) and are registered internally with my DNS servers by dynamic-DNS
updates.
I am able to purchase the above described configuration for < $200
a month, do not need to talk BPG4 and have >10Mb/s download and >2Mb/s upload
bandwidth. To replace it with something that avoids the "if possible" case
would cost 6 to 8 times as much. I have also setup systems for more than a
few companies with a T1 or T3 and fallback to a DSL (or going way back, ISDN)
line in a similar fashion. (Typical discounted US pricing is as low as $18/mo
for 5 dynamic IPs on a 3Mb/512Kb DSL line and $45 for the same with static IPs;
6Mb/1Mb service is about double these costs. Fractional T1s start at ~$260/mo
and add $50-250 depending on the provider for BGP4 service - plus ARIN fees
for any IP and AS allocations.)
So while Alex is like correct that the intention was not to give
everyone Carte Blache, the wording does in fact do exactly that (since SHOULD
isn't binding on anyone). Also while some of my subnets do use RFC1918 IPs,
most of my machines use addresses taken from my legacy class C, which are only
visible when routed down one external interface (very inexpensively - I am
grandfathered in with that provider - a new customer with the same or similar
requirements would have to pay much more for service).
Unlike the example I provided before, since I do have one pipe with
routing announcements and do use allocated addresses, my machines are indeed
on and part of the internet - but that is not discernable to everyone by every
path they may end up "speaking" down; Hence I seem to clearly fall into the
not "if possible" case.
RFC2821 provides absolutely no guidance, examples or suggestions of
what to do for the not "if possible" case, leaving only the requirement that
a FQDN be used (a literal can not and a host name should not, as it would be
incorrect); Thus my assertion that *any* FQDN which lacks an 'A' RR is the
only appropriate action, and "in the wild", only a FQDN with a 'MX' entry
actually works. In fact, for the 'not "if possible"' case, there are no stated
requirements at all (though other sections' requirements continue to apply).
Of course, from the viewpoint of a company with a much large Internet
presence, it could always be claimed that smaller players do not deserve or
need to be able to be multi-homed or redundant (look at the history of shim6
and IPv6 in the NANOG mailing list archives), but that seems quite unreasonable
to me.
Paul Shupak
hostmaster at plectere.com
More information about the RFCI-Discuss
mailing list