Dave CROCKER schrieb:
J.D. Falk wrote:
Murray S. Kucherawy wrote:
n fact, there is an experimental DKIM reputation service out there now that
does something of this nature. The implementation I wrote has optional
support for it. I don't yet have any information about who's using it or
what the results of such are.
And, there are others in progress.
Within the obvious limits of protecting proprietary concerns, it would be
quite
helpful to be able to have the dkim.org site list existing and planned
DKIM-based reputation services. Such services move DKIM from promising to
useful.
Hi,
let me summarize some insights we collected running www.dkim-reputation.org
since March 08:
1) I was in contact with Murray in Dec 08 the last time discussing uniform
requests/responses to reputation systems. Today I think it would be helpful to
publish - at least - something like a recommendation on (a) suitable publishing
systems (DNS is appropriate in my view) (b) request parameters and (c) response
formats.
(a) IN: identifier, DKIM-based
(b) OUT: scalar, good/bad in a recommended, min/max limited range with (simple)
textual explanations of sub-ranges (not too detailed, cannot be differentiated
by implementors anyway).
Within dkim-reputation.org I am using for (a) as DNS RR subdomain:
(i) if i= is available including local-part:
base64(md5(local-part_i)).base64(md5(domain-part_i)).base64(md5(signdom_d))
(ii) if i= is not available including local-part as a fallback (spoofable
inside a trusted signing domain):
base64(md5(local-part_from)).base64(md5(domain-part_from)).base64(md5(signdom_d))
This format is quite useful:
- if used in combination with DNS, wildcards can be used in the zone to combine
either domain parts and/or users below the reputation of the signing domain
- copied parts of the list (DNS caches, DNS mirrors or plain ASCII feeds) can't
reveal existing addresses (confirmations of addresses remain possible)
- if long usernames or domains are used this doesn't bother the system (btw: a
very long domain name our crawlers at dkim-reputation.org found was
"registeringdomainnamesismorefunthandoingrealwork.com" ;) )
Within dkim-reputation.org I am using for (b) the value of a TXT record that
contains
(i) a timestamp of the last record update (e.g. the last spam hit)
(ii) the reputation value at the time this hit was generated (within a range of
-1000 to 1000)
(iii) a proposed value how much to increase/decrease this value per day to
forgive bad reputation after some time
(iii) is very special and could be implemented on client side individually:
shouldn't be part of a recommendation. (i) is quite useful to prevent regular
updates of a DNS record on the provider side. (ii) is mandatory.
I'd appreciate if someone could follow this topic, I'm unfortunately too busy
to push this at time.
2) our statistics on http://www.dkim-reputation.org/statistics/ are quite
interesting: while those that send valid DomainKeys/DKIM signed spam to us told
us their entire spam traffic increased, we see that the number of spammers
using DKIM (directly with own signing domains or indirectly by using ISP
accounts) drops. The individual user accounts we detected belong mostly to
Gmail and Yahoo!. Here you can see the most significant decrease; both E-Mail
Services successfully react on ARF reports today and block the according
accounts.
It's also interesting to see that the number of bad domains decreases.
On the other hand I see that the number of entire signing domains increases
(Cisco was talking about a triplication since last year, I measured factor 2.5).
This is interesting but might remain without any consequences concerning
filtering: DKIM reputation - in my view - makes 100% sense concerning the
reduction of false positives. Since false positives aren't a great problem at
time I don't push dkim-reputation.org too much, waiting for a time it becomes
more necessary.
Concerning bad reputation there is some usage, but I saw: the hits that our
DKIM-reputation spamassassin plugin generated were just confirmations of spam
mails already rated bad. So no big advantage here, just one means in a combined
approach.
The idea to rate non-signed emails worse should be banned in my view: thinking
about DKIM failure scenarios as well you always should rate unsigned emails as
well as non-validly signed emails neutrally.
3) To get back to "DKIM adoption": since DKIM reputation obviously doesn't
boost there must be other drivers in my view, special example:
the German government is looking for a way to get court-proof emails. They
defined a concept that's very likely too complicated to become true, instead
small steps would be more helful; to provide long-term-proof I could imagine
the following setup (signer has to be trusted, users can change the ISP without
loosing the proof, just an idea):
http://www.agitos.de/pub/20090703-ingoing-dkim-for-stability-proof.pdf
Two aspects in this context, my view:
- as long as spoofing mails isn't a very promising attack like it is today
signatures will remain rather unimportant
- if we'd have signatures (of higher quality than DKIM) and therefore would use
email to e.g. place contracts, attacks on email would be more promising and
signatures would become important
5) a wish: in some scenarios it would be helpful if MUAs could work with DKIM
check results. If the client could somehow decide if an Authentication-Results
header was added by the trusted mailserver the client could use the server-side
generated results. If the server-id inside the Authentication-Results header
could be checked against a confirming DNS record being in the same zone as the
MX entry the client-side validation could be skipped. @Murray: is there some
news about this?
Best regards,
Florian
===
Agitos Technologies und Agitos Webhosting
Florian Sager
Emil-Geis-Straße 40, 81379 München
Telefon: 089/45867554
Telefax: 089/45867555
Support: support(_at_)agitos(_dot_)de
http://www.agitos.de
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html