Re: Last Call: draft-klensin-rfc2821bis

Henning Schulzrinne <hgs@cs.columbia.edu> Sun, 30 March 2008 22:09 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 C2D9A3A691B; Sun, 30 Mar 2008 15:09:51 -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 465A328C30F for <ietf@core3.amsl.com>; Sun, 30 Mar 2008 15:09:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.282
X-Spam-Level:
X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=1.318, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 rTP64-FIEiDa for <ietf@core3.amsl.com>; Sun, 30 Mar 2008 15:09:49 -0700 (PDT)
Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 473C928C24C for <ietf@ietf.org>; Sun, 30 Mar 2008 15:09:49 -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 serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m2UM9ZB4013131 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 30 Mar 2008 18:09:36 -0400 (EDT)
Message-Id: <9D0AB334-54C0-40F3-95BF-DA328CD1CC92@cs.columbia.edu>
From: Henning Schulzrinne <hgs@cs.columbia.edu>
To: Dave Crocker <dhc2@dcrocker.net>
In-Reply-To: <47EFFC7C.3070703@dcrocker.net>
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: Last Call: draft-klensin-rfc2821bis
Date: Sun, 30 Mar 2008 18:09:34 -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> <53378CB3-DA0D-4421-9426-C3CB342360AF@cs.columbia.edu> <47EFFC7C.3070703@dcrocker.net>
X-Mailer: Apple Mail (2.919.2)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.63 on 128.59.29.6
Cc: 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

>
> If an incorrect domain name is in an author or return handling  
> address, there are bigger problems to solve than AAAA/MX.

Indeed, this is the problem - the problem is that such  
misconfiguration doesn't get detected since the address *seems* to  
work just fine.

>
>> The mail is "received", but  disappears into some never-seen /var  
>> file.
>
> So, a domain name erroneously appears in an address field and the  
> references host erroneously accepts mail it shouldn't.
>
> This degree of problematic operation is not likely to get solved  
> with a new DNS construct.
>
> If someone is sending out invalid email addresses, then that needs  
> to get fixed, rather than working on some post-hoc mechanism.
>

The problem is that fixing this is made much more difficult than  
necessary by having the AAAA record.


>
>> Thus, disabling AAAA checking seems to provide much cleaner error   
>> behavior.
>
> Reasonable idea.
>
> Let's do it for all Internet services, not just email.

Yes, some other time. Email just seems particularly prone to this  
problem due to the SMTP retry behavior. Most other services don't try  
for a week.

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