Re: [Asrg] Iteration #3.
Derek Diget <derek.diget+asrg@wmich.edu> Sat, 06 February 2010 07:28 UTC
Return-Path: <derek.diget+asrg@wmich.edu>
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 BA3453A6EB6 for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 23:28:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.972
X-Spam-Level:
X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=0.628, BAYES_00=-2.599]
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 JhWSpg3mcS3n for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 23:28:03 -0800 (PST)
Received: from mx-tmp.wmich.edu (mx-tmp.wmich.edu [141.218.1.43]) by core3.amsl.com (Postfix) with ESMTP id 6B4DB3A6EB1 for <asrg@irtf.org>; Fri, 5 Feb 2010 23:28:03 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN; charset="US-ASCII"
Received: from spaz.oit.wmich.edu (spaz.oit.wmich.edu [141.218.24.51]) by mta01.service.private (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 64bit)) with ESMTPSA id <0KXE00H15SRUNYE0@mta01.service.private> for asrg@irtf.org; Sat, 06 Feb 2010 02:28:45 -0500 (EST)
X-WMU-Spam: Gauge=X, Probability=10% on Sat Feb 6 02:28:44 2010, Report=' WMU_MSA_SMTP+ 0, TO_IN_SUBJECT 0.5, BODY_SIZE_4000_4999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, FROM_EDU_TLD 0, SPF_NEUTRAL 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CT_TEXT_PLAIN 0, __FRAUD_CONTACT_NAME 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __URI_NS '
X-WMU-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.2.6.63319 - Sat Feb 6 02:28:43 2010
Date: Sat, 06 Feb 2010 02:28:42 -0500
From: Derek Diget <derek.diget+asrg@wmich.edu>
X-X-Sender: diget@spaz.oit.wmich.edu
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
In-reply-to: <4B6C6D35.1050101@nortel.com>
Message-id: <Pine.GSO.4.62.1002060114540.11995@spaz.oit.wmich.edu>
References: <4B6C6D35.1050101@nortel.com>
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 07:28:04 -0000
On Feb 5, 2010 at 14:10 -0500, Chris Lewis wrote: =>We've more-or-less reset the discussion to emailing ARF reports (most people =>are satisfied with emailed ARF reports without other options).. +1 =>I think we need to reset it again, yet further. The reason being that the =>discussion touches too many pieces at once, and the security/practicality =>issues of remotely-specified ARF destinations are obscuring the fact that why =>bother with specifying them at all? Let the user's ARF handling service do =>it. We need to very specifically disentangle MUA/MTA functions and simplify =>yet again. +1 =>So we get rid of inband abuse report instructions altogether. => =>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. => =>This also allows <domain> to use DNS to map them to somewhere else entirely. -1 for having a "standard" address. Let sites decided. Some might want them to go to abuse@, spam@, devnull@, spam-training@anti-spam.vendor. I have deleted the message, but Thursday someone (you?) had a post with regard to having the final MTA insert a header with the ARF reporting address? I like that idea, but would replace MTA with MDA. An MTA never really knows if it is the "last" MTA, where an MDA does. The MDA should be within a trust/security zone of the MUA user since they are retrieving their message from it. (Doesn't matter how they retrieve them be it webmail, IMAP, POP, fetchmail, SSH, NFS, pigeon.) The MDA could be made to insert different reporting addresses in a hosted domain environment thus allowing mailDomainA recipients use reportingAddressA and mailDomainB recipients use reportingAddressB. I get the feeling people are still trying to tie the message retrieval MUA configuration with the MUA's submission configuration. Why? Is it a bad assumption that the MUA is not already configured to send messages via some MSA? If not, then use the MSA. (Clients like Thunderbird would need to pick the right MSA for the "identity/persona" when users have multiple MSA systems configured.) So, if companyA/universityB/hostingCompanyC/dogAndFamilyHobbiestD want to let their user's use a TiS button, they insert[1] the TBDheader with the reporting address for the recipients domain. (Note that fred@example.com and wilma@example.net might get delivered into the same folder of the message store, but the MDA could be configured to inserted different reporting addresses for the different recipient domains.) When the user click the TiS button, the MUA sends the ARF report using the MSA that it has configured for the user's identity/persona that matches where the message was retrieved from. (Note how this even works for webmail based MUA.) Where I see my suggestion break down is on the deliverability of the ARF when a MUA is configured to retrieve message from one message store (companyA), but use ISP-b's MSA. ISP-b might reject/quarantine/discard the ARF if it is scanning it user's out-bound mail and thus the ARF reporting address for companyA never gets the user's message. (So, if companyA wants to get their user's ARF messages, they needs to be running a MSA that their user's can use, tell them to use, and require them to use. :) 1: I think having the option of reporting back up the delivery chain several hops currently creates to many potential issues. Let just start with the MDA removing any existing headers and putting the one that works for user's "local" address. -- *********************************************************************** Derek Diget Office of Information Technology Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/ ***********************************************************************
- [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