Subject: Re: [ietf-dkim] DKIM adoption

From: <[email-masked]>
Date: Mon, 3 Aug 2009 08:21:45 -0400

I am not ready to make that statement yet. Considering that a lot of spam has valid DKIM signatures I am not sure when I will make that statement
________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Franck Martin
Sent: Friday, July 31, 2009 6:23 PM
To: [email-masked]
Subject: [ietf-dkim] DKIM adoption

Looking at DKIM adoption. I have seen statements that some mailers will do DKIM based reputation if available, but I have yet to see a statement as either:
-an email not signed with DKIM will have its reputation lowered (less likely to pass filters)
-an email signed with DKIM will have its reputation increased (more likely to pass filters)

I think if there were some postmasters making such statement it would boost the adoption of DKIM.

I think stating that some postmasters are moving to domain based reputation is just encouraging the status quo of not DKIM signing to stay in IP based reputation.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 03 Aug 2009 12:49:33 -0600

Franck Martin wrote:
> Looking at DKIM adoption. I have seen statements that some mailers will
> do DKIM based reputation if available,  but I have yet to see a statement
> as either:

Yahoo! broadly hinted, some years ago, that they'd start giving a slight 
positive bump to messages signed with DomainKeys.  Two things happened:

1. serious hardcore spammers (not just misguided marketers) started 
including DomainKeys signatures

2. lots of people who really should've known better started saying "use 
DomainKeys and your deliverability will improve!"

We also wrote about the slow emergence of domain reputation recently, trying 
to avoid piling on to the hyperbolic misrepresentations so common on other 
email marketing blogs:

http://www.returnpath.net/blog/2009/07/domain-reputation-what-it-mean.php

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 03 Aug 2009 12:51:29 -0700

[email-masked] wrote:
>      , but I have yet to see a statement
> as either:

The presence or absence of a DKIM signature carries no inherent semantics about 
reputation of the signer.

Consequently anyone increasing or lowering a reputation assessment based on the 
presence or absence of a DKIM signature is going far beyond its stated purpose.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "MH Michael Hammer \(5304\)" <[email-masked]>
Date: Tue, 4 Aug 2009 11:44:52 -0400

Interesting replies. My apologies for my delayed response. I was off in
Vegas at defcon and intentionally not getting online for the duration.

While I don't believe that receivers would be particularly well served
by lowering reputation for unsigned emails or raising reputation for
those that are signed, it would certainly be useful if receivers took a
stronger stance in saying they are taking advantage of DKIM signatures
to track reputation. While in the past I have been primarily interested
in first party signing, I have been thinking about potential benefits of
our organization signing with a second signature so that we can use it
across properties. 

Mike

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Franck Martin
Sent: Friday, July 31, 2009 6:23 PM
To: [email-masked]
Subject: [ietf-dkim] DKIM adoption

Looking at DKIM adoption. I have seen statements that some mailers will
do DKIM based reputation if available, but I have yet to see a statement
as either:
-an email not signed with DKIM will have its reputation lowered (less
likely to pass filters)
-an email signed with DKIM will have its reputation increased (more
likely to pass filters)

I think if there were some postmasters making such statement it would
boost the adoption of DKIM.

I think stating that some postmasters are moving to domain based
reputation is just encouraging the status quo of not DKIM signing to
stay in IP based reputation.

---

From: hector <[email-masked]>
Date: Thu, 06 Aug 2009 03:15:28 -0400

> our organization signing with a second signature so that we can use it

I find it very hard to justify to finishing the addition of DKIM into 
our wcSMTP and wcListServer products.  We were all set to go when SSP 
was still in play and part of the DKIM API.

Without policy and no public reputation services, adding DKIM would 
add confusion to our customer base as to its purpose. To me, 
technology come first, not marketing.

So I ask you, how do you track "reputation?" especially anonymous?

Doug and I had this discussion 2-3 years ago about the problem of 
"Blitz" attacks in order to force a DoS facsimile forcing the receiver 
to turn of DKIM processing.

If DKIM needs batteries in order to have a payoff or some values, what 
batteries do you recommend?

