Re: [Asrg] seeking comments on new RMX article

Vernon Schryver <vjs@calcite.rhyolite.com> Tue, 06 May 2003 14:45 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24858 for <asrg-archive@odin.ietf.org>; Tue, 6 May 2003 10:45:54 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46EsP129562 for asrg-archive@odin.ietf.org; Tue, 6 May 2003 10:54:25 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46EsP829559 for <asrg-web-archive@optimus.ietf.org>; Tue, 6 May 2003 10:54:25 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24852; Tue, 6 May 2003 10:45:24 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D3j7-0007UP-00; Tue, 06 May 2003 10:47:29 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19D3j6-0007UM-00; Tue, 06 May 2003 10:47:28 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46EkP829101; Tue, 6 May 2003 10:46:25 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h46Ejs829071 for <asrg@optimus.ietf.org>; Tue, 6 May 2003 10:45:54 -0400
Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24546 for <asrg@ietf.org>; Tue, 6 May 2003 10:36:53 -0400 (EDT)
Received: (from vjs@localhost) by calcite.rhyolite.com (8.12.9/8.12.9) id h46EbrCf011293 for asrg@ietf.org env-from <vjs>; Tue, 6 May 2003 08:37:53 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
Message-Id: <200305061437.h46EbrCf011293@calcite.rhyolite.com>
To: asrg@ietf.org
Subject: Re: [Asrg] seeking comments on new RMX article
References: <Pine.GSO.4.10.10305060734430.13081-100000@nber5.nber.org>
Sender: asrg-admin@ietf.org
Errors-To: asrg-admin@ietf.org
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/pipermail/asrg/>
Date: Tue, 06 May 2003 08:37:53 -0600

> From: Daniel Feenberg <feenberg@nber.org>

> ...
> Why has Vixie's similar proposal gotten no discussion here? He wanted to
> overload existing MX records with the same information. In effect, 
> receivers would accept mail only from hosts with MX records matching the
> MAIL FROM address. If a sending domain wished to send from a host but
> not receive mail to it, the MX record could be given a very low priority.
> A minor advantage here is that BIND doesn't need to be changed. A larger
> advantage is that many sites already send and receive from the same host,
> so there is a "start up capital" of many millions of pre-configured
> sites.

That's clearly the way to implement RMX bits.  However, it suffers
smaller but still serious versions of the problems that come with
other RMX ideas.  One is the new limitation that mail with any given
sender domain name can only be sent from a pre-determined handful of
computers.  That limitation conflicts with the business models of many
ISPs and the desires of many users.

(Please, everyone, don't treat me to yet another recitation of how
changes in the Internet require that the rules change unless you are
Dictator of the Internet and have the netcops to enforce new rules.
If the IETF/IRTF had any netcops, it would have long since enforced
rules on more important issues than spam.)


> If the "very low priority" is specified in the standard, then there isn't
> even any difficulty telling if an MX record is specifically for
> verification purposes or not.

I think part of the idea is that you don't need to standardize "very
low priority."  In practice, thre are only two cases.  Either the host
answers port 25 and so the MX record is perfectly valid, or it doesn't,
and no harm is done.  The worst effects of an MX record pointing to
a host that doesn't answer port 25 is an immediate ICMP Port Unreachable
message telling the SMTP client port 25 isn't working.  Since these
bogus MX records would be last, they would only slightly slow down the
SMTP failure case of no working MX server.


Vernon Schryver    vjs@rhyolite.com
_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg