Re: [Asrg] Iteration #3.

Alessandro Vesely <vesely@tana.it> Sat, 06 February 2010 10:17 UTC

Return-Path: <vesely@tana.it>
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 262A13A7059 for <asrg@core3.amsl.com>; Sat, 6 Feb 2010 02:17:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level:
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
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 EzbxTrvEwdm9 for <asrg@core3.amsl.com>; Sat, 6 Feb 2010 02:17:23 -0800 (PST)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id F3C8F3A7051 for <asrg@irtf.org>; Sat, 6 Feb 2010 02:17:22 -0800 (PST)
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 06 Feb 2010 11:18:11 +0100 id 00000000005DC033.000000004B6D41E3.0000533B
Message-ID: <4B6D41E3.8000209@tana.it>
Date: Sat, 06 Feb 2010 11:18:11 +0100
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: asrg@irtf.org
References: <4B6C6D35.1050101@nortel.com>
In-Reply-To: <4B6C6D35.1050101@nortel.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] Iteration #3.
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 10:17:24 -0000

On 05/Feb/10 20:10, Chris Lewis wrote:
> So we get rid of inband abuse report instructions altogether.

(I assume "report instructions" is not exactly the same as "reporting 
addresses", but what's the difference?)

> I propose two specifications:
>
> 1) a spec for MUAs that says nothing more than "if the TiS button is
> pushed, the selected email[s] get sent in ARF format to <some standard
> address>, via the usual mail submission methods it uses". I recommend,
> so as to not stomp/overload existing naming conventions, that it be
> "arf@arf.<domain in the RCPT TO that reached the user>". Or, "ar", or
> whatever. I don't care what it is (if you really don't want to use
> "arf") as long as it doesn't collide with existing conventions and
> standards. Eg: IMAP/POP/SMTP/SPAM et. al. are unacceptable.

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

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 also allows <domain> to use DNS to map them to somewhere else
> entirely.

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

> 2) a followon spec that specifies what goes on at arf@arf.<domain>" in
> terms of remote report forwarding (if any). Rather than relying on
> inband ARF destination signalling, I think we should consider doing
> something with DNS ala SPF/SenderID and DKIM.

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

> 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, 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. Ian's contributions look differently from this 
perspective, and imply that using IMAP directly is the best choice in 
this case.