RE: Last Call: draft-klensin-rfc2821bis

"Tony Hain" <alh-ietf@tndh.net> Wed, 26 March 2008 19:21 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 15FB428C70A; Wed, 26 Mar 2008 12:21:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.143
X-Spam-Level:
X-Spam-Status: No, score=-100.143 tagged_above=-999 required=5 tests=[AWL=0.294, 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 zGonBSR3oGIl; Wed, 26 Mar 2008 12:20:59 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DED6128C459; Wed, 26 Mar 2008 12:20:58 -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 663A93A6B43 for <ietf@core3.amsl.com>; Wed, 26 Mar 2008 12:20:57 -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 3WegsEop66rS for <ietf@core3.amsl.com>; Wed, 26 Mar 2008 12:20:52 -0700 (PDT)
Received: from tndh.net (static-66-15-163-216.bdsl.verizon.net [66.15.163.216]) by core3.amsl.com (Postfix) with ESMTP id EA69628C3B0 for <ietf@ietf.org>; Wed, 26 Mar 2008 12:20:51 -0700 (PDT)
Received: from eagle (192.168.123.10:4232) by tndh.net with [XMail 1.17 (Win32/Ix86) ESMTP Server] id <S149FD95> for <ietf@ietf.org> from <alh-ietf@tndh.net>; Wed, 26 Mar 2008 12:14:29 -0700
From: Tony Hain <alh-ietf@tndh.net>
To: ietf@ietf.org
References: <20080326150139.86203.qmail@simone.iecc.com> <47EA8CD8.3010500@network-heretics.com> <alpine.BSF.1.00.0803261436260.36932@simone.iecc.com>
In-Reply-To: <alpine.BSF.1.00.0803261436260.36932@simone.iecc.com>
Subject: RE: Last Call: draft-klensin-rfc2821bis
Date: Wed, 26 Mar 2008 12:14:17 -0700
Message-ID: <11a101c88f75$96b63bd0$c422b370$@net>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AciPcnC0JtbiJbxvQq+JHKQLtDiudAAAU5Xw
Content-Language: en-us
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: alh-ietf@tndh.net
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

John Levine wrote:
> >> Not to be cynical or anything, but regardless of what we decree, I
> >> think it's vanishingly unlikely that many systems on the public
> >> Internet* will accept mail from a domain with only an AAAA record.
> 
> > I think it's vanishing unlikely that email will be useful at all, if
> spam
> > filter writers keep trashing mail based on such dubious criteria.
> 
> Not to reignite the usual spam argument, but it is (unfortunately in
> this
> case) not 1988 or even 1998 any more.  When upwards of 90% of all mail
> is
> spam, keeping mail usable is at least as dependent on limiting the spam
> that shows up in people's mailboxes as delivering the trickle of good
> mail.
> 
> Real life spam filters use metrics and tune to the actual behavior of
> mailers.  If most of the mail that comes from domains with AAAA and no
> MX
> is spam, they'll tune for that, and it won't be a mistake.  For the
> forseeable future, most such mail will be from zombies, and it'll all
> be
> spam.

This document is not the place to fight spam. If you want a BCP to deprecate
the fall-back, then write one. Until all the implementations remove
fall-back to A, the correct behavior is to also fall-back to AAAA. People
(particularly the apps dev & support communities) are having a hard enough
time getting their heads around even thinking about IPv6 that making your
proposed procedural change is insane. Whatever reasons people have for not
implementing MX will not change just because they are deploying IPv6. 

The current text is just fine the way it is.

Tony 




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