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.
- [Asrg] Iteration #3. Chris Lewis
- Re: [Asrg] Iteration #3. Dave CROCKER
- Re: [Asrg] Iteration #3. Steve Atkins
- Re: [Asrg] Iteration #3. Chris Lewis
- Re: [Asrg] Iteration #3. Derek Diget
- Re: [Asrg] Iteration #3. Alessandro Vesely
- Re: [Asrg] Iteration #3. Chris Lewis
- Re: [Asrg] Iteration #3. Chris Lewis
- [Asrg] Consensus Call - submission via posting (w… Dave CROCKER
- Re: [Asrg] Consensus Call - submission via postin… Lyndon Nerenberg (VE6BBM/VE7TFX)
- Re: [Asrg] Consensus Call - submission via postin… Chris Lewis
- Re: [Asrg] Consensus Call - submission via postin… Steve Atkins
- Re: [Asrg] Consensus Call - submission via postin… Dave CROCKER
- Re: [Asrg] Consensus Call - submission via postin… Dotzero
- Re: [Asrg] Iteration #3. Derek Diget
- Re: [Asrg] Consensus Call - submission via postin… Derek Diget
- Re: [Asrg] Consensus Call - submission via postin… Bart Schaefer
- Re: [Asrg] Consensus Call - submission via postin… Alessandro Vesely
- Re: [Asrg] Iteration #3. Alessandro Vesely
- Re: [Asrg] Iteration #3. Daniel Feenberg
- Re: [Asrg] Iteration #3. John Levine
- Re: [Asrg] Iteration #3. Daniel Feenberg
- Re: [Asrg] Iteration #3. Dave CROCKER
- Re: [Asrg] Iteration #3. John Levine
- Re: [Asrg] Iteration #3. Dave CROCKER
- Re: [Asrg] Consensus Call - submission via postin… Ian Eiloart
- Re: [Asrg] Consensus Call - submission via postin… John Levine
- Re: [Asrg] Consensus Call - submission via postin… BOBOTEK, ALEX (ATTCINW)
- Re: [Asrg] Consensus Call - submission via postin… Andrew Richards
- [Asrg] who has the message (was Re: Consensus Cal… Dave CROCKER
- Re: [Asrg] Consensus Call - submission via postin… Chris Lewis
- Re: [Asrg] Consensus Call - submission via postin… Andrew Richards
- Re: [Asrg] who has the message (was Re: Consensus… Andrew Richards
- Re: [Asrg] who has the message (was Re: Consensus… Dave CROCKER
- Re: [Asrg] who has the message (was Re: Consensus… Chris Lewis
- Re: [Asrg] who has the message (was Re: Consensus… John Levine
- Re: [Asrg] who has the message (was Re: Consensus… Dave CROCKER
- Re: [Asrg] overloading server names doesn't work,… John R Levine
- Re: [Asrg] Consensus Call - submission via postin… Bill Cole
- Re: [Asrg] overloading server names doesn't work,… Daniel Feenberg
- Re: [Asrg] who has the message (was Re: Consensus… Ian Eiloart
- Re: [Asrg] Consensus Call - submission via postin… Ian Eiloart
- Re: [Asrg] who has the message (was Re: Consensus… Ian Eiloart
- Re: [Asrg] who has the message (was Re: Consensus… Andrew Richards
- Re: [Asrg] who has the message (was Re: Consensus… Andrew Richards
- Re: [Asrg] who has the message (was Re: Consensus… Ian Eiloart
- Re: [Asrg] who has the message (was Re: Consensus… Andrew Richards
- Re: [Asrg] who has the message (was Re: Consensus… Ian Eiloart
- Re: [Asrg] overloading server names doesn't work,… Dave CROCKER
- Re: [Asrg] who has the message (was Re: Consensus… Paul Russell
- Re: [Asrg] overloading server names doesn't work,… John R Levine
- Re: [Asrg] overloading server names doesn't work,… Dave CROCKER
- Re: [Asrg] DNS basics, was overloading server nam… John R Levine
- Re: [Asrg] Consensus Call - submission via postin… Andrew Richards
- Re: [Asrg] Consensus Call - submission via postin… Ian Eiloart
- Re: [Asrg] DNS basics, was overloading server nam… Dave CROCKER
- Re: [Asrg] DNS basics, was overloading server nam… John R Levine
- Re: [Asrg] Consensus Call - submission via postin… Jose-Marcio Martins da Cruz
- Re: [Asrg] DNS basics, was overloading server nam… Douglas Otis
- Re: [Asrg] Consensus Call - submission via postin… Ian Eiloart
- Re: [Asrg] Consensus Call - submission via postin… Jose-Marcio Martins da Cruz