Re: [Asrg] We really don't need no stinkin, was MUA spam button

"John R. Levine" <johnl@iecc.com> Sat, 06 February 2010 22:33 UTC

Return-Path: <johnl@iecc.com>
X-Original-To: asrg@core3.amsl.com
Delivered-To: asrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5830C3A69AC for <asrg@core3.amsl.com>; Sat, 6 Feb 2010 14:33:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.9
X-Spam-Level:
X-Spam-Status: No, score=-13.9 tagged_above=-999 required=5 tests=[AWL=5.143, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156]
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 MOXT7rL1rwgC for <asrg@core3.amsl.com>; Sat, 6 Feb 2010 14:33:46 -0800 (PST)
Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 864363A6877 for <asrg@irtf.org>; Sat, 6 Feb 2010 14:33:46 -0800 (PST)
Received: (qmail 7916 invoked from network); 6 Feb 2010 22:34:41 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1002; bh=R5vjGlt3aAMNQxSrquJv3ePgHdj+WwUr3iMi1u9k+OI=; b=utClog4O77yi020loAeFK6VA6ZmXmshxfdCKLIw+H2vnFDi8ereXsy83Zen5RL0G+oEmeoftTrn5dwoS0yOvbiKebEQRhQfjwbBxWXKJt85fRegfDujXsSqogfa7iEQEulS0vYRSt5fmkV6NsZVq2EkkPsQAO2PO9uK6RUDhUlU=
Received: (ofmipd 208.31.42.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 6 Feb 2010 22:34:18 -0000
Date: 6 Feb 2010 17:34:40 -0500
Message-ID: <alpine.BSF.2.00.1002061551510.18091@simone.lan>
From: "John R. Levine" <johnl@iecc.com>
To: "Dave CROCKER" <dcrocker@bbiw.net>
In-Reply-To: <4B6DD607.6000304@bbiw.net>
References: <20100206200921.7841.qmail@simone.iecc.com> <4B6DCF41.1070006@dcrocker.net> <alpine.BSF.2.00.1002061524280.11458@simone.lan> <4B6DD607.6000304@bbiw.net>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
Cleverness: None detected
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: Anti Spam Research Group <asrg@irtf.org>
Subject: Re: [Asrg] We really don't need no stinkin, was MUA spam button
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
List-Id: Anti-Spam Research Group - IRTF <asrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/asrg>
List-Post: <mailto:asrg@irtf.org>
List-Help: <mailto:asrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Feb 2010 22:33:48 -0000

> Offhand, your model seems to be confusing public domain names -- such as what 
> others send email to -- from internal names, such as what is used between the 
> hosting service and their direct clients.

Sorry, I don't understand this.  Would you call the host name of the POP 
or IMAP server configured into the user's MUA a "public" or an "internal" 
name?  It hardly matters, since whichever it is, you cannot count on it 
being consistent or even known to the server operator.

Anyway, since this is supposed to be a research group, I did a little 
research to see what other mail hosting providers do:

Rackspace: use their name
Fusemail: per-domain CNAME
Everyone.net: use their name
Godaddy: unclear, examples all say "use your server name"
Yourdomainhost: use their name
runbox: use their name
host45.com: per-domain name (unclear whether CNAME or A)

It's certainly not universal to use per-domain names, but it's not an 
unusual edge case either.

> Here', we have a direct -- single 'hop' -- trust-based relationship.  Much 
> simpler.

And it has the same problem as SPF.  SPF is based on the false premise 
that all mail is sent directly from the originating to the receiving 
server, and the equally false premise that all mail is sent from servers 
managed by the owner of the bounce address domain (or, for Sender ID, the 
false premise that it's servers managed by the From: line domain.)

You're proposing a system based on the false premise that all mail is 
delivered via POP and IMAP, and the equally false premise that all POP and 
IMAP servers are referred to by a single name known to the server 
operator.

In both cases, although the premises are true often enough to be 
superficially plausible, they fail in significant numbers of cases, and 
when they do, you're stuck with ugly complex kludges, or you just give up.

The proposals for Authentication-Results: seem to have workable ways to 
detect fake headers.  What do they know that we don't?

R's,
John