Florian Thanks for these great insights.
I would not have communicated when a spam trap was hit at all, or I would have just given the From: and Subject: header, and may be the DKIM header just to prove the authenticity. Any other information may contain enough data to trace to the to: header. There are studies around that says that in 30% of the cases the intent of the user was not to flag the message as spam but just to say "stop sending". The problem is the users have started not to trust any removal mechanism embedded in the message, like the famous CAN-SPAM footer. It just flags, I'm alive, send me more spam, to unscrupulous people. I have seen on one web site of an email marketer, to advise, "if you don't want anymore the emails, just click the spam button in your application" as a method for removal. I think some of the purpose of the current FBL, is to give a service to the recipient, by which they are assured that no more emails will be sent to them when they click the spam button, because the email address will be removed at the source of the problem (list washing) or because the infected PC will be cleaned. Companies want to reach their customers, in which framework is still the question, but they want to play fair with the recieving mail server, the trouble is that the people that want to play unfair will play unfair whatever rules, ethics you throw at them. About 90% of all email is spam and 70% of that comes from botnets. So I'm looking here for a mechanism for easy "unsubscription"/ (you can call it list washing) for the people that play fair without giving an edge to the unfair people, and at the same time giving information to ISPs about the emails they sent to medium sized organisation (only big ISP/ESP run feedback loop programs). I think Dave Croker summary of the problem is very good, and I think there are possibilities here to achieve the goal of a general feedback loop for the benefit of all. ----- Original Message ----- From: "Florian Sager" <[email protected]> To: "Franck Martin" <[email protected]> Cc: [email protected] Sent: Friday, 29 May, 2009 7:04:31 PM GMT +12:00 New Zealand Subject: Re: [ietf-dkim] General Feedback loop using DKIM Franck Martin schrieb: > I'm curious to see if the feedback loop mechanism could be extended > using DKIM. ... > This would provide a mechanism similar to FBL but allowing small > receiving mail systems to participate. Hi Franck, with http://www.dkim-reputation.org we offered automatic FBLs for valid DKIM signed messages in the following setup from approx. Sept 08 to Jan 09: - feedback is provided for mails hitting a spamtrap - destination address of the feedback: I discussed with Murray the use of an r= entry (there was once a discussion about its use as reporting address) but since this is not supported I chosed the following: a) lookup the first public IP in the received header b) lookup an abuse address in the whois entry of the IP - the ARF reports contained headers with garbled destination addresses to hide spamtrap addresses - trusted signers get ungarbled mails: there is an extended mode, offered in http://service.dkim-reputation.org that allows the sending of feedback to registered users (so we have some control). Currently just Google and Yahoo! wanted to get ARFs from us. Why using abuse-addresses from the whois? 'Cause I expected that sending feedback to the signer of the message could mean that I directly help spammers to do list-washing. LESSONS LEARNT with this setup: 1) even abuse-addresses in the whois lead to spammers: one wrote an email to me and asked why content is garbled. I explained that I want to hide destination addresses. He said he sends identifiers in the email body that shows the destination address to him, so he removed the spamtrap address. Maybe as a consequence of this open feedback the spamtraffic in the spamtraps dropped a bit so I decided to switch open FBLs off in Jan 09. 2) even datacenter's abuse contacts just forwarded the reports to the spammers 3) ISPs like earthlink.net with a high spam ratio didn't respond to our offer to send them FBLs (I think they didn't understand the system, professionality in abuse departments is very different) CHANGED setup: we just send ARFs to trusted, manually confirmed feedback addresses (that were entered in http://service.dkim-reputation.org) With this experience I think FBLs should be provided to a very coarse granular entity on the network administration level. Some guys in our email working group in Germany started http://www.abusix.de that sends reports based on AS numbers. The according network administrators can process ARFs (a) more professionally (b) are more likely farest away from spammers (c) can escalate the processing internally if necessary (d) would get more reports that can be aggregated and analyzed by "significant peaks" (e) can take serious actions [McColo]. Best regards, Florian
_______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
