Subject: Re: [ietf-dkim] General Feedback loop using DKIM

From: Franck Martin <[email-masked]>
Date: Sat, 30 May 2009 10:47:30 +1200 (NZST)

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-masked]> 
To: "Franck Martin" <[email-masked]> 
Cc: [email-masked] 
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