Re: [Exim] Domain literals: weighing up the arguments

Hi Philip, on Fri, 5 Dec 2003 10:55:58 +0000 (GMT) you wrote:

> I'm probably biased about this, but my personal view is that email
> should be delivered to domains, not to boxes.
<snip>
> 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).

I agree entirely, with one crucial exception: the *administrator*. In this
context, I think it *is* meaningful to want to deliver mail to a specific
box, if one knows that it is running an MTA. (And if it isn't, the mail
bounces - no problem).

Of course, generally speaking, I don't under any circumstances want people
to start sending mail to end users via user@[ip.address] (or even
user@primary_hostname for that matter, but that's a different issue
entirely).

However, it doesn't seem to me to be unreasonable to want to contact the
*postmaster* of a *specific machine*.

So, in all the rest of this (and the previous mail), please read in the
implicit assumption that I am talking about the specific, special case of
"postmaster@[ip]" and not "arbitraryuser@[ip]".

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

Bear in mind, however, that you, presumably, have your machines configured
properly :) The usual case of wanting to contact a postmaster at a
particular machine is because it's got some configuration problem.
Unfortunately, machines with configuration problems are often set up by
less-experienced people, and they're also the ones who are probably least
likely to have turned literal addressing on, if it's off by default.

(of course, having it turned on by default doesn't mean that something
meaningful will actually happen to the mail after reception, but it's at
least more likely than in the case where the format is not accepted at
all)

> > In the default config, there are some very stern-sounding warnings
> The thing is, people forget about them. They build rules and tests based
> on domains.

Fair point. But at the least, I think it might be helpful to clarify that
the warnings are not based on any vulnerabilities within Exim itself, but
are purely a reminder that if you enable literals, you need to be careful
with ACL rules etc.

[how to contact the administrator of a specific server]
> > 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@???.

True, but there are several problems with this approach:

1. (main problem): It's not systematic. As Tom pointed out, DNSBL's that
have automated systems for checking/adding/removing open SMTP relays are
an example of why you might want to be able to contact the administrator
of a specific machine systematically (DSBL is one I know about). If a
server is an open relay, they might reasonably want to ensure that
confirmations of removal or discussions about the listing are addressed to
the administrator of the specific server in question. The only systematic
way to do this is to send to postmaster@[ip]. Now, I hope that not many
Exim users are getting themselves listed in DSBL as open relays, but
that's not really the point.

2. Whilst it might render meaningful contacts in the case of academic
institutions or other organisations that have netblocks assigned to them
specifically (e.g. Cambridge Uni), for many cases it wouldn't. In your
case, the contacts in IPWHOIS are probably either the same, or work
reasonably closely with the people managing machines within that IP block.
At worst, they would be diligent enough to ensure that mails were
forwarded to the right people. Unfortunately, these days this situation is
probably the exception rather than the rule, especially in commercial
environments.

Consider the case where I notice a machine, 1.2.3.4, trying to send mail
to my machine. I can see that the flirble is fubared on the remote
machine, it's clearly running an MTA (from "telnet 1.2.3.4 25") and I want
to contact the admin of that specific machine. What's the obvious choice?
postmaster@[ip]. I try rev DNS, but that's broken and the SMTP banner
doesn't give any obvious primary_hostname. The server is within a huge /16
netblock and IPWHOIS lists several role contacts for HugeUpstreamISP but I
know full well that, realistically, even if my mail reaches a human rather
than an autoresponder, none of them are likely to go to the trouble of
finding out which customer has been assigned 1.2.3.4 and forward the mail
on. And even if they did, that was a load of extra work (and time) for
both me and HugeUpstreamISP when I could have just sent to postmaster@[ip]
if it worked.

3. Significant amounts of IPWHOIS data are of poor quality/missing/bad.

> > Which leaves postmaster@[ip], an unambiguous globally-routeable
> > address mandated by RFCs.
> It may be routeable, but it sure ain't necessarily deliverable.

Of course...except that in the case of postmaster@[ip] where 'ip' runs a
public MTA, it would be very helpful if it *was* deliverable - hence this
discussion.

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

Perhaps so, if only because you are vastly more experienced than the
average user :) However, bear in mind that your organisation is one that
has many things which others (especially in the 'mass' commercial arena)
don't, including:

- experienced administrators
- assigned netblocks
- working reverse DNS
- meaningful WHOIS with human contacts who actually respond
- a single, unambiguous identity together with a corresponding domain

Some of these might (rightly) seem quite fundamental, but unfortunately
that doesn't seem to be reflected in everyday experience, hence why the
facility to contact postmaster[ip] is one that does have at least some
use.

The point here is that since it's a *default* option, this is going to be
inherited by an awful lot of people but as mentioned above this means that
it will often make it impossible to (easily) contact the very Exim users
most in need of knowing that their machine is broken.

Do you see what I'm getting at?


Finally, even if "@[]" is left out of the default local_domains list and
is unsupported locally, having the domain_literal transport (and
allow_domain_literals) commented out by default (AIUI) also stops anyone
who is using Exim as a relay from contacting remote sites via literals,
even if it's supported by the remote site, which also seems a shame.


Tim