Subject: [ietf-dkim] FW: An issue with DKIM reporting extensions

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 12 Oct 2010 12:11:47 -0700

I don't think this is really something this WG needs to deal with, though I could be wrong.  It's forwarded here just for informational purposes.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Tuesday, October 12, 2010 12:11 PM
To: [email-masked]
Subject: [marf] An issue with DKIM reporting extensions

Here's another problem case with ADSP that directly involves the DKIM reporting extensions.

Setup:

-          Domain X evaluates DKIM and ADSP inbound.

-          Domain Y's border MTA is configured to sign mail outbound and also generate success DSNs on request.  Domain Y posts an ADSP policy of "all", and furthermore is using the draft-ietf-marf-dkim-reporting extensions to announce it wants fraud reports about mail that fails ADSP.

Scenario:

-          X sends mail to Y.  The message requests a success DSN on delivery.

-          Y receives mail.  MTA generates success DSN as requested; however, it's generated internally (an MTA design decision) and goes directly to the outbound queue.  It therefore does not go through the SMTP filters, and thus isn't signed outbound.

-          X receives success DSN.  It is unsigned, as described.  Therefore, ADSP fails.  X detects that the reporting extension is in use and observes that Y wants fraud reports, so it generates one.

The MTA in question is widely deployed on the Internet.  It does not have the ability to change the domain in the From: field on DSNs it generates so as to detach it from the published policy, nor can it filter generated DSNs through a signing filter.  Also, ADSP doesn't have a mechanism to exempt DSNs from ADSP processing.  This means some or all of the following:

-          In order to make use of ADSP, Y needs to change which MTA it's using.  This is almost certainly an expensive effort.

-          Y simply can't use ADSP.

-          The DKIM reporting extensions should have a flag that says DSNs should not cause generation of fraud reports.

Comments?

-MSK
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 13 Oct 2010 13:29:02 -0000

>-          In order to make use of ADSP, Y needs to change which MTA it's
>using.  This is almost certainly an expensive effort.
>
>-          The DKIM reporting extensions should have a flag that says DSNs
>should not cause generation of fraud reports.

I'll take "none of the above", Alex.

I've seen a enough spam masquerading as DSNs that I really wouldn't
want to give DSNs a free pass.  I also think that history has not been
kind to people who made permanent changes to standards to work around
temporary software limitations.  If the MTA can't sign its DSNs, that's
a bug, no matter how popular it is.  (Come to think of it, my MTA has
the same issue, although since I will never publish dkim=all, it's
not functionally a bug.)

If people are serious about signing all their mail, they should sign
all their mail.  Maybe they'll switch MTAs, maybe their popular MTA
will eventually fix the DSN signing bug, and then they can publish
dkim=all.

R's,
John

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 13 Oct 2010 11:05:37 -0400

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of John Levine
> Sent: Wednesday, October 13, 2010 9:29 AM
> To: [email-masked]
> Subject: Re: [ietf-dkim] FW: An issue with DKIM reporting extensions
> 

I have to agree with John. The fact that a particular MTA doesn't sign
DSNs is a problem with that particular MTA. dkim=all means just that. 

The implementer is faced with the choice of not publishing "all",
getting their vendor to fix the product, switching vendors or accepting
that their DSNs may end up in /dev/null.

Mike

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 13 Oct 2010 17:07:34 +0200

> I'll take "none of the above", Alex.

Murray brought this up.

> a bug, no matter how popular it is.

 From the ADSP all/discardable point of view this is a bug. Not signing 
a message or DSN in itself is not a bug, of course ;-) Although we all 
hope that there will be one day that signing with DKIM is the de facto 
(or should we say de jure) standard and not signing with DKIM becomes a 
functional defect.

>    (Come to think of it, my MTA has
> all their mail.

+1

We have seen ADSP can cause issues with MLMs. Now we see that it can 
cause problems with DSNs (and feedback reports, see below) as well. This 
is input to item 3. of the current charter.

> Maybe they'll switch MTAs, maybe their popular MTA

Talking about fraud reports, let's not forget that these fraud reports 
need to be signed with DKIM by every domain, that is publishing an ADSP 
all or discardable policy. Of course DSN's and fraud reports etc. could 
be signed with a specific subdomain (e.g. notifications.example.com) or 
a special selector (e.g. s=notifications), to identify the different 
nature of this mail stream?

/rolf

---

From: Steve Atkins <[email-masked]>
Date: Wed, 13 Oct 2010 08:55:25 -0700

On Oct 13, 2010, at 8:07 AM, Rolf E. Sonneveld wrote:

> or 

No. Never do this.

Selectors are an operational convenience for key rotation and
ease of domain delegation. They have no semantics beyond
being used to query DNS to find the public key.

Cheers,
  Steve

---

From: Jeff Macdonald <[email-masked]>
Date: Wed, 13 Oct 2010 14:03:07 -0400

> being used to query DNS to find the public key.

+1 trillion

-- 
Jeff Macdonald
Ayer, MA

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 13 Oct 2010 14:24:28 -0400

On 10/13/2010 2:03 PM, Jeff Macdonald wrote:
> On Wed, Oct 13, 2010 at 11:55 AM, Steve Atkins<[email-masked]>  wrote:
>>> or

squared.

people really do need to read the Deployment RFC.

d/

-- 

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

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 13 Oct 2010 14:25:09 -0400

> being used to query DNS to find the public key.

Sure.  That's the right answer from a standard POV, but if I can extract 
statistically significant information by segregating mail streams by selector, 
I'll do it anyway, I don't care what the standard says (no, I haven't done 
this analysis yet, so I don't have an opinion on if one actually could do it 
or not).

Scott K

---

From: Steve Atkins <[email-masked]>
Date: Wed, 13 Oct 2010 11:39:22 -0700

> this analysis yet, so I don't have an opinion on if one actually could do it 

Do whatever you like as a receiver, as long as you do it in private -
I expect there will be some interesting, though probably not terribly
useful correlations there.

But don't encourage senders to break DKIM by suggesting
that there are any semantics to selectors. There aren't, and
trying to add any will break things.

Cheers,
  Steve

---

From: Michael Thomas <[email-masked]>
Date: Wed, 13 Oct 2010 11:34:18 -0700

> this analysis yet, so I don't have an opinion on if one actually could do it

Better: how does one slap the wrist of a Bayesian filter?

Mike