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

"Peter J. Holzer" <hjp-asrg@hjp.at> Mon, 08 February 2010 13:32 UTC

Return-Path: <hjp-asrg@hjp.at>
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 78B663A73A4 for <asrg@core3.amsl.com>; Mon, 8 Feb 2010 05:32:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.274
X-Spam-Level:
X-Spam-Status: No, score=-1.274 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, 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 KAxL7lU2-pSR for <asrg@core3.amsl.com>; Mon, 8 Feb 2010 05:32:56 -0800 (PST)
Received: from zeno.hjp.at (zeno.hjp.at [81.223.91.228]) by core3.amsl.com (Postfix) with ESMTP id 0DE6A3A73A6 for <asrg@irtf.org>; Mon, 8 Feb 2010 05:32:55 -0800 (PST)
Received: by zeno.hjp.at (Postfix, from userid 1000) id 148E34007; Mon, 8 Feb 2010 14:33:55 +0100 (CET)
Date: Mon, 08 Feb 2010 14:33:54 +0100
From: "Peter J. Holzer" <hjp-asrg@hjp.at>
To: asrg@irtf.org
Message-ID: <20100208133354.GC18987@hjp.at>
References: <20100206200921.7841.qmail@simone.iecc.com> <4B6DCF41.1070006@dcrocker.net> <alpine.BSF.2.00.1002061524280.11458@simone.lan> <D5E318E219CCBAFB23E087F2@lewes.staff.uscs.susx.ac.uk>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="S1BNGpv0yoYahz37"
Content-Disposition: inline
In-Reply-To: <D5E318E219CCBAFB23E087F2@lewes.staff.uscs.susx.ac.uk>
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: Re: [Asrg] We really don't need no stinkin IMAP or POP foram button to M
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: Mon, 08 Feb 2010 13:32:57 -0000

On 2010-02-08 12:00:43 +0000, Ian Eiloart wrote:
>
>
> --On 6 February 2010 15:38:04 -0500 John R Levine <johnl@iecc.com> 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).

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

-- 
   _  | Peter J. Holzer    | Openmoko has already embedded
|_|_) | Sysadmin WSR       | voting system.
| |   | hjp@hjp.at         | Named "If you want it -- write it"
__/   | http://www.hjp.at/ |  -- Ilja O. on community@lists.openmoko.org