On Fri, 5 Dec 2003, Tim Jackson wrote:
> All (particularly Philip),
I'm probably biased about this, but my personal view is that email
should be delivered to domains, not to boxes. Indeed, somewhere in one
of the RFCs it says more or less that. You don't want explicit IP
addresses ending up in users' addressbooks. Nor do you want them to
choose which box a message is sent to (assuming such sending actually
succeeds).
Just because a box has an IP address doesn't mean it should/must/will
accept email. In the days when we had an IBM mainframe (a decade ago
now) it had an IP address, but did not accept SMTP mail. It had an MX
record that pointed to an intermediate box that passed on the mail by a
non-TCP/IP route. It got boring trying explain to people that this was
perfectly legitimate.
Moving on to today. I'm sending this message from cus.cam.ac.uk, which
is a collection of 3 machines. If you want to contact the postmaster
for this system, you must mail to postmaster@???. The MX
records for cus.cam.ac.uk do NOT point to any of these machines. They
point to the University's central mail switch servers. Although the cus
machines are listening on port 25, they reject all mail from outside
Cambridge with
550 Mail for cus.cam.ac.uk must be routed via the MX records
That is because we want all incoming mail to be virus and spam scanned.
We have not accepted mail to IP literals for as long as I've been
involved, which is now over 10 years. It does not seem to have done us
any noticeable harm.
> In the default config, there are some very stern-sounding warnings about
> them: "This [enabling domain literals] is not recommended" coupled with
> scary comments like "This ancient format has been used by those seeking to
> abuse hosts by using them for unwanted relaying" and (again) "it...has
> been exploited by evil people seeking to abuse SMTP relays".
The thing is, people forget about them. They build rules and tests based
on domains. Maybe today people are more savvy about this - those
comments were written a few years ago.
> However, the recent discussions made me realise: if you want to contact
> the administrator of a specific server, where there is no [meaningful]
> rDNS (or it cannot be determined, for whatever reason) and no way of
> telling its "primary domain", it seems you have two choices (please
> correct me if I am missing something):
>
> a) "postmaster" (with no qualifying domain), or
> b) "postmaster@[ip address]"
c) Take the server's IP address and use whois or whatever to find out
who owns the server, and an associated domain name. Take the name
x.y.z.whatever.tld and search around the DNS till you find a subset of
that name with an MX record. Then email to postmaster@???. For
example, if you have a problem with 131.111.x.y the whois entry given by
whois -h ripe.net 131.111.0.0
will lead you to cam.ac.uk.
> Which leaves postmaster@[ip], an unambiguous globally-routeable
> address mandated by RFCs.
It may be routeable, but it sure ain't necessarily deliverable.
> 1. As far as I can tell, despite the stern security warnings, I can see no
> security risk inherent in Exim itself if IP literals are enabled.
> Therefore, the comments seem to me to be slightly misleading and may put
> off people enabling an option which, irrelevant of whether it is agreed
> it's necessary or not, is fundamentally just as safe as adding any other
> local domain. Am I missing something?
The risk is in forgetting about it (both for policy checking, and in
configuring your MTA to recognize its own address as local) and in
encouraging users to make use of the facility.
> 2. If I am correct, given that the IP literal format (even if uncommon and
> rarely used) is useful at least for the purposes of contacting postmasters
> and required by RFCs, would it not be better to enable it by default?
I don't think so, but then, I'm biased. :-)
Philip
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
Get the Exim 4 book: http://www.uit.co.uk/exim-book
