Subject: Re: Last Call: draft-klensin-rfc2821bis: closing the implicit MX issue

From: Tony Hansen <[email-masked]>
Date: Mon, 14 Apr 2008 22:33:51 -0400

<shepherd hat on>

During the second last call for rfc2821bis, there has been much
discussion of how the "implicit MX" handling is to be handled in an
IPv6-capable and IPv6-only environment.

This has generated much heat, as well as numerous proposals that were
both productive and counter-productive, and that were both in scope and
out of scope.

I came at this question with an open mind, trying to weigh each of the
arguments being made both for and against different stances. My
measuring stick in each case against has been: How does this measure
against what is required to advance 2821bis to Draft Standard? What is
the current usage? What do the implementation reports have to say on
this issue?

The SMTP implementations that have made the transition to support IPv6
appear to already have done it in a way that supports AAAA records for
the implicit MX case. In some cases they are following RFC 3974, and
other cases they are just using getaddrinfo() and letting it do the
rest. Note that RFC 3974 itself was supposedly "based on experience in
deploying IPv6". At least one of these MTAs is in common use around the
network in the IPv4 world.

In essence, these implementations are following the RFC 821 and RFC 974
(sans WKS) rules of looking for address records. They've ignored the
A-only wording of RFC 2821 and are acting like we specify currently in
2821bis-09.

In my queries I haven't yet found any IPv6-capable SMTP server that
doesn't do it.

I've seen examples of sites that are in regular use that mail would
break in an IPv6-only world if implicit MX to AAAA did not work.

 From this viewpoint, running code wins.

I'm also swayed by the principle of "least surprise". Some of the
responses I've gotten have been along the lines of "Why's this a
question? Of course you do AAAA lookup". One person who had a site set
up with an IPv6-only connection and no MX record told me "I wanted to
forward my e-mail to an account on that machine. It worked the first
time, so I didn't see a need to change it." As mentioned above, at least
one of the IPv6-capable MTAs is in common use around the network in the
IPv4 world, and turning on IPv6 on those boxes should not cause surprises.

Last of all, I'm swayed by the discussions around RFC 974 and the DRUMS
archive search around the question of what led to the wording change in
2821bis saying explicitly to do A lookups. These indicate that the
intent of adding the A record description was to be descriptive, not
prescriptive nor proscriptive.

So the bottom line is that I see sufficient support for including AAAA
lookups when implicit MX comes into play.

It's been suggested that 2821bis revert back to either the implicit MX
description found in RFC 821 or RFC 974, although Glen Anderson had some
suggested improvements to that latter's description that do make it
clearer. Any of these three would satisfy this decision, and I'll let
John choose the wording he prefers.

</shepherd hat off>

	Tony Hansen
	[email-masked]
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Dave Crocker <[email-masked]>
Date: Mon, 14 Apr 2008 20:50:51 -0700

Tony Hansen wrote:
> I'm also swayed by the principle of "least surprise". 
...
> archive search 
...
> lookups when implicit MX comes into play.

Wow.

Diligently thorough.  Carefully reasoned.  Historically solid.  (Running code 
that interoperated was what resolved a problem with checksum for the original 
TCP spec...)

Nice job, Tony!

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Tue, 15 Apr 2008 00:59:28 -0400

Dave Crocker wrote:

> Diligently thorough.  Carefully reasoned.  Historically solid.  (Running 
> code that interoperated was what resolved a problem with checksum for 
> the original TCP spec...)

and it completely ignored the entire purpose for updating 2821 - to keep 
it relevant.

I call foul.

Keith

---

From: Lisa Dusseault <[email-masked]>
Date: Tue, 15 Apr 2008 13:22:03 -0700

Hi Keith,

I've been working with Tony and John very closely on this issue, and  
whether it smells foul or not, I think this is the best we can do.   
Tony was very diligent about having conversation on all aspects and  
looking at a number of different resolutions including the one he  
recommends.

The goal of updating RFC2821 to keep it relevant is certainly one, but  
only one, of a bunch of constraints and criteria.  "Consensus" and  
"Timeliness" are two others which are in play for this particular  
issue.  We have no clear consensus for changes that would make  
RFC2821bis more relevant on this particular issue, and we have already  
lost much time.

If you believe you can drive consensus on this issue to a different  
resolution, please take that on yourself and we'll participate and pay  
attention.

Thanks,

Lisa

---

From: Douglas Otis <[email-masked]>
Date: Tue, 15 Apr 2008 16:15:23 -0700

On Apr 14, 2008, at 7:33 PM, Tony Hansen wrote:

> The SMTP implementations that have made the transition to support  
> IPv6 appear to already have done it in a way that supports AAAA  
> records for the implicit MX case. In some cases they are following  
> RFC 3974, and other cases they are just using getaddrinfo() and  
> letting it do the rest. Note that RFC 3974 itself was supposedly  
> "based on experience in deploying IPv6". At least one of these MTAs  
> is in common use around the network in the IPv4 world.
>
> In essence, these implementations are following the RFC 821 and RFC  
> 974 (sans WKS) rules of looking for address records. They've ignored  
> the A-only wording of RFC 2821 and are acting like we specify  
> currently in 2821bis-09.
>

