On May 26, 2009, at 3:36 PM, Franck Martin wrote: > I'm curious to see if the feedback loop mechanism could be extended > using DKIM. The concept may have many issues, but I want to see if > it is a stupid idea, or if it would have some merit. > > The system would be for the sender to include in the dkim mechanism > an FBL-email: header wich would tell the receiving mail system where > to send an ARF email if the recipient hit the spam button. > > This would provide a mechanism similar to FBL but allowing small > receiving mail systems to participate.
FBLs as currently implemented don't work very well except for webmail and AOL, because there's no UI support for it elsewhere. Without some sort of MUA support, I think it's pretty much a non- starter (though there are a bunch of startups and projects that disagree with me and try and do similar things by annotating the email itself at the MX). Are you thinking that this would be something that could be handled by, for example, an Outlook or Thunderbird plugin, without necessarily needing any support from the receiving ISP? > I think some stats show that 30% of people hitting the spam button, > really means, unsubscribe me from this mailing list. > > Also, mail footers with remove links, are either not read or are not > trusted by the recipient, I think, it is safer to hit the spam > button, than to click on the links. The List-Unsubscribe header is nearly as trustworthy as a DKIM signed FBL-Email header as far as communicating a desire to receive no further email is concerned, and it's been around forever, yet there's not been that much MUA support for it so far. I'm not sure whether that's because of a lack of desire or just due to the overly vague specification of List-Unsubscribe and friends. > > By sigining the FBL-email: header it would give a certain level of > trust, that there is a mailbox at this address and that the mailbox > has been set to process ARF emails. The FBL-header must be DKIM > validated, otherwise it would not be helpful at all. Presumably there'd be some constraint to prevent a (DKIM-signing) spammer putting some random third party email address in there too. Cheers, Steve _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
