Re: [Asrg] Report-as-Spam header

[Alessandro Vesely <[e-mail]>]

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. 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.

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.  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.

> 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?

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, at least to the extent of learning
whether abuse reporting has any effect.  For example, in some cases it
may be better to send reports to the sender's network provider. Thus,
it may be convenient to delegate abuse reporting to a trusted central
service, such as the recipient's mailbox provider.

In the latter scenario, MUA support can be limited to flagging
messages to be reported as spam.  It would work much like "spam"
buttons on webmail sites.  That strategy requires less updates to MUA
functionality, as it is sufficient to upgrade server software on both
sides.  However, server software itself is not updated as often as
needed, since there are still MXex that understand HELO but not EHLO.