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