Abusive running code wins as well.  Indeed, many bad-actors will  
appreciate not being limited to A or MX records, as specifically  
specified in RFC 2821 discovery mechanisms.  Whether the specifics of  
this specification were in error is a separate issue, where endorsing  
AAAA records as a valid discovery mechanism represents a substantial  
change, and one likely to prove unsuccessful when more widely adopted  
and then abused.  The A resource record enabled a transition to MX  
resource records.  The necessity of the implied MX record is no longer  
justifiable.  Permitting A records as a means to discover SMTP servers  
often generates a steady amount of abuse by bad-actors that use A  
record only host-names as spoofed domains in their email-address.

To overcome what is destine to become an undesirable MX fall-back  
mode, some have suggested bogus MX records could be published  
instead.  Bogus MX records would then become perhaps the _only_ means  
to protect hosts not involved in the public reception of SMTP  
messages.  Much of the undesired traffic does not directly emanate  
from clients controlled by bad-actors.  Often, undesired traffic  
results from attempts to validate oft spoofed email sources.  The  
level of this undesired traffic can be substantial.

> question? Of course you do AAAA lookup". One person who had a site  
> set up with an IPv6-only connection and no MX record told me "I  
> wanted to forward my e-mail to an account on that machine. It worked  
> the first time, so I didn't see a need to change it." As mentioned  
> above, at least one of the IPv6-capable MTAs is in common use around  
> the network in the IPv4 world, and turning on IPv6 on those boxes  
> should not cause surprises.

Those wanting inbound SMTP on their IPv6 only hosts can routinely  
include MX records in addition to their AAAA records.  Keeping a  
requirement to publish either A or MX records would alleviate the rest  
of the world from seeking protection by publishing bogus MX records  
for all hosts where inbound SMTP is not desired.  High levels of abuse  
often require public inbound receivers to specialize in defending  
against the abusive traffic.  The percentage of public SMTP servers  
represent a shrinking minority of hosts that might benefit from a  
convenience of not needing to publish MX records.  However, to improve  
both the performance of SMTP servers in general, and acceptance rates  
of IPv6 only hosts, publishing MX records for an email domain is  
likely to become increasingly critical.  "Least surprise" is assured  
by discovery methods that work on a large scale while also limiting  
avenues for abuse.  Having AAAA records imply MX resource records on a  
large scale without rampant abuse would be astonishing.

> Last of all, I'm swayed by the discussions around RFC 974 and the  
> DRUMS archive search around the question of what led to the wording  
> change in 2821bis saying explicitly to do A lookups. These indicate  
> that the intent of adding the A record description was to be  
> descriptive, not prescriptive nor proscriptive.

SMTP represents a great achievement.  Much of this achievement has  
occurred by minimizing administrative efforts needed to establish SMTP  
services.  These minimal administrative efforts now play a significant  
role in fostering current levels of abuse afflicting SMTP.   
Standardizing on AAAA as an MX fall-back moves SMTP and IPv6 in the  
wrong direction.  Sensitivity to abuse adopts a practice of "opt-in"  
rather than "opt-out".   AAAA as an MX fall-back may necessitate SMTP  
IPv6 hosts the need to publish bogus MX records for the specific  
purpose of "opting out".

> So the bottom line is that I see sufficient support for including  
> AAAA lookups when implicit MX comes into play.

It seems the specification should attempt to differentiate what might  
be achievable within private versus public server configurations.

> It's been suggested that 2821bis revert back to either the implicit  
> MX description found in RFC 821 or RFC 974, although Glen Anderson  
> had some suggested improvements to that latter's description that do  
> make it clearer. Any of these three would satisfy this decision, and  
> I'll let John choose the wording he prefers.

While ensuring that the 'S' in SMTP upholds the concept of Simple,  
avoiding greater levels of abuse will help further that goal.  While  
those that live and breath SMTP don't want to see any administrative  
dependencies added, this costs hosts running unrelated protocols that  
must then terminate a seemingly endless stream of SMTP related abuse.   
The success of SMTP requires greater administrative care be taken.  To  
take this to the logical conclusion, the transition to IPv6 with a  
reduction in SMTP related abuse would be further aided by deprecating  
use of A records as an MX fall-back mechanism published in a follow-on  
draft, where the current draft could warn of this possible change.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Tue, 15 Apr 2008 13:41:20 -0400

Tony, John,

I appreciate the hard work (and time) you guys put into this. I also 
support the "least surprise" principle and feel this is the best 
decision at this time related to this issue.

I can only hope someone can take the lead or be the point behind a new 
*consolidated* SMTP IPv6/4 technical spec effort.

Thanks

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 16 Apr 2008 21:39:35 -0400

This decision raises a somewhat larger issue, namely whether deferring  
to implementor desires is always the right thing to do. Compared to  
implementers, there are many more users and system administrators. For  
the reasons discussed earlier and alluded to below, they now lose in  
having poorer error handling and more abuse. I thought standards  
writers and implementer were supposed to serve end users (and maybe  
the large number of people having to install and manage things), not  
the other way around. Maybe this is another instance of the oft- 
bemoaned absence of operators from the IETF discussion. End users seem  
to be even more absent, even indirectly.