Also, with our mail model, post SMTP processing is after the mail is 
checked. Our stock mail filtering scripting language are at the SMTP 
and DATA level before a response is provided.

When Mail is finally accepted, our design takes it very serious to no 
longer be part of the content decision making process - the buck 
(heuristic considerations) is passed to the operator.

Its an old school philosophy that accepting mail is taken very 
serious.   But if we were to add DKIM support, we would do so at the 
DATA level with our package. Efficiency and scalability is important. 
It has to be fast. That is why policy and fault tolerance was very 
important.  The idea of processing and still accepting failure is a 
big waste of time for us.  Note: that doesn't stop customers from 
adding DKIM themselves using some external post smtp scripting engine 
or whatever.  But it won't be ours and 99$ of them are going use what 
we provide.  After quite frankly, if I got 2 blind request for DKIM 
support, that would be a lot.  If we don't support DKIM, it won't 
happen for them.

--

---

From: Douglas Otis <[email-masked]>
Date: Thu, 06 Aug 2009 08:25:56 -0700

> batteries do you recommend?

It seems DKIM might be used to bypass filtering that typically good 
messages would otherwise confront as a means to reduce false positives. 
  Since few domains have only perfect users, one could also create a 
block list based upon the hash of the i= (on-behalf-of) value.  The 
query might look something like:

Query: <base32(sha-1(i=))>.<d=>.

For domains that have problematic users and don't offer even an opaque 
i= value that corresponds to message sources, the domain would need to 
be removed from the list which might have prevented false positive 
detections.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 6 Aug 2009 10:50:39 -0700

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Douglas Otis
> Sent: Thursday, August 06, 2009 8:26 AM
> To: hector
> Cc: [email-masked]; MH Michael Hammer (5304)
> Subject: Re: [ietf-dkim] DKIM adoption
> 

In 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.

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 06 Aug 2009 14:08:23 -0600

> In 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 informatio…

And, there are others in progress.

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 07 Aug 2009 07:21:38 -0700

> And, there are others in progress.

Folks,

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.

d/

-- 

   Dave Crocker

---

From: Florian Sager <[email-masked]>
Date: Thu, 27 Aug 2009 18:04:08 +0200

Dave CROCKER schrieb:
>>> 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.
>>>       
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: [email-masked]
http://www.agitos.de

---

From: John Levine <[email-masked]>
Date: 29 Aug 2009 15:51:36 -0000

> 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.

Back when we were developing VBR, we spent a fair amount of time
considering reputation query formats as a followon to VBR.  We came up
with some rough ideas, but the general feeling was that we don't
understand reputation well enough to try to nail anything down, and
that seems as true now as it ever was.

With respect to your specific proposal, I have two comments.  One is
that although the scheme for encoding i= strings is clever, since we
just went through a lengthy process to establish the d= domain as the
primary identifier, so I would just use that.  Using a plain domain
also makes it easier to use a system on top of other authentication
systems like SPF and Sender-ID.  (Although I am a fan of neither,
there are certainly some cases where they can give you a solid enough
positive result to use.)

The other is that "reputation" is hardly a single dimension.  In our
work, we had a DNS query that returned a reputation number on a 0-100
scale, but we also had a confidence value to give a hint about how
certain we were that our opinion was right, and a code to indicate
what sort of organization it was.  (The code was a SIC number, a
common business type code used in North America.)  The idea was that
if you got mail from someone, and the lookup said it was a bank, a
poor reputation might indicate that it was likely to be spam, but
since it's from a real bank, it's unlikely to be a phish so you might
want to deliver it anyway.  It occurs to me that you might need a
variety of reputation scales for spamminess, phishiness, sleaziness,
and so forth, since different receivers are likely to have different
opinions of, e.g., unsolicited mail advertising an actual vendor of
fancy coffee.

This strikes me as a fine topic for the ASRG since it is, you know,
research.  It would be quite reasonble to publish one or more
experimental RFCs via the ASRG with proposed reputation exchange
formats to document what we've been thinking about and give the rest
of the world a place to start.

R's,
John