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

Dave CROCKER <dcrocker@bbiw.net> Sun, 07 February 2010 00:38 UTC

Return-Path: <dcrocker@bbiw.net>
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 19BE33A6E84 for <asrg@core3.amsl.com>; Sat, 6 Feb 2010 16:38:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.504
X-Spam-Level:
X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 zpM1lv-DE8nD for <asrg@core3.amsl.com>; Sat, 6 Feb 2010 16:38:32 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 2EE9B3A6E83 for <asrg@irtf.org>; Sat, 6 Feb 2010 16:38:32 -0800 (PST)
Received: from [192.168.1.43] (adsl-68-122-70-87.dsl.pltn13.pacbell.net [68.122.70.87]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o170d5L3016505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Feb 2010 16:39:11 -0800
Message-ID: <4B6E0BA2.5080001@bbiw.net>
Date: Sat, 06 Feb 2010 16:38:58 -0800
From: Dave CROCKER <dcrocker@bbiw.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: "John R. Levine" <johnl@iecc.com>
References: <20100206200921.7841.qmail@simone.iecc.com> <4B6DCF41.1070006@dcrocker.net> <alpine.BSF.2.00.1002061524280.11458@simone.lan> <4B6DD607.6000304@bbiw.net> <alpine.BSF.2.00.1002061551510.18091@simone.lan>
In-Reply-To: <alpine.BSF.2.00.1002061551510.18091@simone.lan>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV 0.92/10362/Fri Feb 5 23:14:06 2010 on sbh17.songbird.com
X-Virus-Status: Clean
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 06 Feb 2010 16:39:11 -0800 (PST)
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: Sun, 07 Feb 2010 00:38:33 -0000

On 2/6/2010 2:34 PM, John R. Levine wrote:
>> 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's an internal name.

It's not for use by anyone out there in the open
Internet, the way an MX domain name is.  It's for use by clients with whom the 
operator has an established relationship.  That's internal.


 >   It hardly matters, since whichever it is, you cannot
> count on it being consistent or even known to the server operator.

Actually, it matters quite a lot.  Pre-arranged relationship vs. no prior
relationship carry masses of differences.  This becomes merely one more.


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

You left out yahoo, google, comcast, att, and the broad range of non-US-based
major ISPs.  I believe the list I just provided constitutes the vast majority of 
public mailboxes and I believe they all are "use their domain".

The fact that there is more than one provider that suits your scenario does not
automatically remove it from the edge.

And for reference, you are postulating that the DNS-based query is hugely
expensive for those providers using your scenario, but I'm not convinced that it 
does.

They have tailored software to support the scenario:  they have to, to get the 
name-and-address mappings and logins and permissions to all work.  There's a 
considerable administrative engine behind that scenario and I suspect that 
modifying that engine to support this additional function is a long, long way 
from onerous.


>> Here', we have a direct -- single 'hop' -- trust-based relationship. Much
>> simpler.
>
> And it has the same problem as SPF.

You appear to be postulating that the DNS query would fail.  Please explain how 
and in what cases.

DNS queries have significantly different characteristics from multi-hop email 
relaying, so I do not see how the problem SPF experience applies to a DNS query.


> 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.

(FWIW, I didn't propose this.  I'm merely supporting it...)

The proposal does not know or care about the retrieval protocol.  What it cares 
about is that the retrieval is based on access using a domain name.  If it has a 
domain name for retrieval, then this scheme is reasonable.

I suspect that the use of detached MUAs (thunderbird, outlook, etc.) based on 
Internet applications employs a domain name for something like six sigmas of the 
Internet user population (that uses MUAs.)

But FWIW, it's ok to specify a mechanism that works for "only" those folk who 
use POP or IMAP...

It's ok for a percentage of cases to need a different mechanism.


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

I'm not aware of its having enough experience to report back on the trust 
boundary enforcement issues.

I suspect when there is reasoned discussion based on experience, we'll also find 
some important differences in the architecture it is used within, differing in 
one or another important ways from the architecture this mechanism is being 
targeted for.

But perhaps not.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net