[Top] [All Lists]

Re: Minor isn't. It's a pardigm change

2008-03-31 00:19:36

At 18:57 30-03-2008, John C Klensin wrote:
MXs that way is, IMO, inappropriate. However, while the requirement for relaying has become less as we have evolved toward a fully-connected Internet, if MXs are relegated to "administrative convenience", we would, IMO, need to restore the original RFC 821 model of forward and reverse paths. Put differently, one either has MX records or one has to have "came from" and "route through" functions in the mail transport syntax and model. Getting rid of those functions turned MX from what might otherwise have been an administrative convenience into a fundamental part of the architecture.

This is an interesting point. We have been discussing about whether a MX should be a test of whether the domain elects to receive mail. Nobody mentioned the forward and reverse paths model up to now although that's what tends to be enforced.

There are times when people or automated agents send a message as a notification. It's a fire and forget approach as a reply to act on isn't expected. There's also the case where a message is sent and we expect a reply or a DSN to determine whether the message has reached the receiver. The reverse path is not important in the first case. With a MX-only approach, we have a constraint where the first case would only work if the sending domain has a MX RR.

But that modeling issue doesn't have anything to do with whether getting rid of implicit MXs, or restricting them to IPv4, is a good idea. I do see a reason to do that in principle, but I don't think it holds up in practice: to the extent that "transport over IPv6" is a different service than "transport over IPv4", then one might reasonably have SMTP-related reasons for preferring one of those services over the other that were independent of the considerations of RFC 3484. That might suggest DNS setups like  IN MX 10
                IN MX 5 IN A IN AAAA 2001:DB8::6
  ;  IN AAAA 2001:DB8::6
  ;                   IN A

and, all other things being equal, avoiding the MX default to help force people to think about those issues. But, as others have said at more length, it appears to me that the horse is long out of the barn.

One of the arguments for the change is the above. It may also help the transition to IPv6. But then we don't usually do changes on a may alone.

Getting back to the existence test:

IPv4 example  IN MX 10  IN A       IN A       IN A        IN A

IPv6 example  IN MX 10  IN A 2001:DB8::1       IN A 2001:DB8::1       IN A 2001:DB8::1       IN A 2001:DB8::21 doesn't wish to receive mail. However, it will see SMTP transaction attempts for domain because of the implicit fallback. That can be an issue for some receivers which is why they use null-mx and other tricks. The sending domain,, has a reachable reverse path.

Without the implicit MX for AAAA RRs  IN MX 10  IN A 2001:DB8::1     IN A 2001:DB8::2       IN A 2001:DB8::1       IN A 2001:DB8::1          IN A 2001:DB8::21       IN A 2001:DB8::22

In this example, if the sending domain is, we would accept the mail for as it fits our RFC 821 model. Without the implicit MX, we would need       IN MX 10

for the message to be accepted. There are valid reasons for to be able to send mail to and for (running a SMTP service this time) to be able to accept mail and DSNs without having to resort to a MX RR. From an operational point of view, let's assume that this is a short term fix and we don't have the access to do a DNS change.

IPv6 is yet to see extensive deployment. To ensure coexistence between IPv4 and IPv6 networks, the "where" test is more important and it's better to have MX RRs for any message exchange. That won't necessarily solve the transition problem. And if we go down that path, we are putting restrictions in the current model.

Now, for a reality test, we all know that it has become more difficult to ensure mail delivery due to barriers at the receiving end. At the end of the day, the receiver's policy dictates whether the sender can get the message through. The receiver can always enforce a policy where the sender hostname requires a MX RR. But then we cannot play the blame game where we refer to the SMTP standard to determine who is wrong.

The advantages of the change are:

 1. A domain can publish whether it wants to accept mail

 2. Operational problems due to misconfiguration may be detected more easily

 3. IPv6 transition may be easier

The disadvantages are:

 1. A domain has to publish whether it wants to send mail.

 2. People would expect the same behavior with IPv6.

 3. We are changing the model by making it more difficult to exchange mail.