Hi all
Has a spam reporting header been considered, similar to the
List-Unsubscribe header in RFC2369? Already many Bulk Mail service
providers provide readable headers directing recipients where to send
spam complaints. I don't think this is standardised in any way however.
One of my specialities is handling abuse complaints and monitoring
outbound spam blocking systems. The performance of my team and I have a
direct correlation to network reputation and RBL listings as a result of
compromised end-user accounts. Automated (or even semi-automated)
suspension of compromised accounts would aid in this field and would
probably outperform any army of abuse-complaint "specialists".
The notion of being able to report back to the responsible ISP/mail
server directly without going through a long process is attractive. In
some environments a relay cluster with outbound anti-spam scanning could
even report high-spam-scoring mails with little to no human intervention.
Differences between List-Unsubscribe and "Report-as-Spam":
List-Unsubscribe is added by List Maintainers or Mailing-List
Distribution servers. Report-as-Spam could be added by the mail or relay
server independently of the sender's MUA when the server receives the
mail. The implication is that every "MAIL FROM" could result in a unique
Report-as-Spam ID, similar to where Message-Id would be generated. If a
relay server implicitly trusts a mail server that already adds a
Report-as-Spam header then the relay server would not bother to add
another header.
Drawbacks:
Broken Header/Header Abuse? - My guess is that we will probably end up
with RBLs targeting servers that relay with invalid headers
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.
Advantages:
Better First Response against compromised accounts
Standardisation of as-of-yet incompatible/incongruent features
Any comments, positive or negative, would be appreciated, unless its
simply a link to those lists of "why your idea won't stop spam". This
isn't supposed to stop spam, its supposed to make fighting spam more
effective for responsible ISPs.
--
__________
Brendan Hide
http://swiftspirit.co.za/
Web Africa - Internet Business Solutions
http://www.webafrica.co.za/?AFF1E97
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg