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" <sager(_at_)agitos(_dot_)de>
To: "Franck Martin" <franck(_at_)genius(_dot_)com>
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
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