Re: [Asrg] Iteration #3.

"Chris Lewis" <> Sat, 06 February 2010 17:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 35FAD28C110 for <>; Sat, 6 Feb 2010 09:54:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.522
X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tZ1wIbH67-yh for <>; Sat, 6 Feb 2010 09:54:46 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 10E7F28C10B for <>; Sat, 6 Feb 2010 09:54:45 -0800 (PST)
Received: from ( []) by (Switch-2.2.0/Switch-2.2.0) with ESMTP id o16Htb005880 for <>; Sat, 6 Feb 2010 17:55:38 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Sat, 6 Feb 2010 12:55:37 -0500
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 8.1.340.0; Sat, 6 Feb 2010 12:55:37 -0500
Message-ID: <>
Date: Sat, 6 Feb 2010 12:55:24 -0500
From: "Chris Lewis" <>
Organization: Nortel
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090812 Lightning/0.9 Thunderbird/ Mnenhy/
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 06 Feb 2010 17:55:37.0433 (UTC) FILETIME=[969BC490:01CAA755]
Subject: Re: [Asrg] Iteration #3.
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <>
List-Id: Anti-Spam Research Group - IRTF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 06 Feb 2010 17:54:47 -0000

Alessandro Vesely wrote:
> On 05/Feb/10 20:10, Chris Lewis wrote:

> -1. It is perfectly legal for an IMAP server to be at, but 
> that doesn't produce an email address by the above rule.

If an installation configures that way, then they don't want abuse 
reports.  If they do want them, they adjust how it's configured.

> This argument is the opposite of what Derek said. That is, a 
> convenience mailstore located on the recipient side of a message path 
> may have no clue at all, and rely on its upstream servers for SPF/DKIM 
> verifications, filtering, and reputation assessments.

This is not a problem.  The mailstore owner either configures DNS to 
make it happen properly, or elects not to.  Without necessarily having 
to involve the mailstore in the report flow.

And yet,

> If we reset the discussion why do we maintain that reports have to be 
> sent by SMTP/MSA? IMAP is better (see below).

You just did it again.  This _forces_ technology dependence, requires 
that the mailstore implement abuse reporting mechanisms, and violates 
the whole idea of simplification so as to not dictate that any specific 
part of the mailflow other than the UA needs to know how to send an 
abuse report.

Spec #1 is _only_ how the UA finds out when TiS is enabled, and where to 
send SMTP'd reports (presumably ARFd).  If you want to go back to IMAP, 
that undoes both resets and goes back to something that probably 
disenfranchises most installations from being able to do this.

> -1. Even if I haven't got what DNSish thing you mean, if we discard 
> the message path we cannot distinguish botnets from reliable servers. 
> Inband authentication traces are the keystones for handling 
> non-criminal spam.

All the message path information is in the ARF report, to be processed 
or not, as the abuse reporting service is designed. Including DKIM/SPF 
information etc.  Well, yes, the body could be S/Mime'd or PGP 
encrypted, but the report probably has all it needs in the header anyway.

Your argument presupposes that the UA can distinguish such things. 
Usually it can't.  Leave that to the report receiver.

>> Astute readers will notice that (1) is a trivially simple MUA hack, and
>> that (2) isn't necessary for many installations wanting TiS info (for
>> filter tuning) and don't forward them anywhere.

> For filter training you also need "ham" type submissions,

Only if you're doing server-based Bayes and the abuse handling mechanism 
is separate from the inbound mail flow. You don't necessarily need 
user-end ham submissions if you can get at the mailflow.

> which ARF is 
> currently missing. In addition, you need to deliver uncertain 
> messages, flagged as possible spam, e.g. in a "Junk" folder.
> Although similar, the topic of how to properly synchronize server side 
> filtering with client's Bayesian data is different from the idea of 
> generalizing FBLs. My understanding is that this topic primarily 
> concerns IMAP, since webmail and POP3 have no provisions for 
> synchronizing contents. 

It's in the ARF, so synchronization isn't necessary.