Re: Report-as-Spam header

Hi Brendan,
At 20:36 10-06-2012, Brendan Hide wrote:
>  content, perhaps even only one header. A full report in ARF format 
> is far too much information when all I really want is enough 
> information to know/determine:
>a) A recipient reckons the mail was spam
>b) The account responsible for having sent the mail

[snip]

>Legitimate bulk mail services are already successfully using simple 
>headers and unique IDs. Typically their "unsubscribe" and 
>"report-as-spam" links embedded in the headers and in the mail 
>itself all use the same ID with only the URL being slightly 
>different, for example /unsubscribe?id=xyz and /report?id=xyz. This 
>has required minimal investment and research for the providers to 
>implement yet, in theory, it already achieves a reporting mechanism 
>that can be automated. The only hindrance with this type of 
>reporting is critical mass and standardisation. I'm not aware of any 
>two bulk mail services that use the same format or header.
>
>A concern I'm looking at is development time and achievable results. 
>How many days and lines of code will it take to implement a 
>server-side report-as-spam header (and corresponding support in 
>MUAs) vs implementing the reporting mechanisms the IETF MARF Working 
>Group are working on?

There are systems which add a reporting URL for users to provide 
feedback.  That can be used for point (a).  A server-side header can 
be added in less than an hour if you already have the backend in 
place to process the report.  The corresponding support in MUAs would 
take years.  The likelihood of that happening is very small due to legacy.

Picking points from your previous message:

>Drawbacks:
>Broken Header/Header Abuse? - My guess is that we will probably end 
>up with RBLs targeting servers that relay with invalid headers

There will be abuse.

>Performance - Mail servers implementing an automated suspension 
>system would need to maintain a database (or would need to be able 
>to trawl its own logs) for the account responsible for the abuse. 
>This does not necessarily have to be a large database, however it is 
>conceivable that some mail systems will want to trim this database 
>to only include recent outgoing mail.

It's possible to track even on a large system.

>Advantages:
>Better First Response against compromised accounts

That only works if both sides are proactive.  That's rare in practice 
as abuse handling is an expense people would prefer not to have.

>Standardisation of as-of-yet incompatible/incongruent features

That can take a year or more.  Some could write a draft as a starting 
point for the discussion.

Regards,
-sm