ok we need to see the problem from the right angle.
Sometimes when the user clicks the button spam it means unsubscribe, or stop.
How do we provide this capability to the user (in as simple way) so it really
means that.
Problem: fake headers, the user thinks he/she is unsubscribing while the
intended result is to suppress a spam report.
Keep SPAM button: even if there is an usubscribe button the user may still want
to report a spam
So there is a need for a process at the MUA and MTA to make sure the
unsubscribe header is valid and will be honored.
I think list management functions should be better build in MUA. X-headers for
mailing lists has been there for ages but they look like more a waste of space.
I may be mistaken but which MxA system process list headers usefully?
----- Original Message -----
From: "Steve Atkins" <steve(_at_)blighty(_dot_)com>
To: "Anti-Spam Research Group - IRTF" <asrg(_at_)irtf(_dot_)org>
Sent: Friday, 14 November, 2008 2:42:03 PM (GMT+1200) Auto-Detected
Subject: Re: [Asrg] FeedBack loops
On Nov 13, 2008, at 6:31 PM, Barry Shein wrote:
But second, and this is the much larger problem: widespread
adoption of
this will almost instantly lead to its mass exploitation by spammers.
How? Maybe I lack imagination, but why is this any more of a problem
than spammers just sending unsub etc requests now?
One would hope the path between a customer clicking a spam complaint
button and the service provider is reasonably reliable. And the unsub
could be verified by the same sort of means it might be verified
today. For example I might only execute an unsub from AOL if it came
either from a customer who was actually sub'd to the list or from
AOL's feedback loop MTA. I suppose an FBL could also set up some sort
of asymmetric key pair method at setup.
But maybe I'm missing something entirely.
I think so, yes.
The suggestion is that the sender of the email can suppress sending
a report via feedback loop by including an unsubscription link in the
headers of the mail.
One flaw with that is that this allows spammers to suppress feedback
loop
reports. Consider the (usual) case where the recipient of the feedback
loop is not the author of the original email, rather they're a service
provider
to the original author.
Cheers,
Steve
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
https://www.irtf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
https://www.irtf.org/mailman/listinfo/asrg