ietf-smtp
[Top] [All Lists]

deprecate implicit MX even for IPv4

2008-04-07 00:57:59

The longer I follow this discussion and think about it, I am feeling that
the cleanest solution would be to deprecate implicit MX even for IPv4. In
the meantime I am convinced the implizit MX is a defect of RFC 2821. It
was introduced more than 20 years ago as a workaround to get the routing
via explizit MX RRs running.

At the time source routes were deprecated the use of implizit MX should
have been deprecated too, because at that time the model about routing was
the usage of MX RRs and not A RRs and source routes.

Today email is a mission critical application. More and more legal
implications about handling of emails are coming up. For example it is
clear that the administrator is responsible and liable for an email after
it has been accepted by the MTA he is manageing at least by german law.
From thi it follows , that there will be a time in the future were you
have to process double bounces.

Just imagine a hypothetical case, where a machine is not working properly,
heating up till it burns. Imagine futher, this machine sent a warning
email to the admin of the maschine. But beause the email was sent to an
unknown user, the DSN now sits in your queue and waits until it times out,
because there is now MX-Record.

Now, what will the court do? Will you as the admin of the email server get
some part of the assigement of obligation for the bunrt maschine (and
maybe for the burnt house)? I do not know.

But what position will you have, if implizit MX is not allowed anymore.
Your MTA would reject the email immediately because now it is required to
specify a MX RR for the delivery of the DSN. Not doing this is the sole
error of the admin of the machine. From a legal standpoint, I think you
will have a much better position.

Over the weekend I run a script to process all the domains of the 'mail
from' addresses, my dual-stack MTAs got via IPv4 (the other statitic about
received email I sent already was about IPv6).

There were 155583 different domains, 6311 had no MX RR, but only an A RR
(4 had in addition an AAAA RR). This means 4 % of the domains were
reachable by implizit MX only. If you compare this with my statistic about
were we really send emails to, this was 1 %. My interpretation of this
discrepancy is, that a big part of the this A-only RRs are misconfigured
systems. I tested some of these domains, and a lot did not run an email
server.

Therefore from an operational and liability standpoint it is time to
deprecate the implizit MX RR. You had the guts to the deprecation the
source routes some years back. Now have the guts to deprecate the implizit
MX RR.

Michael Storz

<Prev in Thread] Current Thread [Next in Thread>