Subject: [marf] An issue with DKIM reporting extensions

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

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

---

From: Tony Hansen <[email-masked]>
Date: Tue, 12 Oct 2010 15:41:38 -0400

On 10/12/2010 3:10 PM, Murray S. Kucherawy wrote:
> - 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:
>
> - 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.
>
Yes, either of the above.
Another possibility is for the ADSP record to be enhanced to say "all 
but DSNs" -- but I don't like that idea.

The bottom line is that the site should not be using "all" unless *all* 
of its messages really are signed -- this site's are not.

> - The DKIM reporting extensions should have a flag that says DSNs 
> should not cause generation of fraud reports.
>
Not the best solution, but doable. You need to be careful in deciding 
how to determine DSNs: Do you use MAILFROM == <>, do you use 
Content-Type: multipart/report, or some other method?

Remember also that many joe jobs are done through DSNs. Are you going to 
prevent those from generating fraud reports?

I would consider this to be a bug in that MTA's implementation of 
signing. (Personally, I look forward to the day that I can drop any DSN 
that isn't signed.)

     Tony Hansen

---

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

I agree it's primarily an MTA issue.  I'd be fine with a consensus of deciding to leave it there, but I wanted to get some discussion going about it first.

If given my choice, I'd define "DSN" as "empty envelope sender" in this context, for the purposes of writing a reporting flag.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony Hansen
Sent: Tuesday, October 12, 2010 12:42 PM
To: [email-masked]
Subject: Re: [marf] An issue with 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.

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.
Yes, either of the above.
Another possibility is for the ADSP record to be enhanced to say "all but DSNs" -- but I don't like that idea.

The bottom line is that the site should not be using "all" unless *all* of its messages really are signed -- this site's are not.

The DKIM reporting extensions should have a flag that says DSNs should not cause generation of fraud reports.
Not the best solution, but doable. You need to be careful in deciding how to determine DSNs: Do you use MAILFROM == <>, do you use Content-Type: multipart/report, or some other method?

Remember also that many joe jobs are done through DSNs. Are you going to prevent those from generating fraud reports?

I would consider this to be a bug in that MTA's implementation of signing. (Personally, I look forward to the day that I can drop any DSN that isn't signed.)

    Tony Hansen

---

From: Steve Atkins <[email-masked]>
Date: Tue, 12 Oct 2010 13:27:57 -0700

On Oct 12, 2010, at 12:10 PM, Murray S. Kucherawy wrote:

> Here’s another problem case with ADSP that directly involves the DKIM reporting extensions.
>  
> Setup:
> -          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:
> -          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.
> 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.

One of those two (or Y should disable DSN support). If Y sends email that is not DKIM signed, yet also claim that all mail they send is really, really, really DKIM signed then.... well, they really have no clue what they're doing and are not a good candidate for ADSP-discardable usage.

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

That doesn't seem a good idea. If the purpose of the reports is to identify where Y has broken their DKIM signing, then they need to see the reports. If it's to determine when there's someone phishing their "brand" then they need to see the reports, even when the phisher is using an empty envelope sender.

I think it would be an option that would only be used by people who don't understand what they're doing, so it's probably just a foot-gun.

Cheers,
  Steve

---

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Steve Atkins
> Sent: Tuesday, October 12, 2010 1:28 PM
> To: Message Abuse Report Format working group
> > -          In order to make use of ADSP, Y needs to change which MTA
> it's using.  This is almost certainly an expensive effort.
> One of those two (or Y should disable DSN support). If Y sends email
> that is not DKIM signed, yet also claim that all mail they send is
> really, really, really DKIM signed then.... well, they really have no
> clue what they're doing and are not a good candidate for ADSP-
> discardable usage.

I think that's probably a bit of an extreme conclusion given that the arcana of MTA architecture can conceal things like this.  It's neither documented nor intuitive, for example, that DSN generation bypasses input mail filters in this particular case.

---

From: Steve Atkins <[email-masked]>
Date: Tue, 12 Oct 2010 14:41:15 -0700

> I think that's probably a bit of an extreme conclusion given that the arcana of MTA architecture can conceal things like this.  It's neither documented nor intuitive, for example, that DSN generati…

I don't think it's extreme. The mistake this example company made was to allow its inbound MXes to send mail directly to external machines - sure, they didn't understand the MTA configuration, but much more importantly they didn't have any egress filtering in place.

If they don't have full control over *every* legitimate email they send then they're not a good candidate for publishing ADSP-discardable.

To do that reliably they need to allow only their bulkmail cannons and a corporate smarthost to connect to port 25 outbound. Everything else, including their inbound MXes, should be behind packet filters that prevent (and ideally alert on) outbound port 25 connections. That way any attempts to send legitimate email over an unsanctioned channel will fail.

Yes, it will be inconvenient, but reconfiguring the corporate firewall to block port 25 outbound is a fairly small task. The real work is going to be identifying all the "unexpected" email that's being sent, and either stopping it or ensuring it's signed correctly - and that's something that has to be done before you can even consider publishing ADSP-discardable (or -all, I guess) records. That's the ADSP deployment cost.

Even on my own network of three small sites and <100 systems, I don't think I could guarantee that all legitimate email was signed without quite a lot of port 25 packet filtering - I'm pretty sure that no large organization could do so without it.

Cheers,
  Steve

---

From: Barry Leiba <[email-masked]>
Date: Tue, 12 Oct 2010 23:36:42 -0400

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

I see this as completely straightforward.  As others have said, this
domain is misusing ADSP, and needs to stop.  It says it signs all its
mail, yet it's sending mail that isn't signed.  I don't really care
*why* it's doing that.  It IS.

We should not be proposing workarounds for broken infrastructure.  If
you can't use ADSP because your infrastructure isn't up to it, then
don't use ADSP until you can fix your infrastructure.

C'est tout.

Barry