Allowing a sending entity to determine a destination for FBL reports
by embedding that information in a message header implies trust of
that sender. Signing mail with DKIM is not an indicator of trust. So
how do you know to trust that sender? It's ends up being a big catch
22, in that if you trust the sender, perhaps because they've
registered with you, then they might as well have registered with you
directly to set up the FBL that way.
Savvy anti-spammers have long had a distrust of spam reporting vectors
being defined only by the sender of the message. Systems that track
where to send complaints by IP or domain (for example, Spamcop and
Abuse.net), as well as ISPs, have run into various scenarios where a
bad actor will attempt to direct complaints back only to himself, to
keep his connectivity provider or other provider in the dark as to the
nature of the bad acts. I had an "X-Complaints-to" header in mail sent
on the platform I used to manage at my last employer. The only notice
of it taken was by angry complainers assuming that use of this header
was evidence that I was trying to guide complaints away from
upstreams. Based on all of this, I wouldn't support a mechanism that
would allow a sender to specify where reports should be sent, because
of the potential for abuse, and the (in my opinion), very small chance
that it would gain traction.
BTW, I think that dismissing FBL utility because it's only (currently)
most useful in webmail environments is a bit short sighted. I wouldn't
be surprised to see more "report spam" plugins for various desktop or
smartphone MUAs in the future. Outlook + a widely distributed report
spam button plugin = a gold mine of reputation data for spam filter
developers. I am sure that I am not the first person to think of this.
--
Al Iverson on Spam and Deliverability, see http://www.spamresource.com
News, stats, info, and commentary on blacklists: http://www.dnsbl.com
My personal website: http://www.aliverson.com -- Chicago, IL, USA
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html