Re: [Asrg] who gets the report, was We really don't need

Alessandro Vesely <> Mon, 08 February 2010 17:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD33628C165 for <>; Mon, 8 Feb 2010 09:54:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.53
X-Spam-Status: No, score=-4.53 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nC1R7u3XeLyi for <>; Mon, 8 Feb 2010 09:54:06 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id ACC7C28C161 for <>; Mon, 8 Feb 2010 09:54:06 -0800 (PST)
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by with ESMTPSA; Mon, 08 Feb 2010 18:55:08 +0100 id 00000000005DC035.000000004B704FFC.00005915
Message-ID: <>
Date: Mon, 08 Feb 2010 18:55:08 +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] who gets the report, was We really don't need
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 17:54:07 -0000

On 08/Feb/10 17:42, Seth wrote:
> John Levine<>  wrote:
>>  If a spammer wants to confirm receipt, which very few of them do, he
>>  uses web bugs.  I suppose info about the MUA might be marginally
>>  useful, but if I were a spammer and knew that a recipient was
>>  sufficiently annoyed to press the spam button, I'd take them off the
>>  list.  I still have millions of other people to mail to, after all.
> But I'd also sell his email address as a "known to exist, known to
> look at spam" one :-(

That's the risk we run when _mis_directing ARs. It can be minimized by 
choosing a header that MTAs are aware of and actively zap unless 
trusted, just like the A-R field of rfc 5451. Possible alternatives 
may be to

1. use 5451's authserv-id,
2. create an A-R's extension, or
3. create a brand new header field.

(I'd never go for #3, to avoid duplicating specs. #1 seems good to me, 
as I'm not aware of conflicts with existing deployments.)

Sooner or later we'll have to discuss how MTAs would route ARs in 
order to avoid bad recipients, and this question will be even more 
relevant at that point.