On Mon, 7 Apr 2008, Robert A. Rosenberg wrote:
At 09:40 +0200 on 04/07/2008, Michael Storz wrote about deprecate
implicit MX even for IPv4:
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.
While I agree with you that the time has come to depreciate implicate
MX for IPv4, I do not think addressing this issue/need should be
commingled with a ban on implicate MX for IPv6. IOW: Ban the
Implicate IPv6 MX as one effort and ban the Implicate IPv4 MX as a
separate effort or a failure of the IPv4 ban may prevent the IPv6 ban
from being effective. I see the 2 bans as SEPARATE issues and thus
should be addresses separately or we will have the IPv4 issue affect
the IPv6 issue. I see the IPv6 issue as something that needs to be
addressed NOW while the IPv4 issue can be fought another day if
needed. We have lived with this problem for 20 years and can live
with it, if needed, for a few more years. The IPv6 issue can NOT be
ignored or we will just end up in the same situation with AAAA record
usage as we have with A record usage. The time to act on AAAA usage
is NOW while the A usage can be addressed later/eventually.
As far as I can see, the discussion is going into the direction of
respecting again the seperation of the different protocol layers as far as
possible (a principle which I do support). And that couples the two
protocols IPv4 and IPv6 closely together. And that means, if you want to
depreciate implicit synthesized MX RRs, you have to depreciate them for
IPv4 at the same time.
Depreciating impicit synthesized MX RRs makes only sense, if you think
that using this feature nowadays with IPv4 or in the future with IPv6 is a
problem. Unfortunately (from my point of view), several people on this
list have expressed that this is not a problem for them.
However, my experience from being responsible (together with my team) for
running email for a large scientific network for more than 20 years, is
different. For us it is a problem. It would be much better, to have a
clear and clean statement that routing for SMTP is done by MX RRs and
nothing else, basta! and everything else is a configuration error.
But this has never been a design goal. There are several areas in RFC
821/2821 and RFC 822/2822 where such stements are missing (I do not name
them, because I do not want to direct discussion to these points again).
The general design principle has been
- you SHOULD not generate wrong things, but
- you MUST accept them instead of rejecting such messages.
I understand that this attitude was necessary at the beginning to get SMTP
running and having the maximum reachability. But I am absolutely convinced
that this necessity does not exist anymore since a long time.
The result is that more and more ISPs are ignoring the standard. Some of
them have at least the respectability to document this, like Frank just
showed us with the link to the dokumentation of the suppression of DSNs by
Dyndns.
Just my 2 cents from the operational world.
Michael Storz