Re: [Asrg] We really don't need no stinkin IMAP or POP foram button to M

Dave CROCKER <dcrocker@bbiw.net> Sat, 06 February 2010 20:49 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 C13963A6E02 for <asrg@core3.amsl.com>; Sat, 6 Feb 2010 12:49:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.509
X-Spam-Level:
X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=-0.066, 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 VyrXTGNMsmh2 for <asrg@core3.amsl.com>; Sat, 6 Feb 2010 12:49:50 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id AE8423A6C8C for <asrg@irtf.org>; Sat, 6 Feb 2010 12:49:50 -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 o16KoMu7008892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Feb 2010 12:50:28 -0800
Message-ID: <4B6DD607.6000304@bbiw.net>
Date: Sat, 06 Feb 2010 12:50:15 -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>
In-Reply-To: <alpine.BSF.2.00.1002061524280.11458@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 12:50:28 -0800 (PST)
Cc: Anti-Spam Research Group - IRTF <asrg@irtf.org>
Subject: Re: [Asrg] We really don't need no stinkin IMAP or POP foram button to M
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 20:49:51 -0000

On 2/6/2010 12:38 PM, John R Levine wrote:
>       A large mail hosting company with thousands of POP and IMAP
> customers should be the ideal environment for an MUA spam button,
> particularly since they already have a button in their web mail.

But the scenario you put forward is far more specialized that this description. 
  A "large mail hosting company that lets each of its customers configure domain 
names for their retrieval host" is pretty bloody unusual.

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.

Again, I'm not saying that the scenario you put forward is wrong or even a poor 
choice.  Merely that the more distributed the control, the more likely that 
changes to the operation will have a more distributed effect.


>> Basically, with an environment of the sort you describe, everything is
>> relatively more difficult.
>
> That hasn't been my experience. They make all sorts of changes, but they
> don't make changes that require every reseller to change the DNS for
> every customer.

It's always nice to have scaling effects where massive increases in scale do not 
require significant increases in operations effort.  But it's not mandatory.


>> While it's fine to try to design something so that it's scaling
>> characteristics are /better/ than linear, but it's typically also
>> acceptable for it to be linear.
>
> I really don't understand all the resistance to a header applied by the
> MDA.

For one thing, it introduces a somewhat more complicated trust model, and 
probably introduces some undesireable security edge conditions.


> Yes, this will require a one-time change to the MDA, but you get a
> much more solid system that doesn't fail in mysterious ways when people

"much more solid"???


> have legitimate mail setups that happen to differ from the one the
> designer anticipated. It's not unlike the advantage of DKIM over SPF.

In fact it's quite similar, but the balance is different.  SPF merely requires 
an administrative act to participate on the 'sending' side.  This is hugely 
attractive.  (We'll ignore the fact that it involves the wrong address field.) 
The problem is the fragility of failing to handle multiple MTA hops.

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

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net