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