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

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
>   foo.bar.baz.  IN MX 10 v4host.smtp.example.com.
>                 IN MX 5  v6host.smtp.example.com.
>   v4host.smtp.example.com IN A 10.0.0.6
>   v6host.smtp.example.com IN AAAA 2001:DB8::6
>   ; smtp.example.com  IN AAAA 2001:DB8::6
>   ;                   IN A 10.0.0.6
>
> 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

example.com.  IN MX 10 smtp.example.com.

smtp.example.com.  IN A 192.0.2.1
example.com.       IN A 192.0.2.1
example.net.       IN A 192.0.2.1

user.example.org        IN A 192.0.2.21

IPv6 example

example.com.  IN MX 10 smtp.example.com.

smtp.example.com.  IN A 2001:DB8::1

example.com.       IN A 2001:DB8::1
example.net.       IN A 2001:DB8::1

user.example.org.       IN A 2001:DB8::21

example.net 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, user.example.org, 
has a reachable reverse path.
Without the implicit MX for AAAA RRs

example.com.  IN MX 10 smtp.example.com.

smtp.example.com.  IN A 2001:DB8::1
a.example.com.     IN A 2001:DB8::2

example.com.       IN A 2001:DB8::1
example.net.       IN A 2001:DB8::1

user.example.org.          IN A 2001:DB8::21
toaster.example.org.       IN A 2001:DB8::22

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

for the message to be accepted.  There are valid reasons for 
toaster.example.com to be able to send mail to a.example.com and for 
toaster.example.org (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.

Regards,
-sm