Re: [Asrg] Adding a spam button to MUAs

"Chris Lewis" <clewis@nortel.com> Thu, 04 February 2010 21:45 UTC

Return-Path: <CLEWIS@nortel.com>
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 6AF0028C0F3 for <asrg@core3.amsl.com>; Thu, 4 Feb 2010 13:45:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.415
X-Spam-Level:
X-Spam-Status: No, score=-6.415 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156]
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 6SKTTmlvrpBl for <asrg@core3.amsl.com>; Thu, 4 Feb 2010 13:45:57 -0800 (PST)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 0218928C0CE for <asrg@irtf.org>; Thu, 4 Feb 2010 13:45:56 -0800 (PST)
Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id o14LkcZ29031 for <asrg@irtf.org>; Thu, 4 Feb 2010 21:46:39 GMT
Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 16:46:38 -0500
Received: from [47.130.65.61] (47.130.65.61) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 4 Feb 2010 16:46:37 -0500
Message-ID: <4B6B4032.1080602@nortel.com>
Date: Thu, 4 Feb 2010 16:46:26 -0500
From: "Chris Lewis" <clewis@nortel.com>
Organization: Nortel
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
References: <20100201145903.30670.qmail@simone.iecc.com> <3741B85B916D847C703F2724@lewes.staff.uscs.susx.ac.uk> <A50C736E-EE14-4213-B99D-DD58C669FDAC@blighty.com> <100201092326.ZM5487@torch.brasslantern.com> <4B67ADC2.4080204@nortel.com> <4B68133A.6040104@tana.it> <4B686886.6010402@nortel.com> <4B6947EA.60505@tana.it> <4B69A82F.3030603@nortel.com> <4B6B212C.7010104@tana.it>
In-Reply-To: <4B6B212C.7010104@tana.it>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 Feb 2010 21:46:38.0593 (UTC) FILETIME=[87AD6F10:01CAA5E3]
Subject: Re: [Asrg] Adding a spam button to MUAs
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: Thu, 04 Feb 2010 21:45:58 -0000

Alessandro Vesely wrote:
> On 03/Feb/10 17:45, Chris Lewis wrote:

>> Removing the ones it doesn't want the client to respect and/or rewriting
>> the ones it does want the client to respect, or simply replacing them
>> all with its own is the best way of doing that.
> 
> Like removal of "Received" traces, this shouldn't be done frivolously.

It's never stopped Microsoft :-E

I'm envisaging a situation where the email as received by the UA has one 
or more sets of instructions of how to send a TiS report, and where. 
_Most_ of the time it _may_ be the MUA communicating back to its MTA 
(perhaps by IMAP).  The MTA can simply insert those as per site policy. 
  But the MTA may choose to allow upstream instructions through as well 
(if it chooses to trust them).

>>> It filters off any maliciously forged Authentication-Results bearing
>>> its own authserv-id, but they wouldn't have provided a different
>>> target anyway.
>> Why not? Why wouldn't a scammer attempt to divert the recipient's TiS
>> buttons to /dev/null, DDOS someone else, or divert complaints away from
>> their provider who might zap them?
> 
> That's not possible: the authserv-id is just a naked token.

It can if the instructions contain where and how to report.

>> For simplicity, you may well want to have the core specification require
>> that the receiving MTA makes all the choices at transit time, and
>> removes all forwarding instructions that it doesn't agree with.

> Hmm... I like the idea that an MTA may acknowledge ARF reports in 
> transit,

I'm specifically referring to the MTA indicating _which_ TiS 
"instructions" the MUA is permitted to follow (perhaps simply by 
removing whatever instructions it elects not to permit).  Not 
necessarily that the MTA send the ARF reports.  In fact (as below), it 
wouldn't be the MTAs that send an ARF report in my infrastructure.

> Slight alterations of messages that give corporate acknowledgments are 
> quite usual, e.g. footers and DKIM signatures. However, changing a 
> message's destination is not common, AFAIK.

I'm not talking about altering destination of the message.  I'm talking 
about altering/replacing the destination of an abuse report.

Besides, spam filters change destinations all the time.

> The client can rely on the fact that all messages in a given mailbox 
> have been received by the relevant server. However, a server doesn't 
> know that an ARF contains a message that it had previously delivered 
> to the reporter. This is different from webmail.

Doesn't necessarily need to, especially if it's told/allowed the MUA to 
send the report directly.

>> The indirection may well be desirable, but you have to ensure that it is
>> convenient to do so (in other words, make sure that the client's
>> provider's AR handling _know_ what routing decisions they're being asked
>> to assess and implement).

> Well stated. Policies and experience are essential here, but it would 
> be desirable to have a set of easy rules that a newcomer may/ should 
> follow in order to behave correctly. Perhaps, presentation of new mail 
> domains and reputation tracking will eventually be specified.

I don't think we want the user to be involved at all, aside from pushign 
the TiS button.

>>> As for tying an MTA to abuse reports handling, I think it is the most
>>> convenient choice. The kind of spam that we may be able to control by
>>> properly routing ARs does not require the immediateness of HTTP.
>> The MTA is only essential to abuse report handling insofar as the abuse
>> reports may adjust the filters.

> Not only that. User IDs and authentication methods may be specific for 
> mail apps. We should follow ease of development and deployment.

As long as you don't force it.

>> It'll be convenient to do the AR
>> handling on the MTA in some instances, but in many it will be not a good
>> choice. A specification design that makes AR handling independent of
>> the MTA is a better one. You can run it co-resident if you wish. But you
>> don't have to. Making the spec require too much of the MTA function
>> would be a mistake in that regard.

> Some task may deserve a different tool, of course. However, making the 
> spec too general, e.g. reporting spam using different transports, may 
> become cumbersome.

This has nothing to do with transports, but everything to do with 
destinations.

> Do you have a specific case in mind?

Yes, mine.  As many as 11 dumb front end SMTP filtering engines in DMZes 
firewalled off like crazy.  Internal infrastructure a mixture of O/S and 
MTA technology run by a different group. and has dozens of mailbox 
servers (mixture of IMAP, POP and Microsoft stuff).

Filtering engines managed by centralized filter control server, which 
manages quarantine, abuse complaints, logging, FP mitigation, and all 
filter adjustment.

Bad idea to put much intelligence on the DMZes of any kind. These things 
really are dumb - SMTP in, SMTP to infrastructure, control & log 
exchange with control server.  No mailboxes, IMAP, POP or anything. No 
persistent message data of any kind - no spool, even logs are highly 
transient.

[If one of these blows up, I reinstall the software on bare machine, hit 
"go" and it's back in operation.  Truly appliances.]

Have zero access to internal infrastructure.  Would have to replicate 
and manage TiS extensions on them all.

We treat abuse management/spam as an independent overlay on top of the 
internal infrastructure.  I don't bug them, they don't bug me ;-)  It's 
  entirely internal infrastructure/technology independent.

[The filtering infrastructure is designed that way, originally as a 
potential product, without having to alter the customer's internal 
machines.  That's not going to happen now.]

The logical place to implement abuse reporting mechanisms is on the 
control server, and I've already dabbled in that.  They don't even have 
to be user-initiated.  Have a filter say "this message came from a BOT", 
automatically the control server sends a notification.

Our TiS button consists, in the main, getting a filter-generated 
message-id (not RFC2822 Message-ID) back to the control server, and it 
can identify everything it needs to know about the email from that. 
Today, it's by simple forwarding of the message to an alias on the 
control server, and the ID is scraped from that.  A simpler mechanism 
using existing tools would be a simple HTTP GET with a ID parameter, but 
tying that to a UA button is hard (unless it gets standardized).  If it 
were standardized, could use a entirely different protocol.  Even a 
single short UDP packet would do the trick.

The filters could have rules on how to add/adjust inbound abuse 
reporting instructions.  I'd like nothing more than to accept/implement 
"forward to X" instructions from sites I trust.  Whether the MUA or the 
control server actually executes the instructions I don't care that much.