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: supp...@agitos.de http://www.agitos.de _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html