Re: Last Call: draft-klensin-rfc2821bis: closing the implicit MX issue
Douglas Otis <dotis@mail-abuse.org> Tue, 15 April 2008 23:14 UTC
Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 469343A6BC4; Tue, 15 Apr 2008 16:14:53 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76AEC3A6BC4 for <ietf@core3.amsl.com>; Tue, 15 Apr 2008 16:14:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.426
X-Spam-Level:
X-Spam-Status: No, score=-4.426 tagged_above=-999 required=5 tests=[AWL=2.173, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMZ60s6O49LB for <ietf@core3.amsl.com>; Tue, 15 Apr 2008 16:14:50 -0700 (PDT)
Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 69BAA3A683D for <ietf@ietf.org>; Tue, 15 Apr 2008 16:14:50 -0700 (PDT)
Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 63A4FA94552; Tue, 15 Apr 2008 23:15:24 +0000 (UTC)
Message-Id: <AD7FE79F-F6A0-433D-873D-5622240ACBB4@mail-abuse.org>
From: Douglas Otis <dotis@mail-abuse.org>
To: Tony Hansen <tony@att.com>
In-Reply-To: <4804140F.2070305@att.com>
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: Last Call: draft-klensin-rfc2821bis: closing the implicit MX issue
Date: Tue, 15 Apr 2008 16:15:23 -0700
References: <200803202203.m2KM32hA031011@drugs.dv.isc.org> <4804140F.2070305@att.com>
X-Mailer: Apple Mail (2.919.2)
Cc: SMTP Interest Group <ietf-smtp@imc.org>, IETF General Discussion Mailing List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
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. > > 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. 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. > 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. 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 _______________________________________________ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- RE: Last Call: draft-klensin-rfc2821bis (Simple M… Hollenbeck, Scott
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… Pete Resnick
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… Ned Freed
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… Dave Crocker
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… Ned Freed
- Lists and aliases (Re: Last Call: draft-klensin-r… Harald Tveit Alvestrand
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… Pete Resnick
- Re: Lists and aliases (Re: Last Call: draft-klens… Ned Freed
- Re: Lists and aliases (Re: Last Call: draft-klens… Tony Finch
- Re: Lists and aliases (Re: Last Call: draft-klens… Ned Freed
- Last Call: draft-klensin-rfc2821bis (Simple Mail … Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… Ned Freed
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… Ned Freed
- Re: Last Call: draft-klensin-rfc2821bis (Simple M… Pekka Savola
- Re: Last Call: draft-klensin-rfc2821bis Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis Douglas Otis
- Re: Last Call: draft-klensin-rfc2821bis John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis Mark Andrews
- Re: Last Call: draft-klensin-rfc2821bis John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis Douglas Otis
- Re: Last Call: draft-klensin-rfc2821bis John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis John Leslie
- Re: Last Call: draft-klensin-rfc2821bis Ned Freed
- Re: Last Call: draft-klensin-rfc2821bis Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis Douglas Otis
- Re: Last Call: draft-klensin-rfc2821bis Ned Freed
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis Bill Manning
- Re: Last Call: draft-klensin-rfc2821bis Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis Mark Andrews
- Re: Last Call: draft-klensin-rfc2821bis Bill Manning
- Re: Last Call: draft-klensin-rfc2821bis Bill Manning
- Re: Last Call: draft-klensin-rfc2821bis Ned Freed
- Re: Last Call: draft-klensin-rfc2821bis Ned Freed
- Re: Last Call: draft-klensin-rfc2821bis Willie Gillespie
- Re: Last Call: draft-klensin-rfc2821bis Mark Andrews
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis Ned Freed
- Re: Last Call: draft-klensin-rfc2821bis Ned Freed
- Re: Last Call: draft-klensin-rfc2821bis Ned Freed
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis Markku Savela
- Re: Last Call: draft-klensin-rfc2821bis Ned Freed
- RE: Last Call: draft-klensin-rfc2821bis Hallam-Baker, Phillip
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis SM
- Re: Last Call: draft-klensin-rfc2821bis Bill Manning
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis Mark Andrews
- Re: Last Call: draft-klensin-rfc2821bis SM
- Re: Last Call: draft-klensin-rfc2821bis John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis SM
- Re: Last Call: draft-klensin-rfc2821bis Pekka Savola
- Re: Last Call: draft-klensin-rfc2821bis Mark Andrews
- Re: Last Call: draft-klensin-rfc2821bis Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis Bill Manning
- Implicit MX and A RRs (was: Re: Last Call: draft-… John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis Mark Andrews
- Re: Last Call: draft-klensin-rfc2821bis Frank Ellermann
- Re: Implicit MX and A RRs Tony Hansen
- Re: Last Call: draft-klensin-rfc2821bis John Levine
- Re: Last Call: draft-klensin-rfc2821bis Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis Tony Finch
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis John Levine
- Re: Last Call: draft-klensin-rfc2821bis Eliot Lear
- RE: Last Call: draft-klensin-rfc2821bis Tony Hain
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis Dave Crocker
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- RE: Last Call: draft-klensin-rfc2821bis Hallam-Baker, Phillip
- Re: Last Call: draft-klensin-rfc2821bis Willie Gillespie
- IPv6 incentive? RE: Last Call: draft-klensin-rfc2… Hallam-Baker, Phillip
- Re: Last Call: draft-klensin-rfc2821bis Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis Jim Fenton
- Re: Last Call: draft-klensin-rfc2821bis David Conrad
- RE: Last Call: draft-klensin-rfc2821bis Tony Hain
- Re: Last Call: draft-klensin-rfc2821bis Dave Crocker
- Re: Last Call: draft-klensin-rfc2821bis Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- RE: Last Call: draft-klensin-rfc2821bis Hallam-Baker, Phillip
- RE: Last Call: draft-klensin-rfc2821bis Tony Hain
- RE: Last Call: draft-klensin-rfc2821bis John C Klensin
- Re: Implicit MX and A RRs John C Klensin
- Re: Implicit MX and A RRs Matti Aarnio
- RE: Last Call: draft-klensin-rfc2821bis John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis Mark Andrews
- Re: Implicit MX and A RRs Tony Finch
- Re: Last Call: draft-klensin-rfc2821bis Ned Freed
- Re: Last Call: draft-klensin-rfc2821bis Mark Andrews
- Re: Last Call: draft-klensin-rfc2821bis Joe Abley
- Re: Last Call: draft-klensin-rfc2821bis Mark Andrews
- Re: Last Call: draft-klensin-rfc2821bis John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis David Morris
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Implicit MX and A RRs Keith Moore
- RE: Last Call: draft-klensin-rfc2821bis michael.dillon
- Re: Last Call: draft-klensin-rfc2821bis Douglas Otis
- Re: Last Call: draft-klensin-rfc2821bis John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis Ned Freed
- Re: Implicit MX and A RRs Ned Freed
- Re: Last Call: draft-klensin-rfc2821bis Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis Ned Freed
- Re: Last Call: draft-klensin-rfc2821bis Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis Pekka Savola
- Re: Last Call: draft-klensin-rfc2821bis John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis Pekka Savola
- Re: Last Call: draft-klensin-rfc2821bis Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis Ned Freed
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis Dave Crocker
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis Theodore Tso
- Re: Last Call: draft-klensin-rfc2821bis Frank Ellermann
- Re: Last Call: draft-klensin-rfc2821bis Henning Schulzrinne
- Re: Last Call: draft-klensin-rfc2821bis John Levine
- Re: Last Call: draft-klensin-rfc2821bis SM
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis SM
- Re: Last Call: draft-klensin-rfc2821bis John Levine
- Re: Last Call: draft-klensin-rfc2821bis Dave Crocker
- Re: Last Call: draft-klensin-rfc2821bis Henning Schulzrinne
- Re: Last Call: draft-klensin-rfc2821bis David Morris
- Re: Last Call: draft-klensin-rfc2821bis Dave Crocker
- Re: Last Call: draft-klensin-rfc2821bis Mark Andrews
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis John C Klensin
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis Tony Finch
- Re: Last Call: draft-klensin-rfc2821bis Henning Schulzrinne
- Re: Last Call: draft-klensin-rfc2821bis Bill Manning
- Re: Last Call: draft-klensin-rfc2821bis Dave Crocker
- Re: Last Call: draft-klensin-rfc2821bis Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis: closing … Tony Hansen
- Re: Last Call: draft-klensin-rfc2821bis: closing … Dave Crocker
- Re: Last Call: draft-klensin-rfc2821bis: closing … Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis: closing … Lisa Dusseault
- Re: Last Call: draft-klensin-rfc2821bis: closing … Douglas Otis
- Re: Last Call: draft-klensin-rfc2821bis: closing … Hector Santos
- Re: Last Call: draft-klensin-rfc2821bis: closing … Henning Schulzrinne
- Re: Last Call: draft-klensin-rfc2821bis: closing … Dave Crocker
- Re: Last Call: draft-klensin-rfc2821bis: closing … Paul Smith
- Re: Last Call: draft-klensin-rfc2821bis: closing … Keith Moore
- Re: Last Call: draft-klensin-rfc2821bis: closing … Tom.Petch
- Re: Last Call: draft-klensin-rfc2821bis: closing … Hector Santos
- Re: Last Call: draft-klensin-rfc2821bis: closing … Robert A. Rosenberg