From msk@cloudmark.com Tue Oct 12 12:09:31 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E31343A69FF for ; Tue, 12 Oct 2010 12:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.787 X-Spam-Level: X-Spam-Status: No, score=-103.787 tagged_above=-999 required=5 tests=[AWL=-1.189, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aBkPYBOkMXM for ; Tue, 12 Oct 2010 12:09:24 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id A91523A6A15 for ; Tue, 12 Oct 2010 12:09:24 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 12 Oct 2010 12:10:35 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 12 Oct 2010 12:10:35 -0700 Thread-Topic: An issue with DKIM reporting extensions Thread-Index: ActqQSXr/D4FHwyQR42OwzG0qeXEEw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F1340BA3811EXCHC2corpclo_" MIME-Version: 1.0 Subject: [marf] An issue with DKIM reporting extensions X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 19:09:32 -0000 --_000_F5833273385BB34F99288B3648C4F06F1340BA3811EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here's another problem case with ADSP that directly involves the DKIM repor= ting extensions. Setup: - Domain X evaluates DKIM and ADSP inbound. - Domain Y's border MTA is configured to sign mail outbound and al= so generate success DSNs on request. Domain Y posts an ADSP policy of "all= ", and furthermore is using the draft-ietf-marf-dkim-reporting extensions t= o announce it wants fraud reports about mail that fails ADSP. Scenario: - X sends mail to Y. The message requests a success DSN on delive= ry. - Y receives mail. MTA generates success DSN as requested; howeve= r, 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. Therefor= e, ADSP fails. X detects that the reporting extension is in use and observ= es that Y wants fraud reports, so it generates one. The MTA in question is widely deployed on the Internet. It does not have t= he 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 D= SNs 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 u= sing. 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 --_000_F5833273385BB34F99288B3648C4F06F1340BA3811EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here’s another problem case with ADSP that direc= tly involves the DKIM reporting extensions.

 

Setup:

-&nb= sp;         Domain X evaluates DKIM and ADSP inbound.

-&nb= sp;         Domain Y’s border MTA is configured to sign m= ail outbound and also generate success DSNs on request.  Domain Y posts an ADSP policy of “all”, and furthermore is using the draft-ietf-m= arf-dkim-reporting extensions to announce it wants fraud reports about mail that fails ADSP.

 

Scenario:

-&nb= sp;         X sends mail to Y.  The message requests a suc= cess DSN on delivery.

-&nb= sp;         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.

-&nb= sp;         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 generate= s 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 DSN= s it generates so as to detach it from the published policy, nor can it filter g= enerated DSNs through a signing filter.  Also, ADSP doesn’t have a mechan= ism to exempt DSNs from ADSP processing.  This means some or all of the following:

 

-&nb= sp;         In order to make use of ADSP, Y needs to change whi= ch MTA it’s using.  This is almost certainly an expensive effort.

-&nb= sp;         Y simply can’t use ADSP.

-&nb= sp;         The DKIM reporting extensions should have a flag th= at says DSNs should not cause generation of fraud reports.

 

Comments?

 

-MSK

--_000_F5833273385BB34F99288B3648C4F06F1340BA3811EXCHC2corpclo_-- From tony@att.com Tue Oct 12 12:41:49 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CCF83A6A79 for ; Tue, 12 Oct 2010 12:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.39 X-Spam-Level: X-Spam-Status: No, score=-106.39 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYnePeKSw-rO for ; Tue, 12 Oct 2010 12:40:53 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 416893A6A67 for ; Tue, 12 Oct 2010 12:40:32 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-3.tower-146.messagelabs.com!1286912506!16446504!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 4547 invoked from network); 12 Oct 2010 19:41:46 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-3.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 12 Oct 2010 19:41:46 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o9CJg2WJ027962 for ; Tue, 12 Oct 2010 15:42:03 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o9CJfwdZ027872 for ; Tue, 12 Oct 2010 15:41:58 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o9CJfeEP026640 for ; Tue, 12 Oct 2010 15:41:40 -0400 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id o9CJfdb3026635 for ; Tue, 12 Oct 2010 15:41:40 -0400 Received: from [135.70.254.105] (vpn-135-70-254-105.vpn.east.att.com[135.70.254.105]) by maillennium.att.com (mailgw1) with ESMTP id <20101012194139gw100ei13me> (Authid: tony); Tue, 12 Oct 2010 19:41:39 +0000 X-Originating-IP: [135.70.254.105] Message-ID: <4CB4B9F2.3070107@att.com> Date: Tue, 12 Oct 2010 15:41:38 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: "marf@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020702080804000806080701" Subject: Re: [marf] An issue with DKIM reporting extensions X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 19:41:49 -0000 This is a multi-part message in MIME format. --------------020702080804000806080701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/12/2010 3:10 PM, Murray S. Kucherawy wrote: > > 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. > 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 --------------020702080804000806080701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/12/2010 3:10 PM, Murray S. Kucherawy wrote:

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.

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
--------------020702080804000806080701-- From msk@cloudmark.com Tue Oct 12 12:57:35 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26F3B3A67FA for ; Tue, 12 Oct 2010 12:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.785 X-Spam-Level: X-Spam-Status: No, score=-103.785 tagged_above=-999 required=5 tests=[AWL=-1.187, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6PMsQCmJTPZF for ; Tue, 12 Oct 2010 12:57:28 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id C8C5B3A6A5B for ; Tue, 12 Oct 2010 12:57:28 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 12 Oct 2010 12:58:43 -0700 From: "Murray S. Kucherawy" To: "marf@ietf.org" Date: Tue, 12 Oct 2010 12:58:42 -0700 Thread-Topic: [marf] An issue with DKIM reporting extensions Thread-Index: ActqRcoF3gLYSCqCRX6ASxqE1X4ivAAAfJ5Q Message-ID: References: <4CB4B9F2.3070107@att.com> In-Reply-To: <4CB4B9F2.3070107@att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F1340BA3815EXCHC2corpclo_" MIME-Version: 1.0 Subject: Re: [marf] An issue with DKIM reporting extensions X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 19:57:35 -0000 --_000_F5833273385BB34F99288B3648C4F06F1340BA3815EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree it's primarily an MTA issue. I'd be fine with a consensus of decid= ing to leave it there, but I wanted to get some discussion going about it f= irst. If given my choice, I'd define "DSN" as "empty envelope sender" in this con= text, for the purposes of writing a reporting flag. From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Ton= y Hansen Sent: Tuesday, October 12, 2010 12:42 PM To: marf@ietf.org Subject: Re: [marf] An issue with DKIM reporting extensions On 10/12/2010 3:10 PM, Murray S. Kucherawy wrote: Here's another problem case with ADSP that directly involves the DKIM repor= ting 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 furt= hermore 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 gen= erated internally (an MTA design decision) and goes directly to the outboun= d 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 fai= ls. X detects that the reporting extension is in use and observes that Y w= ants fraud reports, so it generates one. The MTA in question is widely deployed on the Internet. It does not have t= he 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 D= SNs 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. Yes, either of the above. Another possibility is for the ADSP record to be enhanced to say "all but D= SNs" -- 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 t= o determine DSNs: Do you use MAILFROM =3D=3D <>, do you use Content-Type: m= ultipart/report, or some other method? Remember also that many joe jobs are done through DSNs. Are you going to pr= event 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 s= igned.) Tony Hansen --_000_F5833273385BB34F99288B3648C4F06F1340BA3815EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree it’s prima= rily an MTA issue.  I’d be fine with a consensus of deciding to leave it the= re, but I wanted to get some discussion going about it first.

 =

If given my choice, I= 217;d define “DSN” as “empty envelope sender” in this context, for the purposes of= writing a reporting flag.

 =

From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of Tony Hansen
Sent: Tuesday, October 12, 2010 12:42 PM
To: marf@ietf.org
Subject: Re: [marf] An issue with DKIM reporting extensions

 

On 10/12/2010 3:10 PM, Murray S. Kucherawy wrote:

Here’s another problem case with ADSP that direc= tly involves the DKIM reporting extensions.

 

Setup:

Domain X evaluates= DKIM and ADSP inbound.

Domain Y’s b= order MTA is configured to sign mail outbound and also generate success DSNs on request.  Domain Y posts an ADSP policy of “all”, and furt= hermore 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.&n= bsp; MTA generates success DSN as requested; however, it’s generated internall= y (an MTA design decision) and goes directly to the outbound queue.  It therefor= e 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 fr= aud 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 Fr= om: field on DSNs it generates so as to detach it from the published policy, no= r can it filter generated DSNs through a signing filter.  Also, ADSP doe= sn’t have a mechanism to exempt DSNs from ADSP processing.  This means some= or all of the following:

 

In order to make u= se of ADSP, Y needs to change which MTA it’s using.  This is almost ce= rtainly 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 =3D=3D <>, do you use Content-Typ= e: 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

--_000_F5833273385BB34F99288B3648C4F06F1340BA3815EXCHC2corpclo_-- From steve@wordtothewise.com Tue Oct 12 13:26:47 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECEFA3A6A2B for ; Tue, 12 Oct 2010 13:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.573 X-Spam-Level: X-Spam-Status: No, score=-4.573 tagged_above=-999 required=5 tests=[AWL=-1.974, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9vDkegrSrAR for ; Tue, 12 Oct 2010 13:26:44 -0700 (PDT) Received: from m.wordtothewise.com (goliath.word-to-the-wise.com [208.187.80.130]) by core3.amsl.com (Postfix) with ESMTP id 3E4393A6A26 for ; Tue, 12 Oct 2010 13:26:44 -0700 (PDT) Received: from platterhard.wordtothewise.com (184.wordtothewise.com [208.187.80.184]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id 977902DE7B for ; Tue, 12 Oct 2010 13:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wordtothewise.com; s=1.wttw; t=1286915278; bh=fSgJA90RyxgaYtSd6apUCozhTaDmNDKqI2MmhBPkfl4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=Dwx3uay1jrKxGxsUyNH1Mx8GBUXZuGr584LEE8fGiXmmBYzPIWrqUSpUgYIh2pExe 7y9LPYicHSo3rqAMDKjva+DakX40NxMVkHSgC4ayVY7IP358SvfmyU3B62cF30BiDF 90QsUUy+Tsh9U+fs8pI3KwkM12v+BqNm9KX5nhTI= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1081) From: Steve Atkins In-Reply-To: Date: Tue, 12 Oct 2010 13:27:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1D771F33-288A-4180-A52F-5D6DFB84BC0C@wordtothewise.com> References: To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1081) Subject: Re: [marf] An issue with DKIM reporting extensions X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 20:26:47 -0000 On Oct 12, 2010, at 12:10 PM, Murray S. Kucherawy wrote: > Here=92s another problem case with ADSP that directly involves the = DKIM reporting extensions. > =20 > Setup: > - Domain X evaluates DKIM and ADSP inbound. > - Domain Y=92s border MTA is configured to sign mail outbound = and also generate success DSNs on request. Domain Y posts an ADSP = policy of =93all=94, and furthermore is using the = draft-ietf-marf-dkim-reporting extensions to announce it wants fraud = reports about mail that fails ADSP. > =20 > 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=92s 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=92t 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. > =20 > 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=92t = have a mechanism to exempt DSNs from ADSP processing. This means some = or all of the following: > =20 > - In order to make use of ADSP, Y needs to change which MTA = it=92s using. This is almost certainly an expensive effort. > - Y simply can=92t 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 msk@cloudmark.com Tue Oct 12 14:10:18 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F4173A6A80 for ; Tue, 12 Oct 2010 14:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.78 X-Spam-Level: X-Spam-Status: No, score=-103.78 tagged_above=-999 required=5 tests=[AWL=-1.181, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wjsvVWnUo+j for ; Tue, 12 Oct 2010 14:10:15 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 14A643A6A87 for ; Tue, 12 Oct 2010 14:10:15 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 12 Oct 2010 14:11:30 -0700 From: "Murray S. Kucherawy" To: Message Abuse Report Format working group Date: Tue, 12 Oct 2010 14:11:28 -0700 Thread-Topic: [marf] An issue with DKIM reporting extensions Thread-Index: ActqTAJqtVHqHMlfSz64Kk2uKiz/JwABaqzw Message-ID: References: <1D771F33-288A-4180-A52F-5D6DFB84BC0C@wordtothewise.com> In-Reply-To: <1D771F33-288A-4180-A52F-5D6DFB84BC0C@wordtothewise.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [marf] An issue with DKIM reporting extensions X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 21:10:18 -0000 > -----Original Message----- > From: marf-bounces@ietf.org [mailto:marf-bounces@ietf.org] On Behalf Of S= teve Atkins > Sent: Tuesday, October 12, 2010 1:28 PM > To: Message Abuse Report Format working group > Subject: Re: [marf] An issue with DKIM reporting extensions >=20 > On Oct 12, 2010, at 12:10 PM, Murray S. Kucherawy wrote: > > - 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. >=20 > 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 arcan= a of MTA architecture can conceal things like this. It's neither documente= d nor intuitive, for example, that DSN generation bypasses input mail filte= rs in this particular case. From steve@wordtothewise.com Tue Oct 12 14:40:51 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B4843A6AAB for ; Tue, 12 Oct 2010 14:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.516 X-Spam-Level: X-Spam-Status: No, score=-4.516 tagged_above=-999 required=5 tests=[AWL=-1.917, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZRCrWixjtZF for ; Tue, 12 Oct 2010 14:40:31 -0700 (PDT) Received: from m.wordtothewise.com (b.wordtothewise.com [208.187.80.136]) by core3.amsl.com (Postfix) with ESMTP id BE7833A6AA2 for ; Tue, 12 Oct 2010 14:40:00 -0700 (PDT) Received: from platterhard.wordtothewise.com (184.wordtothewise.com [208.187.80.184]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id BD0B82DE75 for ; Tue, 12 Oct 2010 14:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wordtothewise.com; s=1.wttw; t=1286919675; bh=BQFZDwkiQGk0aG73A60BwbuwHWD6uGLwVftQ71DVrTY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=g8ROSGao3p03EIuEcEmlXQTIRCYbKWIOXVhCzOOa4IBMpRzBfbEL6Yqs0poBYTyYV YPEUMgXDS13746uP9VgOzq4FNoV4Aj7PwncJWuHJqYd1vuoeolfeNfAHD/mOAghyag HpwOyBywtznLMO4Am5ziO3O7eRk/Y3tmclLzjAaQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Steve Atkins In-Reply-To: Date: Tue, 12 Oct 2010 14:41:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1D771F33-288A-4180-A52F-5D6DFB84BC0C@wordtothewise.com> To: Message Abuse Report Format working group X-Mailer: Apple Mail (2.1081) Subject: Re: [marf] An issue with DKIM reporting extensions X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 21:40:51 -0000 On Oct 12, 2010, at 2:11 PM, Murray S. Kucherawy wrote: >> On Oct 12, 2010, at 12:10 PM, Murray S. Kucherawy wrote: >>> - 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. >>=20 >> 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. >=20 > 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. 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 barryleiba.mailing.lists@gmail.com Tue Oct 12 20:35:27 2010 Return-Path: X-Original-To: marf@core3.amsl.com Delivered-To: marf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9505E3A6B38 for ; Tue, 12 Oct 2010 20:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.972 X-Spam-Level: X-Spam-Status: No, score=-101.972 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fc73w0tp68PM for ; Tue, 12 Oct 2010 20:35:26 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 6BFB93A6B26 for ; Tue, 12 Oct 2010 20:35:26 -0700 (PDT) Received: by iwn10 with SMTP id 10so7228598iwn.31 for ; Tue, 12 Oct 2010 20:36:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=+i7wG6DLgMOzl8MIDZioXxxZLtmDDqqWLYVL/XkW+uU=; b=DgFPLAwvF0i7JGv6rF8qtjhZbEa64m3uL4Le1HaPK56B9o7zzzdNfh8gkD5InArPUx uleEgmgiDPK3GlLu2gn+xeCpyfeyhayIK2I/ueb4gLR4hb/RgvbUqZKNjwfSZsp32S0e l3fFk7F61lzTxQu/+S5LkS+314bGoK0ndpTSE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=piuLEBDL9kAkSWDvp7pXYNHJYlVPbApUl/F4FRM+c43uwXDgYwVIIJnKmyDczCkm4n tK9igacJXEMh+ovyicafJGXMPKQ9XO3TnfsVFn6/qpRvPpVv4bYDickBdhSqCMD2R7D4 Kjoho3ZfN0Oyl+Z7nwAB0+Y5kAwXTdEeeqf6A= MIME-Version: 1.0 Received: by 10.42.8.76 with SMTP id h12mr3819315ich.0.1286941002038; Tue, 12 Oct 2010 20:36:42 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.42.6.65 with HTTP; Tue, 12 Oct 2010 20:36:42 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Oct 2010 23:36:42 -0400 X-Google-Sender-Auth: sg8Ps-BKhxCdlYwjjgUqg-821-s Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "marf@ietf.org" Subject: Re: [marf] An issue with DKIM reporting extensions X-BeenThere: marf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Message Abuse Report Format working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 03:35:27 -0000 > The MTA in question is widely deployed on the Internet.=A0 It does not ha= ve > 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 DS= Ns > through a signing filter.=A0 Also, ADSP doesn=92t have a mechanism to exe= mpt > DSNs from ADSP processing.=A0 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