Re: [Asrg] We really don't need no stinkin IMAP or POP foram button to M

Ian Eiloart <> Mon, 08 February 2010 14:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 448083A73E2 for <>; Mon, 8 Feb 2010 06:49:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.523
X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B5wSs1vw53CI for <>; Mon, 8 Feb 2010 06:49:17 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CE9AD3A709A for <>; Mon, 8 Feb 2010 06:49:15 -0800 (PST)
Received: from ([]:59314) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from <>) id KXJ2JP-000ICG-GZ for; Mon, 08 Feb 2010 14:50:13 +0000
Date: Mon, 08 Feb 2010 14:50:13 +0000
From: Ian Eiloart <>
To: Anti-Spam Research Group - IRTF <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <alpine.BSF.2.00.1002061524280.11458@simone.lan> <> <>
Originator-Info: login-token=Mulberry:01kZfHY/r4NcjSBBvF/b0EDDrW9w/ovfS9BgI=;
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Sussex: true
X-Sussex-transport: remote_smtp
Subject: Re: [Asrg] We really don't need no stinkin IMAP or POP foram button to M
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: Mon, 08 Feb 2010 14:49:18 -0000

--On 8 February 2010 14:33:54 +0100 "Peter J. Holzer" <> 

> On 2010-02-08 12:00:43 +0000, Ian Eiloart wrote:
>> --On 6 February 2010 15:38:04 -0500 John R Levine <> wrote:
>>> I really don't understand all the resistance to a header applied by the
>>> MDA.  Yes, this will require a one-time change to the MDA, but you get a
>>> much more solid system that doesn't fail in mysterious ways when people
>>> have legitimate mail setups that happen to differ from the one the
>>> designer anticipated.  It's not unlike the advantage of DKIM over SPF.
>> If I see a message that I think is spam, and it carries a
>> "report-abuse-to" header, how do I know that the header was added by the
>> MDA and not by the spammer?
> In general you don't. But I don't see that as a particularly bad
> problem: The worst a spammer can do is a DDoS attack on a small ESP by
> adding a Report-Abuse-To header with the abuse address of that ESP.
> That doesn't seem much worse to me than what they can already do by
> simply using that address in the sender (which will cause bounces and
> complaints to be sent to that address).

Except that that doesn't happen much these days. The number of bounces that 
I see into my domain is very small compared with even a year ago. What 
you're suggesting here would revive that problem in a new form.

Given that most domains won't immediately deploy this mechanism, my guess 
is that the amount of abuse will exceed the amount of use. I'll be hoping 
that clients won't deploy the mechanism at all.

Administrators will simply advise people to NOT use the junk mail button 
for exactly the same reasons that we advise people NOT to reply to spam.

In fact, my first action will probably be to configure my mail server to 
remove the abuse-report header on inbound, outbound, and forwarded email. 
Will I add an abuse-report header of my own? Probably not, because that'll 
mean (currently) creating a new email domain to collect the reports, trying 
to work out a way of filtering the reports from the spam that reaches the 
same address. And then doing something with the reports.

Probably I won't accept reports on my MX server - there won't be an MX 
record for the domain for that reason. I might permit my SUBMIT server to 
deliver the messages somewhere. But, really, I'd rather the MUA just set a 
junk flag on the imap server.

> If there is a Report-Abuse-To header, I would suggest that it is handled
> like this:
> A Report-Abuse-To header may be added by any MTA or MDA.
>     Rationale: This allows ESPs (especially big freemail providers like
>     gmail, yahoo, gmx) to tag outgoing mails with an abuse address.
> Any MTA or MDA which adds Report-Abuse-To header MUST prepend it to the
> message (just like a Received header).
>     Rationale: This provides ordering among Report-Abuse-To headers:
>     The first one is the newest and it was added by the MTA which added
>     the Received header immediately after it:
> 	Received: by A from B
> 	Report-Abuse-To: X
> 	Received: by B from C
> 	Received: by C from D
> 	Report-Abuse-To: Y
> 	Received: by D
>     Assuming that none of the lines was faked, Report-Abuse-To: X was
>     added by B, and Report-Abuse-To: Y was added by D. Anything outside
>     your MX is suspect (for example C may be a spammer) but may still be
>     useful.
> A MUA SHOULD send an abuse report to the address of the first
> Report-Abuse-To header it finds.
>     Rationale: This is the one which was added last, i.e., closest to
>     the recipient - it is therefore most likely to be relevant and least
>     likely to be failed.
> A MUA MAY do some plausibility checks and warn against sending the
> report.
>     Rationale: The Report-Abuse-To header may be faked. Analysis of the
>     Received headers may be able to detect the fake, but this is tricky
>     and error-prone, so the result of this analysis should only be
>     offered as advice.
> If there is more than one Report-Abuse-To header, the MUA MAY offer to
> send a report to each of them.
>     Rationale: If an ESP adds Report-Abuse-To to their outgoing mail,
>     they obviously want to be notified about abuse and they can even do
>     something about it (e.g., terminate the spammer's account). OTOH,
>     you don't know who added the the header, so this should also be
>     viewed with some suspicion.
> A report handling agent may forward the report if it finds an "upstream"
> Report-Abuse-To header.
>     Rationale: As above. The report handling agent may have better
>     information about the legitimacy of upstream Report-Abuse-To headers
>     than the MUA (or user).
> It may be possible to use DKIM (or something similar) to prevent forged
> Report-Abuse-To headers, but I haven't thought about this yet.
> 	hp

Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see