Re: Report-as-Spam header

Hi Allesandro
On 06/11/12 16:27, Alessandro Vesely wrote:
> On Mon 11/Jun/2012 05:36:59 +0200 Brendan Hide wrote:
>> Legitimate bulk mail services are already successfully using simple
>> headers and unique IDs.
> Having such links is required by law in some countries.  However, some
> of them just don't work.  Some of them seem to work and tell
> recipients they're unsubscribed from stream "xyz", but then they get
> spam with /unsubscribe?id=xyzbis, /unsubscribe?id=xyzter, and so
> forth.
I hadn't thought about the links being required by law. Re the differing 
IDs, it *has to* be unique for every mail sent, not just per recipient. 
This aids in tracking down a specific offence.
>    In addition, spammers can add such kind of links pretending to
> be a reputable originator, in the same way that they fake "From:" and
> "Return-Path:" header fields.  Thus, getting at least a part of the
> header and body of reported messages would seem to be appropriate in
> order to reliably determine the originator's identity.
I don't see this part being an issue at all. If my report-handling 
server responds saying the report is invalid then the relaying IP 
address will very quickly find its way onto an RBL. On the other hand:
> A disadvantage of reporting spam directly, from final recipients to
> senders, is that each end user would have to keep track of the
> complaints she sent.  The reporting entity needs to assess the
> trustworthiness of each sender.
This IS a very good point (even if it is made indirectly). If reports 
are sent directly to the spammer, the spammer is not going to do 
anything about it while the end-recipient believes he has properly 
reported the issue. This would not be such an issue if the ISP is 
pro-active and aware of the Report-as-Spam header (the ISP might insert 
their own header above the spammer's). Additionally, if the spammer has 
a dedicated server (ie the ISP does not intercept/relay the mail 
directly) then, again, the ISP won't be able to insert its own header.

Ultimately, there's no way for the end-user to place any trust in the 
header's origin. DNS is probably the only saving grace but, regardless, 
its back to the drawing board.

Thank you, Allesandro. :)

-- 
__________
Brendan Hide
Web Africa - Internet Business Solutions
http://www.webafrica.co.za/?AFF1E97