Re: Last Call: draft-klensin-rfc2821bis

Henning Schulzrinne <hgs@cs.columbia.edu> Sat, 29 March 2008 15:11 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietfarch-ietf-archive@core3.amsl.com
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0B8228C237; Sat, 29 Mar 2008 08:11:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.832
X-Spam-Level:
X-Spam-Status: No, score=-100.832 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
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 zcII220iGhGF; Sat, 29 Mar 2008 08:11:05 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 324443A6B39; Sat, 29 Mar 2008 08:11:05 -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 285B13A6825 for <ietf@core3.amsl.com>; Sat, 29 Mar 2008 08:11:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 N7lUoPxd9-hN for <ietf@core3.amsl.com>; Sat, 29 Mar 2008 08:11:01 -0700 (PDT)
Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id CB2E23A6B39 for <ietf@ietf.org>; Sat, 29 Mar 2008 08:11:00 -0700 (PDT)
Received: from [192.168.0.57] (pool-71-250-66-107.nwrknj.east.verizon.net [71.250.66.107]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m2TFAttQ011609 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 29 Mar 2008 11:10:56 -0400 (EDT)
Message-Id: <53378CB3-DA0D-4421-9426-C3CB342360AF@cs.columbia.edu>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
To: Theodore Tso <tytso@MIT.EDU>
In-Reply-To: <20080329143401.GB32033@mit.edu>
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: Last Call: draft-klensin-rfc2821bis
Date: Sat, 29 Mar 2008 11:10:54 -0400
References: <47EA8CD8.3010500@network-heretics.com> <alpine.BSF.1.00.0803261436260.36932@simone.iecc.com> <11a101c88f75$96b63bd0$c422b370$@net> <47EAB7E3.4060308@dcrocker.net> <47EACFB4.5010100@cisco.com> <alpine.LRH.1.10.0803290926060.7344@netcore.fi> <9D58802557DBD059763C0316@p3.JCK.COM> <01MSZFLDOT0U000078@mauve.mrochek.com> <47EE499E.5090602@dcrocker.net> <47EE4F2A.8040801@network-heretics.com> <20080329143401.GB32033@mit.edu>
X-Mailer: Apple Mail (2.919.2)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.63 on 128.59.29.5
Cc: Keith Moore <moore@network-heretics.com>, 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

One of the problems I have seen first-hand is "disappearing" mail.  
Example: A webserver sends outbound email directly, but doesn't want  
to receive inbound email. The hostname leaks and mail gets sent to  
that address, based  on the A(AAA) record. The mail is "received", but  
disappears into some never-seen /var file. In that case, the sender  
never suspects that anything is amiss; it would be much better if the  
sender got an immediate "sorry, that domain name doesn't support email  
service" error.

Even if you turn off sendmail, as someone has pointed out earlier, the  
sending MTA will retry for several days until giving up, thus delaying  
error notification that would be immediate otherwise in this  
particular case.

You can obviously turn off sendmail local delivery, but many of the  
standard web hosting (cPanel and kin, but also the standard RH mail  
setup) arrangements don't make it particularly easy to have outbound- 
only sendmail.

Thus, disabling AAAA checking seems to provide much cleaner error  
behavior. The 'MX 0' proposals would achieve some of the same results,  
but removing the AAAA lookup is default-safe, rather than requiring  
operator action. It's too late to change the A behavior, but there  
doesn't seem to be a reason to perpetuate this violation of the  
principle of least surprise.

Henning

On Mar 29, 2008, at 10:34 AM, Theodore Tso wrote:
> On Sat, Mar 29, 2008 at 10:16:10AM -0400, Keith Moore wrote:
>> I think it is time to put an end to specious arguments.
>>
>> These standards get used for decades.  I don't think it's  
>> appropriate to
>> cripple them because of some arrangement that happens to exist now  
>> from
>> a few dysfunctional DNS providers.  Providers will get more  
>> flexible as
>> the need becomes apparent, and domain owners who have problems with
>> their DNS providers can change providers.  It's not difficult.
>
> So I must be missing something, probably because I deleted without
> reading closely enough one of the earlier messages on this thread.
> But please indulge me --- exactly what is the benefit of deprecating
> the "A" fallback, and/or not doing a lookup on the AAAA record if the
> MX record doesn't exist?  Is it the load on the nameservers that
> people would believe would be reduced if we didn't do this?  Is that
> really a problem?  Or is it something else?
>
> 					- Ted
> _______________________________________________
> IETF mailing list
> IETF@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf