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
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg