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 (EST)
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/
***********************************************************************