Henning

---

From: Dave Crocker <[email-masked]>
Date: Thu, 17 Apr 2008 07:14:17 -0700

Henning Schulzrinne wrote:
> having poorer error handling and more abuse. 

Yeah, this "running code" thing is over-rated.

It does have one characteristic that seems to be missing from your own varied 
assertions about nasty impact:  observable data.

It also presumes that those implementing code operate wholly independently of 
those who will operate or use that running code.  (An extended pattern of such 
independence is usually a good way of going out of business.)

And the claim of more spam was directly addressed as being wrong.

So perhaps you can show an empirical basis for your claims of doom and gloom?

Oh.  Right.  During the very extended discussion threads, none was produced.

d/
-- 

   Dave Crocker

---

From: Paul Smith <[email-masked]>
Date: Thu, 17 Apr 2008 10:48:54 +0100

Henning Schulzrinne wrote:
> the other way around. Maybe this is another instance of the 
> oft-bemoaned absence of operators from the IETF discussion. End users 
> seem to be even more absent, even indirectly.
Agreed. I see this as a big step in the wrong direction. No one has 
given a good reason for doing it other than 'its similar to what happens 
in IPv4', 'it makes life easier for people with awful internal 
procedures' and 'it saves us 3 lines of code in our software'. None of 
those are good enough reasons IMHO, given all the reasons not to do it.

It might end up not being a big deal except for mail server 
administrators at big companies or ISPs, but it *might* be a massive 
deal, and given the easy change we could make now, I think it's a big 
opportunity being missed.

---

From: Keith Moore <[email-masked]>
Date: Thu, 17 Apr 2008 13:47:51 -0400

> Yeah, this "running code" thing is over-rated.

indeed it is.  many people are so accustomed to accepting the problems 
with today's large-scale email operation that they fail to see how 
things could be any other way.  after all, it "works"...sort of.

> It does have one characteristic that seems to be missing from your own 
> varied assertions about nasty impact:  observable data.

there's plenty of observable data to support the assertions about nasty 
impact.

> It also presumes that those implementing code operate wholly 
> independently of those who will operate or use that running code.

no.  it only presumes that when the standard says one thing and the 
needs of operators say something else, that the implementor is placed in 
an awkward position.

> So perhaps you can show an empirical basis for your claims of doom and 

so perhaps you can show an empirical basis for your claim of superiority ?

I didn't think so.

Keith

---

From: "Tom.Petch" <[email-masked]>
Date: Fri, 18 Apr 2008 09:35:42 +0200

----- Original Message -----
From: "Paul Smith" <[email-masked]>
To: "Henning Schulzrinne" <[email-masked]>
Cc: "Douglas Otis" <[email-masked]>; "Tony Hansen" <[email-masked]>; "SMTP
Interest Group" <[email-masked]>; "IETF General Discussion Mailing List"
<[email-masked]>
Sent: Thursday, April 17, 2008 11:48 AM
Subject: Re: Last Call: draft-klensin-rfc2821bis: closing the implicit MX issue

> opportunity being missed.
I agree; this is an opportunity to clean up a obsolescent bodge
and we should do just that.

Tom Petch

---

From: Hector Santos <[email-masked]>
Date: Thu, 17 Apr 2008 14:19:30 -0400

> things could be any other way.  after all, it "works"...sort of.

+1

> needs of operators say something else, that the implementor is placed in 

+1000

Thank you for seeing this Keith.

-- 
Sincerely

Hector Santos, CTO

---

From: "Robert A. Rosenberg" <[email-masked]>
Date: Thu, 17 Apr 2008 16:22:35 -0400

At 21:39 -0400 on 04/16/2008, Henning Schulzrinne wrote about Re: 
Last Call: draft-klensin-rfc2821bis: closing the implic:

>This decision raises a somewhat larger issue, namely whether 
>deferring to implementor desires is always the right thing to do. 
>Compared to implementers, there are many more users and system 
>administrators. For the reasons discussed earlier and alluded to 
>below, they now lose in having poorer error handling and more abuse. 
>I thought standards writers and implementer were supposed to serve 
>end users (and maybe the large number of people having to install 
>and manage things), not the other way around. Maybe this is another 
>instance of the oft-bemoaned absence of operators from the IETF 
>discussion. End users seem to be even more absent, even indirectly.
>
>Henning

How an implementor writes their code is ONLY relevant if the people 
responsible for maintaining the DNS fail to supply MX records that 
point ONLY at the hosts who are running MTAs. So long as they DO 
supply these MX records (and these records supply a IPv4 connected 
MTA that will accept [and possibly relay to an IPv6-Only MTA] email 
for the FQDN) the issue of if the SMTP code will look for both A and 
AAAA records in the absence of an MX is a non-issue. The need for 
this direct use of A/AAAA is only to support DNS administrators who 
for whatever reason (political, ignorance, or just laziness) fail to 
supply MX records.
_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf