Re: [Asrg] Adding a spam button to MUAs

Alessandro Vesely <> Thu, 04 February 2010 19:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CDB4728C111 for <>; Thu, 4 Feb 2010 11:33:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.638
X-Spam-Status: No, score=-4.638 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tYA6UzbF5cPR for <>; Thu, 4 Feb 2010 11:33:22 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 815B228C19A for <>; Thu, 4 Feb 2010 11:33:22 -0800 (PST)
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by with ESMTPSA; Thu, 04 Feb 2010 20:34:05 +0100 id 00000000005DC033.000000004B6B212D.000012C5
Message-ID: <>
Date: Thu, 04 Feb 2010 20:34:04 +0100
From: Alessandro Vesely <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] Adding a spam button to MUAs
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <>
List-Id: Anti-Spam Research Group - IRTF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 04 Feb 2010 19:33:23 -0000

On 03/Feb/10 17:45, Chris Lewis wrote:
> Alessandro Vesely wrote:
>> The receiving end does not /have/ to zap prior instances of the same
>> [Authentication-Results] field.
> No, it doesn't technically have to, but it _will_ have to give the
> client a hand in making sure the client doesn't trust bogus/malicious
> ones or ones outside of the receiving site's policies.

An ADMD may keep a database of known bogus authserv-id's (OpenDKIM 
apparently supports this). It may prevent gullible users from trusting 
questionable servers. However, it shouldn't be needed unless MUAs 
repeatedly ask users to trust any authserv-id just because they found 
it in some messages' headers.

> 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 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. Actually, 
it doesn't even have to be an existing mail domain. Overloading RFC 
5451 in order to derive a destination for ARs is just a convenience 
for MUAs. Otherwise, users could just spell out a list of ARF 
recipients. The problem with that approach is how to avoid that MUAs 
have to resort to heuristics when a user has multiple accounts or 
forwarders. Since the Authentication-Results header conveys exactly 
the same meaning --the party responsible for receiving a message-- the 
overload is correct, IMHO.

However, Authentication-Results contains no further meta-info, 
command, or indication that would be used for sending ARs. Just the 
authserv-id token itself.

>> In general, a (trusted) report from a client should reach the
>> originating domain, whose operators can make the best use of it,
>> assuming they're honest.
> And assuming that meets the recipient server's policies. As a corporate,
> for example, we must have the final word on what reporting our users do
> and to where. That will often _not_ be where the sender or forwarder is
> trying to tell the client.
> 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, as it allows users to communicate to their ISPs that they 
have enabled some other authserv-id. However, there may be better ways 
to achieve the same effect without specifying SMTP behavior that would 
be unique to ARF handling.

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.

> That means that the client, assuming that the client knows that the
> receiver is doing all the work, doesn't have to do any cryptographic
> verification, and the receiver may not need to either.

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.

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

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

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

Do you have a specific case in mind?