From nobody Fri May 1 03:01:19 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C341B30E9 for ; Fri, 1 May 2015 03:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.398 X-Spam-Level: * X-Spam-Status: No, score=1.398 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_61=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A50JfcoOwopf for ; Fri, 1 May 2015 03:01:15 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id 346F41B30E8 for ; Fri, 1 May 2015 03:01:14 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id 6A23683D9 for ; Fri, 1 May 2015 12:01:12 +0200 (CEST) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Fri, 1 May 2015 12:01:12 +0200 Message-ID: <93765AFCDBF64BC18A97AEB7DA9FCEB6@fgsr.local> From: "J. Gomez" To: References: <7120368.SRLs5cRkaz@kitterma-e6430> <30438248.UfeGvtBVnr@kitterma-e6430> Date: Fri, 1 May 2015 12:01:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: Subject: Re: [dmarc-ietf] YAIMFS (Yet Another Indirect Mail Flow "Solution") X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 10:01:17 -0000 On Thursday, April 30, 2015 7:19 PM [GMT+1=3DCET], Scott Kitterman = wrote: > On Thursday, April 30, 2015 10:00:46 AM Kurt Andersen wrote: > > On Thu, Apr 30, 2015 at 9:06 AM, Scott Kitterman > > =20 > >=20 > > wrote: > > > It might be useful though to have some opt-in mechanism for DMARC > > > senders to > > > get an additional query for verification purposes. > > >=20 > > > Concept: > > >=20 > > > Participating senders add a new optional tag to their DMARC > > > record, something > > > like yaimfs=3Dy and a new field in the header that is something > > > like:=20 > > >=20 > > > yaimfs-id: localpart@domain > > >=20 > > > Domain must be aligned with the From domain > > >=20 > > > For mail that passes DMARC, no changes are made. If a message > > > fails DMARC checks and both the DMARC record (which is already in > > > the local cache) has yaimfs=3Dy and the message has yaimfs-id is > > > possible, then the receiver sends a > > > DNS query to message-id.yamfsidlocalpart._dmarc.domain. The > > > sender then replies pass/fail/error. > > >=20 > > > I suggest message ID be included since it's supposed to be > > > globally unique to > > > reduce the risk of collision. > > >=20 > > > This idea effectively would create a new authentication protocol > > > based on direct query/feedback and extend DMARC to use it. It > > > would be totally opt-in. > >=20 > > Interesting idea - essentially it would allow senders to provide an > > independent authorization channel for messages. What worries me, is > > why a sender would sanction a message that presumably has been > > sufficiently altered as to fail DKIM validation without knowing > > something about the content as received. > >=20 > > It seems somewhat like saying that if you get a check (the > > old-fashioned paper kind), that if you call me and tell me what > > color the paper is, then you can cash the check (presuming that the > > color is correct). I would not, personally, be granting any such > > approvals.=20 >=20 > I think it's a bit more than that. It's more like "Give me the > serial number" "Oh, I just wrote a check with the number 30 seconds > ago, OK"=20 >=20 > I agree it's not a 100% secure solution since there's a replay risk, > but the risk is less than with the fs=3D proposal. If the message as received at the final recipient is failing the DMARC = check, then it comes from a non-authorized IP (regarding the domain in = the Header-From) and has an invalid/none DKIM signature (regarding the = domain in the Header-From). Anyone could grep the yaimfs-id: of such a = message, see that a query to message-id.yamfsidlocalpart._dmarc.domain. = passes, and build in the spot a 5 million messages Cryptolocker = campaign. Regards, J.Gomez From nobody Fri May 1 04:39:53 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D651B3102 for ; Fri, 1 May 2015 04:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_61=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVxzRT0RIe3n for ; Fri, 1 May 2015 04:39:51 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0122C1B30FE for ; Fri, 1 May 2015 04:39:51 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id DBF5BC40103 for ; Fri, 1 May 2015 06:39:49 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1430480389; bh=/FOewmWkm3KekJ7q7VJ1N/q99qtBAF/zzq/oeSLcM54=; h=From:To:Subject:Date:In-Reply-To:References:From; b=y+TGdWCwrzB2fg8DJdD2KEOkgIN5gNWQCtbwFBZcY7t6J1lBBf8zx/EpldC8rMGrY MLPlcNPO8C2il/K28zm0tgbiR8F8kiSM5fhUB2p4IVRcyDJv5bLussVk/5eh8ClQ1H 60kQkmitH5UZfX5HwOP4SPt14q/sEOdS2haMiY78= From: Scott Kitterman To: dmarc@ietf.org Date: Fri, 01 May 2015 07:39:49 -0400 Message-ID: <4223607.hj9JOhFhnK@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-51-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <93765AFCDBF64BC18A97AEB7DA9FCEB6@fgsr.local> References: <7120368.SRLs5cRkaz@kitterma-e6430> <30438248.UfeGvtBVnr@kitterma-e6430> <93765AFCDBF64BC18A97AEB7DA9FCEB6@fgsr.local> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] YAIMFS (Yet Another Indirect Mail Flow "Solution") X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 11:39:52 -0000 On Friday, May 01, 2015 12:01:00 PM J. Gomez wrote: > On Thursday, April 30, 2015 7:19 PM [GMT+1=CET], Scott Kitterman wrote: > > On Thursday, April 30, 2015 10:00:46 AM Kurt Andersen wrote: > > > On Thu, Apr 30, 2015 at 9:06 AM, Scott Kitterman > > > > > > > > > wrote: > > > > It might be useful though to have some opt-in mechanism for DMARC > > > > senders to > > > > get an additional query for verification purposes. > > > > > > > > Concept: > > > > > > > > Participating senders add a new optional tag to their DMARC > > > > record, something > > > > like yaimfs=y and a new field in the header that is something > > > > like: > > > > > > > > yaimfs-id: localpart@domain > > > > > > > > Domain must be aligned with the From domain > > > > > > > > For mail that passes DMARC, no changes are made. If a message > > > > fails DMARC checks and both the DMARC record (which is already in > > > > the local cache) has yaimfs=y and the message has yaimfs-id is > > > > possible, then the receiver sends a > > > > DNS query to message-id.yamfsidlocalpart._dmarc.domain. The > > > > sender then replies pass/fail/error. > > > > > > > > I suggest message ID be included since it's supposed to be > > > > globally unique to > > > > reduce the risk of collision. > > > > > > > > This idea effectively would create a new authentication protocol > > > > based on direct query/feedback and extend DMARC to use it. It > > > > would be totally opt-in. > > > > > > Interesting idea - essentially it would allow senders to provide an > > > independent authorization channel for messages. What worries me, is > > > why a sender would sanction a message that presumably has been > > > sufficiently altered as to fail DKIM validation without knowing > > > something about the content as received. > > > > > > It seems somewhat like saying that if you get a check (the > > > old-fashioned paper kind), that if you call me and tell me what > > > color the paper is, then you can cash the check (presuming that the > > > color is correct). I would not, personally, be granting any such > > > approvals. > > > > I think it's a bit more than that. It's more like "Give me the > > serial number" "Oh, I just wrote a check with the number 30 seconds > > ago, OK" > > > > I agree it's not a 100% secure solution since there's a replay risk, > > but the risk is less than with the fs= proposal. > > If the message as received at the final recipient is failing the DMARC > check, then it comes from a non-authorized IP (regarding the domain in the > Header-From) and has an invalid/none DKIM signature (regarding the domain > in the Header-From). Anyone could grep the yaimfs-id: of such a message, > see that a query to message-id.yamfsidlocalpart._dmarc.domain. passes, and > build in the spot a 5 million messages Cryptolocker campaign. Almost. You only get a pass if the originator says so, so they have the ability to limit this to no more than whatever local policy would specify. That's the difference in exposure between this proposal and the fs= proposal. In this proposal the sender is in full control of how many times to say yes. With fs= the most that could be done is put a time limit which , if too short causes other operational problems. Scott K From nobody Fri May 1 08:55:24 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA931A1BE5 for ; Fri, 1 May 2015 08:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhNb1YQ61Nu5 for ; Fri, 1 May 2015 08:55:20 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 821EB1A1BDB for ; Fri, 1 May 2015 08:55:20 -0700 (PDT) Received: from vindemiatrix.encs.concordia.ca (vin-anne@vindemiatrix.encs.concordia.ca [132.205.47.192]) by oldperseverance.encs.concordia.ca (envelope-from anne@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t41FtGAq015364 for ; Fri, 1 May 2015 11:55:16 -0400 Received: from vindemiatrix.encs.concordia.ca (vin-anne@localhost) by vindemiatrix.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t41FtFDA017718 for ; Fri, 1 May 2015 11:55:16 -0400 X-Authentication-Warning: vindemiatrix.encs.concordia.ca: vin-anne owned process doing -bs To: dmarc@ietf.org In-reply-to: Your message of Thu, 30 Apr 2015 09:34:30 PDT References: <554233AE.8090901@gmail.com> From: Anne Bennett Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Date: Fri, 01 May 2015 11:55:15 -0400 Message-ID: <17717.1430495715@vindemiatrix.encs.concordia.ca> X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-05-01 11:55:16 EDT Archived-At: Subject: Re: [dmarc-ietf] DMARC,SPF, null senders, and indirect mail flow X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 15:55:22 -0000 Franck Martin writes: > Note that postfix/sendmail can DKIM sign the bounces it creates. A few weeks ago I searched for documentation on how to make Sendmail sign its bounces, and I failed to find anything. If you could point me at any document at all as a starting point for that, I'd be grateful. Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne@encs.concordia.ca +1 514 848-2424 x2285 From nobody Fri May 1 09:54:12 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF95C1A8AA7 for ; Fri, 1 May 2015 09:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZaXQwpEwj-O for ; Fri, 1 May 2015 09:54:09 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24D181A1B91 for ; Fri, 1 May 2015 09:54:09 -0700 (PDT) Received: by wgin8 with SMTP id n8so95443198wgi.0 for ; Fri, 01 May 2015 09:54:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1LFTT9vc6m4Kejcz6Taar+HWxIAiMIFOk91XX/suI2g=; b=to767uAsTmCacjG4WK0cDjcikvbHhEjraxv4y+QH8JOhcHsuIsm4fPZscwP5/ppryo HGojIafdjXHr/izuVsNG2IIl0cgpzQu6Nn21YHiFHfwFzifF7wl3eaTHoaOimjJsNKnq krMPG9JNV+sym2OaTvnpAycxVX9n8FpjehJtH/XK+5F3lz4OYHE/Ma6c/FRKaoIn3LhW +fWgS2ttj/faLtZGnM+W9U19vsn0EaYCRpFWL6FUHEcy4NlM5Q45b9PvG1kmkZKUYfQm sVHAfI1JN6GUwIa+nItcjXHrQl5HcxiT5lYbl2w0hn6a2PnYPBJuR6jkYgvkZs8uob11 8Srg== MIME-Version: 1.0 X-Received: by 10.180.83.195 with SMTP id s3mr16284866wiy.52.1430499247892; Fri, 01 May 2015 09:54:07 -0700 (PDT) Received: by 10.27.170.75 with HTTP; Fri, 1 May 2015 09:54:07 -0700 (PDT) In-Reply-To: <17717.1430495715@vindemiatrix.encs.concordia.ca> References: <554233AE.8090901@gmail.com> <17717.1430495715@vindemiatrix.encs.concordia.ca> Date: Fri, 1 May 2015 09:54:07 -0700 Message-ID: From: "Murray S. Kucherawy" To: Anne Bennett Content-Type: multipart/alternative; boundary=f46d04428d1c85af220515080fd9 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC,SPF, null senders, and indirect mail flow X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 16:54:11 -0000 --f46d04428d1c85af220515080fd9 Content-Type: text/plain; charset=UTF-8 On Fri, May 1, 2015 at 8:55 AM, Anne Bennett wrote: > > Franck Martin writes: > > Note that postfix/sendmail can DKIM sign the bounces it creates. > > A few weeks ago I searched for documentation on how to make > Sendmail sign its bounces, and I failed to find anything. > If you could point me at any document at all as a starting > point for that, I'd be grateful. DKIM signing in sendmail is done via its milter API, which is instantiated only when traffic arrives via SMTP. DSNs are generated and queued internally, not via SMTP. Thus sendmail does not sign its bounces. The only way to do that would be to have the sendmail instance generating the DSN route the DSN through a second MTA on its way out, and that second one would do the signing. I have no idea if any of that is true for postfix, but I believe it has hooks for calling milter APIs even for non-SMTP messages. -MSK --f46d04428d1c85af220515080fd9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, May 1, 2015 at 8:55 AM, Anne Bennett <anne@e= ncs.concordia.ca> wrote:

Franck Martin <franck@peachyma= ngo.org> writes:
> Note that postfix/sendmail can DKIM sign the bounces it creates.

A few weeks ago I searched for documentation on how to make
Sendmail sign its bounces, and I failed to find anything.
If you could point me at any document at all as a starting
point for that, I'd be grateful.
=C2=A0
DKIM sign= ing in sendmail is done via its milter API, which is instantiated only when= traffic arrives via SMTP.=C2=A0 DSNs are generated and queued internally, = not via SMTP.=C2=A0 Thus sendmail does not sign its bounces.=C2=A0 The only= way to do that would be to have the sendmail instance generating the DSN r= oute the DSN through a second MTA on its way out, and that second one would= do the signing.

I = have no idea if any of that is true for postfix, but I believe it has hooks= for calling milter APIs even for non-SMTP messages.

-MSK=
--f46d04428d1c85af220515080fd9-- From nobody Fri May 1 10:06:38 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFDCD1B2AEF for ; Fri, 1 May 2015 10:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocpwlS7r9R13 for ; Fri, 1 May 2015 10:06:34 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 563981B2AB2 for ; Fri, 1 May 2015 10:06:34 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id C6A265641EC; Fri, 1 May 2015 12:06:31 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id B254960817; Fri, 1 May 2015 12:06:31 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xi0XaqTFgCIF; Fri, 1 May 2015 12:06:31 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 59BD76081B; Fri, 1 May 2015 12:06:31 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 59BD76081B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1430499991; bh=AgbUmxgwmZTVX7u9NSrti8Xme92AQsAkXe67WHRy0WA=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=CnMWNJYmiseWVtXMqAZ5BvLA50pAnqifhNMfSBmEDxMuCKYuhU33pvBKGxTLI25iV hlrRTDxm1mblDoyWN9kGO/lv5TF0/s5QKuU22LTP/1uy37GwZf35z5szrbCDn+UWQH QIMtkIIWaBXzunWsfUHNrOLz9jhmd9v3Bbp0qJUA= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 3D5A860817; Fri, 1 May 2015 12:06:31 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id tj-A5XuA2eI5; Fri, 1 May 2015 12:06:31 -0500 (CDT) Received: from [10.0.0.6] (c-67-180-100-98.hsd1.ca.comcast.net [67.180.100.98]) by smtp-out-2.01.com (Postfix) with ESMTPSA id 7FCBF6080B; Fri, 1 May 2015 12:06:30 -0500 (CDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_FFEB1817-1073-416E-A2CA-B8AB44C5C201" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Franck Martin In-Reply-To: Date: Fri, 1 May 2015 10:06:29 -0700 Message-Id: <5201C7D4-D4CC-488F-BF5B-62D6CDB82281@peachymango.org> References: <554233AE.8090901@gmail.com> <17717.1430495715@vindemiatrix.encs.concordia.ca> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "dmarc@ietf.org" , Anne Bennett Subject: Re: [dmarc-ietf] DMARC,SPF, null senders, and indirect mail flow X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 17:06:37 -0000 --Apple-Mail=_FFEB1817-1073-416E-A2CA-B8AB44C5C201 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On May 1, 2015, at 9:54 AM, Murray S. Kucherawy = wrote: >=20 > On Fri, May 1, 2015 at 8:55 AM, Anne Bennett > wrote: >=20 > Franck Martin > = writes: > > Note that postfix/sendmail can DKIM sign the bounces it creates. >=20 > A few weeks ago I searched for documentation on how to make > Sendmail sign its bounces, and I failed to find anything. > If you could point me at any document at all as a starting > point for that, I'd be grateful. > =20 > DKIM signing in sendmail is done via its milter API, which is = instantiated only when traffic arrives via SMTP. DSNs are generated and = queued internally, not via SMTP. Thus sendmail does not sign its = bounces. The only way to do that would be to have the sendmail instance = generating the DSN route the DSN through a second MTA on its way out, = and that second one would do the signing. >=20 > I have no idea if any of that is true for postfix, but I believe it = has hooks for calling milter APIs even for non-SMTP messages. >=20 http://www.postfix.org/MILTER_README.html = Signing internally-generated bounce messages Postfix normally does not apply content filters to mail that is = generated internally such as bounces or Postmaster notifications. = Filtering internally-generated bounces would result in loss of mail when = a filter rejects a message, as the resulting double-bounce message would = almost certainly also be blocked.=20 To sign Postfix's own bounce messages, enable filtering of = internally-generated bounces (line 2 below), and don't reject any = internally-generated bounces with non_smtpd_milters = , = header_checks or = body_checks (lines = 3-5 below).=20 1 /etc/postfix/main.cf : 2 internal_mail_filter_classes = =3D = bounce 3 non_smtpd_milters = =3D don't = reject internally-generated bounces 4 header_checks = =3D don't reject = internally-generated bounces 5 body_checks =3D= don't reject internally-generated bounces --Apple-Mail=_FFEB1817-1073-416E-A2CA-B8AB44C5C201 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On May 1, 2015, at 9:54 AM, Murray S. Kucherawy <superuser@gmail.com>= wrote:

On Fri, May 1, 2015 at 8:55 AM, Anne Bennett = <anne@encs.concordia.ca> = wrote:
Franck Martin <franck@peachymango.org> writes:
> Note that postfix/sendmail can DKIM sign the bounces it creates.

A few weeks ago I searched for documentation on how to make
Sendmail sign its bounces, and I failed to find anything.
If you could point me at any document at all as a starting
point for that, I'd be grateful.
 
DKIM signing in sendmail is done via its milter = API, which is instantiated only when traffic arrives via SMTP.  = DSNs are generated and queued internally, not via SMTP.  Thus = sendmail does not sign its bounces.  The only way to do that would = be to have the sendmail instance generating the DSN route the DSN = through a second MTA on its way out, and that second one would do the = signing.

I have no idea if any of = that is true for postfix, but I believe it has hooks for calling milter = APIs even for non-SMTP messages.


Signing internally-generated = bounce messages

Postfix normally does not apply content filters to = mail that is generated internally such as bounces or Postmaster = notifications. Filtering internally-generated bounces would result in = loss of mail when a filter rejects a message, as the resulting = double-bounce message would almost certainly also be = blocked. 

To sign = Postfix's own bounce messages, enable filtering of internally-generated = bounces (line 2 below), and don't reject any internally-generated = bounces with non_smtpd_milters, header_checks or body_checks (lines 3-5 below). 

1 =
/etc/postfix/main.cf:
2     internal_mail_filter_classes =3D bounce
3     non_smtpd_milters =3D don't reject =
internally-generated bounces
4     header_checks =3D don't reject =
internally-generated bounces
5     body_checks =3D don't reject =
internally-generated bounces


= --Apple-Mail=_FFEB1817-1073-416E-A2CA-B8AB44C5C201-- From nobody Sat May 2 09:56:49 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12381A702B for ; Sat, 2 May 2015 09:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.299 X-Spam-Level: *** X-Spam-Status: No, score=3.299 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWuCJO5PACPA for ; Sat, 2 May 2015 09:56:46 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 483611A702D for ; Sat, 2 May 2015 09:56:45 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 782C81C392A; Sun, 3 May 2015 01:56:44 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 5177C11F6A1; Sun, 3 May 2015 01:56:44 +0900 (JST) From: "Stephen J. Turnbull" To: Kurt Andersen In-Reply-To: References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Sun, 03 May 2015 01:56:44 +0900 Message-ID: <87r3qyor3n.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" , Franck Martin Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 16:56:48 -0000 Kurt Andersen writes: > On Thu, Apr 30, 2015 at 9:27 AM, Franck Martin > wrote: > > my corporate email address, but I wanted to mention the presence of such > > headers is not foolproof. > With List-Id becoming a more generic feedback channel, I suspect > that its value for indicating the participation of a MLM will > further degrade. Guys, if you want to attack a proposal, please make one first. I did not propose this. My whole point was that it's easy to imagine ways that the registration problem could be handled by "p=reject" domains *if* they want to handle it, and therefore we *don't* need to make any such proposal ourselves. No more, and no less -- I wouldn't waste the list's time on such a proposal if I were you. But YMMV, be my guest. Burning-strawmen-is-child's-play-ly y'rs, Steve From nobody Sat May 2 10:34:45 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528E31A892A for ; Sat, 2 May 2015 10:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9vePt5XqGys for ; Sat, 2 May 2015 10:34:43 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E1651A86E3 for ; Sat, 2 May 2015 10:34:43 -0700 (PDT) Received: (qmail 23615 invoked from network); 2 May 2015 17:34:43 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 2 May 2015 17:34:43 -0000 Date: 2 May 2015 17:34:19 -0000 Message-ID: <20150502173419.27958.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: kurta@drkurt.com Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 17:34:44 -0000 >With List-Id becoming a more generic feedback channel, I suspect that its >value for indicating the participation of a MLM will further degrade. This is news to me. Can you explain or give pointers? The only application of List-ID with which I am familiar is to sort (or filter depending on which coast you're from) mailing list traffic more reliably. R's, John From nobody Sat May 2 12:48:20 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6431A8F41 for ; Sat, 2 May 2015 12:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.553 X-Spam-Level: * X-Spam-Status: No, score=1.553 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DRUGS_PAIN=0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_GREY=0.424, URI_HEX=1.122] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdXKNNuy6wcN for ; Sat, 2 May 2015 12:48:17 -0700 (PDT) Received: from mx.msi.es (mx.msi.es [83.61.21.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA6E1A8F3E for ; Sat, 2 May 2015 12:48:16 -0700 (PDT) Received: from eh.msi.es (unknown [192.168.111.3]) by mx.msi.es (Postfix) with ESMTP id 1DF8E842E for ; Sat, 2 May 2015 21:48:14 +0200 (CEST) Received: from servidor3 (62.82.191.195) by exchange01.exchange.msi.es (192.168.223.3) with Microsoft SMTP Server (TLS) id 8.3.298.1; Sat, 2 May 2015 21:48:13 +0200 Message-ID: <8FAFE3834D2B47829A4383DCF890D1E2@fgsr.local> From: "J. Gomez" To: References: <20150502173419.27958.qmail@ary.lan> Date: Sat, 2 May 2015 21:47:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.4657 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4913 Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 19:48:19 -0000 On Saturday, May 02, 2015 7:34 PM [GMT+1=3DCET], John Levine wrote: > > With List-Id becoming a more generic feedback channel, I suspect > > that its value for indicating the participation of a MLM will > > further degrade.=20 >=20 > This is news to me. Can you explain or give pointers? >=20 > The only application of List-ID with which I am familiar is to sort > (or filter depending on which coast you're from) mailing list traffic > more reliably. I see email marketing campaigns using List-ID, behold: BEGIN=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Return-Path: = X-Original-To: changed-not-real@example.com Delivered-To: changed-not-real@example.com X-Greylist: delayed 902 seconds by postgrey-1.27 at gran.example.com; = Thu, 23 Apr 2015 10:32:17 CEST Received-SPF: pass (mail173.atl61.mcsv.net: 205.201.135.173 is = authorized to use = 'bounce-mc.us3_22600075.764833-jgomez=3Dexample.com@mail173.atl61.mcsv.ne= t' in 'mfrom' identity (mechanism 'ip4:205.201.135.173' matched)) = receiver=3Dgran.example.com; identity=3Dmfrom; = envelope-from=3D"bounce-mc.us3_22600075.764833-jgomez=3Dexample.com@mail1= 73.atl61.mcsv.net"; helo=3Dmail173.atl61.mcsv.net; = client-ip=3D205.201.135.173 Received: from mail173.atl61.mcsv.net (mail173.atl61.mcsv.net = [205.201.135.173]) by gran.example.com (Postfix) with ESMTP id A58771335 for ; Thu, 23 Apr 2015 10:32:17 +0200 = (CEST) DKIM-Signature: v=3D1; a=3Drsa-sha1; c=3Drelaxed/relaxed; s=3Dk1; = d=3Dmail173.atl61.mcsv.net; = h=3DSubject:From:Reply-To:To:Date:Message-ID:List-ID:List-Unsubscribe:Sen= der:Content-Type:MIME-Version; = i=3Dinfo=3D3Daceronline.es@mail173.atl61.mcsv.net; bh=3DwGF7q/xDOPhln8GsTOwUyofYAmk=3D; = b=3DX3o/vsisNJ2otny+LFofvyn0QboEogdi5tnTOTqAalIGssHj3CidoXhwm5aj8jsb30CWr= 8omyZDe = jkDq86qUfe0dvo+Tiqd+DYg1GuLDagoHLCuJhajmuPAjU5m/fEyYL3MmKSr1nphnUZy+Uv2n4= 2QJ HS+3HI7c/Elgp+xxSRU=3D DomainKey-Signature: a=3Drsa-sha1; c=3Dnofws; q=3Ddns; s=3Dk1; = d=3Dmail173.atl61.mcsv.net; = b=3DDJAKlTvtTaXjHyzWE2vbHZG445Y17LQ2nqspsqVDCHsCULyrMc932Gv5NORCoLfe9u3Ez= ezZf+x4 = 7/SWl1sk5JXTB6B+L3TJbyHRzpy9JYI9ygF/ZBKW1JL7D10DvZNtHZLZk83aD1gm/CvUf4H1B= zIv L4xpJqbsPu8frmYaM/Q=3D; Received: from (127.0.0.1) by mail173.atl61.mcsv.net id h72n16174ac0 = for ; Thu, 23 Apr 2015 08:17:13 +0000 = (envelope-from = ) Subject: = =3D?utf-8?Q?Regala=3D20m=3DC3=3DA1s=3D20que=3D20un=3D20libro?=3D From: =3D?utf-8?Q?AcerOnline?=3D Reply-To: =3D?utf-8?Q?AcerOnline?=3D To: =3D?utf-8?Q??=3D Date: Thu, 23 Apr 2015 08:17:13 +0000 Message-ID: = X-Mailer: MailChimp Mailer - **CID91c1f99d79d685b8a711** X-Campaign: mailchimpae5586b59986b26a25e2b4f5d.91c1f99d79 X-campaignid: mailchimpae5586b59986b26a25e2b4f5d.91c1f99d79 X-Report-Abuse: Please report abuse for this campaign here: = http://www.mailchimp.com/abuse/abuse.phtml?u=3Dae5586b59986b26a25e2b4f5d&= id=3D91c1f99d79&e=3Dd685b8a711 X-MC-User: ae5586b59986b26a25e2b4f5d X-Feedback-ID: 22600075:22600075.764833:us3:mc List-ID: ae5586b59986b26a25e2b4f5dmc list = X-Accounttype: pd List-Unsubscribe: = , = Sender: "AcerOnline" x-mcda: FALSE Content-Type: multipart/alternative; = boundary=3D"_----------=3D_MCPart_1886660041" MIME-Version: 1.0 This is a multi-part message in MIME format --_----------=3D_MCPart_1886660041 Content-Type: text/plain; charset=3D"utf-8"; format=3D"fixed" Content-Transfer-Encoding: quoted-printable http://www.aceronline.es?mc_cid=3D3D91c1f99d79&mc_eid=3D3D[UNIQID] Port=3DC3=3DA1tiles = (http://www.aceronline.es/portatiles-acer.html?mc_cid=3D3D91=3D c1f99d79&mc_eid=3D3D[UNIQID]) | Tablets = (http://www.aceronline.es/tablets=3D -acer.html?mc_cid=3D3D91c1f99d79&mc_eid=3D3D[UNIQID]) | Smartphones = (http:/=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DEND. Regards, J.Gomez From nobody Sat May 2 14:21:53 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484671A9048 for ; Sat, 2 May 2015 14:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtvojSTvhL7o for ; Sat, 2 May 2015 14:21:50 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4968E1A9047 for ; Sat, 2 May 2015 14:21:50 -0700 (PDT) Received: by pabsx10 with SMTP id sx10so124556653pab.3 for ; Sat, 02 May 2015 14:21:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=C1kgO2lsUGkaFxcLfpRwGfrQ3fBipmKL0d8FynJ+LSE=; b=uUzCnxH+flwXz8A0H7bqoH18kd2BvSPXvb/2PrXvDTyRy7tgBUs7cdMwvyc5R8MhxG Ewr0P/J/i/QWkvJxYgf3oMbZuH7J6KleRgAFizDcimLCWZwKf1WfERUPEdNqTwFDbysn L6EzAt+nI086jKPqbq08Ua1edoQSqNifOiyzwyFJTWV5esvyPgspHDrX23U0OAw4UUo+ 1uLMsMGxQp85d6sAn7kHs7qNAzIrQU2cKMXqoohS+B8s+beyIkQ+ydg5QH96HOPzOL8J 87nu+Y/JgXlxxyA98OrXvK9n6ge5Ty2Z2O6dmB1PKD8NTYnJEGJXuSrDAlbC6CFltsb+ uGnw== X-Received: by 10.66.179.81 with SMTP id de17mr29324211pac.59.1430601709896; Sat, 02 May 2015 14:21:49 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id xo3sm8412012pbb.74.2015.05.02.14.21.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 May 2015 14:21:48 -0700 (PDT) Message-ID: <55453FEA.2080308@gmail.com> Date: Sat, 02 May 2015 14:21:46 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> <87r3qyor3n.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87r3qyor3n.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 21:21:52 -0000 On 5/2/15 9:56 AM, Stephen J. Turnbull wrote: > Kurt Andersen writes: > > > On Thu, Apr 30, 2015 at 9:27 AM, Franck Martin > > wrote: > > > > my corporate email address, but I wanted to mention the presence of such > > > headers is not foolproof. > > > With List-Id becoming a more generic feedback channel, I suspect > > that its value for indicating the participation of a MLM will > > further degrade. > > Guys, if you want to attack a proposal, please make one first. I did > not propose this. My whole point was that it's easy to imagine ways > that the registration problem could be handled by "p=reject" domains > *if* they want to handle it, and therefore we *don't* need to make any > such proposal ourselves. No more, and no less -- I wouldn't waste the > list's time on such a proposal if I were you. But YMMV, be my guest. Dear Stephen, Tend to agree. Authentication methods alone never exclude malefactors. Problems occur when assuming general public messages MUST maintain alignment between mailfrom and from while completely ignoring sender and group syntax needed to handle EIA, or the addition of PGP encryption, or defanging dangerous links and banned words. The mistaken assumption is use of standard conventions identifies untrustworthy or conversely DMARC identifies trustworthy sources. Since DMARC uses either SPF or DKIM and since DKIM can always be replayed to any number of recipients, controlling abuse REQUIRES constant monitoring beyond DMARC feedback whether or not extended by TPA-Label, DKIM-Conditional, DKIM-Transform. Trust requires constant assessment and close cooperation between receiving and sending domains. Email does not support "Set and forget it" modes of operation when dealing with public exchanges. Senders should never assume restrictive DMARC assertions relieves the need to monitor and respond to abuse. The few DMARC domains causing trouble can be handled by private override lists, but there should be standardized profiles to help ensure better practices. One possible profile is described here: https://tools.ietf.org/html/draft-otis-dmarc-escape-02#section-2 This profile better ensures email is less likely disrupted by errant policy assertions simply by offering "public" handling. This avoids causing recipients to be unable to ascertain authors or the contents of their quarantine folders while avoiding expensive message disruptions. Regards, Douglas Otis From nobody Sat May 2 20:58:18 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A141A006F for ; Sat, 2 May 2015 20:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.102 X-Spam-Level: X-Spam-Status: No, score=-100.102 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDHHalhc16kl for ; Sat, 2 May 2015 20:58:12 -0700 (PDT) Received: from ntbbs.santronics.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id EABE61A0070 for ; Sat, 2 May 2015 20:58:11 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1467; t=1430625481; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=J4K0WbrA2Tphnld4YdemNyBW6bk=; b=Xh1o1Ca6VL2BOeiVpi1b vGtPEI3Md1PPnb8XVxUB08CenY6bUVy3qfBHiofxnt6HlU5L28VfWEi3SzvPsRuk Ry1gugupf1xYucXi11GiEuIABsQxtVP77rA/9XLD9Ki8XGHUrwP/JBKv5+ExmH2m CfPshuc5FpIPPPPpX7Xd3WM= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 02 May 2015 23:58:01 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 40510834.141.2892; Sat, 02 May 2015 23:58:00 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1467; t=1430625215; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=SVzCI+7 OX9tGNevl6eQ7XX3sxuEdAg/VgRNHDOOeTt0=; b=Ns4bki1thVJ2nyJCFRyThUF RiCie2nafnwjTM7SERxOFZzK4RpNp/IQRcUxXTMumr7cNuiOW5KXjfZDsb8AnP8p 2NwzQ5thd8k2uiV011IY6lNpAX3UiBa/Ssv/n5PvLck/rNeqvoEmAl3lSY6W0Dez fNxrNUACWkxWxpC9Lv18= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 02 May 2015 23:53:35 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2927751551.9.6964; Sat, 02 May 2015 23:53:35 -0400 Message-ID: <55459CCC.3050304@isdg.net> Date: Sat, 02 May 2015 23:58:04 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150502173419.27958.qmail@ary.lan> In-Reply-To: <20150502173419.27958.qmail@ary.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2015 03:58:16 -0000 On 5/2/2015 1:34 PM, John Levine wrote: >> With List-Id becoming a more generic feedback channel, I suspect that its >> value for indicating the participation of a MLM will further degrade. > > This is news to me. Can you explain or give pointers? > > The only application of List-ID with which I am familiar is to sort > (or filter depending on which coast you're from) mailing list traffic > more reliably. You can also filter, separate, categorized, "folderized" or "sort" per se using List-Post. And for modern List-* supportive MUAs, it triggers adding a third possible button for replying: [Reply] Reply-ID, if any, otherwise From: [Reply to All] Reply-Id, From, To, Cc, List-ID [Reply to List] List-ID Just like "Newsgroup:" also triggers a [Reply to Group] button display in NNTP mail readers/writers. Btw, you are the only one that I have seen use the term "sort" for this purpose. I get it, but seems odd. Sort would not be the proper idea unless you were sorting all the incoming mail first in order to find something, and it would be ordered too when using the term sort. The MUAs have called it "Create/Manage Messages Filters" or RBM (Rule Based Messaging) as they were patently called decades ago. They did not do any "sorting" per se, but move the mail as it streamed in into user created folders or in the case of at least one MUA, it auto creates the folders based on either List-ID or List-Post. -- HLS From nobody Mon May 4 07:00:11 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57CA41A00F9 for ; Mon, 4 May 2015 07:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TTVmA-Z5KDH for ; Mon, 4 May 2015 07:00:08 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE95F1A00F7 for ; Mon, 4 May 2015 07:00:08 -0700 (PDT) Received: by pdbqa5 with SMTP id qa5so163756367pdb.1 for ; Mon, 04 May 2015 07:00:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=D6pgNeCEAwVx4llWoSu7A/HiRI1OE2rQ0DZh6oEytcg=; b=CA6rkv6kUGcFDLB+/rs8ythSKl/A1Bh6DpAKinyKMCFXUHa/NDpC+eI8CotSRdBliy 3LcdUQGqLVkL5sEGdCmkJwkfBcdm8ggM+pGnbcFqjy0DItFjSqJIA0u99eY8gCAxCfid TxVtU51K8MSxU8tBpAApBIyiUtEDf/B4txmrxrhEY6hEZLBkItZQs//RIsq8bez5NzMa NudVtHuULa8DmpvQ16359inq54oEMXqIAw8PNOdYChZpu0VA3Ii9KT/1dPi1vFKOuRQ+ jx6wUxBTN0lQuB9EY12CEaq3w0PtsI4NsDLbq7wKn+GiCpcejwkePCvUWQOSajDhcjqv dKkg== X-Received: by 10.70.90.129 with SMTP id bw1mr42609927pdb.85.1430748008441; Mon, 04 May 2015 07:00:08 -0700 (PDT) Received: from [50.95.215.116] ([50.95.215.116]) by mx.google.com with ESMTPSA id vi5sm12919179pbc.89.2015.05.04.07.00.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 May 2015 07:00:06 -0700 (PDT) Message-ID: <55477B65.7020607@gmail.com> Date: Mon, 04 May 2015 07:00:05 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Kurt Andersen , Franck Martin References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "Stephen J. Turnbull" , "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 14:00:10 -0000 On 4/30/2015 10:03 AM, Kurt Andersen wrote: > With List-Id becoming a more generic feedback channel, Kurt, forgive my confusion but I don't understand what it means for List-ID to be a 'feedback channel'. List-ID provides some identification. How does that make it a channel and specifically a feedback channel? Thanks. d/ From nobody Mon May 4 07:03:21 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBE51A015F for ; Mon, 4 May 2015 07:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6m1eo35Mnb8 for ; Mon, 4 May 2015 07:03:19 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E83D1A00FE for ; Mon, 4 May 2015 07:02:59 -0700 (PDT) Received: by pabtp1 with SMTP id tp1so161568516pab.2 for ; Mon, 04 May 2015 07:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=qgK+HFykytS7THZ37pxHc4RsWR9pddtFPbftAJxyGUo=; b=f2j1C1lXBrGuCxMMtYhGPQNHzaCtdj1/nDdVCBBUdgWvJPjY+SVaQCIR/7zLOTh4Hd eUBp0A0yO0Q/K8U/FFGZFl1Nb1ZLvkV+Nxlv2pJ/wEumnDgJSwGndhRbpm23R7PosXOT jkjCeDRRpwUperiXKSn+E6Zj/ZVNp3tcTLH0sQf2bGHcsTzF8zkjiSv5psyIEPp1v382 ihsd5CCKvOM2YEkGl58fshR02Y7ql9335YMCR3eK4jSrDcXZp9Nj2bmOWMfNccJVvOOu 3Hp3fWw0J5R0OOxauiIa93AXPLxoTXdZwLcZ7icYa6LjAvkZJSXM6OfpPzCB80SkpYBo uTQg== X-Received: by 10.70.127.202 with SMTP id ni10mr42831731pdb.10.1430748178807; Mon, 04 May 2015 07:02:58 -0700 (PDT) Received: from [50.95.215.116] ([50.95.215.116]) by mx.google.com with ESMTPSA id fh9sm12991933pdb.17.2015.05.04.07.02.57 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 May 2015 07:02:58 -0700 (PDT) Message-ID: <55477C11.2080103@gmail.com> Date: Mon, 04 May 2015 07:02:57 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Stephen J. Turnbull" , Kurt Andersen References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> <87r3qyor3n.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87r3qyor3n.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" , Franck Martin Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 14:03:20 -0000 On 5/2/2015 9:56 AM, Stephen J. Turnbull wrote: > Guys, if you want to attack a proposal, please make one first. Small process comment: It's always best to offer a solution when one offers a criticism. But it's not required. If something won't work, it won't work. Although desirable, offering a solution that /will/ work isn't a pre-requisite to commenting about a proposal's deficiencies. d/ From nobody Mon May 4 08:35:58 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA051A870D for ; Mon, 4 May 2015 08:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLumZVlJvYkY for ; Mon, 4 May 2015 08:35:53 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 71DB61A1C00 for ; Mon, 4 May 2015 08:35:53 -0700 (PDT) Received: from vindemiatrix.encs.concordia.ca (vin-anne@vindemiatrix.encs.concordia.ca [132.205.47.192]) by oldperseverance.encs.concordia.ca (envelope-from anne@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t44FZpfq003907 for ; Mon, 4 May 2015 11:35:51 -0400 Received: from vindemiatrix.encs.concordia.ca (vin-anne@localhost) by vindemiatrix.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t44FZpuk026476 for ; Mon, 4 May 2015 11:35:51 -0400 X-Authentication-Warning: vindemiatrix.encs.concordia.ca: vin-anne owned process doing -bs To: "dmarc@ietf.org" In-reply-to: Your message of Fri, 01 May 2015 10:06:29 PDT References: <554233AE.8090901@gmail.com> <17717.1430495715@vindemiatrix.encs.concordia.ca> <5201C7D4-D4CC-488F-BF5B-62D6CDB82281@peachymango.org> From: Anne Bennett Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Date: Mon, 04 May 2015 11:35:51 -0400 Message-ID: <26475.1430753751@vindemiatrix.encs.concordia.ca> X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-05-04 11:35:51 EDT Archived-At: Subject: Re: [dmarc-ietf] DMARC,SPF, null senders, and indirect mail flow X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 15:35:56 -0000 FM = Franck Martin AB = Anne Bennett MK = Murray S. Kucherawy FM>>>> Note that postfix/sendmail can DKIM sign the bounces it creates. AB>>> A few weeks ago I searched for documentation on how to make AB>>> Sendmail sign its bounces, and I failed to find anything. AB>>> If you could point me at any document at all as a starting AB>>> point for that, I'd be grateful. MK>> DKIM signing in sendmail is done via its milter API, which MK>> is instantiated only when traffic arrives via SMTP. DSNs are MK>> generated and queued internally, not via SMTP. Thus sendmail MK>> does not sign its bounces. That was the conclusion I had come to. MK>> The only way to do that would be MK>> to have the sendmail instance generating the DSN route the MK>> DSN through a second MTA on its way out, and that second one MK>> would do the signing. Oooh, ick, but that would work. I'll keep it in mind. Thank you. FM> http://www.postfix.org/MILTER_README.html [...] FM> To sign Postfix's own bounce messages, enable filtering of FM> internally-generated bounces (line 2 below), and don't reject any FM> internally-generated bounces with non_smtpd_milters Okay, so Postfix can do it more straightforwardly. Good to know, and thank you too. Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne@encs.concordia.ca +1 514 848-2424 x2285 From nobody Mon May 4 15:43:09 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5AD1A89FD for ; Mon, 4 May 2015 15:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B_s9sJGjt5li for ; Mon, 4 May 2015 15:43:01 -0700 (PDT) Received: from groups.winserver.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id ACE401A89FC for ; Mon, 4 May 2015 15:43:01 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1782; t=1430779380; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=FVXHycCyj7EKx9JdmVXnc1xAdRM=; b=J+mNyNU71oITLQKGDIdJ VFznC5u6tIvqRVJ4L49piHqUcRkVxJlq82CQFyTcDFwwCaYxcgSoiuZcLWeus0j8 3dahwi9rkqycWjIfbVpHUiZeLV6GNP7TbfrTy366unxxqlAmWZMEO+pjG8au58tt lxV1CwkEDDkW1GiQMg0XsKw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 04 May 2015 18:43:00 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 194407599.52.6116; Mon, 04 May 2015 18:42:59 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1782; t=1430779114; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=IyIQQH/ G4vLonuuw/U6NqrahcPmzjbw3O86HKNuJx2I=; b=1XCqGtOBzbjqqdRMLc2Q8CL tNFYWTkAJ0vk9X18uKMFeJWeYejER/pLw7c7Sdx96aMfn5RBwEWKwiQRzqk4Mn63 ajFRpr/lgz9imn/I0fxgTEEUGyrOiLsLNOi8Z+KAgCSoxI5Q4bNRIWmor+A0HDnT 0NvaJnkMPgZnniXDkM3w= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 04 May 2015 18:38:34 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3081649316.9.3624; Mon, 04 May 2015 18:38:32 -0400 Message-ID: <5547F5F2.1040309@isdg.net> Date: Mon, 04 May 2015 18:42:58 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> <87r3qyor3n.fsf@uwakimon.sk.tsukuba.ac.jp> <55477C11.2080103@gmail.com> In-Reply-To: <55477C11.2080103@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 22:43:08 -0000 +1 I agree alternatives should not, nor has it even been required, to offer "criticism" in reviews. However, in this case, for what its worth, I didn't see/read Kurt's comment as criticism so I don't think the outburst was warranted. Kurt might explain what he meant but I believe the 5322.List-ID header appears to have less added value and significance for DKIM purposes. It is very useful for the MUAs for categorizing mail. In fact, if we were to use a "List-ID" to trigger perhaps some "relaxed" DKIM verification method, it can be used as a DKIM policy security hole. I think the List-ID idea for DKIM/Policy is where it can possibly help in an automated registration scheme or even protocol to help initiate the authorization process of MLMs. Its possible, but not everyone will use the List-ID so it can't be completely automated. I think the key essential difference for the the MLM condition is: Author Domain IDentity (ADID) != Signer Domain IDentity (SDID) That should be the trigger that will offer the maximum backend compatibility and plug and play solution. No other triggers are needed. -- HLS On 5/4/2015 10:02 AM, Dave Crocker wrote: > On 5/2/2015 9:56 AM, Stephen J. Turnbull wrote: >> Guys, if you want to attack a proposal, please make one first. > > > Small process comment: > > It's always best to offer a solution when one offers a criticism. > > But it's not required. > > If something won't work, it won't work. > > Although desirable, offering a solution that /will/ work isn't a > pre-requisite to commenting about a proposal's deficiencies. > > > d/ > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > From nobody Mon May 4 16:20:53 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3271ACD32 for ; Mon, 4 May 2015 16:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NpY9Z_LpTgH for ; Mon, 4 May 2015 16:20:46 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5871ACD2C for ; Mon, 4 May 2015 16:20:46 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 977C3563D23; Mon, 4 May 2015 18:20:45 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 8F792603FE; Mon, 4 May 2015 18:20:45 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsEa73zqJHpR; Mon, 4 May 2015 18:20:44 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 4C55260373; Mon, 4 May 2015 18:20:44 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 4C55260373 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1430781644; bh=bzmDfI3zmwEvzlRC/3txIte8YSI9aHOKqZJScDu5MXQ=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=QLj06f6TScBXGRhoryM6vNtKzmHOSFlJg52HVMZp41PMdukYeaRpG2SNFW/5lN7DZ NoY8C+JhrOxJW72Nukywlq2ldtSEc+kQoYS2VLZPGGOTGuP7NhVDO+cmqKoRUufXSy qUhEayRuZobwmLQj3khGTJhSyZ17kUPzWK1pef3k= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 35C70603FE; Mon, 4 May 2015 18:20:44 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8jJ9ANJ_v0_J; Mon, 4 May 2015 18:20:44 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 18BA660373; Mon, 4 May 2015 18:20:44 -0500 (CDT) Date: Mon, 4 May 2015 18:20:42 -0500 (CDT) From: Franck Martin To: "Stephen J. Turnbull" Message-ID: <1560828201.22399.1430781642344.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> <87r3qyor3n.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF37 (Mac)/8.0.5_GA_5839) Thread-Topic: OpenDKIM ADSP, DMARC and ATPS support Thread-Index: z7qHGsGc6kXnCJth+d9NvutPyDnshA== Archived-At: Cc: "Murray S. Kucherawy" , dmarc@ietf.org, Kurt Andersen Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 23:20:49 -0000 ----- Original Message ----- > From: "Stephen J. Turnbull" > To: "Kurt Andersen" > Cc: dmarc@ietf.org, "Murray S. Kucherawy" , "Franck Martin" > Sent: Saturday, May 2, 2015 9:56:44 AM > Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support > > Kurt Andersen writes: > > > On Thu, Apr 30, 2015 at 9:27 AM, Franck Martin > > wrote: > > > > my corporate email address, but I wanted to mention the presence of such > > > headers is not foolproof. > > > With List-Id becoming a more generic feedback channel, I suspect > > that its value for indicating the participation of a MLM will > > further degrade. > > Guys, if you want to attack a proposal, please make one first. I did > not propose this. My whole point was that it's easy to imagine ways > that the registration problem could be handled by "p=reject" domains > *if* they want to handle it, and therefore we *don't* need to make any > such proposal ourselves. No more, and no less -- I wouldn't waste the > list's time on such a proposal if I were you. But YMMV, be my guest. I did not want to burn your proposal, sorry if it passed like this. I just wanted to make a comment, from personal observations, that non-mailing list related emails have list-id too. From nobody Tue May 5 09:32:21 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E861A1ACA for ; Tue, 5 May 2015 09:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.498 X-Spam-Level: ** X-Spam-Status: No, score=2.498 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuvhkaPfYE05 for ; Tue, 5 May 2015 09:32:17 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 990251A1A11 for ; Tue, 5 May 2015 09:16:18 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id CEB8B1C3866; Wed, 6 May 2015 01:16:16 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id A9D1A11F6A1; Wed, 6 May 2015 01:16:16 +0900 (JST) From: "Stephen J. Turnbull" To: Franck Martin In-Reply-To: <1560828201.22399.1430781642344.JavaMail.zimbra@peachymango.org> References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> <87r3qyor3n.fsf@uwakimon.sk.tsukuba.ac.jp> <1560828201.22399.1430781642344.JavaMail.zimbra@peachymango.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 06 May 2015 01:16:16 +0900 Message-ID: <87wq0n3sq7.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: Kurt Andersen , dmarc@ietf.org, "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 16:32:18 -0000 Franck Martin writes: > I did not want to burn your proposal, sorry if it passed like > this. I just wanted to make a comment, from personal observations, > that non-mailing list related emails have list-id too. I made the same observation from a theoretical point of view, so I have no problem with you stating those facts. But the main point that everybody is missing is that we *do not* need to deal with the "registration problem" in this WG because the information to register a substantial fraction of mailing lists is distributed in the related mailflows already, and the mailbox providers know where to find the users for confirmation of their intent. There's no need for new protocols. I would prefer to focus on getting a signature delegation protocol specified and hopefully put into practice, discussing mailing list verification practices when potential users bring them up. From nobody Tue May 5 09:54:04 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A49B1A7025 for ; Tue, 5 May 2015 09:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuEP2pHw-0VQ for ; Tue, 5 May 2015 09:54:00 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B98BE1A8769 for ; Tue, 5 May 2015 09:50:48 -0700 (PDT) Received: from [IPv6:2600:1003:b11f:e59b:74c4:433:bc24:bf22] (unknown [IPv6:2600:1003:b11f:e59b:74c4:433:bc24:bf22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 7D10DC40028; Tue, 5 May 2015 11:50:47 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1430844647; bh=cFoj3tYvojfkD/prxfdm2MdSCLOZvPk5SLOKcvUyPJU=; h=In-Reply-To:References:Subject:From:Date:To:From; b=pUH0sIC3DjV7uKoqMgXdwAkuT3DFVgan7HxLf/wu7AiAKI8tBhOHCyHyF4sDdyOdy EcdUY34Ja3OUw6m3S2j9CPIcZUg9ISlQu5JwIhgGw6gbT9/DYmJWgz6EdTDnXyq+pV kdGjADq8Qtnwh8/eNq+mBKMVseuSOjpttStMyefA= User-Agent: K-9 Mail for Android In-Reply-To: <87wq0n3sq7.fsf@uwakimon.sk.tsukuba.ac.jp> References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> <87r3qyor3n.fsf@uwakimon.sk.tsukuba.ac.jp> <1560828201.22399.1430781642344.JavaMail.zimbra@peachymango.org> <87wq0n3sq7.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Tue, 05 May 2015 12:50:43 -0400 To: dmarc@ietf.org Message-ID: <12DB7EB5-8EDE-4163-B96F-17CCCDD7A23D@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 16:54:02 -0000 On May 5, 2015 12:16:16 PM EDT, "Stephen J. Turnbull" wrote: >Franck Martin writes: > > > I did not want to burn your proposal, sorry if it passed like > > this. I just wanted to make a comment, from personal observations, > > that non-mailing list related emails have list-id too. > >I made the same observation from a theoretical point of view, so I >have no problem with you stating those facts. > >But the main point that everybody is missing is that we *do not* need >to deal with the "registration problem" in this WG because the >information to register a substantial fraction of mailing lists is >distributed in the related mailflows already, and the mailbox >providers know where to find the users for confirmation of their >intent. There's no need for new protocols. > >I would prefer to focus on getting a signature delegation protocol >specified and hopefully put into practice, discussing mailing list >verification practices when potential users bring them up. No. I believe that entirely assumes away the hard part of the work. The hard part isn't figuring out candidate data. That can trivially be done as you suggest. The hard part is figuring out the subset of the data that's worthy of special treatment. Approximately as soon as list-id enables DMARC bypass, the bad guys will start adding it to everything. List-id is useless in this context. Scott K From nobody Tue May 5 10:08:50 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D271A1B25 for ; Tue, 5 May 2015 10:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gn6tv23A2qDf for ; Tue, 5 May 2015 10:08:44 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49AC81A039B for ; Tue, 5 May 2015 10:08:42 -0700 (PDT) Received: by wizk4 with SMTP id k4so169970604wiz.1 for ; Tue, 05 May 2015 10:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WR8CrK8EiHWaiLqw6jwUOgQjlNpyTi2yGEXiKZRCRvg=; b=JuyL8gBEutzObqj1nKnUiMxTNhH2buXEUkkEFuUimBkHzSHgUIXLs2rkl/bbcFybAt Kc4PWyNUPglXgRa2G806nLXbjDfuXHu+9CTGJB36MSx8OO444HPUYhOQWIfiDxKySjlu bvHJNa2v+OwBmYN5tY9Brq+cDc5TJfyX3zGkb8yUjZccDYMVNbVTZfeysFWONaxwNVsW A8X8EZj7o6BpOMWuZ+3G/IAN4MvY3tQrh//zFOUomAA3YgMfEab7Rc4zFNajQK5zaIb2 m4rTBOEMijd+gX3xh4kFqxdVLKedGCVScvnlxzwm3wf+pPeZ1UKi1PzqMrPxiQmqg4Di AAHQ== MIME-Version: 1.0 X-Received: by 10.194.61.208 with SMTP id s16mr42869785wjr.135.1430845721046; Tue, 05 May 2015 10:08:41 -0700 (PDT) Received: by 10.27.170.75 with HTTP; Tue, 5 May 2015 10:08:40 -0700 (PDT) In-Reply-To: <12DB7EB5-8EDE-4163-B96F-17CCCDD7A23D@kitterman.com> References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> <87r3qyor3n.fsf@uwakimon.sk.tsukuba.ac.jp> <1560828201.22399.1430781642344.JavaMail.zimbra@peachymango.org> <87wq0n3sq7.fsf@uwakimon.sk.tsukuba.ac.jp> <12DB7EB5-8EDE-4163-B96F-17CCCDD7A23D@kitterman.com> Date: Tue, 5 May 2015 10:08:40 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=047d7b86d3e6ee76e8051558bae7 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 17:08:46 -0000 --047d7b86d3e6ee76e8051558bae7 Content-Type: text/plain; charset=UTF-8 On Tue, May 5, 2015 at 9:50 AM, Scott Kitterman wrote: > >But the main point that everybody is missing is that we *do not* need > >to deal with the "registration problem" in this WG because the > >information to register a substantial fraction of mailing lists is > >distributed in the related mailflows already, and the mailbox > >providers know where to find the users for confirmation of their > >intent. There's no need for new protocols. > Doesn't this presuppose that only good actors use that information channel properly? > >I would prefer to focus on getting a signature delegation protocol > >specified and hopefully put into practice, discussing mailing list > >verification practices when potential users bring them up. > > No. I believe that entirely assumes away the hard part of the work. The > hard part isn't figuring out candidate data. That can trivially be done as > you suggest. The hard part is figuring out the subset of the data that's > worthy of special treatment. > > Approximately as soon as list-id enables DMARC bypass, the bad guys will > start adding it to everything. List-id is useless in this context. > I think that's right. I'm guessing that the Gmails of the world have heuristics that go beyond List-Id for identifying what incoming flows are legitimate lists and which are not. On the other hand, for small operators, maybe List-Id is enough of a good starting point to suggest it, without baking it into a protocol document as something normative. -MSK --047d7b86d3e6ee76e8051558bae7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 5, 2015 at 9:50 AM, Scott Kitterman <skli= st@kitterman.com> wrote:
<= div class=3D"h5">>But the main point that everybody is missing is that w= e *do not* need
>to deal with the "registration problem" in this WG because th= e
>information to register a substantial fraction of mailing lists is
>distributed in the related mailflows already, and the mailbox
>providers know where to find the users for confirmation of their
>intent.=C2=A0 There's no need for new protocols.

Doesn't this presuppose that only good ac= tors use that information channel properly?
=C2=A0
>I would prefer to focus on getting a signature delegation protocol
>specified and hopefully put into practice, discussing mailing list
>verification practices when potential users bring them up.

No.=C2=A0 I believe that entirely assumes away the hard part of= the work. The hard part isn't figuring out candidate data. That can tr= ivially be done as you suggest.=C2=A0 The hard part is figuring out the sub= set of the data that's worthy of special treatment.

Approximately as soon as list-id enables DMARC bypass, the bad guys will st= art adding it to everything. List-id is useless in this context.

I think that's right.=C2=A0 I'm guessing = that the Gmails of the world have heuristics that go beyond List-Id for ide= ntifying what incoming flows are legitimate lists and which are not.
On the other hand, for small operators, maybe List-Id is enough= of a good starting point to suggest it, without baking it into a protocol = document as something normative.

-MSK
=C2= =A0
--047d7b86d3e6ee76e8051558bae7-- From nobody Tue May 5 10:17:03 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25DA81A024E for ; Tue, 5 May 2015 10:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4EKC69aRCDP for ; Tue, 5 May 2015 10:17:00 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0A311A8828 for ; Tue, 5 May 2015 10:16:59 -0700 (PDT) Received: by pabtp1 with SMTP id tp1so200084633pab.2 for ; Tue, 05 May 2015 10:16:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=tyYFyDGM5+MtMqLkw07d1NqtdhfaHafyayXAa0S2LrM=; b=scgC/y+E9t2q0TCofs48J1ccLKqXXwZova90kv6auaCyv/n5yxSXBluJRzO09zjTU0 PSen0jY/DArMRJFahfNML12Y6U7SVJz9S2VzIuohgNLwSlnoUli1VRdRju/KUEUkTGNf g0ZLr1HIH5Jul0msFlsdDOurmCq9KFqKY1Q7C3/6+VfK/zPpBW+X/OqiVn+FgPasvGuv sTTkQFDWAGHJVLhD+76wJ+PmUj5zajYCa/RqbKoERAmX0HPJXlEY18u/A4Y8icpwq+SL zmHjSOIoQbXos/rnSQwbw4gBmwBmibvLvw5j2GVdE/J6hiO11RI5CkMOfmIBbVu1TlV6 nHQQ== X-Received: by 10.67.3.3 with SMTP id bs3mr42913139pad.51.1430846218662; Tue, 05 May 2015 10:16:58 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id ho10sm16407178pbc.27.2015.05.05.10.16.55 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 May 2015 10:16:57 -0700 (PDT) Message-ID: <5548FB07.9030008@gmail.com> Date: Tue, 05 May 2015 10:16:55 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> <87r3qyor3n.fsf@uwakimon.sk.tsukuba.ac.jp> <1560828201.22399.1430781642344.JavaMail.zimbra@peachymango.org> In-Reply-To: <1560828201.22399.1430781642344.JavaMail.zimbra@peachymango.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 17:17:02 -0000 On 5/4/15 4:20 PM, Franck Martin wrote: > ----- Original Message ----- >> From: "Stephen J. Turnbull" >> To: "Kurt Andersen" >> Cc: dmarc@ietf.org, "Murray S. Kucherawy" , "Franck Martin" >> Sent: Saturday, May 2, 2015 9:56:44 AM >> Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support >> >> Kurt Andersen writes: >> >> > On Thu, Apr 30, 2015 at 9:27 AM, Franck Martin >> > wrote: >> >> > > my corporate email address, but I wanted to mention the presence of such >> > > headers is not foolproof. >> >> > With List-Id becoming a more generic feedback channel, I suspect >> > that its value for indicating the participation of a MLM will >> > further degrade. >> >> Guys, if you want to attack a proposal, please make one first. I did >> not propose this. My whole point was that it's easy to imagine ways >> that the registration problem could be handled by "p=reject" domains >> *if* they want to handle it, and therefore we *don't* need to make any >> such proposal ourselves. No more, and no less -- I wouldn't waste the >> list's time on such a proposal if I were you. But YMMV, be my guest. > I did not want to burn your proposal, sorry if it passed like this. I just wanted to make a comment, from personal observations, that non-mailing list related emails have list-id too. Dear Kurt and Franck, List-ids on their own offer little value. Accommodations for MLMs can leverage list-ids to confirm a subscription which can be sorted accordingly. Unlike transactional messaging that often does not involve non-vetted messages, public interaction often makes use of friendly displays and simple sorting methodology. It is doubtful there is a safe and responsive method to delegate signing on a public message by public message basis without causing uncontrollable risk. No authentication method prevents abuse, but signature delegation introduces a greater range of deceptions. An ability to require specific list-ids/domain offers a few advantages- 1) origination out of a subscribed and authorized source 2) exceptions that permit invalid author domain signatures but require an ability to be sorted accordingly 3) allows disabling specific problematic lists without impacting others Regards, Douglas Otis From nobody Tue May 5 10:25:54 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB2C1A8839 for ; Tue, 5 May 2015 10:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOcaY-K9ocXF for ; Tue, 5 May 2015 10:25:50 -0700 (PDT) Received: from winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 623681A700B for ; Tue, 5 May 2015 10:25:50 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2014; t=1430846746; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=0yZyVmwxyuDkdsiszhc/8SgwM3c=; b=S5mP1jPMHGqmAY57CWGK gNKMRtLRAFftXrFH0Y+rbVyv2cNwmK3W0H3wv8YGGdgH4yMe7XFceb4utekJc5Rd h/wdu0KaQ69jI8YNlCi5Bh2S5DtfOXyu8q4uyQYse9JCKUWpi0wvekAUrffXxD+K XZZsX7wlnl+JWBeKzwptqpA= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 05 May 2015 13:25:46 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 261773245.1497.1864; Tue, 05 May 2015 13:25:45 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2014; t=1430846477; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=juEypNs B6KZpltq2rUfeCUbnCO6sI/FzL64w+lYpH7o=; b=MqhnfJgYruGyZC6JYXBB01R fCaUXgtRdVvfiFNVTsKB1ecJpR6z6niGtlPUP9CWQmCgBQRKnodfsVsq3vx4U0VA in6gM7OY6bjxIIt/B16wobPT6OVzMsedMJNTuRB/qfrviY+i+QmTlgVrPNPsP6Zn alI/SiuQ9WKlTCPjQ/YE= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 05 May 2015 13:21:17 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3149012363.9.12604; Tue, 05 May 2015 13:21:15 -0400 Message-ID: <5548FD17.7050901@isdg.net> Date: Tue, 05 May 2015 13:25:43 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> <87r3qyor3n.fsf@uwakimon.sk.tsukuba.ac.jp> <1560828201.22399.1430781642344.JavaMail.zimbra@peachymango.org> <87wq0n3sq7.fsf@uwakimon.sk.tsukuba.ac.jp> <12DB7EB5-8EDE-4163-B96F-17CCCDD7A23D@kitterman.com> In-Reply-To: <12DB7EB5-8EDE-4163-B96F-17CCCDD7A23D@kitterman.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 17:25:53 -0000 On 5/5/2015 12:50 PM, Scott Kitterman wrote: > On May 5, 2015 12:16:16 PM EDT, "Stephen J. Turnbull" wrote: >> But the main point that everybody is missing is that we *do not* need >> to deal with the "registration problem" in this WG because the >> information to register a substantial fraction of mailing lists is >> distributed in the related mailflows already, and the mailbox >> providers know where to find the users for confirmation of their >> intent. There's no need for new protocols. >> >> I would prefer to focus on getting a signature delegation protocol >> specified and hopefully put into practice, discussing mailing list >> verification practices when potential users bring them up. > > No. I believe that entirely assumes away the hard part of the work. The hard part isn't figuring out candidate data. That can trivially be done as you suggest. The hard part is figuring out the subset of the data that's worthy of special treatment. > > Approximately as soon as list-id enables DMARC bypass, the bad guys will start adding it to everything. List-id is useless in this context. > > Scott K The main point would be that DSAP protocols can still be completed making the registration part out of scope. It would be part of the publishing and adoption, migration section as a short or long prospect. The same was true with SPF -- you had to wait until domains were published and registered. Btw, What is your SPF payoff? Your average daily SPF rejection? It is up to yahoo and others if they want to put an effort of registering domains in order to white list them. That shouldn't stop an issue for most domains and it should not be a barrier to having a 3rd party authorization protocol. As a receiver, I am willing to do a DNS call to the ADID/SDID pair (when it differs) to see if there is an authorization. I don't really wish to be changing code to read/write double signatures. This will raise the adoption barrier. -- HLS From nobody Tue May 5 10:34:10 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA0E1A88F1 for ; Tue, 5 May 2015 10:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhWaEh5arvvF for ; Tue, 5 May 2015 10:33:58 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087911A88E9 for ; Tue, 5 May 2015 10:33:57 -0700 (PDT) Received: from [IPv6:2600:1003:b11f:e59b:74c4:433:bc24:bf22] (unknown [IPv6:2600:1003:b11f:e59b:74c4:433:bc24:bf22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id D0BF3C40028; Tue, 5 May 2015 12:33:56 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1430847237; bh=FTYJykJqXD+m6++lHp/HxsOqKXOv3QxpQzf5JNJn1k0=; h=In-Reply-To:References:Subject:From:Date:To:From; b=eoslUegm0RKge8w9ed4dRcZoCo6laTYKJxRhX3N+6SwT47UCxcXUsa/19y3jbLHa3 U7HzKuID2jA9hg/1yj6uLm3b1n9mhcknieiOh4YeiOM6ECtkHC1hpyOedJr0TnfyXS 13JTmmxev7iNFNhwa1xZzqZa730ptHMf2e4jjqOU= User-Agent: K-9 Mail for Android In-Reply-To: <5548FD17.7050901@isdg.net> References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> <87r3qyor3n.fsf@uwakimon.sk.tsukuba.ac.jp> <1560828201.22399.1430781642344.JavaMail.zimbra@peachymango.org> <87wq0n3sq7.fsf@uwakimon.sk.tsukuba.ac.jp> <12DB7EB5-8EDE-4163-B96F-17CCCDD7A23D@kitterman.com> <5548FD17.7050901@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Tue, 05 May 2015 13:33:50 -0400 To: dmarc@ietf.org Message-ID: <47FA94B2-67CA-43DD-A2E3-57C6D444183A@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 17:34:00 -0000 On May 5, 2015 1:25:43 PM EDT, Hector Santos wrote: > >On 5/5/2015 12:50 PM, Scott Kitterman wrote: > >> On May 5, 2015 12:16:16 PM EDT, "Stephen J. Turnbull" > wrote: >>> But the main point that everybody is missing is that we *do not* >need >>> to deal with the "registration problem" in this WG because the >>> information to register a substantial fraction of mailing lists is >>> distributed in the related mailflows already, and the mailbox >>> providers know where to find the users for confirmation of their >>> intent. There's no need for new protocols. >>> >>> I would prefer to focus on getting a signature delegation protocol >>> specified and hopefully put into practice, discussing mailing list >>> verification practices when potential users bring them up. >> >> No. I believe that entirely assumes away the hard part of the work. >The hard part isn't figuring out candidate data. That can trivially be >done as you suggest. The hard part is figuring out the subset of the >data that's worthy of special treatment. >> >> Approximately as soon as list-id enables DMARC bypass, the bad guys >will start adding it to everything. List-id is useless in this context. >> >> Scott K > >The main point would be that DSAP protocols can still be completed >making the registration part out of scope. It would be part of the >publishing and adoption, migration section as a short or long prospect. > >The same was true with SPF -- you had to wait until domains were >published and registered. Btw, What is your SPF payoff? Your average >daily SPF rejection? > >It is up to yahoo and others if they want to put an effort of >registering domains in order to white list them. That shouldn't stop >an issue for most domains and it should not be a barrier to having a >3rd party authorization protocol. > >As a receiver, I am willing to do a DNS call to the ADID/SDID pair >(when it differs) to see if there is an authorization. I don't really >wish to be changing code to read/write double signatures. This will >raise the adoption barrier. Wrapping a 'somebody else's problem field' around the registration piece of this doesn't make it any more feasible. Scott K From nobody Tue May 5 10:56:34 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A86971A8F3A for ; Tue, 5 May 2015 10:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7neg8rpYI2EN for ; Tue, 5 May 2015 10:56:31 -0700 (PDT) Received: from winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id ACC071A8F4E for ; Tue, 5 May 2015 10:56:17 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2271; t=1430848571; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=nRlHlesfPYEEB9jmrxZMQlGU20Q=; b=gPGbK5pz/uHmSEwfjT36 1X5LdBRdgo1eAiwH5tUDxax0bnv+w5uIz1Gp0IYr7GFX0+p1DBcnGvWzCjOa8eG4 gD3uOkiXRMKEKAmpI5nQE7hBRuesT+Ru/x8jvrhhO8xSvzr0Ma6Zwj5Ez4Ptg+9x tmaMHTwJqzNAjPkQSux2kEc= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 05 May 2015 13:56:11 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 263598379.1497.4260; Tue, 05 May 2015 13:56:10 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2271; t=1430848304; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=+qre5vS tZvpDiAMM4vWliojnRDX4Ee8ivB6sAtWU6jk=; b=WN6r8vdjpsBjboqlISHlrsq 9mptT+/b4P3GNj0LkNOFjqc8dO6AwumY5Zp86FZsvNUUfvyR8d2dJAmZDAZABUTq 6W7H/dv6WxC6oAt7vi5Wcb0adv7DBVMUl0FfZrp4v5niv6mI5TzAWVOg9xsKTep9 4frBKJRGuzjYQsTXzMEI= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 05 May 2015 13:51:44 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3150839848.9.13464; Tue, 05 May 2015 13:51:43 -0400 Message-ID: <5549043B.90309@isdg.net> Date: Tue, 05 May 2015 13:56:11 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> <87r3qyor3n.fsf@uwakimon.sk.tsukuba.ac.jp> <1560828201.22399.1430781642344.JavaMail.zimbra@peachymango.org> <87wq0n3sq7.fsf@uwakimon.sk.tsukuba.ac.jp> <12DB7EB5-8EDE-4163-B96F-17CCCDD7A23D@kitterman.com> <5548FD17.7050901@isdg.net> <47FA94B2-67CA-43DD-A2E3-57C6D444183A@kitterman.com> In-Reply-To: <47FA94B2-67CA-43DD-A2E3-57C6D444183A@kitterman.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 17:56:32 -0000 On 5/5/2015 1:33 PM, Scott Kitterman wrote: > On May 5, 2015 1:25:43 PM EDT, Hector Santos wrote: >> >> The main point would be that DSAP protocols can still be completed >> making the registration part out of scope. It would be part of the >> publishing and adoption, migration section as a short or long prospect. >> >> The same was true with SPF -- you had to wait until domains were >> published and registered. Btw, What is your SPF payoff? Your average >> daily SPF rejection? >> >> It is up to yahoo and others if they want to put an effort of >> registering domains in order to white list them. That shouldn't stop >> an issue for most domains and it should not be a barrier to having a >> 3rd party authorization protocol. >> >> As a receiver, I am willing to do a DNS call to the ADID/SDID pair >> (when it differs) to see if there is an authorization. I don't really >> wish to be changing code to read/write double signatures. This will >> raise the adoption barrier. > > Wrapping a 'somebody else's problem field' around the registration piece of this doesn't make it any more feasible. > Feasibility? If we are basing progress solely on that, we wouldn't be far along. IETF protocol engineering generally leaves optimization considerations for implementations to work out. The two problems are different. Its the same SPF had and still has. Do you think its fair that the big domains are exerting high SPF processing pressure with multiple DNS calls per transaction only to result in soft or neutral? They are not sure. What if they decided to switch to a hard fail? Will they get it right? My proposal is based on the fact that DMARC overhead is already being done, thus making it feasible to consider a piggy back design that allows for a ATPS lookup. DMARC offers 3rd party extensions for this purpose. It would be optional. Will there ever be high payoff results? Probably not for a long time, but who knows. Maybe there can be an in-band optimizer: 5322.DKIM-ATPS: The ADID creates ATPS records. Please Check the ADID/SDID. and let people decide if that offers some feasibility in minimizing the lookup or if just always does a lookup anyway and crosses its finger. -- HLS From nobody Tue May 5 11:01:34 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40251A9023 for ; Tue, 5 May 2015 11:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HK_tWf2HgDnl for ; Tue, 5 May 2015 11:01:30 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 560AF1A8923 for ; Tue, 5 May 2015 11:01:28 -0700 (PDT) Received: by widdi4 with SMTP id di4so156754968wid.0 for ; Tue, 05 May 2015 11:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ORVZdHUy1ddOO+4X4zzoJH3OHFTr5pLw2jYTcgx0DcU=; b=PmfZ64di7sXzb3cBcErWxy1nKxIu+/G2isRabGurxABqaH9Oz6EdzWo7OgK2fvcXEG fEUpeG+gAFBV3qx0W71lxbeVPtarle1+cgiMkiolyNLI5MxXk2XR5mYVY/c+okmmVOOS D8+dHEeBqOlLHf7CHXnQ5aoqeslm5xAuMrTVUOi+8w8n4M2sJh/jPyQwp+FkUP9B//0g 8DAR14Ta/hhqfckPaSbCSjWmZ8VRCWyx5+UOtMB54TpAHRsMx4KcO4MDEa+EhzlI8h0C T++vnoKnZ+bSIMDpiBPwwqqEdFZJVT79bpzgEFx6u5C5Yxz56j+p7ZyxgHKBv/jOW83E 8F4g== MIME-Version: 1.0 X-Received: by 10.180.99.2 with SMTP id em2mr6409386wib.59.1430848887100; Tue, 05 May 2015 11:01:27 -0700 (PDT) Received: by 10.27.170.75 with HTTP; Tue, 5 May 2015 11:01:26 -0700 (PDT) In-Reply-To: <47FA94B2-67CA-43DD-A2E3-57C6D444183A@kitterman.com> References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> <87r3qyor3n.fsf@uwakimon.sk.tsukuba.ac.jp> <1560828201.22399.1430781642344.JavaMail.zimbra@peachymango.org> <87wq0n3sq7.fsf@uwakimon.sk.tsukuba.ac.jp> <12DB7EB5-8EDE-4163-B96F-17CCCDD7A23D@kitterman.com> <5548FD17.7050901@isdg.net> <47FA94B2-67CA-43DD-A2E3-57C6D444183A@kitterman.com> Date: Tue, 5 May 2015 11:01:26 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d04426c68a49b8c0515597773 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 18:01:31 -0000 --f46d04426c68a49b8c0515597773 Content-Type: text/plain; charset=UTF-8 On Tue, May 5, 2015 at 10:33 AM, Scott Kitterman wrote: > Wrapping a 'somebody else's problem field' around the registration piece > of this doesn't make it any more feasible. > Is it sufficient to say something like this?: "A participating operator needs to solve the registration problem. Different operators will have different capabilities, requirements, and limitations here. A very simple approach would be ; however, this has the following drawbacks: . Non-trivial solutions may or may not appear in later documents." This illustrates the problem and the importance of solving it in some detail which would give someone "skilled in the art" enough context to come up with something in his or her particular environment, while not constraining DMARC to something that is not universally useful. -MSK --f46d04426c68a49b8c0515597773 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 5, 2015 at 10:33 AM, Scott Kitterman <skli= st@kitterman.com> wrote:
Wrapping a 'somebod= y else's problem field' around the registration piece of this doesn= 't make it any more feasible.

Is it= sufficient to say something like this?:

"A particip= ating operator needs to solve the registration problem.=C2=A0 Different ope= rators will have different capabilities, requirements, and limitations here= .=C2=A0 A very simple approach would be <List-Id magic here>; however= , this has the following drawbacks: <List-Id anti-magic here>.=C2=A0 = Non-trivial solutions may or may not appear in later documents."
This illustrates the problem and the importance of solving it = in some detail which would give someone "skilled in the art" enou= gh context to come up with something in his or her particular environment, = while not constraining DMARC to something that is not universally useful.
-MSK
--f46d04426c68a49b8c0515597773-- From nobody Tue May 5 11:24:46 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF541A1B6D for ; Tue, 5 May 2015 11:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lqkaMYKB6v7 for ; Tue, 5 May 2015 11:24:41 -0700 (PDT) Received: from winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCB91A1AC9 for ; Tue, 5 May 2015 11:24:28 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1497; t=1430850261; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=/6YsEk6uhOTTC4OiQjwl390YEVU=; b=TBDwmbbbi+BWnuZJotYw Stq77eHQrgc01q6pkNcHfDoP4VJhrQ3BL68fscNrohx7LXgVWblp9Axr1F+Nuupr E0rS7bNFPKv8wmFkHoyPntp8KHNhwS+TJaUntUNXC5ZQdW62KFQZA0UVaMjTFH1M IhNy3NQ7P7w2+ysGl7umPN8= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 05 May 2015 14:24:21 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 265288462.1497.1512; Tue, 05 May 2015 14:24:20 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1497; t=1430849992; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=tT9qenI HZH0s1yyACIOxrl1AmhRF7CIDZfOqJ8JghHw=; b=RhdIspIfMxyBjLLM+OdvY97 oZxzNM04VBQo9KSMhAhZGHb+VUBKpGQrDRaHyLJuPPOunt+3tkr4/86zh26MaceG xQi70XRxeWAc4AitZlSEMSNnGsq/XV2RHeZ5zQMffGXtLiv6RGeUAPeFs0ibYB3S 5DaAZJVJ60bN++5LEcfg= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 05 May 2015 14:19:51 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3152527707.9.13112; Tue, 05 May 2015 14:19:51 -0400 Message-ID: <55490AD3.6060202@isdg.net> Date: Tue, 05 May 2015 14:24:19 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> <87r3qyor3n.fsf@uwakimon.sk.tsukuba.ac.jp> <1560828201.22399.1430781642344.JavaMail.zimbra@peachymango.org> <87wq0n3sq7.fsf@uwakimon.sk.tsukuba.ac.jp> <12DB7EB5-8EDE-4163-B96F-17CCCDD7A23D@kitterman.com> <5548FD17.7050901@isdg.net> <47FA94B2-67CA-43DD-A2E3-57C6D444183A@kitterman.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 18:24:42 -0000 On 5/5/2015 2:01 PM, Murray S. Kucherawy wrote: > On Tue, May 5, 2015 at 10:33 AM, Scott Kitterman > wrote: > > Wrapping a 'somebody else's problem field' around the registration > piece of this doesn't make it any more feasible. > > > Is it sufficient to say something like this?: > > "A participating operator needs to solve the registration problem. "Participating Publishers ...." What has to be known is that Receivers are willing to participate by doing a policy check with the design presumption there will be records. This is normal migration, adoption considerations. > Different operators will have different capabilities, requirements, > and limitations here. A very simple approach would be here>; however, this has the following drawbacks: here>. Non-trivial solutions may or may not appear in later documents." Of course, it depends on the details of the magic. But yes, its a different problem. > This illustrates the problem and the importance of solving it in some > detail which would give someone "skilled in the art" enough context to > come up with something in his or her particular environment, while not > constraining DMARC to something that is not universally useful. You don't even have to say "universally useful." All that does is keeps possible implementators away. It can be very useful to some and to them, its universal. -- HLS From nobody Tue May 5 11:26:24 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E75F1A9023 for ; Tue, 5 May 2015 11:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6cz5paFtF2g for ; Tue, 5 May 2015 11:26:16 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF5801A1AC9 for ; Tue, 5 May 2015 11:26:13 -0700 (PDT) Received: by pacyx8 with SMTP id yx8so201253626pac.1 for ; Tue, 05 May 2015 11:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=eA0To3S6n8SPkKvZppnrlIWLlGU5ET3wp87gy4tEls4=; b=IXLOK7YZi2hjKzClbJcr7wfD/QVnaFAQOdj5/lBjJlJu9QiZ3kI/FlNboruxdTPhBa aYhfU/UJh+fL0DsyhXmOjgMkaWyU9KVwS42D+5aPWjYjMX4m7s4ec7B4MNqjad/QOUn1 b+jCPT2NtojUVnRZn0ulgLiIqkEQTSCVR5iWKAlGcafECGnqp+Y9ejLH3WoZaD06NJ7u V9X9gtxv/GpYMr2M2dubyPXXcCaiHdXP0k6aFpMru8DAysjlBJAM31KMpqAJ2ZHtEvxa na/9oyBqLADeERjFJUp5rTyd1zKcDlXOqiI1HkonI+wT9i0xQY82GTgfw0Hfk2wZvm+8 O4gg== X-Received: by 10.70.91.37 with SMTP id cb5mr54210925pdb.151.1430850372937; Tue, 05 May 2015 11:26:12 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id qm2sm16635196pdb.57.2015.05.05.11.26.10 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 May 2015 11:26:11 -0700 (PDT) Message-ID: <55490B41.3040408@gmail.com> Date: Tue, 05 May 2015 11:26:09 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> <87r3qyor3n.fsf@uwakimon.sk.tsukuba.ac.jp> <1560828201.22399.1430781642344.JavaMail.zimbra@peachymango.org> <87wq0n3sq7.fsf@uwakimon.sk.tsukuba.ac.jp> <12DB7EB5-8EDE-4163-B96F-17CCCDD7A23D@kitterman.com> <5548FD17.7050901@isdg.net> <47FA94B2-67CA-43DD-A2E3-57C6D444183A@kitterman.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 18:26:23 -0000 On 5/5/15 11:01 AM, Murray S. Kucherawy wrote: > On Tue, May 5, 2015 at 10:33 AM, Scott Kitterman > wrote: > >> Wrapping a 'somebody else's problem field' around the registration piece >> of this doesn't make it any more feasible. >> > Is it sufficient to say something like this?: > > "A participating operator needs to solve the registration problem. > Different operators will have different capabilities, requirements, and > limitations here. A very simple approach would be ; > however, this has the following drawbacks: . > Non-trivial solutions may or may not appear in later documents." > > This illustrates the problem and the importance of solving it in some > detail which would give someone "skilled in the art" enough context to come > up with something in his or her particular environment, while not > constraining DMARC to something that is not universally useful. Dear Murray and Hector, Almost. Consider the DDoS concern issue that made ATPS impractical by requiring special TP DKIM signatures. This problem can be solved with standard DKIM signatures in conjunction with a domain wide semaphore provided by a DMARC assertion ignored by recipients lacking the TP enhancement. Special DKIM signatures are really not necessary and will introduce more DNS overhead than would be caused by a simple hash reference. Faster, smaller message size, and far simpler signing processes become possible. As illustrated in http://tools.ietf.org/html/draft-otis-dmarc-escape-02#section-4 ,-- DMARC could make an assertion of "sam=tpa; and tpa=third-party-authority.example.com;" when the DMARC domain offers the Specific Advisory Methods "sam=" tag indicating the third-party advisory methods supported. The "tpa=" tag can also indicate the domain location where third- party-authorization hashes have been consolidated with an assumed prefix of "_smtp._tpa.". '-- This would allow large ESP a simple means to share the registration profiles that should greatly benefit all of their recipients. Regards, Douglas Otis From nobody Tue May 5 11:56:10 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB02D1B2F87 for ; Tue, 5 May 2015 11:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.263 X-Spam-Level: ** X-Spam-Status: No, score=2.263 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_21=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvLXLsME0Uqp for ; Tue, 5 May 2015 11:56:06 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55C8A1A873E for ; Tue, 5 May 2015 11:56:06 -0700 (PDT) Received: (qmail 62495 invoked from network); 5 May 2015 18:56:07 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 5 May 2015 18:56:07 -0000 Date: 5 May 2015 18:55:43 -0000 Message-ID: <20150505185543.42741.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 18:56:08 -0000 >Is it sufficient to say something like this?: > >"A participating operator needs to solve the registration problem. >Different operators will have different capabilities, requirements, and >limitations here. So far so good. > A very simple approach would be ; Not so good, since there are lists that do't have list-id and spam that does. There's a large class of approaches that either require registration, the various third party signers, or would likely work better with it like my double signing thing. But it's clear to me that if there were an easy way to register lists globally, we would already have done it. Large providers have a pretty good idea of who's sending them list mail, e.g. Google notes in in their DMARC reports, so they can use their own list if they want. Small providers will have to do other stuff, but ad hoc approaches like adding lists when users compiain is probably OK. So I'd just note when something needs or would be aided by registration but not waste time trying to invent a way to do it. R's, John From nobody Tue May 5 12:02:02 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6B41B2B19 for ; Tue, 5 May 2015 12:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44CEh5b398UA for ; Tue, 5 May 2015 12:01:49 -0700 (PDT) Received: from winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 66ECA1B2FBF for ; Tue, 5 May 2015 12:01:49 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1448; t=1430852501; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=lSXnVqqRF058GPHfMKbQarJMMls=; b=BaWCiiWR9Sw8sNV0bRvM uQZhmSIvRS3YMKB86/yO8BK5TG9V7x+iUSBKcUoGoPYoBuL82s3ACHZaeiYlWJbi OQ1fYwqqps4yxqTEDgsuxDQYAoob8ZxI5+/6WxN95hDLKUOG2rRItP+tk5DmN42W S8nw+oV4YSsifZaqjPHV++4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 05 May 2015 15:01:41 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 267528621.1497.5980; Tue, 05 May 2015 15:01:40 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1448; t=1430852232; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=MzUUGwk yoC4xXIZ+LwHQp4tL7EXmdLlkfbBG+by+WpQ=; b=h3EJ7GthldSHUCUVekbng0B EEuXZoZk+hVzDrXQxfHU9EAKF44WdptZr3PtTcNOn4IYxX/eA+crleXtpVUY50zI cE4Az9WjHnEQ00ZjTAtTfFHhG9pQOntfmjBPTdFGEPeB/K4GRbyaXXyI2A4DWsgc 1p6We4QqObFnHyQ5Oq7g= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 05 May 2015 14:57:12 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3154768316.9.13948; Tue, 05 May 2015 14:57:11 -0400 Message-ID: <55491393.7020800@isdg.net> Date: Tue, 05 May 2015 15:01:39 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> <87r3qyor3n.fsf@uwakimon.sk.tsukuba.ac.jp> <1560828201.22399.1430781642344.JavaMail.zimbra@peachymango.org> <87wq0n3sq7.fsf@uwakimon.sk.tsukuba.ac.jp> <12DB7EB5-8EDE-4163-B96F-17CCCDD7A23D@kitterman.com> <5548FD17.7050901@isdg.net> <47FA94B2-67CA-43DD-A2E3-57C6D444183A@kitterman.com> <55490B41.3040408@gmail.com> In-Reply-To: <55490B41.3040408@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 19:01:57 -0000 On 5/5/2015 2:26 PM, Douglas Otis wrote: > > Dear Murray and Hector, > > ,-- > > DMARC could make an > assertion of "sam=tpa; and tpa=third-party-authority.example.com;" > when the DMARC domain offers the Specific Advisory Methods "sam=" > tag indicating the third-party advisory methods supported. The > "tpa=" tag can also indicate the domain location where third- > party-authorization hashes have been consolidated with an assumed > prefix of "_smtp._tpa.". > > '-- First, it needs to protect the 1st party. The "tpa=" tag does offer a method to allow outsourcing. As long as it remains a choice of the first party, under control of the first party, and it defaults to the first party, then it offers something worth while. Corollary: Do not mandate a "Batteries Required" 3rd party trust system. Second, this would be a DMARC extension, so it would piggy back off the DMARC call already being made. At most, there would be two DNS calls. But there is no dependency on DKIM signer/verifier code change. Third, a "sam=" tag can be used to support different methods, including Levine's in-band method. I think we will need the "hash=" tag to define how a lookup hash is done, if any, default none. But in my ATPS experience, this was the hardest part. Keep it simple. I can support a simple spec that is basically a lookup as you described above, with a first party priority. -- HLS From nobody Tue May 5 12:09:51 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19DD11A87A2 for ; Tue, 5 May 2015 12:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90O6XKhNErSk for ; Tue, 5 May 2015 12:09:49 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2E721A874D for ; Tue, 5 May 2015 12:09:48 -0700 (PDT) Received: by wizk4 with SMTP id k4so174193459wiz.1 for ; Tue, 05 May 2015 12:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BXxUHMkkelP/M+r7ZP/T/BYrmGloRWr97f4jvT+4eho=; b=0ZFeCOaclE7bZI0i4b6Mdm3lOZxiPus6ip2Rj0wbyKM7wb1ycLZPxxB4gcFqjbAu1x LiLA7f+rn/fNCZBRdnhzxxv76DBvfNdKmNPOxyRJw4vJyR2aq1va6S4s8GBPz2xkMbey U/1MCXD9rtRVN4Qgcir1AB68Z5gjcoFrCgn/BdWrylkfM+Q0UXDE91vWU7tD/Ure02SM EhIQyKYNj9xwf8/tzHY/O8H77HzLXzVQWNOqRusrRNL5D/EQSgf6pDpj39JNh1w9opxw Ey+gYpBSl+Ia+cZeGgLy9t1zKfkphEW2nf0egj/DwquEebWa/lTea5fW9rGZ+f7FvkYU SfAQ== MIME-Version: 1.0 X-Received: by 10.194.193.66 with SMTP id hm2mr6280322wjc.111.1430852987454; Tue, 05 May 2015 12:09:47 -0700 (PDT) Received: by 10.27.170.75 with HTTP; Tue, 5 May 2015 12:09:47 -0700 (PDT) In-Reply-To: <20150505185543.42741.qmail@ary.lan> References: <20150505185543.42741.qmail@ary.lan> Date: Tue, 5 May 2015 12:09:47 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=047d7b874e620b0b9705155a6c92 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 19:09:50 -0000 --047d7b874e620b0b9705155a6c92 Content-Type: text/plain; charset=UTF-8 On Tue, May 5, 2015 at 11:55 AM, John Levine wrote: > > Not so good, since there are lists that do't have list-id and spam > that does. > > There's a large class of approaches that either require registration, > the various third party signers, or would likely work better with it > like my double signing thing. But it's clear to me that if there were > an easy way to register lists globally, we would already have done it. > > Large providers have a pretty good idea of who's sending them list > mail, e.g. Google notes in in their DMARC reports, so they can use > their own list if they want. Small providers will have to do other > stuff, but ad hoc approaches like adding lists when users compiain is > probably OK. > > So I'd just note when something needs or would be aided by > registration but not waste time trying to invent a way to do it. > > My taking that run at it showed me that an example is necessary to illustrate the goal and the general idea of the mechanism, and potential problems with trivial solutions. We could try relegating it purely to prose, but even a concocted example would probably be useful. So the stuff you're talking about here would go in what I labeled as , and the whole thing should read as "A naive implementation could do this, but it's easily defeated by X, Y, Z; you have to do something better that matches your requirements" or something like that. -MSK --047d7b874e620b0b9705155a6c92 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 5, 2015 at 11:55 AM, John Levine <johnl@taugh.c= om> wrote:

Not so good, since there are lists that do't have list-id and sp= am
that does.

There's a large class of approaches that either require registration, the various third party signers, or would likely work better with it
like my double signing thing.=C2=A0 But it's clear to me that if there = were
an easy way to register lists globally, we would already have done it.

Large providers have a pretty good idea of who's sending them list
mail, e.g. Google notes in in their DMARC reports, so they can use
their own list if they want.=C2=A0 Small providers will have to do other stuff, but ad hoc approaches like adding lists when users compiain is
probably OK.

So I'd just note when something needs or would be aided by
registration but not waste time trying to invent a way to do it.


My taking that run at it showed me tha= t an example is necessary to illustrate the goal and the general idea of th= e mechanism, and potential problems with trivial solutions.=C2=A0 We could = try relegating it purely to prose, but even a concocted example would proba= bly be useful.

So the stuff you're talking about here= would go in what I labeled as <List-Id anti-magic>, and the whole th= ing should read as "A naive implementation could do this, but it's= easily defeated by X, Y, Z; you have to do something better that matches y= our requirements" or something like that.

-MSK
=C2=A0
--047d7b874e620b0b9705155a6c92-- From nobody Tue May 5 12:28:41 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8D41A873D for ; Tue, 5 May 2015 12:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_64=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vylwwY0oT6PB for ; Tue, 5 May 2015 12:28:34 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (mail-sn2ln0088.outbound.o365filtering.com [IPv6:2a01:111:f400:7c04::88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BCE51A1A45 for ; Tue, 5 May 2015 12:28:34 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB604.namsdf01.sdf.exchangelabs.com (10.255.109.166) with Microsoft SMTP Server (TLS) id 15.1.166.2; Tue, 5 May 2015 19:28:18 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.5.118]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.5.118]) with mapi id 15.01.0166.000; Tue, 5 May 2015 19:28:18 +0000 From: Terry Zink To: John Levine , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support Thread-Index: AQHQhsD8kdcEJDtqk02Sy7xJtSnjGJ1tkB0AgAAJoYCAAAnHgIAAAkQAgAAHtwCAAA8qgIAAA9ew Date: Tue, 5 May 2015 19:28:17 +0000 Message-ID: References: <20150505185543.42741.qmail@ary.lan> In-Reply-To: <20150505185543.42741.qmail@ary.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.36] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB604; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(13464003)(189002)(377454003)(199003)(33656002)(46102003)(68736005)(77156002)(5001960100002)(87936001)(15975445007)(102836002)(86362001)(2501003)(62966003)(54356999)(19580405001)(2656002)(19580395003)(106356001)(101416001)(81156007)(50986999)(106116001)(2900100001)(5001920100001)(64706001)(76176999)(92566002)(5001860100001)(2950100001)(66066001)(105586002)(5001770100001)(4001540100001)(97736004)(5001830100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB604; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005002)(5002009)(3002001); SRVR:BL2SR01MB604; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB604; x-forefront-prvs: 0567A15835 received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: multipart/alternative; boundary="_000_BL2SR01MB6052EFC3EE58A625164083996D10BL2SR01MB605namsdf_" MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2015 19:28:17.0856 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB604 Archived-At: Cc: "superuser@gmail.com" Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 19:28:39 -0000 --_000_BL2SR01MB6052EFC3EE58A625164083996D10BL2SR01MB605namsdf_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable What about some variant of the following using a revised version of John Le= vine's conditional DKIM (@fs=3D) draft? Here's the scenario. Joe User is an avid birdwatcher and joins the Birdwatc= hers in the northeast discussion group, bwne@birdwatchers.org. He sends a message to the group: From: Joe User To: bwne@birdwatchers.org Original-To: bwne@birdwatchers.org Subject: Hi, I'm Joe from the northeast! DKIM-Signature: v=3D1; d=3Dyahoo.com; h=3Dfrom:date:subject:to:mime-version:message-id:content-type:original-to= ; DKIM-Signature: v=3D2; d=3Dyahoo.com; l=3D0; h=3Dfrom:date:to:mime-version:message-id:content-type:original-to; Birdwatchers' mail server receives the message and replays it out the rest = of the world, including Frank whose also into bird watching and his email a= ddress is at Hotmail. After some additional formatting, we have the followi= ng with changes marked up with a * next to them: From: Joe User *** To: frank@hotmail.com Original-To: bwne@birdwatchers.org *** Subject: [BIRDWATCHERS] Hi, I'm Joe from the northeast! DKIM-Signature: v=3D1; d=3Dyahoo.com; h=3Dfrom:date:subject:to:mime-version:message-id:content-type:original-to= ; DKIM-Signature: v=3D2; d=3Dyahoo.com; l=3D0; h=3Dfrom:date:to:mime-version:message-id:content-type:original-to; *** DKIM-Signature: v=3D1; d=3Dbirdwatchers.org; h=3Dfrom:date:to:mime-version:message-id:content-type:original-to; *** List-Id: "Birdwatchers in the Northeast" At Hotmail: - This messages passes SPF (birdwatchers.org) - This message fails the first DKIM-Signature (d=3Dyahoo.com) and passes th= e second (d=3Dyahoo.com) but DKIM-Signature v=3D2 cannot be used for DMARC = verification. It passes the third DKIM-signature (d=3Dbirdwatchers.org). - It passed SPF and DKIM, but since neither of those domains aligns with Ya= hoo.com, it fails DMARC. However, Hotmail does something interesting: - It sees that the message has a List-ID header so before failing DMARC, it= should do a little more work since this may be a forward from a mailing li= st. - It sees that the DKIM-Signature v=3D2 with l=3D0 is too weak for DKIM ali= gnment. But it sees that it contains an Original-To that was signed. - The Original-To domain is birdwatchers.org - The DKIM-signature that passed is d=3Dbirdwatchers.org --> which aligns w= ith the domain in the Original-To --> which aligns with the weak signature = that was signed by d=3Dyahoo.com --> which aligns with the domain in the he= ader.from (yahoo.com) - Hotmail then deduces that the forwarding chain is intact and stamps "dmar= c=3Dpass-via-chain" in the Authentication-Results header and doesn't fail t= he message I haven't thought it through entirely, but: - This would be an add-on to DMARC and an add-on to DKIM, but not a big one= . In fact, the DKIM-Sign v=3D2 could be v=3D1. DMARC would know not to alig= n a weak DKIM signature (l=3D0) with DMARC by itself (indeed, we are basica= lly saying l=3D0 should not be used for normal DKIM trust relationships). S= o it's no add on to DMARC. - Senders have to include an Original-To if they know they are sending to a= mailing list but could optionally send it for every message. They also nee= d to send a second weak signature. - DMARC verifiers need to update their handling. - List forwarders don't need changes unless they don't add the List-ID. If = not, they must if they want to pass DMARC. - A short expiration time could be put onto the weak DKIM-signature to prev= ent replay attacks - No TPA requires publishing in DNS, it's basically done on the fly - I am not sure if this mitigates sufficiently against attacks - I am reasonably sure I am missing a bunch of other things But maybe something like that? -- Terry -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of John Levine Sent: Tuesday, May 5, 2015 11:56 AM To: dmarc@ietf.org Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support >Is it sufficient to say something like this?: > >"A participating operator needs to solve the registration problem. >Different operators will have different capabilities, requirements, and >limitations here. So far so good. > A very simple approach would be ; Not so good, since there are lists that do't have list-id and spam that does. There's a large class of approaches that either require registration, the various third party signers, or would likely work better with it like my double signing thing. But it's clear to me that if there were an easy way to register lists globally, we would already have done it. Large providers have a pretty good idea of who's sending them list mail, e.g. Google notes in in their DMARC reports, so they can use their own list if they want. Small providers will have to do other stuff, but ad hoc approaches like adding lists when users compiain is probably OK. So I'd just note when something needs or would be aided by registration but not waste time trying to invent a way to do it. R's, John _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc --_000_BL2SR01MB6052EFC3EE58A625164083996D10BL2SR01MB605namsdf_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <= a name=3D"_MailEndCompose">
What= about some variant of the following using a revised version of John Levine= 's conditional DKIM (@fs=3D) draft?
&nbs= p;
Here= 's the scenario. Joe User is an avid birdwatcher and joins the Birdwatchers= in the northeast discussion group, bwne@birdwatchers.org. He sends a message to the group:
&nbs= p;
From= : Joe User <joe@yahoo.com>
To: bwne@birdwatchers.org
Original-To: bwne@birdwatchers.org
Subject: Hi, I'm Joe from the northeast!
DKIM= -Signature: v=3D1; d=3Dyahoo.com;
&nbs= p; h=3Dfrom:date:subject:to:mime-version:message-id:content-type:original-t= o;
DKIM= -Signature: v=3D2; d=3Dyahoo.com; l=3D0;
&nbs= p; h=3Dfrom:date:to:mime-version:message-id:content-type:original-to;
 <= /div>
Bird= watchers' mail server receives the message and replays it out the rest of t= he world, including Frank whose also into bird watching and his email addre= ss is at Hotmail. After some additional formatting, we have the following with changes marked up with a * next to t= hem:
&nbs= p;
From= : Joe User <joe@yahoo.com>
*** To: frank@hotmail.com
Original-To: bwne@birdwatchers.org
*** Subject: [BIRDWATCHERS] Hi, I'm Joe from the northeast!
DKIM= -Signature: v=3D1; d=3Dyahoo.com;
&nbs= p; h=3Dfrom:date:subject:to:mime-version:message-id:content-type:original-t= o;
DKIM= -Signature: v=3D2; d=3Dyahoo.com; l=3D0;
&nbs= p; h=3Dfrom:date:to:mime-version:message-id:content-type:original-to;
*** = DKIM-Signature: v=3D1; d=3Dbirdwatchers.org;
&nbs= p; h=3Dfrom:date:to:mime-version:message-id:content-type:original-to;
*** = List-Id: "Birdwatchers in the Northeast" <bwne@birdwatchers.or= g>
 <= /div>
At H= otmail:
 <= /div>
- Th= is messages passes SPF (birdwatchers.org)
- Th= is message fails the first DKIM-Signature (d=3Dyahoo.com) and passes the se= cond (d=3Dyahoo.com) but DKIM-Signature v=3D2 cannot be used for DMARC veri= fication. It passes the third DKIM-signature (d=3Dbirdwatchers.org).
- It= passed SPF and DKIM, but since neither of those domains aligns with Yahoo.= com, it fails DMARC.
&nbs= p;
Howe= ver, Hotmail does something interesting:
 <= /div>
- It= sees that the message has a List-ID header so before failing DMARC, it sho= uld do a little more work since this may be a forward from a mailing list.<= /span>
- It= sees that the DKIM-Signature v=3D2 with l=3D0 is too weak for DKIM alignme= nt. But it sees that it contains an Original-To that was signed.
- Th= e Original-To domain is birdwatchers.org
- Th= e DKIM-signature that passed is d=3Dbirdwatchers.org à which aligns with the domain in the Original-To à which aligns with the weak signature that was signed by d=3Dyahoo.com à= ; which aligns with the domain in the header.from (yahoo.com)=
- Ho= tmail then deduces that the forwarding chain is intact and stamps “dm= arc=3Dpass-via-chain” in the Authentication-Results header and doesn&= #8217;t fail the message
 <= /div>
I ha= ven’t thought it through entirely, but:
&nbs= p;
- Th= is would be an add-on to DMARC and an add-on to DKIM, but not a big one. In= fact, the DKIM-Sign v=3D2 could be v=3D1. DMARC would know not to align a = weak DKIM signature (l=3D0) with DMARC by itself (indeed, we are basically saying l=3D0 should not be used for normal DKIM t= rust relationships). So it’s no add on to DMARC.
- Se= nders have to include an Original-To if they know they are sending to a mai= ling list but could optionally send it for every message. They also need to= send a second weak signature.
- DM= ARC verifiers need to update their handling.
- Li= st forwarders don’t need changes unless they don’t add the List= -ID. If not, they must if they want to pass DMARC.
- A = short expiration time could be put onto the weak DKIM-signature to prevent = replay attacks
- No= TPA requires publishing in DNS, it’s basically done on the fly
- I = am not sure if this mitigates sufficiently against attacks
- I = am reasonably sure I am missing a bunch of other things
&nbs= p;
But = maybe something like that?
 <= /div>
-- T= erry
 <= /div>
----= -Original Message-----
From: dmarc [mailto:dmarc-bounces= @ietf.org] On Behalf Of John Levine
Sent: Tuesday, May 5, 2015 11:56 AM
To: dmarc@ietf.org
Cc: superuser@gmail.com
Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support
 <= /div>
>= Is it sufficient to say something like this?:
>=
>= "A participating operator needs to solve the registration problem.
>= Different operators will have different capabilities, requirements, and
>= limitations here.
&nbs= p;
So f= ar so good.
&nbs= p;
>= A very simple approach would be <List-Id magic here>;<= /div>
&nbs= p;
Not = so good, since there are lists that do't have list-id and spam
that= does.
&nbs= p;
Ther= e's a large class of approaches that either require registration,
the = various third party signers, or would likely work better with it
like= my double signing thing.  But it's clear to me that if there were
an e= asy way to register lists globally, we would already have done it.
&nbs= p;
Larg= e providers have a pretty good idea of who's sending them list
mail= , e.g. Google notes in in their DMARC reports, so they can use
thei= r own list if they want.  Small providers will have to do other=
stuf= f, but ad hoc approaches like adding lists when users compiain is
prob= ably OK.
&nbs= p;
So I= 'd just note when something needs or would be aided by
regi= stration but not waste time trying to invent a way to do it.<= /div>
&nbs= p;
R's,=
John=
&nbs= p;
____= ___________________________________________
dmar= c mailing list
 <= /div> --_000_BL2SR01MB6052EFC3EE58A625164083996D10BL2SR01MB605namsdf_-- From nobody Tue May 5 12:39:09 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037591ACE9C for ; Tue, 5 May 2015 12:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFZL0AwkIGeL for ; Tue, 5 May 2015 12:39:06 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72F961ACE92 for ; Tue, 5 May 2015 12:39:06 -0700 (PDT) Received: by wgso17 with SMTP id o17so195152955wgs.1 for ; Tue, 05 May 2015 12:39:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0LmBQF/DIy45XbniPMNGI203so670J7ajkX9Dae6c8g=; b=OAIhJs3+y937s66LaZpvR0E6JBGs6Fk1WlyncjDQy++A6x6gOP7FLaONHg3ocOxPlB Hx6X+9vrf8yg0ZxsmnN9lbuAoc93VwwzDedyZfqYJyR8Q8RX7aVZEfLcLO1Tjo6njgUa oh/Ng/AFZuROLhY8NyRRzpeDLz0kVqp3TyjV2lrpMYOl00vuSF4k7+isjM2ZC2GKhkvp SnEj5XtyiF8Qj4XOZOUpTgdVKgizf45GXGgadJ9hD5gQ/xrbg9RP6F9lPUPYy2zmBQFr zy+D05U7vSIdfwzlSKXS7V3z09tAo2yYbmv25PGlcC44YOogJypjITcCtfOTfOHBVaTP PHeg== MIME-Version: 1.0 X-Received: by 10.180.78.199 with SMTP id d7mr7065265wix.94.1430854745265; Tue, 05 May 2015 12:39:05 -0700 (PDT) Received: by 10.27.170.75 with HTTP; Tue, 5 May 2015 12:39:05 -0700 (PDT) In-Reply-To: References: <20150505185543.42741.qmail@ary.lan> Date: Tue, 5 May 2015 12:39:05 -0700 Message-ID: From: "Murray S. Kucherawy" To: Terry Zink Content-Type: multipart/alternative; boundary=f46d0435c02ed11c9e05155ad414 Archived-At: Cc: "dmarc@ietf.org" , John Levine Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 19:39:08 -0000 --f46d0435c02ed11c9e05155ad414 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, May 5, 2015 at 12:28 PM, Terry Zink wrote: > From: Joe User > *** To: frank@hotmail.com > Original-To: bwne@birdwatchers.org > *** Subject: [BIRDWATCHERS] Hi, I'm Joe from the northeast![...] > DKIM-Signature: v=3D1; d=3Dyahoo.com; > h=3Dfrom:date:subject:to:mime-version:message-id:content-type:original-= to; > DKIM-Signature: v=3D2; d=3Dyahoo.com; l=3D0; > h=3Dfrom:date:to:mime-version:message-id:content-type:original-to; > *** DKIM-Signature: v=3D1; d=3Dbirdwatchers.org; > h=3Dfrom:date:to:mime-version:message-id:content-type:original-to; > *** List-Id: "Birdwatchers in the Northeast" > > [...] > > - This would be an add-on to DMARC and an add-on to DKIM, but not a big > one. In fact, the DKIM-Sign v=3D2 could be v=3D1. DMARC would know not to= align > a weak DKIM signature (l=3D0) with DMARC by itself (indeed, we are basica= lly > saying l=3D0 should not be used for normal DKIM trust relationships). So = it=E2=80=99s > no add on to DMARC. > You're either saying this change belongs in DKIM (which then ascribes special meaning to this kind of signature combination, or to "v=3D2" signatures, or something), or you're leaving DKIM alone and saying that the analysis logic appears in DMARC. What advantage does this have over John's proposal? It actually looks more complicated to me, because it spans the divide between DKIM and DMARC. John's proposal is completely contained within DKIM. -MSK --f46d0435c02ed11c9e05155ad414 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 5, 2015 at 12:28 PM, Terry Zink <t= zink@exchange.microsoft.com> wrote:
F= rom: Joe User <joe@ya= hoo.com>
*** To: frank@hotmai= l.com
Original-To: bwn= e@birdwatchers.org
*** Subject: [BIRDWATCHERS] Hi, I'm Joe from the northeast!= [...]
= DKIM-Signature: v=3D1; d=3Dyahoo.com;=C2=A0=
=C2=A0 h=3Dfrom:date:subject:to:mime-version:mess= age-id:content-type:original-to;
DKIM-= Signature: v=3D2; d=3Dyahoo.= com; l=3D0;
=C2= =A0 h=3Dfrom:date:to:mime-version:message-id:content-type:original-to;
*** D= KIM-Signature: v=3D1; d=3Dbirdwatchers.org;
=C2= =A0 h=3Dfrom:date:to:mime-version:message-id:content-type:original-to;
*** L= ist-Id: "Birdwatchers in the Northeast" <bwne@birdwatchers.org><= /font>
=C2=A0[...]

- This would be an add-on to D= MARC and an add-on to DKIM, but not a big one. In fact, the DKIM-Sign v=3D2= could be v=3D1. DMARC would know not to align a weak DKIM signature (l=3D0= ) with DMARC by itself (indeed, we are basically saying l=3D0 should not be used for normal DKIM t= rust relationships). So it=E2=80=99s no add on to DMARC.

You're either saying this= change belongs in DKIM (which then ascribes special meaning to this kind o= f signature combination, or to "v=3D2" signatures, or something),= or you're leaving DKIM alone and saying that the analysis logic appear= s in DMARC.

What advantage does this have over John's proposal?=C2=A0 It actually = looks more complicated to me, because it spans the divide between DKIM and = DMARC.=C2=A0 John's proposal is completely contained within DKIM.
-MSK
<= /div>
--f46d0435c02ed11c9e05155ad414-- From nobody Tue May 5 13:17:35 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0201ACEA2 for ; Tue, 5 May 2015 13:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fS3MFov5hUzh for ; Tue, 5 May 2015 13:17:29 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97A7C1ACE89 for ; Tue, 5 May 2015 13:17:29 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB606.namsdf01.sdf.exchangelabs.com (10.255.109.168) with Microsoft SMTP Server (TLS) id 15.1.166.2; Tue, 5 May 2015 20:17:28 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.5.118]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.5.118]) with mapi id 15.01.0166.000; Tue, 5 May 2015 20:17:27 +0000 From: Terry Zink To: "Murray S. Kucherawy" Thread-Topic: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support Thread-Index: AQHQhsD8kdcEJDtqk02Sy7xJtSnjGJ1tkB0AgAAJoYCAAAnHgIAAAkQAgAAHtwCAAA8qgIAAA9ewgAAIR4CAAAk9MA== Date: Tue, 5 May 2015 20:17:27 +0000 Message-ID: References: <20150505185543.42741.qmail@ary.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.36] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB606; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(24454002)(377454003)(199003)(189002)(19580395003)(101416001)(106356001)(2656002)(19580405001)(54356999)(62966003)(2950100001)(5001860100001)(92566002)(5001830100001)(66066001)(97736004)(19300405004)(105586002)(16601075003)(4001540100001)(2900100001)(16236675004)(81156007)(50986999)(106116001)(76176999)(64706001)(19625215002)(68736005)(1411001)(33656002)(46102003)(19617315012)(93886004)(15975445007)(102836002)(561944003)(86362001)(77156002)(87936001)(110136002)(5001960100002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB606; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005002)(5002009)(3002001); SRVR:BL2SR01MB606; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB606; x-forefront-prvs: 0567A15835 received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: multipart/alternative; boundary="_000_BL2SR01MB6056CDDC8800CC703417DF196D10BL2SR01MB605namsdf_" MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2015 20:17:27.5448 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB606 Archived-At: Cc: "dmarc@ietf.org" , John Levine Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 20:17:32 -0000 --_000_BL2SR01MB6056CDDC8800CC703417DF196D10BL2SR01MB605namsdf_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBZb3UncmUgZWl0aGVyIHNheWluZyB0aGlzIGNoYW5nZSBiZWxvbmdzIGluIERLSU0gKHdoaWNo IHRoZW4gYXNjcmliZXMgc3BlY2lhbA0KPiBtZWFuaW5nIHRvIHRoaXMga2luZCBvZiBzaWduYXR1 cmUgY29tYmluYXRpb24sIG9yIHRvICJ2PTIiIHNpZ25hdHVyZXMsIG9yIHNvbWV0aGluZyksDQo+ IG9yIHlvdSdyZSBsZWF2aW5nIERLSU0gYWxvbmUgYW5kIHNheWluZyB0aGF0IHRoZSBhbmFseXNp cyBsb2dpYyBhcHBlYXJzIGluIERNQVJDLg0KSSB3YW50IHRvIHJlc2NpbmQgbXkgREtJTSB2PTIg YW5kIHB1dCB0aGUgYW5hbHlzaXMgbG9naWMgZW50aXJlbHkgaW4gRE1BUkMuDQoNCj4gV2hhdCBh ZHZhbnRhZ2UgZG9lcyB0aGlzIGhhdmUgb3ZlciBKb2huJ3MgcHJvcG9zYWw/ICBJdCBhY3R1YWxs eSBsb29rcyBtb3JlIGMNCj4gY29tcGxpY2F0ZWQgdG8gbWUsIGJlY2F1c2UgaXQgc3BhbnMgdGhl IGRpdmlkZSBiZXR3ZWVuIERLSU0gYW5kIERNQVJDLiAgSm9obidzDQo+IHByb3Bvc2FsIGlzIGNv bXBsZXRlbHkgY29udGFpbmVkIHdpdGhpbiBES0lNLg0KSm9obuKAmXMgcHJvcG9zYWwgY2hhbmdl cyBES0lNIGJ1dCBhbHNvIHJlcXVpcmVzIGFkZGl0aW9uYWwgY2hhbmdlcyBpbiBETUFSQyB0byBy ZXNwZWN0IHRoZSBjaGFuZ2VzIHRoYXQgd2VyZSBtYWRlIHRvIERLSU0gd2hlbiBkb2luZyBhbGln bm1lbnQgKHRoZSBAZnM9ZG9tYWluIGlzIG1vcmUgb3IgbGVzcyB0aGUgc2FtZSBhcyB0aGUgT3Jp Z2luYWwtVG8gYmVsb3cpLiBJZiBJIHJlc2NpbmQgbXkgREtJTSB2PTIgdG8gb25seSB2PTEsIHRo ZW4gaXQgcmVxdWlyZXMgY2hhbmdlcyB0byBETUFSQyBhbmFseXNpcyBsb2dpYyAod2hpY2ggSm9o buKAmXMgd291bGQgaGF2ZSByZXF1aXJlZCBhbnlob3cgdG8gZXh0cmFjdCB0aGUgQGZzIGFuZCBj b21wYXJlIHRvIHRoZSBmcm9tIGFkZHJlc3MpOyBhbmQsIHJlcXVpcmVzIHNvbWUgY29uZmlndXJh dGlvbiBjaGFuZ2VzIHRvIHNlbmRlcnMgaW4gREtJTSBidXQgbm8gY29kZSBjaGFuZ2UgKHVubGVz cyBhZGRpbmcgYSBzZWNvbmQgc2lnbmF0dXJlIHJlcXVpcmVzIGEgY29kZSBjaGFuZ2UpLg0KDQot LSBUZXJyeQ0KDQpGcm9tOiBNdXJyYXkgUy4gS3VjaGVyYXd5IFttYWlsdG86c3VwZXJ1c2VyQGdt YWlsLmNvbV0NClNlbnQ6IFR1ZXNkYXksIE1heSA1LCAyMDE1IDEyOjM5IFBNDQpUbzogVGVycnkg Wmluaw0KQ2M6IEpvaG4gTGV2aW5lOyBkbWFyY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtkbWFy Yy1pZXRmXSBPcGVuREtJTSBBRFNQLCBETUFSQyBhbmQgQVRQUyBzdXBwb3J0DQoNCk9uIFR1ZSwg TWF5IDUsIDIwMTUgYXQgMTI6MjggUE0sIFRlcnJ5IFppbmsgPHR6aW5rQGV4Y2hhbmdlLm1pY3Jv c29mdC5jb208bWFpbHRvOnR6aW5rQGV4Y2hhbmdlLm1pY3Jvc29mdC5jb20+PiB3cm90ZToNCkZy b206IEpvZSBVc2VyIDxqb2VAeWFob28uY29tPG1haWx0bzpqb2VAeWFob28uY29tPj4NCioqKiBU bzogZnJhbmtAaG90bWFpbC5jb208bWFpbHRvOmZyYW5rQGhvdG1haWwuY29tPg0KT3JpZ2luYWwt VG86IGJ3bmVAYmlyZHdhdGNoZXJzLm9yZzxtYWlsdG86YnduZUBiaXJkd2F0Y2hlcnMub3JnPg0K KioqIFN1YmplY3Q6IFtCSVJEV0FUQ0hFUlNdIEhpLCBJJ20gSm9lIGZyb20gdGhlIG5vcnRoZWFz dCFbLi4uXQ0KREtJTS1TaWduYXR1cmU6IHY9MTsgZD15YWhvby5jb208aHR0cDovL3lhaG9vLmNv bT47DQogIGg9ZnJvbTpkYXRlOnN1YmplY3Q6dG86bWltZS12ZXJzaW9uOm1lc3NhZ2UtaWQ6Y29u dGVudC10eXBlOm9yaWdpbmFsLXRvOw0KREtJTS1TaWduYXR1cmU6IHY9MjsgZD15YWhvby5jb208 aHR0cDovL3lhaG9vLmNvbT47IGw9MDsNCiAgaD1mcm9tOmRhdGU6dG86bWltZS12ZXJzaW9uOm1l c3NhZ2UtaWQ6Y29udGVudC10eXBlOm9yaWdpbmFsLXRvOw0KKioqIERLSU0tU2lnbmF0dXJlOiB2 PTE7IGQ9YmlyZHdhdGNoZXJzLm9yZzxodHRwOi8vYmlyZHdhdGNoZXJzLm9yZz47DQogIGg9ZnJv bTpkYXRlOnRvOm1pbWUtdmVyc2lvbjptZXNzYWdlLWlkOmNvbnRlbnQtdHlwZTpvcmlnaW5hbC10 bzsNCioqKiBMaXN0LUlkOiAiQmlyZHdhdGNoZXJzIGluIHRoZSBOb3J0aGVhc3QiIDxid25lQGJp cmR3YXRjaGVycy5vcmc8bWFpbHRvOmJ3bmVAYmlyZHdhdGNoZXJzLm9yZz4+DQoNClsuLi5dDQoN Ci0gVGhpcyB3b3VsZCBiZSBhbiBhZGQtb24gdG8gRE1BUkMgYW5kIGFuIGFkZC1vbiB0byBES0lN LCBidXQgbm90IGEgYmlnIG9uZS4gSW4gZmFjdCwgdGhlIERLSU0tU2lnbiB2PTIgY291bGQgYmUg dj0xLiBETUFSQyB3b3VsZCBrbm93IG5vdCB0byBhbGlnbiBhIHdlYWsgREtJTSBzaWduYXR1cmUg KGw9MCkgd2l0aCBETUFSQyBieSBpdHNlbGYgKGluZGVlZCwgd2UgYXJlIGJhc2ljYWxseSBzYXlp bmcgbD0wIHNob3VsZCBub3QgYmUgdXNlZCBmb3Igbm9ybWFsIERLSU0gdHJ1c3QgcmVsYXRpb25z aGlwcykuIFNvIGl04oCZcyBubyBhZGQgb24gdG8gRE1BUkMuDQoNCllvdSdyZSBlaXRoZXIgc2F5 aW5nIHRoaXMgY2hhbmdlIGJlbG9uZ3MgaW4gREtJTSAod2hpY2ggdGhlbiBhc2NyaWJlcyBzcGVj aWFsIG1lYW5pbmcgdG8gdGhpcyBraW5kIG9mIHNpZ25hdHVyZSBjb21iaW5hdGlvbiwgb3IgdG8g InY9MiIgc2lnbmF0dXJlcywgb3Igc29tZXRoaW5nKSwgb3IgeW91J3JlIGxlYXZpbmcgREtJTSBh bG9uZSBhbmQgc2F5aW5nIHRoYXQgdGhlIGFuYWx5c2lzIGxvZ2ljIGFwcGVhcnMgaW4gRE1BUkMu DQpXaGF0IGFkdmFudGFnZSBkb2VzIHRoaXMgaGF2ZSBvdmVyIEpvaG4ncyBwcm9wb3NhbD8gIEl0 IGFjdHVhbGx5IGxvb2tzIG1vcmUgY29tcGxpY2F0ZWQgdG8gbWUsIGJlY2F1c2UgaXQgc3BhbnMg dGhlIGRpdmlkZSBiZXR3ZWVuIERLSU0gYW5kIERNQVJDLiAgSm9obidzIHByb3Bvc2FsIGlzIGNv bXBsZXRlbHkgY29udGFpbmVkIHdpdGhpbiBES0lNLg0KLU1TSw0KDQo= --_000_BL2SR01MB6056CDDC8800CC703417DF196D10BL2SR01MB605namsdf_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFw aCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxl LXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFy Z2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZndDsgWW91J3JlIGVpdGhlciBzYXlpbmcgdGhpcyBjaGFuZ2UgYmVsb25ncyBpbiBES0lNICh3 aGljaCB0aGVuIGFzY3JpYmVzIHNwZWNpYWwNCjxicj4NCiZndDsgbWVhbmluZyB0byB0aGlzIGtp bmQgb2Ygc2lnbmF0dXJlIGNvbWJpbmF0aW9uLCBvciB0byAmcXVvdDt2PTImcXVvdDsgc2lnbmF0 dXJlcywgb3Igc29tZXRoaW5nKSwNCjxicj4NCiZndDsgb3IgeW91J3JlIGxlYXZpbmcgREtJTSBh bG9uZSBhbmQgc2F5aW5nIHRoYXQgdGhlIGFuYWx5c2lzIGxvZ2ljIGFwcGVhcnMgaW4gRE1BUkMu PG86cD48L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIHdhbnQg dG8gcmVzY2luZCBteSBES0lNIHY9MiBhbmQgcHV0IHRoZSBhbmFseXNpcyBsb2dpYyBlbnRpcmVs eSBpbiBETUFSQy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PGJyPg0KJmd0OyBXaGF0IGFkdmFudGFnZSBkb2VzIHRoaXMgaGF2ZSBvdmVyIEpvaG4ncyBwcm9w b3NhbD8mbmJzcDsgSXQgYWN0dWFsbHkgbG9va3MgbW9yZSBjPGJyPg0KJmd0OyBjb21wbGljYXRl ZCB0byBtZSwgYmVjYXVzZSBpdCBzcGFucyB0aGUgZGl2aWRlIGJldHdlZW4gREtJTSBhbmQgRE1B UkMuJm5ic3A7IEpvaG4ncyA8YnI+DQomZ3Q7IHByb3Bvc2FsIGlzIGNvbXBsZXRlbHkgY29udGFp bmVkIHdpdGhpbiBES0lNLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Sm9obuKAmXMgcHJv cG9zYWwgY2hhbmdlcyBES0lNIGJ1dCBhbHNvIHJlcXVpcmVzIGFkZGl0aW9uYWwgY2hhbmdlcyBp biBETUFSQyB0byByZXNwZWN0IHRoZSBjaGFuZ2VzIHRoYXQgd2VyZSBtYWRlIHRvIERLSU0gd2hl biBkb2luZyBhbGlnbm1lbnQgKHRoZSBAZnM9ZG9tYWluDQogaXMgbW9yZSBvciBsZXNzIHRoZSBz YW1lIGFzIHRoZSBPcmlnaW5hbC1UbyBiZWxvdykuIElmIEkgcmVzY2luZCBteSBES0lNIHY9MiB0 byBvbmx5IHY9MSwgdGhlbiBpdCByZXF1aXJlcyBjaGFuZ2VzIHRvIERNQVJDIGFuYWx5c2lzIGxv Z2ljICh3aGljaCBKb2hu4oCZcyB3b3VsZCBoYXZlIHJlcXVpcmVkIGFueWhvdyB0byBleHRyYWN0 IHRoZSBAZnMgYW5kIGNvbXBhcmUgdG8gdGhlIGZyb20gYWRkcmVzcyk7IGFuZCwgcmVxdWlyZXMg c29tZSBjb25maWd1cmF0aW9uDQogY2hhbmdlcyB0byBzZW5kZXJzIGluIERLSU0gYnV0IG5vIGNv ZGUgY2hhbmdlICh1bmxlc3MgYWRkaW5nIGEgc2Vjb25kIHNpZ25hdHVyZSByZXF1aXJlcyBhIGNv ZGUgY2hhbmdlKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+LS0gVGVycnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IE11cnJheSBTLiBLdWNoZXJhd3kgW21haWx0bzpzdXBlcnVzZXJAZ21haWwu Y29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE1heSA1LCAyMDE1IDEyOjM5IFBNPGJy Pg0KPGI+VG86PC9iPiBUZXJyeSBaaW5rPGJyPg0KPGI+Q2M6PC9iPiBKb2huIExldmluZTsgZG1h cmNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtkbWFyYy1pZXRmXSBPcGVuREtJ TSBBRFNQLCBETUFSQyBhbmQgQVRQUyBzdXBwb3J0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gVHVlLCBNYXkgNSwgMjAxNSBhdCAxMjoyOCBQTSwgVGVycnkgWmluayAm bHQ7PGEgaHJlZj0ibWFpbHRvOnR6aW5rQGV4Y2hhbmdlLm1pY3Jvc29mdC5jb20iIHRhcmdldD0i X2JsYW5rIj50emlua0BleGNoYW5nZS5taWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOiBKb2UgVXNlciAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmpvZUB5YWhvby5jb20iIHRhcmdldD0iX2JsYW5rIj5qb2VAeWFob28u Y29tPC9hPiZndDs8YnI+DQoqKiogVG86IDxhIGhyZWY9Im1haWx0bzpmcmFua0Bob3RtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmZyYW5rQGhvdG1haWwuY29tPC9hPjxicj4NCk9yaWdpbmFsLVRv OiA8YSBocmVmPSJtYWlsdG86YnduZUBiaXJkd2F0Y2hlcnMub3JnIiB0YXJnZXQ9Il9ibGFuayI+ YnduZUBiaXJkd2F0Y2hlcnMub3JnPC9hPjxicj4NCioqKiBTdWJqZWN0OiBbQklSRFdBVENIRVJT XSBIaSwgSSdtIEpvZSBmcm9tIHRoZSBub3J0aGVhc3QhPC9zcGFuPjxhIG5hbWU9IjE0ZDI1OGNl OTdkN2Y3MDhfX01haWxFbmRDb21wb3NlIj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPlsuLi5dPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+REtJTS1T aWduYXR1cmU6IHY9MTsgZD08YSBocmVmPSJodHRwOi8veWFob28uY29tIiB0YXJnZXQ9Il9ibGFu ayI+eWFob28uY29tPC9hPjs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyBoPWZyb206ZGF0ZTpzdWJqZWN0OnRv Om1pbWUtdmVyc2lvbjptZXNzYWdlLWlkOmNvbnRlbnQtdHlwZTpvcmlnaW5hbC10bzs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRLSU0tU2lnbmF0dXJlOiB2PTI7IGQ9PGEgaHJlZj0i aHR0cDovL3lhaG9vLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnlhaG9vLmNvbTwvYT47IGw9MDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOyBoPWZyb206ZGF0ZTp0bzptaW1lLXZl cnNpb246bWVzc2FnZS1pZDpjb250ZW50LXR5cGU6b3JpZ2luYWwtdG87PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4qKiogREtJTS1TaWduYXR1cmU6IHY9MTsgZD08YSBocmVmPSJodHRw Oi8vYmlyZHdhdGNoZXJzLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmJpcmR3YXRjaGVycy5vcmc8L2E+ Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7IGg9ZnJvbTpkYXRlOnRvOm1p bWUtdmVyc2lvbjptZXNzYWdlLWlkOmNvbnRlbnQtdHlwZTpvcmlnaW5hbC10bzs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPioqKiBMaXN0LUlkOiAmcXVvdDtCaXJkd2F0Y2hlcnMgaW4g dGhlIE5vcnRoZWFzdCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJ3bmVAYmlyZHdhdGNoZXJz Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmJ3bmVAYmlyZHdhdGNoZXJzLm9yZzwvYT4mZ3Q7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPlsuLi5dPGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ LSBUaGlzIHdvdWxkIGJlIGFuIGFkZC1vbiB0byBETUFSQyBhbmQgYW4gYWRkLW9uIHRvIERLSU0s IGJ1dCBub3QgYSBiaWcgb25lLiBJbiBmYWN0LCB0aGUgREtJTS1TaWduIHY9MiBjb3VsZCBiZSB2 PTEuIERNQVJDIHdvdWxkIGtub3cgbm90IHRvIGFsaWduIGEgd2VhayBES0lNIHNpZ25hdHVyZSAo bD0wKSB3aXRoIERNQVJDDQogYnkgaXRzZWxmIChpbmRlZWQsIHdlIGFyZSBiYXNpY2FsbHkgc2F5 aW5nIGw9MCBzaG91bGQgbm90IGJlIHVzZWQgZm9yIG5vcm1hbCBES0lNIHRydXN0IHJlbGF0aW9u c2hpcHMpLiBTbyBpdOKAmXMgbm8gYWRkIG9uIHRvIERNQVJDLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5Zb3Un cmUgZWl0aGVyIHNheWluZyB0aGlzIGNoYW5nZSBiZWxvbmdzIGluIERLSU0gKHdoaWNoIHRoZW4g YXNjcmliZXMgc3BlY2lhbCBtZWFuaW5nIHRvIHRoaXMga2luZCBvZiBzaWduYXR1cmUgY29tYmlu YXRpb24sIG9yIHRvICZxdW90O3Y9MiZxdW90OyBzaWduYXR1cmVzLCBvciBzb21ldGhpbmcpLCBv ciB5b3UncmUgbGVhdmluZw0KIERLSU0gYWxvbmUgYW5kIHNheWluZyB0aGF0IHRoZSBhbmFseXNp cyBsb2dpYyBhcHBlYXJzIGluIERNQVJDLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPldoYXQgYWR2YW50YWdlIGRvZXMgdGhpcyBo YXZlIG92ZXIgSm9obidzIHByb3Bvc2FsPyZuYnNwOyBJdCBhY3R1YWxseSBsb29rcyBtb3JlIGNv bXBsaWNhdGVkIHRvIG1lLCBiZWNhdXNlIGl0IHNwYW5zIHRoZSBkaXZpZGUgYmV0d2VlbiBES0lN IGFuZCBETUFSQy4mbmJzcDsgSm9obidzIHByb3Bvc2FsIGlzIGNvbXBsZXRlbHkNCiBjb250YWlu ZWQgd2l0aGluIERLSU0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPi1NU0s8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BL2SR01MB6056CDDC8800CC703417DF196D10BL2SR01MB605namsdf_-- From nobody Tue May 5 13:24:26 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391A81AD0C9 for ; Tue, 5 May 2015 13:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCTSOvf-6Lvc for ; Tue, 5 May 2015 13:24:22 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB35D1AD0C8 for ; Tue, 5 May 2015 13:24:21 -0700 (PDT) Received: (qmail 75675 invoked from network); 5 May 2015 20:24:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1279a.554926f7.k1505; bh=jT84W1cIMMvDvQVn6ddOm8aSCnvenrKAD4D3UJVP4P0=; b=X+ouBp4H1ZqKV773E79prADqw5B8LWzKs8PkHzopNlwT+L2k9EJLvs+WZvgvPL1Dry+kUBHY6kxlgiUONteezJTiZ3274QqX4U2B3VQid87ctFTbdNfl3K8Ht6RoNZfEsbKnRIfOXHD3jg6rSTJ17k5DZPbTlM9joAL1zH/fgATzvsyyRXzJhMkTHKS43/XxmO95g2Z0KQUKfy214uWAgY6+md9wyz+rvvyXrNzL+xwly2VaLZ4UtwOqGken6TiR DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1279a.554926f7.k1505; bh=jT84W1cIMMvDvQVn6ddOm8aSCnvenrKAD4D3UJVP4P0=; b=TQGjlp+Xe1+CtcU3OI99EiytdHnD5VT0qZerAyh/N+yanaFrAKkPAURkIeNJkkknDNgwYL093+68mjb1cvctqiiAzHMZoQOwHcE4FUO3lfDSbDAf3z2vfeEAcVh/luAXP/MzYj2P4Kgse6fyu6SVMGwR2BtPd51pO/u/r2n4l5I3EzqFca5jjf3+YyIzYPN2g1Pe1TSDmDX//knAtG1JYNzWin5Hxlkwmq9hZ6BypM4fD5eihWcKlJkOfIJcQwLd Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 05 May 2015 20:24:23 -0000 Date: 5 May 2015 16:24:19 -0400 Message-ID: From: "John R Levine" To: "Terry Zink" In-Reply-To: References: <20150505185543.42741.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-430018233-1430857460=:11209" Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 20:24:23 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-430018233-1430857460=:11209 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT > John’s proposal changes DKIM but also requires additional changes in > DMARC to respect the changes that were made to DKIM when doing alignment > (the @fs=domain is more or less the same as the Original-To below). ... It's not supposed to. The decision about whether a DKIM signature that depends on a chained signature is valid is supposed to happen entirely within the updated DKIM module. DMARC just uses that result. I assume the DKIM module is able to look at all of the DKIM signatures on a message and report back which ones are valid. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. --0-430018233-1430857460=:11209-- From nobody Tue May 5 13:35:23 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68F51ACEB7 for ; Tue, 5 May 2015 13:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtRwJ_hKWWll for ; Tue, 5 May 2015 13:35:19 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7314D1ACE98 for ; Tue, 5 May 2015 13:35:19 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB604.namsdf01.sdf.exchangelabs.com (10.255.109.166) with Microsoft SMTP Server (TLS) id 15.1.166.2; Tue, 5 May 2015 20:35:17 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.5.118]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.5.118]) with mapi id 15.01.0166.000; Tue, 5 May 2015 20:35:17 +0000 From: Terry Zink To: John R Levine Thread-Topic: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support Thread-Index: AQHQhsD8kdcEJDtqk02Sy7xJtSnjGJ1tkB0AgAAJoYCAAAnHgIAAAkQAgAAHtwCAAA8qgIAAA9ewgAAIR4CAAAk9MIAAA2aAgAAC2lA= Date: Tue, 5 May 2015 20:35:16 +0000 Message-ID: References: <20150505185543.42741.qmail@ary.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.36] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB604; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(13464003)(189002)(377454003)(199003)(33656002)(93886004)(46102003)(68736005)(77156002)(5001960100002)(110136002)(87936001)(102836002)(561944003)(86362001)(62966003)(54356999)(19580405001)(2656002)(19580395003)(106356001)(101416001)(81156007)(50986999)(106116001)(5001920100001)(2900100001)(64706001)(76176999)(92566002)(5001860100001)(2950100001)(97736004)(105586002)(4001540100001)(5001830100001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB604; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005002)(5002009)(3002001); SRVR:BL2SR01MB604; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB604; x-forefront-prvs: 0567A15835 received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2015 20:35:16.8624 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB604 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 20:35:22 -0000 SG1tLCBva2F5LiBJIG5lZWQgdG8gdGhpbmsgdGhyb3VnaCB3aGF0IEkgd3JvdGUgYSBsaXR0bGUg bW9yZSwgdGhlbi4gSSB0aGluayBJIG1pc3VuZGVyc3Rvb2Qgc29tZXdoYXQgeW91ciBwcm9wb3Nh bC4NCg0KLS0gVGVycnkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGRtYXJj IFttYWlsdG86ZG1hcmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvaG4gUiBMZXZp bmUNClNlbnQ6IFR1ZXNkYXksIE1heSA1LCAyMDE1IDE6MjQgUE0NClRvOiBUZXJyeSBaaW5rDQpD YzogZG1hcmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbZG1hcmMtaWV0Zl0gT3BlbkRLSU0gQURT UCwgRE1BUkMgYW5kIEFUUFMgc3VwcG9ydA0KDQo+IEpvaG7igJlzIHByb3Bvc2FsIGNoYW5nZXMg REtJTSBidXQgYWxzbyByZXF1aXJlcyBhZGRpdGlvbmFsIGNoYW5nZXMgaW4gDQo+IERNQVJDIHRv IHJlc3BlY3QgdGhlIGNoYW5nZXMgdGhhdCB3ZXJlIG1hZGUgdG8gREtJTSB3aGVuIGRvaW5nIGFs aWdubWVudCANCj4gKHRoZSBAZnM9ZG9tYWluIGlzIG1vcmUgb3IgbGVzcyB0aGUgc2FtZSBhcyB0 aGUgT3JpZ2luYWwtVG8gYmVsb3cpLiAuLi4NCg0KSXQncyBub3Qgc3VwcG9zZWQgdG8uICBUaGUg ZGVjaXNpb24gYWJvdXQgd2hldGhlciBhIERLSU0gc2lnbmF0dXJlIHRoYXQgDQpkZXBlbmRzIG9u IGEgY2hhaW5lZCBzaWduYXR1cmUgaXMgdmFsaWQgaXMgc3VwcG9zZWQgdG8gaGFwcGVuIGVudGly ZWx5IA0Kd2l0aGluIHRoZSB1cGRhdGVkIERLSU0gbW9kdWxlLiAgRE1BUkMganVzdCB1c2VzIHRo YXQgcmVzdWx0LiAgSSBhc3N1bWUgDQp0aGUgREtJTSBtb2R1bGUgaXMgYWJsZSB0byBsb29rIGF0 IGFsbCBvZiB0aGUgREtJTSBzaWduYXR1cmVzIG9uIGEgbWVzc2FnZSANCmFuZCByZXBvcnQgYmFj ayB3aGljaCBvbmVzIGFyZSB2YWxpZC4NCg0KUmVnYXJkcywNCkpvaG4gTGV2aW5lLCBqb2hubEB0 YXVnaC5jb20sIFRhdWdoYW5ub2NrIE5ldHdvcmtzLCBUcnVtYW5zYnVyZyBOWQ0KUGxlYXNlIGNv bnNpZGVyIHRoZSBlbnZpcm9ubWVudCBiZWZvcmUgcmVhZGluZyB0aGlzIGUtbWFpbC4NCg== From nobody Tue May 5 14:27:29 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8CE61A1A36 for ; Tue, 5 May 2015 14:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-IoI8UvkR5J for ; Tue, 5 May 2015 14:27:25 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 472EE1B2A5A for ; Tue, 5 May 2015 14:27:25 -0700 (PDT) Received: by wief7 with SMTP id f7so111265006wie.0 for ; Tue, 05 May 2015 14:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XSmzFE+jI5sjdaWcrNLCVRn8neNPnkplANxxinjMZyM=; b=LrZrb4Ezx3B/CFSKWhBpobBRMquZAO0NZq5JFcKu/9VClvEVVq2pPwja0XMcve1NAO BRp4wyDquUSeo3sV/W6g0m3GPf83ULOxRpk3aMT7Cf5710PExm41myyad7bnsy5mQt02 Gt60leYKyjwwhTOSLZmbfxXVET+BIXRCKkJOAGb0yrddDrA2KkUYQynaiDlVHNPikFte x03aCRVKyygcGBFM8XMbNEAUegOzICaTjuiap9of4Ca2CaZKUuCzucgyv3j2nl6jZ7w8 GUi8soB8xrFTgWSAW/3hvaW7YWer2wcbBjq7IeXO3hzmka670/HZTAMT4cSxex8NwuUR hKTQ== MIME-Version: 1.0 X-Received: by 10.194.242.101 with SMTP id wp5mr11455546wjc.4.1430861244073; Tue, 05 May 2015 14:27:24 -0700 (PDT) Received: by 10.27.170.75 with HTTP; Tue, 5 May 2015 14:27:23 -0700 (PDT) In-Reply-To: References: <20150505185543.42741.qmail@ary.lan> Date: Tue, 5 May 2015 14:27:23 -0700 Message-ID: From: "Murray S. Kucherawy" To: Terry Zink Content-Type: multipart/alternative; boundary=089e01419f522d0e6605155c5882 Archived-At: Cc: "dmarc@ietf.org" , John Levine Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 21:27:27 -0000 --089e01419f522d0e6605155c5882 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, May 5, 2015 at 1:17 PM, Terry Zink wrote: > > > What advantage does this have over John's proposal? It actually looks > more c > > complicated to me, because it spans the divide between DKIM and DMARC. > John's > > proposal is completely contained within DKIM. > > > John=E2=80=99s proposal changes DKIM but also requires additional changes= in DMARC > to respect the changes that were made to DKIM when doing alignment (the > @fs=3Ddomain is more or less the same as the Original-To below). If I res= cind > my DKIM v=3D2 to only v=3D1, then it requires changes to DMARC analysis l= ogic > (which John=E2=80=99s would have required anyhow to extract the @fs and c= ompare to > the from address); and, requires some configuration changes to senders in > DKIM but no code change (unless adding a second signature requires a code > change). > > I interpreted John's proposal to mean a DKIM verifier would not pass a signature with "@fs=3D" unless it was also accompanied by a signature from the "fs" domain. Thus, the modified result logic is completely within the DKIM module, which DMARC then consumes. It's a much cleaner separation of function that way. -MSK --089e01419f522d0e6605155c5882 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 5, 2015 at 1:17 PM, Terry Zink <tz= ink@exchange.microsoft.com> wrote:

> What advantage does this= have over John's proposal?=C2=A0 It actually looks more c
> complicated to me, because it spans the divide between DKIM and DMARC.= =C2=A0 John's
> proposal is completely contained within DKIM.


John=E2=80=99s p= roposal changes DKIM but also requires additional changes in DMARC to respe= ct the changes that were made to DKIM when doing alignment (the @fs=3Ddomai= n is more or less the same as the Original-To below). If I rescind my DKIM v= =3D2 to only v=3D1, then it requires changes to DMARC analysis logic (which= John=E2=80=99s would have required anyhow to extract the @fs and compare t= o the from address); and, requires some configuration changes to senders in DKIM but no code change (unless adding a second sign= ature requires a code change).


I interpreted John's proposal to mean a DK= IM verifier would not pass a signature with "@fs=3D" unless it wa= s also accompanied by a signature from the "fs" domain.=C2=A0 Thu= s, the modified result logic is completely within the DKIM module, which DM= ARC then consumes.=C2=A0 It's a much cleaner separation of function tha= t way.

-MSK
=C2=A0
--089e01419f522d0e6605155c5882-- From nobody Tue May 5 14:28:06 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18191B2A5C for ; Tue, 5 May 2015 14:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQIH4eYFpEsH for ; Tue, 5 May 2015 14:28:03 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E38D61B2A62 for ; Tue, 5 May 2015 14:28:02 -0700 (PDT) Received: by wgiu9 with SMTP id u9so34427355wgi.3 for ; Tue, 05 May 2015 14:28:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=r0Y26+CN4M9TVac/ko0eif9PbkTx0VW7u5LnG2RuvoM=; b=S3FRWbFGl1PDYdi4lZTFzrC/UWQEPYCM9FV1z4LN5t88d8PTVM0dlIGxuwlXJCSpRf 1c/sEjNFnbhQ3Af9HiF3UC//navlrwRtJi4pyAiQcYl732ydPZE6u8TEwUMfrICltXQk QYl26BqYAFfrYWdmXAQ3jtqBZGuSOXhZ7Njld2PNtwQMX2awqQNjo+HvaVJnGcvu0ErD 0cs4r823RLVmcteIUvMtaeULXKUvWCHgn7Gn1V77XYcuXLDn4AnXasUMRhPjTKDvjZH7 xqODHc/ohr3SWdVdN48cqlWRL4ZSQvBD7JKzKIqUbuZBdWP+oEotRJPa8508NywjHFz4 yWzw== MIME-Version: 1.0 X-Received: by 10.180.83.195 with SMTP id s3mr8055763wiy.52.1430861281710; Tue, 05 May 2015 14:28:01 -0700 (PDT) Received: by 10.27.170.75 with HTTP; Tue, 5 May 2015 14:28:01 -0700 (PDT) In-Reply-To: References: <20150505185543.42741.qmail@ary.lan> Date: Tue, 5 May 2015 14:28:01 -0700 Message-ID: From: "Murray S. Kucherawy" To: John R Levine Content-Type: multipart/alternative; boundary=f46d04428d1c6b59d605155c5a35 Archived-At: Cc: "dmarc@ietf.org" , Terry Zink Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 21:28:04 -0000 --f46d04428d1c6b59d605155c5a35 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, May 5, 2015 at 1:24 PM, John R Levine wrote: > John=E2=80=99s proposal changes DKIM but also requires additional changes= in DMARC >> to respect the changes that were made to DKIM when doing alignment (the >> @fs=3Ddomain is more or less the same as the Original-To below). ... >> > > It's not supposed to. The decision about whether a DKIM signature that > depends on a chained signature is valid is supposed to happen entirely > within the updated DKIM module. DMARC just uses that result. I assume t= he > DKIM module is able to look at all of the DKIM signatures on a message an= d > report back which ones are valid. > Other chatter on this list suggests that not all DKIM verifier implementations work that way, unfortunately. -MSK --f46d04428d1c6b59d605155c5a35 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 5, 2015 at 1:24 PM, John R Levine <johnl@taugh.= com> wrote:
John=E2=80=99s proposal changes DKIM but also requires additional changes i= n DMARC to respect the changes that were made to DKIM when doing alignment = (the @fs=3Ddomain is more or less the same as the Original-To below). ...

It's not supposed to.=C2=A0 The decision about whether a DKIM signature= that depends on a chained signature is valid is supposed to happen entirel= y within the updated DKIM module.=C2=A0 DMARC just uses that result.=C2=A0 = I assume the DKIM module is able to look at all of the DKIM signatures on a= message and report back which ones are valid.

Other chatter on this list suggests that not all DKIM verifier impl= ementations work that way, unfortunately.

-MSK
=
--f46d04428d1c6b59d605155c5a35-- From nobody Tue May 5 14:42:54 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6476D1B29E2 for ; Tue, 5 May 2015 14:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgehVSVAgotg for ; Tue, 5 May 2015 14:42:50 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBE041B29D5 for ; Tue, 5 May 2015 14:42:47 -0700 (PDT) Received: (qmail 88069 invoked from network); 5 May 2015 21:42:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=15804.55493959.k1505; bh=Mg/3Q1Wlye5ct9xIxG4Gx2AmrGHzTujzXpWnnHof830=; b=qAPy/fRkjFRUBYhyZUrOH+AalUDR9tsNeKQdYasmHcp1+44H4FXMiEq/SJqA8o07/PmnsddQbrbZdDDPUtsGjk/F8Spn2CJ/yVQcGUygey3rB3UE1B0A+GfbtLt45ngEINQGv8gvXYMkotYimQdhUnJeJEXOaEI4BKmCbuUWHEdqppwWxY9S51VGK/HPGr3gSwHrDOA79ydDXVU9iHC1JGXF2lKZKW6stsGIKE5YpB7YvgTDupXU0J2mIFi0MmFu DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=15804.55493959.k1505; bh=Mg/3Q1Wlye5ct9xIxG4Gx2AmrGHzTujzXpWnnHof830=; b=cPx4LE3OJ6dnv7CpkF+8bMAF5txdHFdmYwL3wvvqr4hULgvMYFsyvDdELYXWE9b3MbrPSLez7aeL5VEuTuIxFgKoeQyWA4I2N6RWF60Mvdzapr2b3oBHZeg045qW1C4jql6syw1EeX4bpS+ry+T6baaFcSGW899uhcs+UGj1ma2WR66LWPRDnAnlL494NNEU56ntEIyv6Rhk2Rru+6EjxYSY1XgQDp+tZkeD7HuWMnOx8xaN7jpJpTcxSp8+yxY6 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 05 May 2015 21:42:49 -0000 Date: 5 May 2015 17:42:46 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20150505185543.42741.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 21:42:51 -0000 > I interpreted John's proposal to mean a DKIM verifier would not pass a > signature with "@fs=" unless it was also accompanied by a signature from > the "fs" domain. Thus, the modified result logic is completely within the > DKIM module, which DMARC then consumes. It's a much cleaner separation of > function that way. Yes, exactly. The idea was also that the new @ (or ! or whatever) modifier allows people to add new mandatory tags in the future that DKIM will understand but upper layer protocols don't have to. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Tue May 5 14:44:42 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9811B29F4 for ; Tue, 5 May 2015 14:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAdHZAKXfmmK for ; Tue, 5 May 2015 14:44:39 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 011F21B29F1 for ; Tue, 5 May 2015 14:44:38 -0700 (PDT) Received: (qmail 88434 invoked from network); 5 May 2015 21:44:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=15971.554939c8.k1505; bh=kGblkFa80GIoaLkH05A+2j9gjB3m/Js7wriD/aYhWk4=; b=ci+isam8nacOAa0TW60diqZU5UnEfhzrDUq/czqhRMkldn+1XUuluVKCrGkLRJcTBd7Ps1e5Gi07R7+OE8tabk8mw4vR3olC7MwJlSjdpRjj4dxpSztPekNg1QLf3jkAx/idGX6K0Fq7Q9Hz2dVC93k9/4QQjjNudHqowmuxIox4TAp40KZmn+vS5EJVARR/NMtxY0DGXCQdGPhFXw0m5yo9XgRn2vk7pGUkUbGfjpq3TNVMkKy6TStZZt2x+rA3 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=15971.554939c8.k1505; bh=kGblkFa80GIoaLkH05A+2j9gjB3m/Js7wriD/aYhWk4=; b=A8MmLwuQZrE5yJpWd4t6RGFLmcsIIYS0OX1wXTSEfPtMbis6XUi8orXIZP4nuUlWm1iZjvmjJ8X3QOt6AfIV1+sabN6Vej4KM1YRvGfvkcFuGRL8z9yuxoZqlQ9/6xj3DZgBfCAzhAIUJ0LKts+eEvxBwdEnkjbPxSaqeLugO1QTp6BLSuGRabFoiVFOM4Exd/nXgv5B8aIXBT2Yr01+2ebkH+Idpv2xwsBcRa327Qal5tyJ2nCDycoHPhwwT0oK Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 05 May 2015 21:44:40 -0000 Date: 5 May 2015 17:44:37 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20150505185543.42741.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dmarc@ietf.org" , John R Levine , Terry Zink Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 21:44:40 -0000 >> It's not supposed to. The decision about whether a DKIM signature that >> depends on a chained signature is valid is supposed to happen entirely >> within the updated DKIM module. DMARC just uses that result. I assume the >> DKIM module is able to look at all of the DKIM signatures on a message and >> report back which ones are valid. > > Other chatter on this list suggests that not all DKIM verifier > implementations work that way, unfortunately. I suppose I should take another look at the modules for which I have source code and see what they do. Given that a DKIM verifier needs to have the entire message in hand to do the verification at all, it seems odd not to find all the signatures and do them all together. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Tue May 5 15:24:55 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE091B2A5E for ; Tue, 5 May 2015 15:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obEvmdGT9uUB for ; Tue, 5 May 2015 15:24:43 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 336051B2A66 for ; Tue, 5 May 2015 15:24:29 -0700 (PDT) Received: by pdbqa5 with SMTP id qa5so210405121pdb.1 for ; Tue, 05 May 2015 15:24:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ls/ayl8iWRGt0WmRE6kOqFgBi8/xbTa0S5iYH6tI3Z0=; b=HdZhviqljcD3a6ln2kbGANoel2VdhTCST5sqNcBMNtg7e8yVD/+jzOhrbbZ4jcScd/ vrz5rFzKZoZutB2cjKyNZBGDG4BHdiyR2t4XyBs/9Oh80fLCt4oW+bgmDrYLWRE04vFy 5qiur7DVBu+KN2iB8adH/t8dEsNSxckGYJLH9K6Phn/Ieh9465o69Dy6KMPrF5+eVV0Z DWHM8e9eT45cM8zI2TLhzpkdxGhfsikfKEsdD6B5x2MH/OtCAK4hER9YjaSrvBXMRyXL 0AsvPm879oWpADpO7hAoZajzFm6J2ta6F92vJKXDj6iI0qjyUj0x3jTp68LE6sYsGFh/ f7lw== X-Received: by 10.70.0.201 with SMTP id 9mr12238391pdg.4.1430864668803; Tue, 05 May 2015 15:24:28 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id xm7sm17053892pac.28.2015.05.05.15.24.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 May 2015 15:24:27 -0700 (PDT) Message-ID: <55494317.5000102@gmail.com> Date: Tue, 05 May 2015 15:24:23 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150505185543.42741.qmail@ary.lan> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 22:24:48 -0000 On 5/5/15 1:24 PM, John R Levine wrote: >> John’s proposal changes DKIM but also requires additional >> changes in DMARC to respect the changes that were made to >> DKIM when doing alignment (the @fs=domain is more or less >> the same as the Original-To below). ... > > It's not supposed to. The decision about whether a DKIM > signature that depends on a chained signature is valid is > supposed to happen entirely within the updated DKIM > module. DMARC just uses that result. I assume the DKIM > module is able to look at all of the DKIM signatures on a > message and report back which ones are valid. Dear John, Your version of DKIM delegation is cleaner but there is something that could be even cleaner. For example, TPA-Label could be made simpler by requiring a DKIMv2 like element to indicate which header fields in a delegated signature added by the third-party signature are not to change. Conversely, TPA-Label could reference a compressed selection of headers that represent a predefined element indicating which header fields are not to change between the first and third-party signatures and eliminate even the need for a DKIMv2 signature. This could offer a similar expiry scheme in the same manner, but I doubt such would be needed. The first party DKIM signature could even include a hash representing the content of the requisite headers, if that seems important. No special DKIM signature. No complex TPA registration which upset Hector among others. This would have less overhead without any mandated sequence or special DKIM signatures. DMARC domain would need to track which third-party services are being used. They could simply amend the list as needed and delay sending to any new domains until registered. This effort could be delegated to a different entity able to process outgoing logs and DMARC feedback. Once in place, DMARC induced disruption should evaporate while allowing safe use of Sender header fields to retain SMTP compatibility. We have seen too many botnets using various polymorphic schemes able to leverage any window of time to amplify any malicious message that might be allowed within any expiry. Expiry does not seem to offer much protection. Regards, Douglas Otis From nobody Tue May 5 16:55:58 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E771A89B5 for ; Tue, 5 May 2015 16:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7TUU9VfeZb6 for ; Tue, 5 May 2015 16:55:55 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAD1A1A89B0 for ; Tue, 5 May 2015 16:55:54 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id C57A6C40028 for ; Tue, 5 May 2015 18:55:52 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1430870153; bh=RUOg1hcs6bxn/v3hCkySR1bfSrDbdwc2v9/UMs3kzK0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=xKNlz3rHHsDsR/SF1pH2Jc9FF0yUhX9hLeI8kkNyEs23igvnjIZnPLdOY4QJ4ESQh zOqZS4KJEGJ7Npr7H7JUzuOlQGBQlAsnFtuJAoIQLKByy0KCaOGy13KgW7SkPmnQOU oMtwexQklOLAQv5igICPBYp7liGatd2542tvtvVc= From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 05 May 2015 19:55:52 -0400 Message-ID: <1723345.j8sNWI9Enb@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-51-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <55490AD3.6060202@isdg.net> References: <554111FB.5040801@isdg.net> <55490AD3.6060202@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 23:55:57 -0000 On Tuesday, May 05, 2015 02:24:19 PM Hector Santos wrote: > On 5/5/2015 2:01 PM, Murray S. Kucherawy wrote: > > On Tue, May 5, 2015 at 10:33 AM, Scott Kitterman > > > > wrote: > > Wrapping a 'somebody else's problem field' around the registration > > piece of this doesn't make it any more feasible. > > > > Is it sufficient to say something like this?: > > > > "A participating operator needs to solve the registration problem. > > "Participating Publishers ...." What has to be known is that > Receivers are willing to participate by doing a policy check with the > design presumption there will be records. > > This is normal migration, adoption considerations. > > > Different operators will have different capabilities, requirements, > > and limitations here. A very simple approach would be > here>; however, this has the following drawbacks: > here>. Non-trivial solutions may or may not appear in later documents." > > Of course, it depends on the details of the magic. But yes, its a > different problem. > > > This illustrates the problem and the importance of solving it in some > > detail which would give someone "skilled in the art" enough context to > > come up with something in his or her particular environment, while not > > constraining DMARC to something that is not universally useful. > > You don't even have to say "universally useful." All that does is > keeps possible implementators away. It can be very useful to some > and to them, its universal. It depends on the type of mechanism we're discussing registration for. If it's something receivers can do on their own with no cooperation from originators or mediators, then I agree. A scheme that doesn't require cooperation with other actors in the architecture can be 'good enough' even if it's only useful to a segment of the user based. OTOH, if there is a scheme that requires multiple actors in the architecture to cooperate, then (as I described in my utility analysis), it has to be pretty universally usable or it won't get sufficient deployment to be operationally useful. Scott K From nobody Tue May 5 20:01:08 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 631CD1B2A77 for ; Tue, 5 May 2015 20:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWTkAcagoJ1F for ; Tue, 5 May 2015 20:00:53 -0700 (PDT) Received: from groups.winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5951B2A50 for ; Tue, 5 May 2015 20:00:52 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2178; t=1430881247; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=FCwDT7nqhRtO8vsHLAkstNV69+M=; b=Mr8u513ZcJwW+7CR8BWq kszsi3Dp+1H/XLypev77+2+y70voghL3LL+IIuyDouYmEVZce8yOsnnhvv7Thok8 uB8w1Myw97arzHRqwZpgd4L1zckdd4fKTxK7dLVaCPIspPCH6DTNmpBVFc10fSn7 fwieGKSsC9Dw2GvguzsDLGU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 05 May 2015 23:00:46 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 296273927.1497.4464; Tue, 05 May 2015 23:00:46 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2178; t=1430880975; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Xo4Y6Qd XzmcGffUHni5xScMw1WkPmXV7H8wAgqXAwZ0=; b=V3LXbaafZqj6+gJQ63KRxts N2s68FWD1dNjk6or3v6nBLCoR/8WI/qfjxY3jr1NVFA+GGlxzIgZ2HWqsNSKXs6Y DEC8h68w7djZfIyWFhSwbNaXzdjKjn3zfQWTL3w9WNcSMAv9Sy+Rxmqklud045IZ NoO6XXvMykCuxX126up0= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 05 May 2015 22:56:15 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3183510707.9.12340; Tue, 05 May 2015 22:56:14 -0400 Message-ID: <554983DB.6000106@isdg.net> Date: Tue, 05 May 2015 23:00:43 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554111FB.5040801@isdg.net> <55490AD3.6060202@isdg.net> <1723345.j8sNWI9Enb@kitterma-e6430> In-Reply-To: <1723345.j8sNWI9Enb@kitterma-e6430> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 03:01:05 -0000 On 5/5/2015 7:55 PM, Scott Kitterman wrote: > On Tuesday, May 05, 2015 02:24:19 PM Hector Santos wrote: >> You don't even have to say "universally useful." All that does is >> keeps possible implementators away. It can be very useful to some >> and to them, its universal. > > It depends on the type of mechanism we're discussing registration for. If > it's something receivers can do on their own with no cooperation from > originators or mediators, then I agree. A scheme that doesn't require > cooperation with other actors in the architecture can be 'good enough' even if > it's only useful to a segment of the user based. > > OTOH, if there is a scheme that requires multiple actors in the architecture > to cooperate, then (as I described in my utility analysis), it has to be > pretty universally usable or it won't get sufficient deployment to be > operationally useful. We are talking about DNS publication of records and domains having to roll up their sleeves and collect the data they need, if they want to, making a registration process available to DKIM resigners. I see it as a separation problem. The same one, nearly all the DNS-based protocols had/have -- Publishing DNS records requirement in order to be useful. If we had used this high bar to have a registration/publishing readiness or assurance first before you get started, as you ideally suggest, most of these protocols would not have been done. You need to have your methods in place first and the minimum code changes among all actors is doing a simple DNS lookup as it was originally conceived. That is not hard to compare with the alternatives which has a higher implementation cost and requires much greater code change. Just like SPF, once enough domains published records, it became somewhat useful and only really more useful when rejection policies were set. This is when a payoff was realized -- with a rejection policy. That took a mighty long time and yet, it is still a highly wasteful protocol. Neverteless, it didn't stop anyone from using it and domains with larger network of senders are still trying to figure them all out. -- HLS From nobody Tue May 5 20:24:17 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCDA1A92F5 for ; Tue, 5 May 2015 20:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmLXBdIGDERT for ; Tue, 5 May 2015 20:24:15 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 264C21A92B8 for ; Tue, 5 May 2015 20:24:15 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 3DB45C40028 for ; Tue, 5 May 2015 22:24:14 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1430882654; bh=vmeUJ+7sKNz+AuN/vDvYBqrBQus24moZWwhofBCES0c=; h=From:To:Subject:Date:In-Reply-To:References:From; b=AZ9OytEZE7yvOHG/T8Ps5vW6R5GSlSG5EAs1mMUstOdk+CaQcsOvcEh7dvd+8V7qO rIZUHTitESWqd4OcilDUzwztOdn+evpGDzlBVRjvmMm3Bk1vOYCTBpWeIBgie4uDEt KkT75Mm6ieF4Cbcsm7T8HKuAgUIAiC3S0/A09OW8= From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 05 May 2015 23:24:13 -0400 Message-ID: <1743834.3ha4bUqDIh@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-51-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <554983DB.6000106@isdg.net> References: <554111FB.5040801@isdg.net> <1723345.j8sNWI9Enb@kitterma-e6430> <554983DB.6000106@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 03:24:16 -0000 On Tuesday, May 05, 2015 11:00:43 PM Hector Santos wrote: > On 5/5/2015 7:55 PM, Scott Kitterman wrote: > > On Tuesday, May 05, 2015 02:24:19 PM Hector Santos wrote: > >> You don't even have to say "universally useful." All that does is > >> keeps possible implementators away. It can be very useful to some > >> and to them, its universal. > > > > It depends on the type of mechanism we're discussing registration for. If > > it's something receivers can do on their own with no cooperation from > > originators or mediators, then I agree. A scheme that doesn't require > > cooperation with other actors in the architecture can be 'good enough' > > even if it's only useful to a segment of the user based. > > > > OTOH, if there is a scheme that requires multiple actors in the > > architecture to cooperate, then (as I described in my utility analysis), > > it has to be pretty universally usable or it won't get sufficient > > deployment to be operationally useful. > > We are talking about DNS publication of records and domains having to > roll up their sleeves and collect the data they need, if they want to, > making a registration process available to DKIM resigners. > > I see it as a separation problem. The same one, nearly all the > DNS-based protocols had/have -- Publishing DNS records requirement in > order to be useful. If we had used this high bar to have a > registration/publishing readiness or assurance first before you get > started, as you ideally suggest, most of these protocols would not > have been done. > > You need to have your methods in place first and the minimum code > changes among all actors is doing a simple DNS lookup as it was > originally conceived. That is not hard to compare with the > alternatives which has a higher implementation cost and requires much > greater code change. > > Just like SPF, once enough domains published records, it became > somewhat useful and only really more useful when rejection policies > were set. This is when a payoff was realized -- with a rejection > policy. That took a mighty long time and yet, it is still a highly > wasteful protocol. Neverteless, it didn't stop anyone from using it > and domains with larger network of senders are still trying to figure > them all out. No. It's fundamentally different. For SPF, the managers of an ADMD need to determine their authorized outbound email architecture. That's in the hands of the administrators. For these email list registration proposals it's the mailing list proclivities of every single user. Mars and Jupiter are "the same" in that they are both planets. Trying to land on one is much more feasible than the other despite that sameness. Scott K From nobody Wed May 6 01:23:34 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9571A8A4D for ; Wed, 6 May 2015 01:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOI2k7GTb0p7 for ; Wed, 6 May 2015 01:23:31 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 329881A8A39 for ; Wed, 6 May 2015 01:23:30 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id BEFED1C386C; Wed, 6 May 2015 17:23:29 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 9948711F6A1; Wed, 6 May 2015 17:23:29 +0900 (JST) From: "Stephen J. Turnbull" To: Scott Kitterman In-Reply-To: <12DB7EB5-8EDE-4163-B96F-17CCCDD7A23D@kitterman.com> References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> <87r3qyor3n.fsf@uwakimon.sk.tsukuba.ac.jp> <1560828201.22399.1430781642344.JavaMail.zimbra@peachymango.org> <87wq0n3sq7.fsf@uwakimon.sk.tsukuba.ac.jp> <12DB7EB5-8EDE-4163-B96F-17CCCDD7A23D@kitterman.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 06 May 2015 17:23:29 +0900 Message-ID: <87pp6e3yim.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 08:23:33 -0000 Scott Kitterman writes: > Approximately as soon as list-id enables DMARC bypass, It never will. (BTW, it's List-Post that's relevant.) It's the subscriber's action of posting to the list that enables the bypass. That means that a successful attack of the kind that triggered the April Fiasco requires an iterated phish: first you have to phish *me* to post to your list, then you need to modify my post to phish *Murray*. If you have an alternative threat model in mind, please explain it. > the bad guys will start adding it to everything. They already have, according to Franck. That doesn't matter, though, except as it requires more space in the "apparent lists" database. Again, that's an implementation issue. From nobody Wed May 6 01:25:22 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8031A8A74 for ; Wed, 6 May 2015 01:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJdJeYikFFqu for ; Wed, 6 May 2015 01:25:20 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id AD8AE1A8A60 for ; Wed, 6 May 2015 01:25:20 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 2E51F1C386C; Wed, 6 May 2015 17:25:20 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 077B611F6A1; Wed, 6 May 2015 17:25:19 +0900 (JST) From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> <87r3qyor3n.fsf@uwakimon.sk.tsukuba.ac.jp> <1560828201.22399.1430781642344.JavaMail.zimbra@peachymango.org> <87wq0n3sq7.fsf@uwakimon.sk.tsukuba.ac.jp> <12DB7EB5-8EDE-4163-B96F-17CCCDD7A23D@kitterman.com> <5548FD17.7050901@isdg.net> <47FA94B2-67CA-43DD-A2E3-57C6D444183A@kitterman.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 06 May 2015 17:25:19 +0900 Message-ID: <87oaly3yfk.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 08:25:21 -0000 Murray S. Kucherawy writes: > "A participating operator needs to solve the registration problem. > Different operators will have different capabilities, requirements, and > limitations here. A very simple approach would be ; > however, this has the following drawbacks: . > Non-trivial solutions may or may not appear in later documents." +1 (in fact, that's exactly what I had in mind). From nobody Wed May 6 01:38:11 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8C91A7D83 for ; Wed, 6 May 2015 01:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.199 X-Spam-Level: * X-Spam-Status: No, score=1.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_21=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7ex8FJlxFIU for ; Wed, 6 May 2015 01:38:09 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 490CB1A0041 for ; Wed, 6 May 2015 01:38:09 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id BF73D1C3861; Wed, 6 May 2015 17:38:08 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 99FBB11F6A1; Wed, 6 May 2015 17:38:08 +0900 (JST) From: "Stephen J. Turnbull" To: "John Levine" In-Reply-To: <20150505185543.42741.qmail@ary.lan> References: <20150505185543.42741.qmail@ary.lan> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 06 May 2015 17:38:08 +0900 Message-ID: <87mw1i3xu7.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org, superuser@gmail.com Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 08:38:10 -0000 John Levine writes: > > A very simple approach would be ; > > Not so good, since there are lists that do't have list-id Too bad for those lists. What matters is that an awful lot of lists do have list-id, and even more have list-post (which is the header that matters here). If the idea can convince p=reject-using Author Domains, it's a big improvement for a lot of lists. > and spam that does. Don't register lists that pass spam. If spam that looks like it comes from a list is getting through to your users, you have real problems anyway. What else is new? I don't see an exploit here that isn't already available to the mal-actors, and I don't see how it increases risk substantially since it requires an iterated phish to succeed. I guess the main risk would be if it gives the spammers a new way to conceal the fact that their mailboxes at Author Domains are being used as phishing vehicles via lists based at Spammer Domains. But AIUI that's the whole issue with TPA from the Author Domain standpoint. Is there a *new* issue here? From nobody Wed May 6 04:28:30 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6928F1B2AC0 for ; Wed, 6 May 2015 04:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_21=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tm-pUIVkeVFb for ; Wed, 6 May 2015 04:28:27 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5440B1A889C for ; Wed, 6 May 2015 04:28:27 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 43125C403D5 for ; Wed, 6 May 2015 06:28:26 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1430911706; bh=Q9526qrhK+jUsMInu7rA0wHoKGKsMh/o4cWURhc4xMw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=09KG47LF1ph6fzNm/kKAbhAclFCbWM08TKgg4c2fqjWjn7kKmZ4uGxv7IjvsQCPHF MtP2egWzGExFfoOQ5Xbob3S34pvLNZwpznqkhB2SmQi+I85tXAMDlczRN2RAJGxf6v Nl2RNHOJ2Avqp0g2+oj+X3p5XWRiypVfIyKflQ9k= From: Scott Kitterman To: dmarc@ietf.org Date: Wed, 06 May 2015 07:28:25 -0400 Message-ID: <53018683.LR03mPSUiY@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-51-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <87mw1i3xu7.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20150505185543.42741.qmail@ary.lan> <87mw1i3xu7.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 11:28:28 -0000 On Wednesday, May 06, 2015 05:38:08 PM Stephen J. Turnbull wrote: > John Levine writes: > > > A very simple approach would be ; > > > > Not so good, since there are lists that do't have list-id > > Too bad for those lists. What matters is that an awful lot of lists > do have list-id, and even more have list-post (which is the header > that matters here). If the idea can convince p=reject-using Author > Domains, it's a big improvement for a lot of lists. > > > and spam that does. > > Don't register lists that pass spam. If spam that looks like it comes > from a list is getting through to your users, you have real problems > anyway. What else is new? I don't see an exploit here that isn't > already available to the mal-actors, and I don't see how it increases > risk substantially since it requires an iterated phish to succeed. > > I guess the main risk would be if it gives the spammers a new way to > conceal the fact that their mailboxes at Author Domains are being used > as phishing vehicles via lists based at Spammer Domains. But AIUI > that's the whole issue with TPA from the Author Domain standpoint. Is > there a *new* issue here? TPA requires cooperation from originators and receivers, so there's no "new" issue. Any make a list approach that needs both originators and receivers to participate needs to work for both large/small originators/receivers and I don't think this does. That's not "new", but it is a problem. Scott K From nobody Wed May 6 04:56:36 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A1C1A8ACA for ; Wed, 6 May 2015 04:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.402 X-Spam-Level: X-Spam-Status: No, score=-101.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_36=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ODNJZ6Xhu7T for ; Wed, 6 May 2015 04:56:32 -0700 (PDT) Received: from mail.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7381E1A8AC9 for ; Wed, 6 May 2015 04:56:31 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3370; t=1430913383; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=2roUAg4q1k1FHW+pNQPJMxKCafA=; b=VcmJCuG50n1RHLsNg3l4 4cFbStCP6bt9BEwCO9LU588A9P7y7KsmYHcV+poLVNMViFeK0LKGz/w63E6WP6GQ KJx8pMv05fREARoPNGZS/tT5IUh3gcbO5eieWyqgI/4EgRklLPAh42RwSfYR8M+o VGXstN3uXbzwdsiLZsIpA5A= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 06 May 2015 07:56:23 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 328409369.2450.4688; Wed, 06 May 2015 07:56:22 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3370; t=1430913115; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=KTVtCYO XtvQTx/Pxi5aa2YrT6s5OmSo5EjPpn/T4MrQ=; b=zCBkRXRu0Cd7RRARXnHWuku gUTFDvHSESoObpDJH+Gi+0miIPSTmcglCQPIIT5DZuHZkmMMQ8bs8aX8soL+7tvT pro1t1ydQVSbcBHLpZnOm3yMdP42FnhBuTMG+9xti1wgNFnb9/6jv7ErwkjO15Lg F14mIZROOAh0QipYuvdA= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 06 May 2015 07:51:55 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3215651066.9.12296; Wed, 06 May 2015 07:51:54 -0400 Message-ID: <554A0168.1030700@isdg.net> Date: Wed, 06 May 2015 07:56:24 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "dmarc@ietf.org" References: <554111FB.5040801@isdg.net> <1723345.j8sNWI9Enb@kitterma-e6430> <554983DB.6000106@isdg.net> <1743834.3ha4bUqDIh@kitterma-e6430> In-Reply-To: <1743834.3ha4bUqDIh@kitterma-e6430> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 11:56:34 -0000 On 5/5/2015 11:24 PM, Scott Kitterman wrote: > > No. It's fundamentally different. > > For SPF, the managers of an ADMD need to determine their authorized outbound > email architecture. That's in the hands of the administrators. For these > email list registration proposals it's the mailing list proclivities of every > single user. > > Scott K It is fundamentally the same problem both DMARC and SPF has and I might even suggest, it may be even worst for SPF. With SPF, users also have "proclivities" to roam around and send mail from unknown, "unregistered" machines. I wouldn't say "every single user" have the same behavior of being list members but most people do travel, and may use different IP devices with POP3/IMAP/SMTP. With SPF, you still have almost all the very large "public service" domains such hotmail.com, yahoo.com, aol.com, msn.com, etc, who have not yet figured out their "SPF network" in order to be very restrictive. If any of these domains, all of a sudden, turned on the -ALL rejection switch, oh my, we will see a tremendous amount of complaining as well. For the domains that have locked it down with the hard fail, -ALL policy, they have made a very strong public DNS statement about limiting who can send mail on their behalf, just like Yahoo.com did with DMARC who is now telling the world via their SPF and DMARC policies: I don't know from where my yahoo.com are sending mail from, but I want to tell you, they all must be signed exclusively by yahoo.com Yes, these are very much the same problem and I don't believe its right to be demoting technically sound protocols for the same "registration' problem that SPF still has with a long term prospect for collecting the network of machines in order to be able to publish restrictive policies. We have two basic technical proposals. The first one, the DNS CALL method, I view, as the absolutely baseline, proof of concept method. It will work, we know it. Its already in practice. Just put the data there and it will work if you add the logic to your policy check. This follows RFC5585 DKIM Service Overview guidelines. The 2nd one, has the same 3rd party signer authorization purpose, but has more work with required changed DKIM code. It uses an in-band double signature method. It is theoretically less secure, but the theory here is that the signer will have a basic idea of the list domains to passively register via the message -- a unknown registration problem, perhaps a little less because it seemingly bypasses getting the DNS administrator and DNS network department involved. The proper engineering compromising solution SHOULD be to offer both. The idea of having a SAM or Signature Authorization Method or as Doug calls it "Specific Advisory Method" tag in DMARC, is a sound technical IETF way of resolving this problem that is agnostic to all parties. sam=tpa use a third party DNS lookup method sam=levine use levine's double signature idea Personally, I would use the DNS method only because its cheaper to get to this planet, but if we really think the levine bypass will work as well, add it too. I am just saying lets not lump everyone into the same DNS publishing/registration problem the hotmail.com, yahoo.com, aol.com, msn.com domains have. Others will not. -- HLS From nobody Wed May 6 06:44:59 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36031A916B for ; Wed, 6 May 2015 06:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FK7ma53VSho7 for ; Wed, 6 May 2015 06:44:56 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34D201A9150 for ; Wed, 6 May 2015 06:44:56 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES532.agna.amgreetings.com ([::1]) with mapi id 14.03.0210.002; Wed, 6 May 2015 09:44:55 -0400 From: "MH Michael Hammer (5304)" To: "Stephen J. Turnbull" , Scott Kitterman Thread-Topic: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support Thread-Index: AQHQhsD5WI18zVKgRkuTCOwq6reKhJ1t0ywAgAAJoICAAQScgIAAFRzg Date: Wed, 6 May 2015 13:44:54 +0000 Message-ID: References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> <87r3qyor3n.fsf@uwakimon.sk.tsukuba.ac.jp> <1560828201.22399.1430781642344.JavaMail.zimbra@peachymango.org> <87wq0n3sq7.fsf@uwakimon.sk.tsukuba.ac.jp> <12DB7EB5-8EDE-4163-B96F-17CCCDD7A23D@kitterman.com> <87pp6e3yim.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87pp6e3yim.fsf@uwakimon.sk.tsukuba.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.223] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 13:44:57 -0000 > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Stephen J. > Turnbull > Sent: Wednesday, May 06, 2015 4:23 AM > To: Scott Kitterman > Cc: dmarc@ietf.org > Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support >=20 > Scott Kitterman writes: >=20 > > Approximately as soon as list-id enables DMARC bypass, >=20 > It never will. (BTW, it's List-Post that's relevant.) It's the subscrib= er's action > of posting to the list that enables the bypass. > That means that a successful attack of the kind that triggered the April = Fiasco > requires an iterated phish: first you have to phish *me* to post to your = list, > then you need to modify my post to phish *Murray*. >=20 > If you have an alternative threat model in mind, please explain it. >=20 One that comes to mind immediately is compromise existing list(s) (MLM) us= ed by target audience and then modify posts as desired. It may be that the = modification would be for only one or a few recipients.=20 I'm sure there are other mechanisms if a little thought is put into it. Mike From nobody Wed May 6 11:13:49 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B461A0277 for ; Wed, 6 May 2015 11:13:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8QC_skUkljU for ; Wed, 6 May 2015 11:13:47 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A56A71A88AE for ; Wed, 6 May 2015 11:13:40 -0700 (PDT) Received: by pdbqa5 with SMTP id qa5so16871163pdb.1 for ; Wed, 06 May 2015 11:13:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=5IaI0CSPZ9A+XyqzPkGNvQo+baR/4cg6kWDA4VDpGjo=; b=IFn0EkZsMt/VnWdpHl3QCNf89vJ6NyfJZJ9DHdQ2IcxfRX5JmTtyhCVJRvSqLdg2+K 7lf3XT0+2C5vFjjPajSH0jgv9jAoGyIZyg4DKpSzDD0MNeE/qq07p5QsuTZiV19G2S5n BV8DnRf/n5mRgV8UmH86M6VDi4AxSinacNdYemvQsm2xsTt1BW2NPhWl0ytm+JgifwK/ D3Y+eScIKFWHbKr4jrhcdI6I97c937+v1P/TCEfwnHPFHgH0YyE+oJtk46YmdJ6By2Wy t9QX6OAhgkICMxVnte610IyL9f0vWjkiI1HfL64xuKqlZXhQNvhbmnnqZvD3+WB3HLz9 AA3g== X-Received: by 10.66.119.71 with SMTP id ks7mr61635330pab.147.1430936020207; Wed, 06 May 2015 11:13:40 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id sl9sm2545239pac.41.2015.05.06.11.13.37 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 May 2015 11:13:38 -0700 (PDT) Message-ID: <554A59D1.3080400@gmail.com> Date: Wed, 06 May 2015 11:13:37 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> <87r3qyor3n.fsf@uwakimon.sk.tsukuba.ac.jp> <1560828201.22399.1430781642344.JavaMail.zimbra@peachymango.org> <87wq0n3sq7.fsf@uwakimon.sk.tsukuba.ac.jp> <12DB7EB5-8EDE-4163-B96F-17CCCDD7A23D@kitterman.com> <87pp6e3yim.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 18:13:48 -0000 On 5/6/15 6:44 AM, MH Michael Hammer (5304) wrote: >> -----Original Message----- >> From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Stephen J. >> Turnbull >> Sent: Wednesday, May 06, 2015 4:23 AM >> To: Scott Kitterman >> Cc: dmarc@ietf.org >> Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support >> >> Scott Kitterman writes: >> >> > Approximately as soon as list-id enables DMARC bypass, >> >> It never will. (BTW, it's List-Post that's relevant.) It's the subscriber's action >> of posting to the list that enables the bypass. >> That means that a successful attack of the kind that triggered the April Fiasco >> requires an iterated phish: first you have to phish *me* to post to your list, >> then you need to modify my post to phish *Murray*. >> >> If you have an alternative threat model in mind, please explain it. >> > One that comes to mind immediately is compromise existing list(s) (MLM) used by target audience and then modify posts as desired. It may be that the modification would be for only one or a few recipients. > > I'm sure there are other mechanisms if a little thought is put into it. Dear Mike, Any mail sent from a DMARC domain where content is not vetted can serve to phish anyone. Remember, DKIM does not constrain the number of replays or who are the eventual recipients. A phishing risk primarily relates to visual appearances. As such, typical appearances gives most mailing-lists that are not DMARC compatible high marks by tagging the Subject header field and adding headers or footers. The real problem in using double signature schemes is expiry will be long enough to support significantly large campaigns that can't be stopped even after being detected unless DKIM signatures are pulled. Then of course, this creates nasty DNS handling issues and potentially high levels of collateral damage. At least with TPA-Label, the DMARC domain remains in control using fairly static TPA-Label zones. The TPA-Label zone can be separate from the zones used for everything else by the DMARC domain which can act as a natural source for domain reputation managed directly or indirectly by the sending domain. You'd be amazed how little resources this strategy requires. Regards, Douglas Otis From nobody Wed May 6 11:51:45 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E8C1B2E3F for ; Wed, 6 May 2015 11:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHyovL4MdCPZ for ; Wed, 6 May 2015 11:51:41 -0700 (PDT) Received: from groups.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 948761A92EC for ; Wed, 6 May 2015 11:51:41 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=991; t=1430938299; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=qdnIjVe67cBXqY6d3Itlxd0tNfU=; b=ABq+4NqcOlLPJFiyVAsJ iAQF3Lsw3tDYotcunY1qXEK0338p//dircQHHSrsRW43vFBdpWWJ1PKnjo4gtWy0 IJHnRCdOBkZPHREfkNKnNy+dKXDi2KOA39UE6ZmNNomTn6wza8F7XNg0Ys7veWU0 kq4Us6LqaO/plBkg5N6O7Z8= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 06 May 2015 14:51:39 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 353324772.2450.1472; Wed, 06 May 2015 14:51:38 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=991; t=1430938026; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=XF826I0 YAYmr0ydSPXxJbnCnfctxbuUNrZH/qTY8Ttw=; b=UbDChnX1kO1B1BtgxkoZeAy dDkJW9Dj80L2EFbpObFVVkzetsLJtnK3WzgXiWO4PkPuDKQ7I+jqotCX38JktQzp 96pDozuq3jW6Iy+W+YGpnPI3TA4rZ7Q7CK+8CnfrFATI66LIGDzzwanXCZVEmJu0 WrEFWczpk2axe72ErGP8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 06 May 2015 14:47:06 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3240562223.9.12732; Wed, 06 May 2015 14:47:05 -0400 Message-ID: <554A62B8.80405@isdg.net> Date: Wed, 06 May 2015 14:51:36 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> <87r3qyor3n.fsf@uwakimon.sk.tsukuba.ac.jp> <1560828201.22399.1430781642344.JavaMail.zimbra@peachymango.org> <87wq0n3sq7.fsf@uwakimon.sk.tsukuba.ac.jp> <12DB7EB5-8EDE-4163-B96F-17CCCDD7A23D@kitterman.com> <87pp6e3yim.fsf@uwakimon.sk.tsukuba.ac.jp> <554A59D1.3080400@gmail.com> In-Reply-To: <554A59D1.3080400@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 18:51:43 -0000 On 5/6/2015 2:13 PM, Douglas Otis wrote: > > The real problem in using double signature schemes is expiry > will be long enough to support significantly large campaigns > that can't be stopped even after being detected unless DKIM > signatures are pulled. Then of course, this creates nasty > DNS handling issues and potentially high levels of > collateral damage. I think you are overstating this. Remember, there are DDoS and load controls already in place. DKIM will not exert any more pressure on DNS that already exist. We are also very comfortable with the resilience of DNS software, advanced caching methods, and higher, lower cost, powered machines allowing us to scale up, rather than scale out. The real problem with double signatures is that is more additional coding work is required and there are too many design assumption ifs making it inherently more complex and higher barrier to adoption compared to the baseline, simpler DNS call method. -- HLS From nobody Wed May 6 13:46:29 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF511B2F37 for ; Wed, 6 May 2015 13:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eg7okuLEIN2T for ; Wed, 6 May 2015 13:46:26 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 416E71B2F42 for ; Wed, 6 May 2015 13:46:03 -0700 (PDT) Received: by pabtp1 with SMTP id tp1so19518210pab.2 for ; Wed, 06 May 2015 13:46:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=xyRITSoKJQ9vK4mfOEAJaNKCE7TWKWzHFRxUX5AcxT0=; b=sCJe1u7u+dZlWaRZr38Vi7ieJJsjyzzITwZzRxwMt8JYeXeDStGMvth42TfGf2wGnk KnYx2KLiMm9TXg4FIKWOE+qHCzpQRBAU4k9dJgqcJfgu49gX7NkfcrEOcynC0AQEHjad Meaq7JYOs/JWZtJ8D64vTQ7P9vCJtum9tL/ywaKQpdBx5grYN96Q0RB5K0PySqIyXaEp DrDsXaZXjuJs4FMgyvHOlWksbC8Kuq5qMj/SJ1lDxxnftYV7HCBBX7VQDKJY8sZsohnP Jk9GU4jgIfhXGXSEFElgUw8kH4blPyI8RaBkcgTTTkz5/kDepeOnR+B/xItarsyL2gkB BOUQ== X-Received: by 10.70.130.198 with SMTP id og6mr868897pdb.153.1430945162975; Wed, 06 May 2015 13:46:02 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id ym6sm2748821pac.32.2015.05.06.13.45.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 May 2015 13:46:01 -0700 (PDT) Message-ID: <554A7D85.4030600@gmail.com> Date: Wed, 06 May 2015 13:45:57 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> <87r3qyor3n.fsf@uwakimon.sk.tsukuba.ac.jp> <1560828201.22399.1430781642344.JavaMail.zimbra@peachymango.org> <87wq0n3sq7.fsf@uwakimon.sk.tsukuba.ac.jp> <12DB7EB5-8EDE-4163-B96F-17CCCDD7A23D@kitterman.com> <87pp6e3yim.fsf@uwakimon.sk.tsukuba.ac.jp> <554A59D1.3080400@gmail.com> <554A62B8.80405@isdg.net> In-Reply-To: <554A62B8.80405@isdg.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 20:46:28 -0000 On 5/6/15 11:51 AM, Hector Santos wrote: > On 5/6/2015 2:13 PM, Douglas Otis wrote: >> >> The real problem in using double signature schemes is expiry >> will be long enough to support significantly large campaigns >> that can't be stopped even after being detected unless DKIM >> signatures are pulled. Then of course, this creates nasty >> DNS handling issues and potentially high levels of >> collateral damage. > > I think you are overstating this. Remember, there are DDoS > and load controls already in place. DKIM will not exert > any more pressure on DNS that already exist. We are also > very comfortable with the resilience of DNS software, > advanced caching methods, and higher, lower cost, powered > machines allowing us to scale up, rather than scale out. > > The real problem with double signatures is that is more > additional coding work is required and there are too many > design assumption ifs making it inherently more complex > and higher barrier to adoption compared to the baseline, > simpler DNS call method. Dear Hector, Defending against DDoS is very difficult, but that was not the concern. Collateral damage would be of legitimate messages inadvertently blocked when removing a common DKIM signature. There is also the challenge of managing a double-signature re-signing process where it must be assumed not all destinations receive a signature delegation. Even this double signing process may prove problematic when it goes beyond SQL query rates. There is also another concern regarding any phishing campaign permitted by effectively signing unknown content. Only by removing DKIM signatures from DNS would a DMARC domain be able to squelch a phishing attack it inadvertently authorized. TPA-Label allows authorization removal to be based on the destination domain and even a specific list-id. TPA-Label would not impact any existing DKIM signing process since authorization by destination is managed by TPA-Label zones. Regards, Douglas Otis From nobody Wed May 6 22:53:12 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1681ACEAA for ; Wed, 6 May 2015 22:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PL_GPzRXKG6 for ; Wed, 6 May 2015 22:53:09 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id D6AB61ACEA7 for ; Wed, 6 May 2015 22:53:08 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 07B9E1C3872; Thu, 7 May 2015 14:53:07 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id D608D11F6A1; Thu, 7 May 2015 14:53:06 +0900 (JST) From: "Stephen J. Turnbull" To: Scott Kitterman In-Reply-To: <53018683.LR03mPSUiY@kitterma-e6430> References: <20150505185543.42741.qmail@ary.lan> <87mw1i3xu7.fsf@uwakimon.sk.tsukuba.ac.jp> <53018683.LR03mPSUiY@kitterma-e6430> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 07 May 2015 14:53:06 +0900 Message-ID: <87egmt3pdp.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 05:53:10 -0000 Scott Kitterman writes: > TPA requires cooperation from originators and receivers, so there's > no "new" issue. Any make a list approach that needs both > originators and receivers to participate needs to work for both > large/small originators/receivers and I don't think this does. "Sez you", but I don't see a rationale for "not work" that actually addresses the intended use case. In fact, what's required for making a list is Mediators (mailing lists) that use the List-Post field. A very large proportion of those that allow open (or subscriber) posting do provide that already, and at least for Mailman lists it's trivial to turn them on. So only the Author Domain (and perhaps its users) need participate to make the list. To use the list, the Author Domain needs to produce "delegation signatures", and recipients need to process those signatures. Implementation is hardly high cost. Large domains can generally afford the cost of revising their custom MTAs. Many small domains will be using Exim, Sendmail, or Postfix, and the latter two implement the milter protocol so a software upgrade isn't necessary, and Exim can be configured to call out to another program, too, so it might need a separate implementation, but it would be do-able without upgrading the MTA. A gradual rollout therefore is quite feasible. From nobody Wed May 6 23:46:07 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7C21AD0CD for ; Wed, 6 May 2015 23:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.199 X-Spam-Level: *** X-Spam-Status: No, score=3.199 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlEfQYC71a9b for ; Wed, 6 May 2015 23:46:03 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id A34AF1AD0CB for ; Wed, 6 May 2015 23:46:03 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 781821C3861; Thu, 7 May 2015 15:46:02 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 53DE011F6A1; Thu, 7 May 2015 15:46:02 +0900 (JST) From: "Stephen J. Turnbull" To: "MH Michael Hammer (5304)" In-Reply-To: References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> <87r3qyor3n.fsf@uwakimon.sk.tsukuba.ac.jp> <1560828201.22399.1430781642344.JavaMail.zimbra@peachymango.org> <87wq0n3sq7.fsf@uwakimon.sk.tsukuba.ac.jp> <12DB7EB5-8EDE-4163-B96F-17CCCDD7A23D@kitterman.com> <87pp6e3yim.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 07 May 2015 15:46:02 +0900 Message-ID: <87d22c51hx.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 06:46:05 -0000 MH Michael Hammer (5304) writes: > One that comes to mind immediately is compromise existing list(s) > (MLM) used by target audience and then modify posts as desired. It > may be that the modification would be for only one or a few > recipients. This has nothing to do with the registration issue. It's about the delegation protocols themselves. That said, sure -- that's an obvious threat for the delegation protocols, and it applies to other registration schemes, including "manual" ones like Otis's tpa-labels, too. But is it worth the spammer's while? First, note that we're assuming the spammers really want to send "from" p=reject Author Domains. Otherwise, why bother with suborning the mailing lists? If you can send apparently-from a p=none domain, delegation simply doesn't matter, because even DMARC itself doesn't come into play. I suppose one reason is that they have contact lists from the Author Domains in question. Are these still effective? Next, there is a small number of lists (60,000 or so).[1] What is the probability that you get a "large" intersection of contact lists with subscriber lists? Spammers think in terms of "shots" of *millions*; they need to be able to put out 20 recipients per list even if they compromise *all* of those lists, just to make their first million. Of course, maybe they just want to broadcast to the whole list "from" a p=reject domain address, but that makes the campaign all the more obvious. Is all that really worth it to a spammer, given that such a campaign would be noticed quickly, and delegation authority withdrawn from the Author Domains' MTAs? It all comes down to how p=reject Author Domains perceive the risk of abuse vs. the benefit to their mailbox users of being able to post to mailing lists without having their posts from-munged or wrapped. I think it's worth laying out the threat models we can think of for them, but in the end they decide. > I'm sure there are other mechanisms if a little thought is put > into it. Of course. As long as email as we know it exists, there will be (and most won't involve Mediators at all!) But the real question is can we lock things down enough to make spamming and phishing unprofitable? Footnotes: [1] I suspect that the ones that contain large numbers of p=reject posters are already under attack for this purpose, presumably unsuccessfully. From nobody Thu May 7 04:48:58 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901291A8789 for ; Thu, 7 May 2015 04:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.097 X-Spam-Level: * X-Spam-Status: No, score=1.097 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PZm3l-9nw-q for ; Thu, 7 May 2015 04:48:56 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48D761A8787 for ; Thu, 7 May 2015 04:48:56 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id B7A03C40188 for ; Thu, 7 May 2015 06:48:54 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1430999334; bh=l19tfUy31jdEUVpHMLvzDkdzpeElpFUdfE8XSvMwAsA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=qBs/NPjHo8/wEt0iHD+vMtMQ63UWsOKy4TBADgHolnrj/BoDeZXKpGwqqzdntL5a+ HAy7RtCumA2lq58qf2gCW7jMwF3L2G4NOYfagQ89dbcgMYbUib8Lc9wGyxgDlKGwUv KHxSMM2+ZLPA7tNn0PvyaBrpRL50C/woS/GobaAw= From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 07 May 2015 07:48:54 -0400 Message-ID: <1491152.8VqzAZlGJD@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-51-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <87egmt3pdp.fsf@uwakimon.sk.tsukuba.ac.jp> References: <53018683.LR03mPSUiY@kitterma-e6430> <87egmt3pdp.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 11:48:57 -0000 On Thursday, May 07, 2015 02:53:06 PM Stephen J. Turnbull wrote: > Scott Kitterman writes: > > TPA requires cooperation from originators and receivers, so there's > > no "new" issue. Any make a list approach that needs both > > originators and receivers to participate needs to work for both > > large/small originators/receivers and I don't think this does. > > "Sez you", but I don't see a rationale for "not work" that actually > addresses the intended use case. > > In fact, what's required for making a list is Mediators (mailing > lists) that use the List-Post field. A very large proportion of those > that allow open (or subscriber) posting do provide that already, and > at least for Mailman lists it's trivial to turn them on. So only the > Author Domain (and perhaps its users) need participate to make the > list. > > To use the list, the Author Domain needs to produce "delegation > signatures", and recipients need to process those signatures. > Implementation is hardly high cost. Large domains can generally > afford the cost of revising their custom MTAs. Many small domains > will be using Exim, Sendmail, or Postfix, and the latter two implement > the milter protocol so a software upgrade isn't necessary, and Exim > can be configured to call out to another program, too, so it might > need a separate implementation, but it would be do-able without > upgrading the MTA. A gradual rollout therefore is quite feasible. I agree with all that, but I think it's irrelevant. I publish p=none because I don't want to have problems participating in mailing lists. I've published SPF -all since 2004 and have no trouble with some small cost associated with email authentication, but DMARC is different. I took a quick look at the last week's worth of data for my domain and mail sent through ietf.org. Each mail I send to an IETF list turns into about 25 messages reported in DMARC feedback data. They are all DMARC fail due either to lack of alignment or failed DKIM signatures. Roughly 80% of those reports are from Google, Yahoo!, and Microsoft. I don't see any evidence that any large operators such as this are willing to sign up for an approach like this, but let's imagine everyone else does because it's "easy". Then instead of 100% of my IETF list mail failing DMARC, 80% fails. Is 20% success sufficient for me to switch to p=reject? I guarantee you it is not. At the end of the day, without the large providers on board, any solution that requires change at both the sender and the receiver needs the large providers on board or it's useless. Scott K From nobody Thu May 7 05:19:09 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C361A87EA for ; Thu, 7 May 2015 05:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlpSrHnij6HZ for ; Thu, 7 May 2015 05:19:05 -0700 (PDT) Received: from secure.winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 74F9E1A033B for ; Thu, 7 May 2015 05:19:05 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=642; t=1431001135; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=BWRqyUnmYj8+lpYrmBgEtIPyeBM=; b=AMHiELWM/nOzMNaNdpuq gMyYUFAFX/jZXIulXh9KyAEo2ZaxWAXegGDlzELWXCsPxf5KIPch7pqcPNdCURKh 1cUSZLDDqcW37JQBW9xKFjYHzR+AB+GD/pRxqRIxQMefeDrL4E8+QIQhj2OvXzTb uGFqFNZs2HGvYno272r24Qc= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 07 May 2015 08:18:55 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 416160461.4841.3944; Thu, 07 May 2015 08:18:54 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=642; t=1431000865; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=ApQKwFA A8unVj2i5rotCxLytbiQO49P7smQckw1gRZ4=; b=sJvoea7DtsYk0JExcnSAqpX Bma55HZvOZYNzBzhFhdfqtd895f6m1cSBEp7ZKa27kArjNnC2ZcrXFBeCRC0A9ar ZMYgFdTVH8JzUfPoNVq5/UXvoSsuHwm0bEGIoCUTx80HQmANc+9VrBA6xNk1wsrO 0G/eVZhyao5XkS/z6dpM= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 07 May 2015 08:14:25 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3303400832.9.13360; Thu, 07 May 2015 08:14:24 -0400 Message-ID: <554B5831.6030506@isdg.net> Date: Thu, 07 May 2015 08:18:57 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150505185543.42741.qmail@ary.lan> <87mw1i3xu7.fsf@uwakimon.sk.tsukuba.ac.jp> <53018683.LR03mPSUiY@kitterma-e6430> <87egmt3pdp.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87egmt3pdp.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 12:19:08 -0000 On 5/7/2015 1:53 AM, Stephen J. Turnbull wrote: > To use the list, the Author Domain needs to produce "delegation > signatures", and recipients need to process those signatures. How about the MLM receiver, will it filter the fraud? Will it remove the restrictive domains that do not want any 3rd party resigners? Will you respect and honor the exclusive, restrictive policies? > Implementation is hardly high cost. "Sez you" > Large domains can generally afford the cost of revising their > custom MTAs. That doesn't mean will they alter their code especially when don't have to address the resigner issue. -- HLS From nobody Thu May 7 08:29:13 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8055D1A9300 for ; Thu, 7 May 2015 08:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1hZ9MKnAYUw for ; Thu, 7 May 2015 08:29:09 -0700 (PDT) Received: from pop3.winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D34231A92F6 for ; Thu, 7 May 2015 08:29:08 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1891; t=1431012543; h=Received:Received: Subject:From:Message-Id:Date:To:Organization:List-ID; bh=0jo/YJM tx1I3QXfvziK46zKxWcs=; b=YelQmm4/vHfeMheeHNCyQXGtQG8lIQchpNmviFy /L8j9Ea0rSXT5CvPOYjEtTjwPpFH/ZbwCrm+1YPWqBYBgSTVKGkEChmlgcTL/9BE BF+adORW5NvwRHlqLy5+iLliclyX2KK/S+DsEiTLdg0VGQmvNsX8F/pfNMYN18Em blII= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 07 May 2015 11:29:03 -0400 Received: from [192.168.1.67] (99-3-146-30.lightspeed.miamfl.sbcglobal.net [99.3.146.30]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 427568331.4841.4472; Thu, 07 May 2015 11:29:02 -0400 References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> <87r3qyor3n.fsf@uwakimon.sk.tsukuba.ac.jp> <1560828201.22399.1430781642344.JavaMail.zimbra@peachymango.org> <87wq0n3sq7.fsf@uwakimon.sk.tsukuba.ac.jp> <12DB7EB5-8EDE-4163-B96F-17CCCDD7A23D@kitterman.com> <87pp6e3yim.fsf@uwakimon.sk.tsukuba.ac.jp> <554A59D1.3080400@gmail.com> <554A62B8.80405@isdg.net> <554A7D85.4030600@gmail.com> From: Hector Santos Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (12B435) In-Reply-To: <554A7D85.4030600@gmail.com> Message-Id: Date: Thu, 7 May 2015 11:29:01 -0400 Cc: "dmarc@ietf.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-Comment: Missing recipient address appended by wcSMTP router. To: dmarc@ietf.org Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 15:29:11 -0000 > On May 6, 2015, at 4:45 PM, Douglas Otis wrote: >=20 >=20 > Defending against DDoS is very difficult, but that was not > the concern. Collateral damage would be of legitimate > messages inadvertently blocked when removing a common DKIM > signature. What do you mean by remove? You mean destroy, invalidate existing signature= s? Keep in mind this MAY be desirable, in fact the DKIM STD76 theory is that re= signers can occur blindly anywhere with the mail path. You don't have destr= oy the original integrity during resign, yet that transaction may be illega= l (per policy) with the fact it has ben resigned. > There is also the challenge of managing a > double-signature re-signing process where it must be assumed > not all destinations receive a signature delegation. Even > this double signing process may prove problematic when it > goes beyond SQL query rates. =20 SQL? . Some folks are more optimized using ISAM/BTREE databases!=20 > There is also another concern > regarding any phishing campaign permitted by effectively > signing unknown content. Only by removing DKIM signatures > from DNS would a DMARC domain be able to squelch a phishing > attack it inadvertently authorized. TPA-Label allows > authorization removal to be based on the destination domain > and even a specific list-id. TPA-Label would not impact any > existing DKIM signing process since authorization by > destination is managed by TPA-Label zones. >=20 Doug, we know a positive result of a DNS lookup will work. I believe you w= ish to add more complex semantics on the parsing of the lookup results, I b= elieve that's ok. But we need a basic yes/no query. Maybe it can be sold i= f we offer more bang for the buck on each call but overall, it needs to be v= ery simple. =20 -- Hector Santos http://www.santronics.com= From nobody Thu May 7 12:55:03 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39C21A9106 for ; Thu, 7 May 2015 12:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.28 X-Spam-Level: X-Spam-Status: No, score=-99.28 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_64=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ta7o-rXKuoO for ; Thu, 7 May 2015 12:54:59 -0700 (PDT) Received: from catinthebox.net (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 435CB1A90DD for ; Thu, 7 May 2015 12:54:59 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2180; t=1431028495; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=W6H1bGLp574Crp93PIdJAVm44dA=; b=Be2PN20YU1lQZrh1c9Bf RdpLotRHzH6mUSGW6VSLszW1Uad9cEvB0VVSM3kX3rqjWbQmZWjGenMM2ygfhduz jhr7wAd4/UU4G0pqmv5nn0OW/sUWT4/zY8hO5z1+rWUPD+JmGzFjTTX8VVS53b1Y +4ozRAxADc0Y021tGyP/vFw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 07 May 2015 15:54:55 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 443520822.4841.2004; Thu, 07 May 2015 15:54:55 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2180; t=1431028222; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=g+7g1eo Ydk2Z1m3H+cWeGp28zsJXV/QRLxJHGlbMh9U=; b=wylErmTLRA15Hzawt0sx89B Sbhc2vWptOENrkaLY19ZCF6fKeAq6VgxC++4KB+iB5YMxVtez9685eU6YB3RwshQ G3pCxSts0Ig72+FnE05cmySepI35R5AAfw5qhmt2spsjMSQVaJNOFTiRRPc4YCnq iTB4mpN4B15Aqfe85NeE= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 07 May 2015 15:50:22 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3330757910.9.11480; Thu, 07 May 2015 15:50:21 -0400 Message-ID: <554BC30F.1020107@isdg.net> Date: Thu, 07 May 2015 15:54:55 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Franck Martin Subject: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 19:55:02 -0000 Since 05/2014, I have published DMARC records for several of my domains. Our mail receivers supports ATPS (rev04) where "atps=y" tag extension was added to my records. For example, for my non-corporate, "play around" domain isdg.net, I have: "v=DMARC1; p=none; atps=y; rua=mailto:dmarc-rua@isdg.net; ruf=mailto:dmarc-ruf@isdg.net;" ATPS draft rev04 was written as a ADSP extension. With Rev05 and the final ATPS rfc6541, ATPS was made an extension off the DKIM record instead, not ADSP. What I did was added ATPS support to the DMARC record as an 3rd party Extension allowed by DMARC. I am happy to report that after two years, there is no indication for an interop problem. The unknown tag to non-supported ATPS receivers does not interfere with the DMARC processing. The reports received come from a wide number of domains. I am also happy to report that the concept works very well in authorizing third party resigners using the ATPS (rev04) protocol. Here is an actual Auth-Res for a list message ietf.org resigner. I put a divider line for better viewing: Authentication-Results: dkim.winserver.com; ---- dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org; adsp=pass policy=all author.d=isdg.net asl.d=ietf.org; dmarc=pass policy=none author.d=isdg.net signer.d=ietf.org (atps signer); ---- dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=isdg.net header.s=tms1 header.i=isdg.net; adsp=pass author.d=isdg.net signer.d=isdg.net (originating signer); dmarc=pass policy=none author.d=isdg.net signer.d=isdg.net (originating signer); The first bottom triplet results are for the original signature. It fails the DKIM signature with a body hash mismatch. Both ADSP and DMARC pass as original signers (author == signer). In reality, if the rejection switch was enabled, this should be a FAIL because the signature is invalid. However, for the ietf.org list resigner triplet results, it passed as an ADSP ASL resigner and ATPS record resigner (author != signer). DKIM/ATPS (rev05) is part our Wildcat! SMTP component in our commercial Application Hosting package used by customers in the field. -- HLS From nobody Thu May 7 13:28:56 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437F71ACE44 for ; Thu, 7 May 2015 13:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_64=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nB25sTRxbbdn for ; Thu, 7 May 2015 13:28:53 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1A661ACE1B for ; Thu, 7 May 2015 13:28:53 -0700 (PDT) Received: from [IPv6:2600:1003:b125:6ffc:48dd:4fdf:d0c3:289d] (unknown [IPv6:2600:1003:b125:6ffc:48dd:4fdf:d0c3:289d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id B0026C4016C; Thu, 7 May 2015 15:28:52 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1431030533; bh=tPmH4ONpchP2Y5HCGrlD/Qcgk/IBKwBEDIRO1YUOh/c=; h=In-Reply-To:References:Subject:From:Date:To:From; b=FcwSKe31OURhwUXkTjGhJHw0nCmwSW/33uRT04JTlcH05R5GakgtUq3SwNMeppkrm PjyUZbvwUeUHy+pZXuos4siU/rdowzwko+gyGIwb51tfB3dZHsbF/SyWBrRXf2YjWy lGibLA049RbE4xWOwbH1hBNGL8hcWdm8FvGcJ10o= User-Agent: K-9 Mail for Android In-Reply-To: <554BC30F.1020107@isdg.net> References: <554BC30F.1020107@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Thu, 07 May 2015 16:27:19 -0400 To: dmarc@ietf.org Message-ID: <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 20:28:55 -0000 On May 7, 2015 3:54:55 PM EDT, Hector Santos wrote: >Since 05/2014, I have published DMARC records for several of my >domains. Our mail receivers supports ATPS (rev04) where "atps=y" tag >extension was added to my records. For example, for my non-corporate, >"play around" domain isdg.net, I have: > > "v=DMARC1; p=none; atps=y; rua=mailto:dmarc-rua@isdg.net; >ruf=mailto:dmarc-ruf@isdg.net;" > >ATPS draft rev04 was written as a ADSP extension. With Rev05 and the >final ATPS rfc6541, ATPS was made an extension off the DKIM record >instead, not ADSP. > >What I did was added ATPS support to the DMARC record as an 3rd party >Extension allowed by DMARC. > >I am happy to report that after two years, there is no indication for >an interop problem. The unknown tag to non-supported ATPS receivers >does not interfere with the DMARC processing. The reports received >come from a wide number of domains. > >I am also happy to report that the concept works very well in >authorizing third party resigners using the ATPS (rev04) protocol. >Here is an actual Auth-Res for a list message ietf.org resigner. I >put a divider line for better viewing: > >Authentication-Results: dkim.winserver.com; > ---- > dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org; > adsp=pass policy=all author.d=isdg.net asl.d=ietf.org; > dmarc=pass policy=none author.d=isdg.net signer.d=ietf.org (atps >signer); > ---- > dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=isdg.net header.s=tms1 >header.i=isdg.net; > adsp=pass author.d=isdg.net signer.d=isdg.net (originating signer); > dmarc=pass policy=none author.d=isdg.net signer.d=isdg.net >(originating signer); > > >The first bottom triplet results are for the original signature. It >fails the DKIM signature with a body hash mismatch. Both ADSP and >DMARC pass as original signers (author == signer). In reality, if the >rejection switch was enabled, this should be a FAIL because the >signature is invalid. > >However, for the ietf.org list resigner triplet results, it passed as >an ADSP ASL resigner and ATPS record resigner (author != signer). > >DKIM/ATPS (rev05) is part our Wildcat! SMTP component in our >commercial Application Hosting package used by customers in the field. I think it's wrong to describe that as a DMARC result. For DMARC as specified, that's a fail. Scott K From nobody Thu May 7 13:32:01 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5601ACEBD for ; Thu, 7 May 2015 13:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.28 X-Spam-Level: X-Spam-Status: No, score=-99.28 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_64=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLYP29so8DmM for ; Thu, 7 May 2015 13:32:00 -0700 (PDT) Received: from catinthebox.net (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 358A31A876E for ; Thu, 7 May 2015 13:32:00 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2555; t=1431030710; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=+g4Pb2UHTyl4Yu81bHTgHOiWuvc=; b=Mo93SgGEgs3lrjJxJCn7 SjhiUEHqDLPOG9RE+js/yPSvNKXOUAzHrbIPWRJwwdTV6Ipn+s5Uz1hGCuWtqLgx NfukCNNcRJ8KXt+qA9462itwH4JZLI3tYMFTj0veSw7JxEz64h5tqI3e5jBCqJwl J7fxYv1ldQVMlDPzy/OOrgo= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 07 May 2015 16:31:50 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 445736161.4841.4992; Thu, 07 May 2015 16:31:50 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2555; t=1431030437; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=hZrCZXS URmG5quwQXXwFpJxIK//JjpeSWhXUDQfP8yU=; b=unquXHqKNOgc8LOWRmT1rR0 Yb96BTU/ajyXOCJ82VMMVHVjjBR5C26tftwxs+MBqCP4H88X3mI2x38nhLzAKrwN WMYkNFFMWtFHWlATIuxflFa6RNXIDTRnYSfDXcIDEJho3ef5LvCHmQtpnJBodedG VOIb50azn+ObinPo44WY= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 07 May 2015 16:27:17 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3332973676.9.12824; Thu, 07 May 2015 16:27:17 -0400 Message-ID: <554BCBB7.2030703@isdg.net> Date: Thu, 07 May 2015 16:31:51 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> In-Reply-To: <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 20:32:01 -0000 On 5/7/2015 4:27 PM, Scott Kitterman wrote: > On May 7, 2015 3:54:55 PM EDT, Hector Santos wrote: >> Since 05/2014, I have published DMARC records for several of my >> domains. Our mail receivers supports ATPS (rev04) where "atps=y" tag >> extension was added to my records. For example, for my non-corporate, >> "play around" domain isdg.net, I have: >> >> "v=DMARC1; p=none; atps=y; rua=mailto:dmarc-rua@isdg.net; >> ruf=mailto:dmarc-ruf@isdg.net;" >> >> ATPS draft rev04 was written as a ADSP extension. With Rev05 and the >> final ATPS rfc6541, ATPS was made an extension off the DKIM record >> instead, not ADSP. >> >> What I did was added ATPS support to the DMARC record as an 3rd party >> Extension allowed by DMARC. >> >> I am happy to report that after two years, there is no indication for >> an interop problem. The unknown tag to non-supported ATPS receivers >> does not interfere with the DMARC processing. The reports received >> come from a wide number of domains. >> >> I am also happy to report that the concept works very well in >> authorizing third party resigners using the ATPS (rev04) protocol. >> Here is an actual Auth-Res for a list message ietf.org resigner. I >> put a divider line for better viewing: >> >> Authentication-Results: dkim.winserver.com; >> ---- >> dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org; >> adsp=pass policy=all author.d=isdg.net asl.d=ietf.org; >> dmarc=pass policy=none author.d=isdg.net signer.d=ietf.org (atps >> signer); >> ---- >> dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=isdg.net header.s=tms1 >> header.i=isdg.net; >> adsp=pass author.d=isdg.net signer.d=isdg.net (originating signer); >> dmarc=pass policy=none author.d=isdg.net signer.d=isdg.net >> (originating signer); >> >> >> The first bottom triplet results are for the original signature. It >> fails the DKIM signature with a body hash mismatch. Both ADSP and >> DMARC pass as original signers (author == signer). In reality, if the >> rejection switch was enabled, this should be a FAIL because the >> signature is invalid. >> >> However, for the ietf.org list resigner triplet results, it passed as >> an ADSP ASL resigner and ATPS record resigner (author != signer). >> >> DKIM/ATPS (rev05) is part our Wildcat! SMTP component in our >> commercial Application Hosting package used by customers in the field. > > I think it's wrong to describe that as a DMARC result. For DMARC as specified, that's a fail. > Not following you. -- HLS From nobody Thu May 7 13:37:03 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C138C1AD186 for ; Thu, 7 May 2015 13:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.28 X-Spam-Level: X-Spam-Status: No, score=-99.28 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_64=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-6XosWgCgxC for ; Thu, 7 May 2015 13:37:00 -0700 (PDT) Received: from catinthebox.net (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBAD1AD182 for ; Thu, 7 May 2015 13:37:00 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2886; t=1431031011; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=wyR2fwCt9ysQtVbCtEXjkM+02pM=; b=A2X7PYb/bd3lFTJHszMR bndGXN1eqnivmCcUj4Rm6T9AUfg7QuFEfR8w9xZ3jqNpAI2bHwc8xLj7Fnw0eQPh ssi2AtYD4r+hKgNAxsq+ZRnPbHYT7jm6bqeLJzpRdfQVo8gljbmagmB7iKczrSuR wq+ILgGJsiPILIt6iVByKk4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 07 May 2015 16:36:51 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 446036104.4841.2208; Thu, 07 May 2015 16:36:50 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2886; t=1431030738; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=+bQ4Mcb r285sZn4uZMtyHoFVZFqcHVbUG6BQ6Pzp7sk=; b=0sNS6fGUv5iwyCh1sZd/xHw +yXsJYeT3XLNdHS4Ek3exUDurmv7a6mp0QXJ0wBRksTcQiFHEZM1/bgYINCweZdq 6ZFRU2lsoXpZvXj+ANUNkKurwOn50SK8sTGgd5y8UCUgGSeFHbwN90FTs2MFEgee CidnX2830Kp36LWjJM5A= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 07 May 2015 16:32:18 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3333273551.9.12904; Thu, 07 May 2015 16:32:17 -0400 Message-ID: <554BCCE3.5000002@isdg.net> Date: Thu, 07 May 2015 16:36:51 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> In-Reply-To: <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 20:37:01 -0000 On 5/7/2015 4:27 PM, Scott Kitterman wrote: > On May 7, 2015 3:54:55 PM EDT, Hector Santos wrote: >> Since 05/2014, I have published DMARC records for several of my >> domains. Our mail receivers supports ATPS (rev04) where "atps=y" tag >> extension was added to my records. For example, for my non-corporate, >> "play around" domain isdg.net, I have: >> >> "v=DMARC1; p=none; atps=y; rua=mailto:dmarc-rua@isdg.net; >> ruf=mailto:dmarc-ruf@isdg.net;" >> >> ATPS draft rev04 was written as a ADSP extension. With Rev05 and the >> final ATPS rfc6541, ATPS was made an extension off the DKIM record >> instead, not ADSP. >> >> What I did was added ATPS support to the DMARC record as an 3rd party >> Extension allowed by DMARC. >> >> I am happy to report that after two years, there is no indication for >> an interop problem. The unknown tag to non-supported ATPS receivers >> does not interfere with the DMARC processing. The reports received >> come from a wide number of domains. >> >> I am also happy to report that the concept works very well in >> authorizing third party resigners using the ATPS (rev04) protocol. >> Here is an actual Auth-Res for a list message ietf.org resigner. I >> put a divider line for better viewing: >> >> Authentication-Results: dkim.winserver.com; >> ---- >> dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org; >> adsp=pass policy=all author.d=isdg.net asl.d=ietf.org; >> dmarc=pass policy=none author.d=isdg.net signer.d=ietf.org (atps >> signer); >> ---- >> dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=isdg.net header.s=tms1 >> header.i=isdg.net; >> adsp=pass author.d=isdg.net signer.d=isdg.net (originating signer); >> dmarc=pass policy=none author.d=isdg.net signer.d=isdg.net >> (originating signer); >> >> >> The first bottom triplet results are for the original signature. It >> fails the DKIM signature with a body hash mismatch. Both ADSP and >> DMARC pass as original signers (author == signer). In reality, if the >> rejection switch was enabled, this should be a FAIL because the >> signature is invalid. >> >> However, for the ietf.org list resigner triplet results, it passed as >> an ADSP ASL resigner and ATPS record resigner (author != signer). >> >> DKIM/ATPS (rev05) is part our Wildcat! SMTP component in our >> commercial Application Hosting package used by customers in the field. > > I think it's wrong to describe that as a DMARC result. For DMARC as specified, that's a fail. > Oh, you mean, there should be a "atps=" auth-result? oK, I can buy that but then again the AUTH-RES is for internal consumption not external, having it a single source result to a DMARC result reader, would be ok. Nonetheless, the end result is the same, the ATPS would authorized the resigner. No other DKIM signature related changes need. -- HLS From nobody Thu May 7 13:53:28 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC941B29D3 for ; Thu, 7 May 2015 13:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.28 X-Spam-Level: X-Spam-Status: No, score=-99.28 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_64=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5OnkrrYwQHD for ; Thu, 7 May 2015 13:53:25 -0700 (PDT) Received: from catinthebox.net (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA561B2A75 for ; Thu, 7 May 2015 13:53:10 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4163; t=1431031985; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=VYecnSS0I4tMtIALHxLw5duWhhE=; b=C8mQfU66cq2IhrPsOrD7 V1qSt78vGqgBVB/ZAuTnute8IMfskcnu0QdybxHhNZkgkkSYuWzGDIrUFEdjOA+8 qoBH/OogKT8C6FAicbVsrFWY7xoFBaSzbWghmKarePLqY2W9iRRmfFa3/a7v7ot8 Lv3s8hTGnpMa0Zbrm44mvw0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 07 May 2015 16:53:05 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 447011188.4841.492; Thu, 07 May 2015 16:53:05 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4163; t=1431031714; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=JF2uJqF bvPhqsfGJERIM3rINkuK9I2OXZz/yH1+K1O8=; b=jlAFd08/7Qq7noTMp1R4f+N KHI5kAY3K5TWxFoIaDWYKS412UsbmNlGRJs5lvf8iZ/m0SDn7RiSTj0hhSSSDS8G JSYvEXr+eJI5xwP5YZYGp25XvcE+wrkSKa0gws/lca9kZqsSNMd5sNHto57x9rRz 24uxkTxlXO8l/PqZRAcY= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 07 May 2015 16:48:34 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3334249738.9.13984; Thu, 07 May 2015 16:48:33 -0400 Message-ID: <554BD0B3.7020208@isdg.net> Date: Thu, 07 May 2015 16:53:07 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BCCE3.5000002@isdg.net> In-Reply-To: <554BCCE3.5000002@isdg.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 20:53:27 -0000 Scott, If this is what you are talking about, there should of been an AUTH-RES line for "atps=", I can understand that valid technical point, but I don't agree it is absolute. First, it is a DMARC extension and long as it is an indicated marker in the DMARC result, then should be ok. Second, related, one of the problems with AUTH-RES and the reason there is so many changes to it, is because its doesn't quite satisfy what an receiver might need. I had that problem with just adding ADSP to it. It didn't even support getting SPF fully reported. In other words, the dynamics are still changes in order to get a solid AUTH-RES reporting header completed. In fact, if your point is taken serious, then AUTH-RES will need even more updates to support other results, such as the double signature proposal. So this is a side issue that really has nothing to do with the overall basic protocol issue we are dealing with, but it is a good note to point out because you will run into the same "separation" issue with any other additional layer you want to add on top of DKIM and into the AUTH-RES header. Thanks for the note. On 5/7/2015 4:36 PM, Hector Santos wrote: > On 5/7/2015 4:27 PM, Scott Kitterman wrote: >> On May 7, 2015 3:54:55 PM EDT, Hector Santos wrote: >>> Since 05/2014, I have published DMARC records for several of my >>> domains. Our mail receivers supports ATPS (rev04) where "atps=y" tag >>> extension was added to my records. For example, for my non-corporate, >>> "play around" domain isdg.net, I have: >>> >>> "v=DMARC1; p=none; atps=y; rua=mailto:dmarc-rua@isdg.net; >>> ruf=mailto:dmarc-ruf@isdg.net;" >>> >>> ATPS draft rev04 was written as a ADSP extension. With Rev05 and the >>> final ATPS rfc6541, ATPS was made an extension off the DKIM record >>> instead, not ADSP. >>> >>> What I did was added ATPS support to the DMARC record as an 3rd party >>> Extension allowed by DMARC. >>> >>> I am happy to report that after two years, there is no indication for >>> an interop problem. The unknown tag to non-supported ATPS receivers >>> does not interfere with the DMARC processing. The reports received >>> come from a wide number of domains. >>> >>> I am also happy to report that the concept works very well in >>> authorizing third party resigners using the ATPS (rev04) protocol. >>> Here is an actual Auth-Res for a list message ietf.org resigner. I >>> put a divider line for better viewing: >>> >>> Authentication-Results: dkim.winserver.com; >>> ---- >>> dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org; >>> adsp=pass policy=all author.d=isdg.net asl.d=ietf.org; >>> dmarc=pass policy=none author.d=isdg.net signer.d=ietf.org (atps >>> signer); >>> ---- >>> dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=isdg.net header.s=tms1 >>> header.i=isdg.net; >>> adsp=pass author.d=isdg.net signer.d=isdg.net (originating signer); >>> dmarc=pass policy=none author.d=isdg.net signer.d=isdg.net >>> (originating signer); >>> >>> >>> The first bottom triplet results are for the original signature. It >>> fails the DKIM signature with a body hash mismatch. Both ADSP and >>> DMARC pass as original signers (author == signer). In reality, if the >>> rejection switch was enabled, this should be a FAIL because the >>> signature is invalid. >>> >>> However, for the ietf.org list resigner triplet results, it passed as >>> an ADSP ASL resigner and ATPS record resigner (author != signer). >>> >>> DKIM/ATPS (rev05) is part our Wildcat! SMTP component in our >>> commercial Application Hosting package used by customers in the field. >> >> I think it's wrong to describe that as a DMARC result. For DMARC as >> specified, that's a fail. >> > > Oh, you mean, there should be a "atps=" auth-result? oK, I can buy > that but then again the AUTH-RES is for internal consumption not > external, having it a single source result to a DMARC result reader, > would be ok. > > Nonetheless, the end result is the same, the ATPS would authorized the > resigner. No other DKIM signature related changes need. > > -- HLS From nobody Thu May 7 14:09:13 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA6D1B2AB6 for ; Thu, 7 May 2015 14:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STie0HWJZj9H for ; Thu, 7 May 2015 14:09:10 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960021B2A5B for ; Thu, 7 May 2015 14:09:10 -0700 (PDT) Received: by wiun10 with SMTP id n10so6065230wiu.1 for ; Thu, 07 May 2015 14:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/hm2BiKt9amJ5B4i4REd94TXDbsqk+PJ2dH40cN+J+A=; b=N7hFSU7t4Dz8aD0QflUDSb3CHlHvY/tqltKx2OVdoizWIe5N/KdAMUQD1EPxDR5RFe gGkre0P2sa76apYv6DD/D5i3lMW6TAB/iTp1KANRLPJxjQ7u/swl3GydQSLMGPhUx6pq Y9Qd1ltsHP44y9DpbqXUID+zukyWScRoDRHxLmGKX6gxTRZOGlHzMMZlwRirnP0sKlaF BzGcgu+rG5AklnH1Cv4CV+EXAB7TcLRNCDObHfxm7VV22AC/Ixy88az+XTRVl/EYK9w9 WYkyVWYOh/gOZPzbDrMZD1lG7KNk4LinvBAXLNs+YdK95iYJtMRLRLMZ6wr20dhoHpf3 AJOw== MIME-Version: 1.0 X-Received: by 10.194.193.66 with SMTP id hm2mr889990wjc.111.1431032949371; Thu, 07 May 2015 14:09:09 -0700 (PDT) Received: by 10.27.170.75 with HTTP; Thu, 7 May 2015 14:09:09 -0700 (PDT) In-Reply-To: <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> Date: Thu, 7 May 2015 14:09:09 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=047d7b874e629bf813051584528d Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 21:09:12 -0000 --047d7b874e629bf813051584528d Content-Type: text/plain; charset=UTF-8 On Thu, May 7, 2015 at 1:27 PM, Scott Kitterman wrote: > > I think it's wrong to describe that as a DMARC result. For DMARC as > specified, that's a fail. > > More precisely, for both DKIM and DMARC it's a fail. For DKIM+ATPS-04, it's a pass, but DMARC doesn't pay attention to that. I think it's also important to note that this only proves interoperability with a single implementation (granted, in multiple roles), unless there's data indicating multiple implementations are involved. This seems unlikely, since as far as I know there aren't any other implementations of ATPS-04 or even the RFC version. OpenDKIM did the RFC version, and it's not compatible with -04. Also, this is only part of the whole story. There's still that pesky registration problem to address. I think for ATPS or anything like it to be considered a plausible thing to pursue, that's critical. It might be interesting to know some of the characteristics of the largest operator involved in that report (total domains, total users, details about MLM traffic, etc.). -MSK --047d7b874e629bf813051584528d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, May 7, 2015 at 1:27 PM, Scott Kitterman <skli= st@kitterman.com> wrote:
<= div class=3D"h5">
I think it's wrong to describe that as a DMARC result.=C2= =A0 For DMARC as specified, that's a fail.


More precisely, for both DKIM and DMAR= C it's a fail.=C2=A0 For DKIM+ATPS-04, it's a pass, but DMARC doesn= 't pay attention to that.

I think it's also impor= tant to note that this only proves interoperability with a single implement= ation (granted, in multiple roles), unless there's data indicating mult= iple implementations are involved.=C2=A0 This seems unlikely, since as far = as I know there aren't any other implementations of ATPS-04 or even the= RFC version.=C2=A0 OpenDKIM did the RFC version, and it's not compatib= le with -04.

Also, this is only part of the whole story.= =C2=A0 There's still that pesky registration problem to address.=C2=A0 = I think for ATPS or anything like it to be considered a plausible thing to = pursue, that's critical.=C2=A0 It might be interesting to know some of = the characteristics of the largest operator involved in that report (total = domains, total users, details about MLM traffic, etc.).

-= MSK
--047d7b874e629bf813051584528d-- From nobody Thu May 7 15:03:37 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7B01AD481 for ; Thu, 7 May 2015 15:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.802 X-Spam-Level: X-Spam-Status: No, score=-100.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_54=0.6, J_CHICKENPOX_64=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShMmoHRKuGnK for ; Thu, 7 May 2015 15:03:33 -0700 (PDT) Received: from news.winserver.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD3B1ACEB2 for ; Thu, 7 May 2015 15:03:33 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3654; t=1431036202; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=XjTWfSuHfZxy5BHdpyB7f0EVSqw=; b=db0DFkktplYH/VuPT1Yh uA7aCspKDzt5irO+NP6rKgi3tpHygxZfYJJnGHageodWH1icwQPIaitGLMcHI8ox 4yabPI32szxyX0Q+XYas/UjzVvG9OtIb/5jpzxzMPbD99YXcXPrktn4tmEAZ4HR7 1deXAvvbZTSKTnVQfH2m7Js= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 07 May 2015 18:03:22 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 451226382.4841.5340; Thu, 07 May 2015 18:03:20 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3654; t=1431035928; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=fme7cxX VgZPHX3QIelUqlpKl3WJ3sPhcuILQq+fyYDo=; b=UeqiD6BcrSEzCP7Uco8UXdP 3q+Cgw1c9dnMtkYWuA39eDIafhwVLR6yJat6olORUWiyoPfyTvXjRJH8PusMs8SX wsDt9QzhP94PmhM3clH5j8vH0TXOIj5CUgK1XU1zPk9EbRLWBIWbgkAp2nbmOjfS SEcimV18x8+9ewxNZSqE= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 07 May 2015 17:58:48 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3338464051.9.12880; Thu, 07 May 2015 17:58:47 -0400 Message-ID: <554BE12A.7010606@isdg.net> Date: Thu, 07 May 2015 18:03:22 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 22:03:36 -0000 On 5/7/2015 5:09 PM, Murray S. Kucherawy wrote: > On Thu, May 7, 2015 at 1:27 PM, Scott Kitterman > wrote: > > > I think it's wrong to describe that as a DMARC result. For DMARC > as specified, that's a fail. > > > More precisely, for both DKIM and DMARC it's a fail. For > DKIM+ATPS-04, it's a pass, but DMARC doesn't pay attention to that. Now we are getting into definition and software engineering. DMARC result is a PASS when it is an extension, and in this case, it is an extension, and it is noted as an extension: dmarc=pass policy=none author.d=isdg.net signer.d=ietf.org (atps signer); In other words, does the AUTH-RES protocol allow it itself to be extended, it is flexible enough? If not, then AUTH-RES will need to be updated again. > I think it's also important to note that this only proves > interoperability with a single implementation (granted, in multiple > roles), Running code. > unless there's data indicating multiple implementations are > involved. The more the merrier, but it is running code. > This seems unlikely, since as far as I know there aren't > any other implementations of ATPS-04 or even the RFC version. > OpenDKIM did the RFC version, and it's not compatible with -04. I wish I was there to "protest" making it extend off the DKIM code which required a change to it. That is enough reason to not support it. I wouldn't either. That should be noted. > Also, this is only part of the whole story. There's still that pesky > registration problem to address. Separate issue. SPF would not be here if you used this same criteria. None of the big domains you are concern about have hard fails for SPF for the same reason -- it can not "register" their SPF network of possible users. Same problem. Didn't stop SPF from moving forward, first externally, and then as an IETF "experiment" because making it a "proposed standard" back then during MARID would of cause much protest. > I think for ATPS or anything like it > to be considered a plausible thing to pursue, that's critical. Its important for its success, but I don't buy its a problem nor should it be barrier to establish the DNS-base protocol. DNSSEC is problematic for the same reasons (lack of record support) Don't stop people from moving forward with it despite its pretty much useless to the general market as a whole. > It > might be interesting to know some of the characteristics of the > largest operator involved in that report (total domains, total users, > details about MLM traffic, etc.). It would be interesting but I don't think that proves anything whether it was a million, thousand or just one -- Dimensional Analysis is applicable. When you design the protocol properly, it applicable to all sizes. Thats the mark of a good IETF protocol -- it doesn't choose size and its doesn't create conflicts of interest. You and scott don't believe it is and I believe that is somewhat hypocritical of the fact that SPF has the same exact registration issue that prevented many of the larger public service domains from using the "-ALL" policy. Whatever is done, you will always need the "Data" but you need the protocol in place and by far, the most feasible way to do this, is by leaving DKIM alone and work on the policy layer. If the alternative requires DKIM changes for the same purpose and you going to nix ATPS and go with some double signature method, I think it is necessary from an IETF standpoint that you also offer the baseline solution which is the DNS call method. -- HLS From nobody Thu May 7 15:12:28 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0631B2B6A for ; Thu, 7 May 2015 15:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRuKnkdiJcgV for ; Thu, 7 May 2015 15:12:24 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1229C1AD47E for ; Thu, 7 May 2015 15:12:24 -0700 (PDT) Received: by pabtp1 with SMTP id tp1so51461231pab.2 for ; Thu, 07 May 2015 15:12:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=9PsoqQxOKmVNZMIWN/mALCyQocxYeRN4ECW4tOBG94E=; b=CvSjulhHHTWI8HS+5Fp2e7p1VOPraduhOgyhA7rjDptAnFFN3sFwXbLmoXqLixqDNX 2b1A88bvTO+AgosaY3k4VLK0Z21NUsNF4apRBrTJGaevilPW83VxZW9IiqI3j5oYMxmU SjNT51uS4yXiRLh5F+vZsnCJCB5vR75s7CV+X7ihGp4T3Psxq5z5kL0IYmfYuvkMAd5N cd+NhuMgWLn5fQfU+NYcBiEEneBouZX8D0G/oghpxOPhBUwZwVChVrQquOFm/Dd+0GVg t5dDVVM+7gv1VDg2UWltE9GPHNyXewoFR21fIK42kTZIW+tKAakeFBiEAKV/amXrNkgP 6EiQ== X-Received: by 10.66.218.193 with SMTP id pi1mr1262055pac.152.1431036743760; Thu, 07 May 2015 15:12:23 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id nn6sm3117323pdb.79.2015.05.07.15.12.18 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 May 2015 15:12:20 -0700 (PDT) Message-ID: <554BE340.4040705@gmail.com> Date: Thu, 07 May 2015 15:12:16 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554111FB.5040801@isdg.net> <87a8xqowyd.fsf@uwakimon.sk.tsukuba.ac.jp> <4046A990-2AE5-4975-AE39-B829B29E19E7@peachymango.org> <87r3qyor3n.fsf@uwakimon.sk.tsukuba.ac.jp> <1560828201.22399.1430781642344.JavaMail.zimbra@peachymango.org> <87wq0n3sq7.fsf@uwakimon.sk.tsukuba.ac.jp> <12DB7EB5-8EDE-4163-B96F-17CCCDD7A23D@kitterman.com> <87pp6e3yim.fsf@uwakimon.sk.tsukuba.ac.jp> <554A59D1.3080400@gmail.com> <554A62B8.80405@isdg.net> <554A7D85.4030600@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 22:12:27 -0000 On 5/7/15 8:29 AM, Hector Santos wrote: >> On May 6, 2015, at 4:45 PM, Douglas Otis >> wrote: >> >> Defending against DDoS is very difficult, but that was not the >> concern. Collateral damage would be of legitimate messages >> inadvertently blocked when removing a common DKIM signature. > > What do you mean by remove? You mean destroy, invalidate existing > signatures? Removing signature information from DNS prevents an associated signature to validate as a feckless means to respond to signature delegation chain abuse. > Keep in mind this MAY be desirable, in fact the DKIM STD76 theory is > that resigners can occur blindly anywhere with the mail path. You > don't have destroy the original integrity during resign, yet that > transaction may be illegal (per policy) with the fact it has been > resigned. The concern relates to "delegating" with a DKIM signature fragment, where, when valid, authorizes signatures of a third-party. Even a "short" expiry likely covers several days or delivery may become fragile. It seems any delivery period would permit a sizable phishing campaign well beyond the control of a DMARC domain. TPA-Label provides a method to react to abuse while also minimizing collateral damage to other message streams that utilized the same DNS resources for their DKIM signatures. Of course TPA-Label could impose a similar list of no-change headers as found in a DKIM signature delegation. By leveraging a DKIM process, perhaps you might see that as simpler and offering more bang for the buck. >> There is also the challenge of managing a double-signature >> re-signing process where it must be assumed not all destinations >> receive a signature delegation. Even this double signing process >> may prove problematic when it goes beyond SQL query rates. > > SQL? . Some folks are more optimized using ISAM/BTREE databases! Any interim per message special signing process is likely to encounter scaling issues especially when third-parties are handling tens of thousands of first party domains. Again, the TPA-Label approach does not introduce new signatures nor alter DKIM signature processing. It simply offers low frequency exceptions based on an asserted relationship between the From and third-party domain that can be instantly withdrawn by the From domain upon the detection of abuse. >> There is also another concern regarding any phishing campaign >> permitted by effectively signing unknown content. Only by removing >> DKIM signatures from DNS would a DMARC domain be able to squelch a >> phishing attack it inadvertently authorized. TPA-Label allows >> authorization removal to be based on the destination domain and >> even a specific list-id. TPA-Label would not impact any existing >> DKIM signing process since authorization by destination is managed >> by TPA-Label zones. > > Doug, we know a positive result of a DNS lookup will work. I > believe you wish to add more complex semantics on the parsing of > the lookup results, I believe that's ok. But we need a basic yes/no > query. Maybe it can be sold if we offer more bang for the buck on > each call but overall, it needs to be very simple. TPA-Label is simpler because it does not require third-party processes to be interspersed between each step of message handling. It involves only sender assertions and recipient exceptions. Instances requiring a reaction respond to abuse which TPA-Label can handle both promptly and with minimal collateral disruption. BTW, SPF -all was seldom used since it offered >1% false positive rates and with DMARC, it is even best considered ~all to allow DKIM a chance to rescue messages from rejection or spam folder placement. Regards, Douglas Otis From nobody Thu May 7 15:59:11 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 598991B2C21 for ; Thu, 7 May 2015 15:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5bWAUVYllt1 for ; Thu, 7 May 2015 15:59:08 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id A45511B2C20 for ; Thu, 7 May 2015 15:59:07 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id DBF391C3836; Fri, 8 May 2015 07:59:06 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id B646C11F6A1; Fri, 8 May 2015 07:59:06 +0900 (JST) From: "Stephen J. Turnbull" To: Scott Kitterman In-Reply-To: <1491152.8VqzAZlGJD@kitterma-e6430> References: <53018683.LR03mPSUiY@kitterma-e6430> <87egmt3pdp.fsf@uwakimon.sk.tsukuba.ac.jp> <1491152.8VqzAZlGJD@kitterma-e6430> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 08 May 2015 07:59:06 +0900 Message-ID: <878ud03sg5.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 22:59:10 -0000 Scott Kitterman writes: > not. At the end of the day, without the large providers on board, any > solution that requires change at both the sender and the receiver needs the > large providers on board or it's useless. Which is where I started, but then I was told mentioning names isn't allowed. From nobody Thu May 7 16:24:27 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E087B1B2C59 for ; Thu, 7 May 2015 16:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhL7a-UcI0uv for ; Thu, 7 May 2015 16:24:25 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EA8A1B2C58 for ; Thu, 7 May 2015 16:24:25 -0700 (PDT) Received: from kitterma-e6430.localnet (unknown [50.253.56.123]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 9CB9BC401B4 for ; Thu, 7 May 2015 18:24:24 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1431041064; bh=2dHCqLWjYRs/JK0D5YIyA9FkzLyEmkDWVl92nlqGB8I=; h=From:To:Subject:Date:In-Reply-To:References:From; b=SAoFdkORhp2Lr5idBz0T3gFVkXy10CrZyNf9YBt69kWALlDnC4+iImAgAJfCOGwsu pQYuB8ipVtUw06J1Vz3FAnAuDCA2OoeTiUOj+xTLQUhKyxPOtQjNzvXESDCTrmBjww ysjpUVMs1lBW1GmUSBjNfHT6DQcS/Z2c7meOdMCM= From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 07 May 2015 19:24:23 -0400 Message-ID: <1851929.Vaj3znI54n@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-51-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 23:24:27 -0000 On Thursday, May 07, 2015 02:09:09 PM Murray S. Kucherawy wrote: > On Thu, May 7, 2015 at 1:27 PM, Scott Kitterman > > wrote: > > I think it's wrong to describe that as a DMARC result. For DMARC as > > specified, that's a fail. > > More precisely, for both DKIM and DMARC it's a fail. For DKIM+ATPS-04, > it's a pass, but DMARC doesn't pay attention to that. > > I think it's also important to note that this only proves interoperability > with a single implementation (granted, in multiple roles), unless there's > data indicating multiple implementations are involved. This seems > unlikely, since as far as I know there aren't any other implementations of > ATPS-04 or even the RFC version. OpenDKIM did the RFC version, and it's > not compatible with -04. > > Also, this is only part of the whole story. There's still that pesky > registration problem to address. I think for ATPS or anything like it to > be considered a plausible thing to pursue, that's critical. It might be > interesting to know some of the characteristics of the largest operator > involved in that report (total domains, total users, details about MLM > traffic, etc.). > > -MSK No, it's OK for DKIM. The trick is d=ietf.org, which doesn't align for DMARC purposes. Scott K From nobody Thu May 7 16:30:37 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC9F1B2C60 for ; Thu, 7 May 2015 16:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.098 X-Spam-Level: *** X-Spam-Status: No, score=3.098 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Ar3aOsDMSPj for ; Thu, 7 May 2015 16:30:34 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id DBFCF1B2C5E for ; Thu, 7 May 2015 16:30:33 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 30E0E1C3848; Fri, 8 May 2015 08:30:33 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 0CFE011F6A1; Fri, 8 May 2015 08:30:33 +0900 (JST) From: "Stephen J. Turnbull" To: Hector Santos In-Reply-To: <554B5831.6030506@isdg.net> References: <20150505185543.42741.qmail@ary.lan> <87mw1i3xu7.fsf@uwakimon.sk.tsukuba.ac.jp> <53018683.LR03mPSUiY@kitterma-e6430> <87egmt3pdp.fsf@uwakimon.sk.tsukuba.ac.jp> <554B5831.6030506@isdg.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 08 May 2015 08:30:32 +0900 Message-ID: <877fsk3qzr.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 23:30:35 -0000 Hector Santos writes: > How about the MLM receiver, will it filter the fraud? Why wouldn't it? All do (at least, anybody who hopes to deliver to the large providers does). > Will it remove the restrictive domains that do not want any 3rd > party resigners? No. Such domains simply don't participate in delegation protocols. If, furthermore, they want to restrict their users from posting, they should do so. I suppose domains participating in the DMARC protocol have the information needed to detect violations by their users. MLs don't have that information. In any case, AFAICT, the p=reject domains that originate 99% of list posts covered by p=reject are not restrictive in that sense -- they do permit their users to post, and are pleased when their users' posts are distributed by mailing lists. > Will you respect and honor the exclusive, restrictive policies? If you mean rejecting when p=reject and From alignment fails at receipt, yes. If you mean guessing what the Author Domain intends on resent mail where behavior is not specified by protocol, that's up to the ML admin. I expect almost all will engage in mitigation rather than preemptively reject. Again, it's the Author Domain's responsibility to set policy for its users, and DMARC participating Author Domains do have the information needed to enforce such policy, I suppose. The ML does not. > > Implementation is hardly high cost. > > "Sez you" Sure, but I also explained what I think the required resources are. If you think that's costly, well, "YMMV" always applies to such opinions. > > Large domains can generally afford the cost of revising their > > custom MTAs. > > That doesn't mean will they alter their code especially when don't > have to address the resigner issue. t also doesn't mean they won't. But if there is no protocol for resigning, we can be sure they won't. Steve From nobody Thu May 7 16:42:12 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4CC1B2B22 for ; Thu, 7 May 2015 16:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_54=0.6, J_CHICKENPOX_61=0.6, J_CHICKENPOX_64=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGD26XyRezxf for ; Thu, 7 May 2015 16:42:10 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D88EC1B2B21 for ; Thu, 7 May 2015 16:42:09 -0700 (PDT) Received: from kitterma-e6430.localnet (unknown [50.253.56.123]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 24B88C401B4 for ; Thu, 7 May 2015 18:42:09 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1431042129; bh=Q2ob/X6Kugr6c2B9iHAwT1NTlNda5k3FzmUbeFwWB1k=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Crnh1el+NTmtPoRr0YVLEDE0f16tOChNeTTrpIHiw59WQTKt3X/K6OqF6KcquyETN 3mBW1q7qiE7aoOSegtP1P5pXAcw1yysaZLmLQ4hKDytbQSlfk4jrVF8cQjuufPz1Kr kYy/KbFTSLZXsnx8vvNuxD9Rs7hoFeKzqw/wUDEU= From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 07 May 2015 19:42:08 -0400 Message-ID: <2300683.kWHLFagZsJ@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-51-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <554BE12A.7010606@isdg.net> References: <554BC30F.1020107@isdg.net> <554BE12A.7010606@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 23:42:11 -0000 On Thursday, May 07, 2015 06:03:22 PM Hector Santos wrote: > On 5/7/2015 5:09 PM, Murray S. Kucherawy wrote: > > On Thu, May 7, 2015 at 1:27 PM, Scott Kitterman > > > > wrote: > > I think it's wrong to describe that as a DMARC result. For DMARC > > as specified, that's a fail. > > > > More precisely, for both DKIM and DMARC it's a fail. For > > DKIM+ATPS-04, it's a pass, but DMARC doesn't pay attention to that. > > Now we are getting into definition and software engineering. > > DMARC result is a PASS when it is an extension, and in this case, it > is an extension, and it is noted as an extension: > > dmarc=pass policy=none author.d=isdg.net signer.d=ietf.org (atps > signer); > > In other words, does the AUTH-RES protocol allow it itself to be > extended, it is flexible enough? If not, then AUTH-RES will need to > be updated again. A-R is certainly extensible, but there are IANA registries that need to be updated. RFC 7489 defines DMARC. In fact, if you look at the registry [1], it points to RFC 7489 for the definition of how to use A-R for DMARC. If you are doing something different than that, you're doing it wrong. Call it something else and a comment isn't sufficient. An A-R header field should be able to be automatically processed without reading the comments. Neither author.d nor signer.d are not defined. Given the use of unknown properties with a known method, I think any implementation might reasonably ignore this entire result. I think this should be registered (if it merits continued development and deployment) as its own method. Then you might have something like: dmarc-atps=pass header.from=isdg.net signer.d=ietf.org dmarc=fail header.from=isdg.net Consumers can then decide if they care about dmarc-atps without having to interpret a new authentication method's results if they don't. Scott K [1] http://www.iana.org/assignments/email-auth/email-auth.xhtml From nobody Thu May 7 16:46:25 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460AC1B2C9F for ; Thu, 7 May 2015 16:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKNjHF3bZYgR for ; Thu, 7 May 2015 16:46:23 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0BB81B2C9C for ; Thu, 7 May 2015 16:46:22 -0700 (PDT) Received: from kitterma-e6430.localnet (unknown [50.253.56.123]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 0404FC401B4 for ; Thu, 7 May 2015 18:46:22 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1431042382; bh=fKjYJXFZuCGuJ4Ik25jdFeEdCT/XcCqLuMZCmomHmK8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=diAB46dxsYIE5fKUuY10sLLVkBoFHjEZBmqDAVc3qY1FmHSklcvYUvXAnmAb3PnK5 3H2lcXGX8M8FffQpfg52qcC1p3GXpZkxrQ3bpTsqlvwKNQojl8SJ0op6orj7vxeKTD GVXNHLEEBcSNVxbuEUDRo0TTOWyXtSpi10/+wy5Q= From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 07 May 2015 19:46:21 -0400 Message-ID: <1648138.ScybQyod4h@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-51-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <554BD0B3.7020208@isdg.net> References: <554BC30F.1020107@isdg.net> <554BCCE3.5000002@isdg.net> <554BD0B3.7020208@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 23:46:24 -0000 On Thursday, May 07, 2015 04:53:07 PM Hector Santos wrote: > Scott, > > If this is what you are talking about, there should of been an > AUTH-RES line for "atps=", I can understand that valid technical > point, but I don't agree it is absolute. > > First, it is a DMARC extension and long as it is an indicated marker > in the DMARC result, then should be ok. > > Second, related, one of the problems with AUTH-RES and the reason > there is so many changes to it, is because its doesn't quite satisfy > what an receiver might need. I had that problem with just adding ADSP > to it. It didn't even support getting SPF fully reported. > > In other words, the dynamics are still changes in order to get a solid > AUTH-RES reporting header completed. In fact, if your point is taken > serious, then AUTH-RES will need even more updates to support other > results, such as the double signature proposal. > > So this is a side issue that really has nothing to do with the overall > basic protocol issue we are dealing with, but it is a good note to > point out because you will run into the same "separation" issue with > any other additional layer you want to add on top of DKIM and into the > AUTH-RES header. > > Thanks for the note. ATPS is assigned in the registry {1] as dkim-atps. Scott K [1] http://www.iana.org/assignments/email-auth/email-auth.xhtml From nobody Thu May 7 17:16:18 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257111B2D08 for ; Thu, 7 May 2015 17:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.597 X-Spam-Level: X-Spam-Status: No, score=0.597 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLPhMmjtnOBm for ; Thu, 7 May 2015 17:16:15 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (mail-sn2ln0089.outbound.o365filtering.com [IPv6:2a01:111:f400:7c04::89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EB2E1B2D02 for ; Thu, 7 May 2015 17:16:15 -0700 (PDT) Received: from BY2SR01MB608.namsdf01.sdf.exchangelabs.com (10.255.93.167) by BY2SR01MB609.namsdf01.sdf.exchangelabs.com (10.255.93.168) with Microsoft SMTP Server (TLS) id 15.1.166.2; Fri, 8 May 2015 00:15:57 +0000 Received: from BY2SR01MB608.namsdf01.sdf.exchangelabs.com ([169.254.12.98]) by BY2SR01MB608.namsdf01.sdf.exchangelabs.com ([169.254.12.98]) with mapi id 15.01.0166.000; Fri, 8 May 2015 00:15:57 +0000 From: Terry Zink To: Scott Kitterman , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support Thread-Index: AQHQhsD8kdcEJDtqk02Sy7xJtSnjGJ1tkB0AgAAJoYCAAAnHgIAAAkQAgAAHtwCAAA8qgIAA5cgAgAAvlICAATSlAIAAY2kAgADO5kA= Date: Fri, 8 May 2015 00:15:55 +0000 Message-ID: References: <53018683.LR03mPSUiY@kitterma-e6430> <87egmt3pdp.fsf@uwakimon.sk.tsukuba.ac.jp> <1491152.8VqzAZlGJD@kitterma-e6430> In-Reply-To: <1491152.8VqzAZlGJD@kitterma-e6430> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::3] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2SR01MB609; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(51704005)(68736005)(54356999)(50986999)(76176999)(106116001)(19580395003)(102836002)(106356001)(46102003)(2501003)(101416001)(64706001)(33656002)(105586002)(81156007)(86362001)(5001960100002)(87936001)(2656002)(93886004)(5001830100001)(5001860100001)(97736004)(4001540100001)(5001770100001)(107886002)(2950100001)(2900100001)(62966003)(77156002)(92566002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2SR01MB609; H:BY2SR01MB608.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5002009)(5005002)(3002001); SRVR:BY2SR01MB609; BCL:0; PCL:0; RULEID:; SRVR:BY2SR01MB609; x-forefront-prvs: 0570F1F193 received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2015 00:15:56.0392 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2SR01MB609 Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 00:16:17 -0000 > Roughly 80% of those reports are from Google, Yahoo!, and Microsoft. > > Is 20% success sufficient for me to switch to p=3Dreject? I guarantee yo= u it is=20 > not. At the end of the day, without the large providers on board, any=20 > solution that requires change at both the sender and the receiver needs t= he=20 > large providers on board or it's useless. And from Murray: > There's still that pesky registration problem to address. Checking DNS for third party authorization may be workaround for this probl= em at a large provider (Microsoft) but publishing them on behalf of Microso= ft would be a tough (probably impossible) sell. If I own my own domain, I c= an keep track of mailing lists for a few dozen users. But something like ou= tlook.com has millions of years. The registration problem means that either= we have to review hundreds or thousands of additions per day (or a bootstr= ap of tens of thousands) or automate it. But if we automate it, that has it= s own problems: - What's the threat model? How do we prevent malicious sign ups? - The outlook.com sign-up is self-serve; this means that anyone can sign-up= for outlook.com and create their own mailing lists and subscribe to it, an= d then outlook.com would need to automatically add that to its DNS zone. In= other words, a complete outsider can register something in the zone that i= s maintained by Microsoft. This can be abused (a spammer could blow up the = zone by doing this tens or millions of times per day using a botnet). - When do we remove things from DNS? That's a big risk. I can't speak for the company, but I think we'd rather l= ive with the DMARC p=3Dreject inconvenience than allow a regular user to pu= blish anything to its DNS zone. -- Terry From nobody Thu May 7 17:17:28 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753C01A8987 for ; Thu, 7 May 2015 17:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2x_4T4eWZBh for ; Thu, 7 May 2015 17:17:26 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 308591A1BBD for ; Thu, 7 May 2015 17:17:26 -0700 (PDT) Received: from BY2SR01MB608.namsdf01.sdf.exchangelabs.com (10.255.93.167) by BY2SR01MB609.namsdf01.sdf.exchangelabs.com (10.255.93.168) with Microsoft SMTP Server (TLS) id 15.1.166.2; Fri, 8 May 2015 00:17:22 +0000 Received: from BY2SR01MB608.namsdf01.sdf.exchangelabs.com ([169.254.12.98]) by BY2SR01MB608.namsdf01.sdf.exchangelabs.com ([169.254.12.98]) with mapi id 15.01.0166.000; Fri, 8 May 2015 00:17:22 +0000 From: Terry Zink To: Terry Zink , Scott Kitterman , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support Thread-Index: AQHQhsD8kdcEJDtqk02Sy7xJtSnjGJ1tkB0AgAAJoYCAAAnHgIAAAkQAgAAHtwCAAA8qgIAA5cgAgAAvlICAATSlAIAAY2kAgADO5kCAAAIhQA== Date: Fri, 8 May 2015 00:17:21 +0000 Message-ID: References: <53018683.LR03mPSUiY@kitterma-e6430> <87egmt3pdp.fsf@uwakimon.sk.tsukuba.ac.jp> <1491152.8VqzAZlGJD@kitterma-e6430> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::3] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2SR01MB609; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(189002)(13464003)(51704005)(68736005)(54356999)(50986999)(76176999)(106116001)(19580395003)(19580405001)(15975445007)(102836002)(106356001)(46102003)(1511001)(2501003)(101416001)(64706001)(33656002)(105586002)(81156007)(86362001)(5001960100002)(87936001)(2656002)(93886004)(5001830100001)(5001860100001)(97736004)(4001540100001)(5001770100001)(107886002)(2950100001)(2900100001)(62966003)(77156002)(92566002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2SR01MB609; H:BY2SR01MB608.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5002009)(5005002)(3002001); SRVR:BY2SR01MB609; BCL:0; PCL:0; RULEID:; SRVR:BY2SR01MB609; x-forefront-prvs: 0570F1F193 received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2015 00:17:21.4960 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2SR01MB609 Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 00:17:27 -0000 > has millions of years Er, millions of users. -- Terry -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Terry Zink Sent: Thursday, May 7, 2015 5:16 PM To: Scott Kitterman; dmarc@ietf.org Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support > Roughly 80% of those reports are from Google, Yahoo!, and Microsoft. > > Is 20% success sufficient for me to switch to p=3Dreject? I guarantee yo= u it is=20 > not. At the end of the day, without the large providers on board, any=20 > solution that requires change at both the sender and the receiver needs t= he=20 > large providers on board or it's useless. And from Murray: > There's still that pesky registration problem to address. Checking DNS for third party authorization may be workaround for this probl= em at a large provider (Microsoft) but publishing them on behalf of Microso= ft would be a tough (probably impossible) sell. If I own my own domain, I c= an keep track of mailing lists for a few dozen users. But something like ou= tlook.com has millions of years. The registration problem means that either= we have to review hundreds or thousands of additions per day (or a bootstr= ap of tens of thousands) or automate it. But if we automate it, that has it= s own problems: - What's the threat model? How do we prevent malicious sign ups? - The outlook.com sign-up is self-serve; this means that anyone can sign-up= for outlook.com and create their own mailing lists and subscribe to it, an= d then outlook.com would need to automatically add that to its DNS zone. In= other words, a complete outsider can register something in the zone that i= s maintained by Microsoft. This can be abused (a spammer could blow up the = zone by doing this tens or millions of times per day using a botnet). - When do we remove things from DNS? That's a big risk. I can't speak for the company, but I think we'd rather l= ive with the DMARC p=3Dreject inconvenience than allow a regular user to pu= blish anything to its DNS zone. -- Terry _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Thu May 7 18:48:41 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05EBE1A1A15 for ; Thu, 7 May 2015 18:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.801 X-Spam-Level: X-Spam-Status: No, score=-100.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_54=0.6, J_CHICKENPOX_61=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3_ZIxHDpFe_J for ; Thu, 7 May 2015 18:48:38 -0700 (PDT) Received: from ntbbs.santronics.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 920A01A1A06 for ; Thu, 7 May 2015 18:48:38 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3404; t=1431049712; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=IwiHI6jSxmRyqf+bX7aqJ1Wwx8s=; b=dqQCvXHtw/lpUVEFCPwW qgj0ojV1jLUMlvqNf1vJvncPjmLH8Oplvd7AB6pS3SOL9YoafPIFn/d1kYFcKWMS 3XapI6Av0C8DgpV0Cm0fMIOuh+0kknkHmYxV4A2AFYEqrkxbI/LEBwFi2MMsj/8U Rb8k1tJ7etCyidz1SOibAJA= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 07 May 2015 21:48:32 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 464736630.4841.5968; Thu, 07 May 2015 21:48:31 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3404; t=1431049436; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=h9NsXih t72fBv4akuQ3gNDNitpzAumbpfmqcj01rEQ0=; b=OkUL4VcrVs+FcGWtolOFLXU z78uRrzLpHzclI5ZORCwBI1PhxiaJevqcPckn6f7chSd1YzJZyQphmZ8pUMADKCh M/2mMxvCj/mBte7qX8/j1yFXm94Co7sg/soKhL42GFckXDWOPZF6rRy7eEXDYp7V nj1BvTU8OVereqcp5wU0= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 07 May 2015 21:43:56 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3351971895.9.13000; Thu, 07 May 2015 21:43:55 -0400 Message-ID: <554C15EE.3050707@isdg.net> Date: Thu, 07 May 2015 21:48:30 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554BC30F.1020107@isdg.net> <554BE12A.7010606@isdg.net> <2300683.kWHLFagZsJ@kitterma-e6430> In-Reply-To: <2300683.kWHLFagZsJ@kitterma-e6430> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 01:48:41 -0000 On 5/7/2015 7:42 PM, Scott Kitterman wrote: >> In other words, does the AUTH-RES protocol allow it itself to be >> extended, it is flexible enough? If not, then AUTH-RES will need to >> be updated again. > > A-R is certainly extensible, but there are IANA registries that need to be > updated. Its not extendable (meaning its optional as well) if you can not use the same namespace. Think flexible I/O functional interfacing with null/default parameters. You want to use the same I/O otherwise more updates are required. > RFC 7489 defines DMARC. True, just consider per DMARC (RFC7489) section 3.1.3 3.1.3. Alignment and Extension Technologies If in the future DMARC is extended to include the use of other authentication mechanisms, the extensions will need to allow for domain identifier extraction so that alignment with the RFC5322.From domain can be verified. This means that AUTH-RES semantics requires to be functionally compatible (extendable) as well from an integration standpoint. >In fact, if you look at the registry [1], it points to > RFC 7489 for the definition of how to use A-R for DMARC. If you are doing > something different than that, you're doing it wrong. First, the work predated DMARC and second, Murray was made aware AUTH-RES was not flexible enough for DKIM+ADSP+ATPS as it wasn't for SPF. It may be today. I haven't checked. > Call it something else and a comment isn't sufficient. So why was it acceptable by you for SPF? > An A-R header field should be able to be automatically processed > without reading the comments. I agree, but software is smart it can do a "(atps signer)" string check, just like you accepted the "(comment) kludge to complete SPF AUTH-RES reporting as well. > Neither author.d nor signer.d are not defined. Given the use of unknown > properties with a known method, I think any implementation might reasonably > ignore this entire result. AUTH-RES is constantly being updated and IMO prematurely registers stuff because it actually is a real standard in practice. But this is all besides the point. You are going off on an tangent that has nothing to do with this. Plus, it wasn't defined so you do what you need. It SHOULD NOT break any current Auth-Res reader. Lets also note the AUTH-RES is for internal consumption and actually more for reporting because odds are good they are internal ways to do the handling anyway. Lets not not assume it will all be done by reading AUTH-RES, i.e. SMTP level rejection at DATA. > I think this should be registered (if it merits continued development and > deployment) as its own method. Then you might have something like: > > dmarc-atps=pass header.from=isdg.net signer.d=ietf.org > dmarc=fail header.from=isdg.net > > Consumers can then decide if they care about dmarc-atps without having to > interpret a new authentication method's results if they don't. > Those are details. I agree we want to a consensus on a common nomenclature, but its all besides the point. I did not want to make this issue about Auth-Res, but if you ask me, from a plug and play standpoint, if you have an DMARC handling reading Auth-Res as it written with a "dmarc=" namespace, I would not propose a new "dmarc-atps" namespace. Its an extension of DMARC therefore it belongs in the same "dmarc=" namespace. -- HLS From nobody Thu May 7 18:51:50 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AADDD1A1AAE for ; Thu, 7 May 2015 18:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.137 X-Spam-Level: X-Spam-Status: No, score=-101.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YRoj20v4S_Ip for ; Thu, 7 May 2015 18:51:49 -0700 (PDT) Received: from ntbbs.santronics.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 548641A1AA0 for ; Thu, 7 May 2015 18:51:48 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=303; t=1431049902; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=of4RXtUF4t60KCJk8xe/BlnjQKc=; b=iKKpdlBxB7NskR4ljSRm TnhJ50d0+R5nbMBSovX/9rVxHXU2rVMDUco7fb8QHeWDL2uY3PoDUq4H2eqDTh6d C/Xrm1cpEGVc0LGE504tK6874ZBBIaH6PkbJN/g/z2jsPwQvzYwiGXy1S3NlAxv0 tv/V2IJlvBg2/Zjsb7fRFv0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 07 May 2015 21:51:42 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 464926639.4841.2276; Thu, 07 May 2015 21:51:41 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=303; t=1431049629; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=JFkqmFx /iFyNQsTHqFNwdweEXQwiXi7cDSEnhzDvr7k=; b=2kkrLYhTRjX5aX9RWwUuGEz SO2RpIdODdsz6D6bP50pahDp0N6Foz1qW6gL08Vlsx3xd7nS+fR4xIaMHhNZ/mdO Bz+kXmkCDRh0yshb1yh43RgJoV8MxhKwrb1uwLoOEo9zviGghsigeXYclbc3VvlX 1ukFTbuaGwQxVdRlck80= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 07 May 2015 21:47:09 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3352164770.9.14056; Thu, 07 May 2015 21:47:08 -0400 Message-ID: <554C16AF.7000907@isdg.net> Date: Thu, 07 May 2015 21:51:43 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554BC30F.1020107@isdg.net> <554BCCE3.5000002@isdg.net> <554BD0B3.7020208@isdg.net> <1648138.ScybQyod4h@kitterma-e6430> In-Reply-To: <1648138.ScybQyod4h@kitterma-e6430> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 01:51:49 -0000 On 5/7/2015 7:46 PM, Scott Kitterman wrote: > > ATPS is assigned in the registry {1] as dkim-atps. As stated already, the work predated what Murray did after ATPS rev04. But its good to know that is this is the case and this is yet another good reason to continue with ATPS work. -- HLS From nobody Thu May 7 20:05:28 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF88F1A88EC for ; Thu, 7 May 2015 20:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03vpj8_6rafe for ; Thu, 7 May 2015 20:05:26 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61B711A88A4 for ; Thu, 7 May 2015 20:05:26 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 15217C4016C for ; Thu, 7 May 2015 22:05:25 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1431054325; bh=xUUExey31A5bJ5HN5nlvZCaAvX8ci8DHIp0WSgwduWE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=VS5D+7+By0aaguuIZW/6u+sMsRZkMHVsZ65Ba3iGOjZ+7EMyl1ieZgX/fv2eT+0zS YVa/xi83/X8E4P5TnsM/pZfDl0N/R3HAy7KP5sFl16k2DLRDxqcL+eeVgIlLgIgo0j v7/yXToqYM0+g3g12SiH8wOyrTaftvJQrDH0nXno= From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 07 May 2015 23:05:24 -0400 Message-ID: <2078066.0F7ZvcXkhm@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-51-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <554C16AF.7000907@isdg.net> References: <554BC30F.1020107@isdg.net> <1648138.ScybQyod4h@kitterma-e6430> <554C16AF.7000907@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 03:05:27 -0000 On Thursday, May 07, 2015 09:51:43 PM Hector Santos wrote: > On 5/7/2015 7:46 PM, Scott Kitterman wrote: > > ATPS is assigned in the registry {1] as dkim-atps. > > As stated already, the work predated what Murray did after ATPS rev04. > > But its good to know that is this is the case and this is yet another > good reason to continue with ATPS work. I'm really not sure what you're talking about (and equally not sure I need to), but in version -00 of the ATPS draft it already had: Method dkim-atps Defined In [THIS MEMO] ptype header property from If you want to document a ATPS result in an A-R header, there's a way to do it and that's how it should be done. Scott K From nobody Thu May 7 20:18:31 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88AE31ACD6B for ; Thu, 7 May 2015 20:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_54=0.6, J_CHICKENPOX_61=0.6, J_CHICKENPOX_64=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3X709M5rlGYm for ; Thu, 7 May 2015 20:18:28 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F8FA1A8958 for ; Thu, 7 May 2015 20:18:28 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 12980C4016C for ; Thu, 7 May 2015 22:18:27 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1431055107; bh=oLclP+FbqfL+HA6oUGlDl6tMMYYCrQ+noBvYrKpqWAg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=qc/g9lV6JZ1KRLzP6cPbZxfj1z3VOBvSdOfeBJsph/ndGvq0+G6CCgq5uQYdI3Wob WrnXBDIz4cP8ysUvLmingZlxNjl7x+Go/vGRlkl1o1ctYiKmT/iwUW5vYYeHPd86fq E1LI2ZKiMubWlMr6bhGEEApfD6RLsdCo3ttq3stc= From: Scott Kitterman To: dmarc@ietf.org Date: Thu, 07 May 2015 23:18:26 -0400 Message-ID: <3429228.BpIaqHtTm2@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-51-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <554C15EE.3050707@isdg.net> References: <554BC30F.1020107@isdg.net> <2300683.kWHLFagZsJ@kitterma-e6430> <554C15EE.3050707@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 03:18:29 -0000 On Thursday, May 07, 2015 09:48:30 PM Hector Santos wrote: > On 5/7/2015 7:42 PM, Scott Kitterman wrote: > >> In other words, does the AUTH-RES protocol allow it itself to be > >> extended, it is flexible enough? If not, then AUTH-RES will need to > >> be updated again. > > > > A-R is certainly extensible, but there are IANA registries that need to be > > updated. > > Its not extendable (meaning its optional as well) if you can not use > the same namespace. Think flexible I/O functional interfacing with > null/default parameters. You > want to use the same I/O otherwise more updates are required. All that goes in the DMARC part is the deader.from and the result. It doesn't need to be extended to add a new auth method. > > RFC 7489 defines DMARC. > > True, just consider per DMARC (RFC7489) section 3.1.3 > > 3.1.3. Alignment and Extension Technologies > > If in the future DMARC is extended to include the use of other > authentication mechanisms, the extensions will need to allow for > domain identifier extraction so that alignment with the RFC5322.From > domain can be verified. > > This means that AUTH-RES semantics requires to be functionally > compatible (extendable) as well from an integration standpoint. And it is. You put the new information in a phrase of the header field dedicated to the new method. It only changes the result for DMARC once DMARC has been extended to include it, which it hasn't been yet for ATPS or any other method. > >In fact, if you look at the registry [1], it points to > > > > RFC 7489 for the definition of how to use A-R for DMARC. If you are doing > > something different than that, you're doing it wrong. > > First, the work predated DMARC and second, Murray was made aware > AUTH-RES was not flexible enough for DKIM+ADSP+ATPS as it wasn't for > SPF. It may be today. I haven't checked. For SPF, it's adequate to communicate the result. It's not adequate to allow someone to independently reconstruct and assess the validity of that result, so it's less useful as a trace header field than Recieved-SPF, but given it's goals, it meets them. > > Call it something else and a comment isn't sufficient. > > So why was it acceptable by you for SPF? You get an identity and a result which is all that's absolutely needed to machine parse the SPF answer. As above, it's adequate even if not, from my PoV ideal. > > An A-R header field should be able to be automatically processed > > without reading the comments. > > I agree, but software is smart it can do a "(atps signer)" string > check, just like you accepted the "(comment) kludge to complete SPF > AUTH-RES reporting as well. No. If you make any assumptions about the contents of a comment field, that's a poor design. You can, but you shouldn't. > > Neither author.d nor signer.d are not defined. Given the use of unknown > > properties with a known method, I think any implementation might > > reasonably > > ignore this entire result. > > AUTH-RES is constantly being updated and IMO prematurely registers > stuff because it actually is a real standard in practice. But this is > all besides the point. You are going off on an tangent that has > nothing to do with this. Plus, it wasn't defined so you do what you > need. It SHOULD NOT break any current Auth-Res reader. Lets also > note the AUTH-RES is for internal consumption and actually more for > reporting because odds are good they are internal ways to do the > handling anyway. Lets not not assume it will all be done by reading > AUTH-RES, i.e. SMTP level rejection at DATA. It's true that A-R was designed for consumption inside an ADMD. It doesn't necessarily follow that all software within that ADMD is provided by a single vendor. A-R is standardized to make that internal communication easer. I think your point about internal consumption is true, but not particularly relevant. Also, people have proposed extending the structure to carry authentication information from a trusted mediator to a receiver which is at most only sort of internal to an ADMD. As long as in your experimentation you don't interfere with what's already standardized (and IMO your example did), then I'm fine with it. > > I think this should be registered (if it merits continued development and > > deployment) as its own method. Then you might have something like: > > > > dmarc-atps=pass header.from=isdg.net signer.d=ietf.org > > dmarc=fail header.from=isdg.net > > > > Consumers can then decide if they care about dmarc-atps without having to > > interpret a new authentication method's results if they don't. > > Those are details. I agree we want to a consensus on a common > nomenclature, but its all besides the point. > > I did not want to make this issue about Auth-Res, but if you ask me, > from a plug and play standpoint, if you have an DMARC handling reading > Auth-Res as it written with a > "dmarc=" namespace, I would not propose a new "dmarc-atps" namespace. > Its an extension of DMARC therefore it belongs in the same "dmarc=" > namespace. As above, no. It's an auth method that DMARC uses, not a internal part of DMARC (SPF and DKIM results are not reported inside a DMARC= namespace and this is no different). Scott K From nobody Thu May 7 21:03:32 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC901A1BE0 for ; Thu, 7 May 2015 21:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1b9H4y9Phgop for ; Thu, 7 May 2015 21:03:29 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B681F1A1BCF for ; Thu, 7 May 2015 21:03:29 -0700 (PDT) Received: by pdbnk13 with SMTP id nk13so61424324pdb.0 for ; Thu, 07 May 2015 21:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=z537BLac18FL2qGYw+mIub7RgO3ly+yFywkDjbruPiM=; b=0t/WVDq5RVFTNGbLMbzN+c0h/KpntrfTsGuqjjJc+lwHER6ESMAvfIUv6eTeL9zAge 7DPSrwpIvXcjr0gLe22AbHj6L+HM2bft4PevO47QQxNGmM1uQUDZ7t07UE+cIqNnVO42 r0zzBnw/ie+22XS27Xcgh8Ydg6irsVwFO5Jopal+XRy5HxCijuzPaicLCLnfLLcFRai6 dMyZiYoNe9gAnHsXwAXXmEgTKN0bDvVOCzrmKtJE5/ZL4hqHX4q8cVsVYo2qbSZ8uHt2 bFjaaiJAS+yOFPry21Nj+/BUr+MHf6tJSHA2n75S5iRYZFs+s+EX5r/aaL9TYBBvHidg XxGQ== X-Received: by 10.70.100.230 with SMTP id fb6mr3173225pdb.29.1431057801721; Thu, 07 May 2015 21:03:21 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id bn7sm3600122pac.22.2015.05.07.21.03.19 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 May 2015 21:03:20 -0700 (PDT) Message-ID: <554C3584.90607@gmail.com> Date: Thu, 07 May 2015 21:03:16 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <53018683.LR03mPSUiY@kitterma-e6430> <87egmt3pdp.fsf@uwakimon.sk.tsukuba.ac.jp> <1491152.8VqzAZlGJD@kitterma-e6430> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] OpenDKIM ADSP, DMARC and ATPS support X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 04:03:31 -0000 On 5/7/15 5:15 PM, Terry Zink wrote: >> Roughly 80% of those reports are from Google, Yahoo!, and Microsoft. >> >> Is 20% success sufficient for me to switch to p=reject? I guarantee you it is >> not. At the end of the day, without the large providers on board, any >> solution that requires change at both the sender and the receiver needs the >> large providers on board or it's useless. > And from Murray: > >> There's still that pesky registration problem to address. > Checking DNS for third party authorization may be workaround for this problem at a large provider (Microsoft) but publishing them on behalf of Microsoft would be a tough (probably impossible) sell. If I own my own domain, I can keep track of mailing lists for a few dozen users. But something like outlook.com has millions of [users]. The registration problem means that either we have to review hundreds or thousands of additions per day (or a bootstrap of tens of thousands) or automate it. But if we automate it, that has its own problems: > > - What's the threat model? How do we prevent malicious sign ups? > - The outlook.com sign-up is self-serve; this means that anyone can sign-up for outlook.com and create their own mailing lists and subscribe to it, and then outlook.com would need to automatically add that to its DNS zone. In other words, a complete outsider can register something in the zone that is maintained by Microsoft. This can be abused (a spammer could blow up the zone by doing this tens or millions of times per day using a botnet). > - When do we remove things from DNS? > > That's a big risk. I can't speak for the company, but I think we'd rather live with the DMARC p=reject inconvenience than allow a regular user to publish anything to its DNS zone. Dear Terry, Many third-party services now munge who authored a message to sidestep inappropriate DMARC restrictive policies. When a DMARC domain can't conclude which third-party services employed by their users aren't causing any phishing threats when they have the benefit of DMARC feedback, outgoing logs, and a sizable spam trap infrastructure, their lack of effort creates a dangerous situation. DMARC now means people have less ability to communicate effectively using third-party services. Some receiving ESPs mitigate some of their complaints by changing "reject" to "quarantine". Looking into a spam folder is likely to reveal rather nasty malware looking like messages unfairly rejected due to inappropriate DMARC assertions. There are some choices that should help make the situation better. 1) define reasonable fallback profiles for ESPs who miss-apply restrictive DMARC policy to permit acceptance based on a validated Sender header field clearly shown to users. 2) define a replacement From header field. The example I gave included a field to track current resources when conveyed over a channel that normally handles IM as well as having a group friendly display to play the role of Subject Tag. 3) We have had experience providing almost exactly what would be needed to support a TPA-Label lists. We tracked behaviors of all known mailing-lists, differentiated those from bulk senders, news feeds on behalf of friends, etc. While you may have millions of users, the number of third-party services in use is much much less. I am convinced doing a good job at simply applying the information known by the DMARC domain would allow all headers to be safely used by email while at the same time making mail safer. If you are interested, perhaps we could get together to demonstrate how the feedback can be automated and managed. Doing this while at the same time guarding access to user accounts should attract happy and even paying customers. I am not a fan of ATPS. IMHO nothing justifies a special DKIM signature, changes to Authentication headers or optional hashes for labels. How in the heck would a third-party keep track of which hash is needed? The reasons claimed for using special DKIM signatures can be replaced by simple DMARC assertions to indicate which conventions are adopted. There would not be any increased DDoS risk nor a need to have everyone change how DKIM is used. But of course, people want to leave their 'd' mark:^) Regards, Douglas Otis From nobody Thu May 7 21:05:44 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80B81A1EFE for ; Thu, 7 May 2015 21:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y_Uwwbn9h3fW for ; Thu, 7 May 2015 21:05:41 -0700 (PDT) Received: from ntbbs.santronics.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id CEEC31A1EF1 for ; Thu, 7 May 2015 21:05:40 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1674; t=1431057932; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=IBpl7Y2e28VkDtX+Q2Rltwv/b4U=; b=opeMnka3WpbgI1kGCBsi S5Od75X4L//DoqEFfE2jkTg5gC7VRXOkdFNdZUGecsrNflc04dDlqhjHk9UMQ6+7 jMr0upwQ0KIXgIHr2Im4YEqXoORkahVusu3JPPbWCX4yo16Da5kRu88UNN7JC0Oy XuzIQxcWV21sjFnJVMKrqvM= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 08 May 2015 00:05:32 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 472956884.4841.4268; Fri, 08 May 2015 00:05:31 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1674; t=1431057657; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=wd0zna/ alMm2T6+DgKhszMq8UHjfYJGaNFVB/c8FQ9g=; b=dK42vxkUmWoqM6ZOghSq2hG r1yaal6bfqfd1fXdLq9OR4JSBM//u1+hrfhXPFoYc4PXZ2o01rvZBKF83hOV08Zo Es/kqVWIHmryr+utT6TPrPI8A3llWwvs2ozjMRX+RPnDhdiIiXCrtLsKdChArh6L Ep5z3SReS1POkMZ/puss= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 08 May 2015 00:00:57 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3360193879.9.12516; Fri, 08 May 2015 00:00:57 -0400 Message-ID: <554C360C.9030702@isdg.net> Date: Fri, 08 May 2015 00:05:32 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554BC30F.1020107@isdg.net> <1648138.ScybQyod4h@kitterma-e6430> <554C16AF.7000907@isdg.net> <2078066.0F7ZvcXkhm@kitterma-e6430> In-Reply-To: <2078066.0F7ZvcXkhm@kitterma-e6430> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 04:05:44 -0000 On 5/7/2015 11:05 PM, Scott Kitterman wrote: > On Thursday, May 07, 2015 09:51:43 PM Hector Santos wrote: >> On 5/7/2015 7:46 PM, Scott Kitterman wrote: >>> ATPS is assigned in the registry {1] as dkim-atps. >> >> As stated already, the work predated what Murray did after ATPS rev04. >> >> But its good to know that is this is the case and this is yet another >> good reason to continue with ATPS work. > > I'm really not sure what you're talking about (and equally not sure I need > to), but in version -00 of the ATPS draft it already had: > > Method dkim-atps > Defined In [THIS MEMO] > ptype header > property from > > If you want to document a ATPS result in an A-R header, there's a way to do it > and that's how it should be done. Thanks for the "bug" report. I should of stated it predated all of the ATPS work. Before ATPS, there was Doug's TPA and my ASL (Allowed Signer List) which came from the DSAP 2006 I-D. ATPS is a simpler version of TPA, uses the similar base32(sha1()) hashing function logic for the sub-domain signer domain label. ASL is a ADSP "asl=resigner-list" tag for the smaller scale that can fit into a single UDP byte limit. I should note this was all done when RFC5451 AUTH-RES was written. Only DKIM and SPF recorded by this moving target specification. I only recorded DKIM since SPF already had Received-SPF and DKIM was still working on ADSP. AUTH-RES and I meant RFC5451, was still incomplete and still a moving target. It was noted (a post/comment) that it didn't cover the needs required. It was all experimental and still early exploration. In any case, thanks for the bug report. -- HLS From nobody Thu May 7 23:08:16 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450F61AC405 for ; Thu, 7 May 2015 23:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qq4dckQCN7lK for ; Thu, 7 May 2015 23:08:13 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3AC1AC3E7 for ; Thu, 7 May 2015 23:08:13 -0700 (PDT) Received: by wizk4 with SMTP id k4so17077033wiz.1 for ; Thu, 07 May 2015 23:08:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1HqB5yOJAl6R62Qi7Em1jsD+TOotl23Uq0ZDB/7I+KA=; b=hi4y6aagJUXTt+4sChbYumJkZ+ITZWwQf3ROnWO/2X2nmDuROajXmcpQZ7VteWkdNh EaYd38WGAtHxJJu7oRdztz7u2tJIMYYPVFlTIIiBX0UnpwpvU3FZO3hy3Ov5P+bD3neY DM9YHIiAy2iNoF+heBDzAhYEX8qEAqL9pxTxaw9SEWuLWsgB8rrPqVheWiZFb7dowREQ Cnmaed7yETij+FE/zbDQWwxEdTXB+7iG2SLsVsHWOc1UFH6TOugWmjhuOlKIUuwpugvC TWpyAPOkvy7Sk0Pi1KKkBubO1uE3Iqi37NH2VHuzqniZpQdBRhMPXZhqgHyfcTBFag3H 7mLw== MIME-Version: 1.0 X-Received: by 10.180.83.195 with SMTP id s3mr3229311wiy.52.1431065292133; Thu, 07 May 2015 23:08:12 -0700 (PDT) Received: by 10.27.170.75 with HTTP; Thu, 7 May 2015 23:08:12 -0700 (PDT) In-Reply-To: <1851929.Vaj3znI54n@kitterma-e6430> References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <1851929.Vaj3znI54n@kitterma-e6430> Date: Thu, 7 May 2015 23:08:12 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d04428d1c635b6b05158bda6e Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 06:08:15 -0000 --f46d04428d1c635b6b05158bda6e Content-Type: text/plain; charset=UTF-8 On Thu, May 7, 2015 at 4:24 PM, Scott Kitterman wrote: > No, it's OK for DKIM. The trick is d=ietf.org, which doesn't align for > DMARC > purposes. > We're saying the same thing, I think. I'm presuming a post-MLM message with an author domain signature and an MLM domain signature. The aligned author signature will presumably fail, and the ietf.org signature will presumably pass. That's all pure DKIM will tell you. DKIM+ATPS would tell you the additional bit that the From: domain signer also approved the ietf.org signature, but as presently specified, DMARC doesn't care about that. -MSK --f46d04428d1c635b6b05158bda6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, May 7, 2015 at 4:24 PM, Scott Kitterman <skli= st@kitterman.com> wrote:
No, it's OK for DKI= M.=C2=A0 The trick is d=3Diet= f.org, which doesn't align for DMARC
purposes.

We're saying the same thi= ng, I think.=C2=A0 I'm presuming a post-MLM message with an author doma= in signature and an MLM domain signature.=C2=A0 The aligned author signatur= e will presumably fail, and the ietf.org si= gnature will presumably pass.=C2=A0 That's all pure DKIM will tell you.=

DKIM+ATPS would tell you the additional bit that the From: domain s= igner also approved the ietf.org signature,= but as presently specified, DMARC doesn't care about that.

-MSK
--f46d04428d1c635b6b05158bda6e-- From nobody Thu May 7 23:15:21 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7CFC1AC42C for ; Thu, 7 May 2015 23:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Bvc84aNkEyp for ; Thu, 7 May 2015 23:15:18 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5429E1AC405 for ; Thu, 7 May 2015 23:15:18 -0700 (PDT) Received: by widdi4 with SMTP id di4so15849820wid.0 for ; Thu, 07 May 2015 23:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eavVK6TP20/P17LQ5QDsiQCK/AhS/Pemuvfbj/7ZAUU=; b=BSuFM38oGIRlL8YQGYYNkoZx31j0P/s9pcKZ71G3etSMqX08+AxUnf7j+JiIkWZI42 pldBvAHF7iiRXhoQhJ6T5IirCGhAL8tdiVHRa3AQqSf0VUATJCA3X+624oxmA2kzIUQa 3NN6UWerHLpFhr+BEzVAKmszOHtoy4tKcD6rgYtauSnxMEK/L0ZK2A1AAR9yCogMG0xn 93xN6tvLo+xf0qmU6iVBDnCr+ubgsp1JwSR2Ab+InVfnIKytIzLu/Y3ZsjEiQCSlhxCO +4ktRCKbWQqzUnK3g9cyC1fv6KhGZyoS7+FFuUpQAbGrIfBmf+zKnr96QTNn/HnxTmFz 4QbA== MIME-Version: 1.0 X-Received: by 10.180.74.37 with SMTP id q5mr3160986wiv.59.1431065717095; Thu, 07 May 2015 23:15:17 -0700 (PDT) Received: by 10.27.170.75 with HTTP; Thu, 7 May 2015 23:15:17 -0700 (PDT) In-Reply-To: <87k2wvp2cq.fsf@uwakimon.sk.tsukuba.ac.jp> References: <5719430.pnL5xihlrb@kitterma-e6430> <553B6B4E.5040607@sonnection.nl> <553DC479.8050304@isdg.net> <3C7A2F6E6BBA4473989BB022BF4088BA@fgsr.local> <1A3319524161475D81DCAC46BC16CB49@fgsr.local> <87zj5sq4cq.fsf@uwakimon.sk.tsukuba.ac.jp> <0BE093A2A8C74D0D8E937B2C33A964B6@fgsr.local> <87k2wvp2cq.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Thu, 7 May 2015 23:15:17 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=f46d043c7f24b7c40e05158bf346 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] A Modest Proposal of Two Variations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 06:15:20 -0000 --f46d043c7f24b7c40e05158bf346 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 29, 2015 at 5:04 AM, Stephen J. Turnbull wrote: > J. Gomez suggests: > > > > That would force DMARC-compliant Mediators to reject (or accept > > > > but not resend) incoming email from p=reject domains, > > > > irrespective of whether such mail passes or not the initial > > > > incoming DMARC checks. > > Something about having mediators (ie, non-MTAs) implement this check > was bothering me. I realized that the nagging thought was the > *Mediator* doesn't have to do it. > > Variation A: > > The *outgoing MTA* can do this check; it has the same information (the > "From" field, the DKIM signature, and the DNS) that the mediator does. > This outgoing check is just a variation on the spamfighting theme of > "if pretty much anybody can send from your system, you have to check > outgoing mail as well as incoming mail." > [...] > Outgoing from the Author, or outgoing from the Mediator? Either way, it seems to me that this is something a fully compliant participant might do, but that broken or hostile actors won't bother doing. -MSK --f46d043c7f24b7c40e05158bf346 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 29, 2015 at 5:04 AM, Stephen J. Turnbull <st= ephen@xemacs.org> wrote:
J. Gomez suggests:
= =C2=A0> > >=C2=A0 =C2=A0 =C2=A0That would force DMARC-compliant Me= diators to reject (or accept
=C2=A0> > >=C2=A0 =C2=A0 =C2=A0but not resend) incoming email from= p=3Dreject domains,
=C2=A0> > >=C2=A0 =C2=A0 =C2=A0irrespective of whether such mail p= asses or not the initial
=C2=A0> > >=C2=A0 =C2=A0 =C2=A0incoming DMARC checks.

Something about having mediators (ie, non-MTAs) implement this check
was bothering me.=C2=A0 I realized that the nagging thought was the
*Mediator* doesn't have to do it.

Variation A:

The *outgoing MTA* can do this check; it has the same information (the
"From" field, the DKIM signature, and the DNS) that the mediator = does.
This outgoing check is just a variation on the spamfighting theme of
"if pretty much anybody can send from your system, you have to check outgoing mail as well as incoming mail."
[...]

Outgoing from the Author, or outg= oing from the Mediator?
=C2=A0
Either way, it seems to me that = this is something a fully compliant participant might do, but that broken o= r hostile actors won't bother doing.

-MSK
--f46d043c7f24b7c40e05158bf346-- From nobody Fri May 8 10:29:40 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A4B1B2DD0 for ; Fri, 8 May 2015 10:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bppdfRoTxNfV for ; Fri, 8 May 2015 10:29:36 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 01A1C1B2DC8 for ; Fri, 8 May 2015 10:29:35 -0700 (PDT) Received: from vindemiatrix.encs.concordia.ca (vin-anne@vindemiatrix.encs.concordia.ca [132.205.47.192]) by oldperseverance.encs.concordia.ca (envelope-from anne@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t48HTYeo023792 for ; Fri, 8 May 2015 13:29:34 -0400 Received: from vindemiatrix.encs.concordia.ca (vin-anne@localhost) by vindemiatrix.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t48HTYWM026012 for ; Fri, 8 May 2015 13:29:34 -0400 X-Authentication-Warning: vindemiatrix.encs.concordia.ca: vin-anne owned process doing -bs To: dmarc@ietf.org In-reply-to: Your message of Thu, 07 May 2015 18:03:22 EDT References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> From: Anne Bennett Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Date: Fri, 08 May 2015 13:29:33 -0400 Message-ID: <26011.1431106173@vindemiatrix.encs.concordia.ca> X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-05-08 13:29:34 EDT Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 17:29:38 -0000 Murray S. Kucherawy writes (with respect to ATPS if I got this right): >> There's still that pesky registration problem to address. Hector Santos writes: > Separate issue. SPF would not be here if you used this same criteria. > None of the big domains you are concern about have hard fails for SPF > for the same reason -- it can not "register" their SPF network of > possible users. Same problem. I'm not convinced that it's the same problem at all. In the case of SPF, I am (supposed to be!) in control of and knowledgeable about which IP addresses are used by my outgoing mail relays, including any third parties I might hire to send out bulk mail on my behalf. Their registration by me into my own DNS is trivial. Now of course we all know that if I used "!all" in my SPF record, this would break messages from my users who: 1 - ... are currently offsite but set their From: line to my domain, then submit mail through another provider. 2 - ... post through a mailing list offsite which doesn't munge "From:". 3 - ... send to recipients who in turn forward their mail (without fancy workarounds) to a third site. I don't think that anyone would suggest that the correct fix for any of the situations above would be to add the relevant IP addresses (of my offsite user's ISP's mail relay, of the mail relays of all the mailing lists to which my users might post, or of my users' recipients' "forwarding" mail relay) to my SPF record. Therefore, I don't think that SPF has a "registration problem". It has plenty of other problems, but not that one. ;-) But if I understand correctly, it's being suggested that for various proposals made here to work, either the sender's mail system or the final receiver's mail system would have to become aware of all of the "legitimate" (definition purposely left out!) mailing lists to which its users subscribe. To me, *that* is a registration problem. I believe that some people have claimed that this problem is easily overcome (or perhaps "worked around" would be a better expression) by examining mail headers and gathering statistics, and this may well be the case, but addressing the problem in this way will always depend on heuristics, just like any other anti-spam method. I cannot see how it would approach a reliable pass/fail result, which I've been told is what DMARC is all about: don't make the users have to decide anything! Handle it all before delivery! What am I missing? Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne@encs.concordia.ca +1 514 848-2424 x2285 From nobody Fri May 8 15:48:09 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008581A6F04 for ; Fri, 8 May 2015 15:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zahcX3Gsr_qi for ; Fri, 8 May 2015 15:48:05 -0700 (PDT) Received: from news.winserver.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB7C1A6EFE for ; Fri, 8 May 2015 15:48:05 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=6269; t=1431125278; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=84tPGSWaWmy4zV1gP6blef3Jdm8=; b=glmNwwpns8miMMiGW4iz q7sZD3AgCmWUr1Uy9QCh1FyVCu+qGVMBiDVz7E4VEItE+o7o8bCmuU5sdsDvxLmH jrM4HhECaGxRNcH3MNBrPexo7aeW8xR+8d+P2vyWBIehuKqT1u7XPW+gJRduTYWK JeZH2nvZRu8WCIQH4C16BYY= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 08 May 2015 18:47:58 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 540302563.1.3148; Fri, 08 May 2015 18:47:58 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=6269; t=1431125002; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=gcKhJtm mtrUM3VKZwGraG3JrNeODAJmQgSfaxAh19Qc=; b=hpezbsuBp/zSu4JQAadprrQ 6IpShsvUABBWsXlfF3sM+uWZVlFwgYfB3DJ1DnmO/aqjx37Lpv1PDa7TyZDE48Sk hR1XXFMxDK+5YMTIUgdYP2D2AljgTut/XNMJQoExbXNKMVM/qrUO07PzLyuRkyd+ CJ5kanMKD/+rq2HThG6o= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 08 May 2015 18:43:21 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3427537176.9.3972; Fri, 08 May 2015 18:43:20 -0400 Message-ID: <554D3D1E.9050509@isdg.net> Date: Fri, 08 May 2015 18:47:58 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> In-Reply-To: <26011.1431106173@vindemiatrix.encs.concordia.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 22:48:09 -0000 On 5/8/2015 1:29 PM, Anne Bennett wrote: > > > Murray S. Kucherawy writes (with respect to ATPS if I got this right): > >>> There's still that pesky registration problem to address. > > Hector Santos writes: > >> Separate issue. SPF would not be here if you used this same criteria. >> None of the big domains you are concern about have hard fails for SPF >> for the same reason -- it can not "register" their SPF network of >> possible users. Same problem. > > I'm not convinced that it's the same problem at all. > > In the case of SPF, I am (supposed to be!) in control of > and knowledgeable about which IP addresses are used by my > outgoing mail relays, including any third parties I might hire > to send out bulk mail on my behalf. Their registration by me > into my own DNS is trivial. How about your roaming users? How about when users use other MSA sites? If you have such a mail network among your domain, then for the most part, the domain is restricted to relaxed policies. It can't use hard policies. Please note, as an early explorer, I didn't believe it was a problem for SPF, nor do I believe its a problem for ATPS-rev04. SPF suffered through the same basic "scale" and lack of path independence arguments. "SPF was not path independent. It didn't scale." DKIM was suppose to be the alternative as a path independent solution -- that was the marketing behind it. > Now of course we all know that if I used "!all" in my SPF > record, this would break messages from my users who: Do you mean "-ALL" hardfail policy? > > 1 - ... are currently offsite but set their From: line to > my domain, then submit mail through another provider. Roaming user. :) > 2 - ... post through a mailing list offsite which doesn't > munge "From:". 5322.From is not SPF related. You mean the 5321.MailFrom? > > 3 - ... send to recipients who in turn forward their mail > (without fancy workarounds) to a third site. > A simple relay, sure, SPF has that problem you will only see for -ALL policies. > I don't think that anyone would suggest that the correct fix > for any of the situations above would be to add the relevant > IP addresses (of my offsite user's ISP's mail relay, of the > mail relays of all the mailing lists to which my users might > post, or of my users' recipients' "forwarding" mail relay) > to my SPF record. I don't think anyone has suggested that. That is the domain's business and it may also mean the domain is not a candidate for strong policies. That is what surprised everyone when Yahoo.com flipped the rejection switch. Its a long time public service domain with a wide network of users, many roaming around. But the market is changing with more centralization and domains wishing to finally clean up their aged and spam-polluted domains. > Therefore, I don't think that SPF has a "registration problem". > It has plenty of other problems, but not that one. ;-) To me, it is pretty much deja vu. :) I didn't have the problem as most private, corporations, non-public service domains do not have this problem. Only the public service domains have a bigger issue with it. The corporate Microsoft.com domain can do a -ALL but can not use a hard fail for outlook.com, hotmail.com and msn.com public service domains. Note again, I was not one to agree it was a problem for SPF as I don't believe it is a problem for ATPS-rev04. But the same/similar issues were raised. DKIM was argued as a better solution because it didn't have the path independent problem. That was a flawed idea. They both had mail path problems once you have a DKIM policy layer. > But if I understand correctly, it's being suggested that for > various proposals made here to work, either the sender's mail > system or the final receiver's mail system would have to become > aware of all of the "legitimate" (definition purposely left > out!) mailing lists to which its users subscribe. > > To me, *that* is a registration problem. Sure, but its a typical one and IMO, generally considered as an implementation issue, more related to the business itself. You can argue that its a barrier to adoption too, but its not something that preempts protocol designs. APTS follows a standard client/server negotiated Lookup methodology/solution that SPF, DMARC currently enjoys as DNS-based applications. We are trying to fit in another lookup or make it piggy back off the existing lookups to minimize the overhead. > I believe that some people have claimed that this problem is > easily overcome (or perhaps "worked around" would be a better > expression) by examining mail headers and gathering statistics, > and this may well be the case, but addressing the problem in > this way will always depend on heuristics, just like any other > anti-spam method. I agree. This is why it is a separate implementation issue. We are looking for a deterministic protocol solution. The lack of not having the "registration" in place first should not stop one from "checking" to see if it exist. If this becomes wasteful with no payoff, we can later deprecate it, turn it off. We desire a short term adoption, adaptation, migration, etc, but it can be long term too. Just considered, all this started around 2003 and we are still fussing with it. > I cannot see how it would approach a reliable pass/fail result, > which I've been told is what DMARC is all about: don't make the > users have to decide anything! Handle it all before delivery! Yes, deterministic, system level, no mail acceptance at SMTP, a 55x return code. This can be also a SMTP accept/discard mode of operation (250 and this discard it) or possibly the accept/quarantine mode of operation which keeps it from the user's main in-box, but he can still see it in a spam folder. > What am I missing? Nothing. :) You appear to have roaming user problems. You can't use a hard SPF policy because you can't register all these users in how they send the mail. Therefore, you have a more open, public, relaxed policy. Millions of domains have more control and use a -ALL policy. They do not expect their users from using their domains in public unknown ways. -- HLS From nobody Fri May 8 17:08:11 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC8B1A1A15 for ; Fri, 8 May 2015 17:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dem9vCP4oETH for ; Fri, 8 May 2015 17:08:09 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (mx-out.zmailcloud.com [192.198.85.98]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3001A19F2 for ; Fri, 8 May 2015 17:08:09 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id F1E2A563DC8 for ; Fri, 8 May 2015 19:08:08 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id E424D6082E for ; Fri, 8 May 2015 19:08:08 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7nZA47W15ei for ; Fri, 8 May 2015 19:08:08 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id B5D3060834 for ; Fri, 8 May 2015 19:08:08 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com B5D3060834 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1431130088; bh=Fa2eaf9eMd8zztxtRYpOaB1gXekrVY4b3Zn6DDHgs5c=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; b=CBAqqLG+zpo2Tlk+6oCCn8g/3lbO8Ghznx1Ky5/UwswzrF9IBRJCoLq/0XEgc0eEJ AwurnnNtN3XiuUhxwwg8v4fhnmuHPlVgBdC3H8lt/tbRDQL72fC4l7faXTeTg7c1jP VhhQIjunhys1Ba87apdph0/0+aK8cGOnmTfA6Vx0= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 969CE60831 for ; Fri, 8 May 2015 19:08:08 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2kKiA8SCfF1m for ; Fri, 8 May 2015 19:08:08 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 728486082E for ; Fri, 8 May 2015 19:08:08 -0500 (CDT) Date: Fri, 8 May 2015 19:08:08 -0500 (CDT) From: Franck Martin To: dmarc Message-ID: <1552316227.113529.1431130088299.JavaMail.zimbra@peachymango.org> In-Reply-To: <1194292369.113442.1431129332815.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_113528_2047401844.1431130088299" X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF37 (Mac)/8.0.5_GA_5839) Thread-Topic: draft-ietf-dmarc-interoperability-02.txt Thread-Index: za5ypuDdJAcdd8MD9N0QBruQ+Yhmog== Archived-At: Subject: [dmarc-ietf] draft-ietf-dmarc-interoperability-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 00:08:11 -0000 ------=_Part_113528_2047401844.1431130088299 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I went over the emails of this week, did not find any new comment/update for the above document. ------=_Part_113528_2047401844.1431130088299 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I went over the emails of this week, did not find any new comment/update for the above document.

------=_Part_113528_2047401844.1431130088299-- From nobody Fri May 8 17:19:40 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43691A1A6E for ; Fri, 8 May 2015 17:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPTCchoMcZzn for ; Fri, 8 May 2015 17:19:37 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD54A1A03E3 for ; Fri, 8 May 2015 17:19:36 -0700 (PDT) Received: by wiun10 with SMTP id n10so43462612wiu.1 for ; Fri, 08 May 2015 17:19:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=siR0GsSDoCF2obC1NHCoJix9BGP8/sq8XNF+r0hfZJk=; b=zjslXPwcL8YijGuWgvF05gU/9UHUnvn2XgXR21h/+eE/KpZHplJk2OOJY/rea2cx87 phpnqGcBb392Q+YwALoJ6lvdIjRrHwa/rQc82LLSN1uUiTSwxIsZcVlRTDw+wkCsZEDy 8XJljirT//90Nxhw3Ofud2ebj9kiVYkFz9finMKKkVf/PrmgEj1p29w5cO1+8dgHUIgV cXZmpUVIcFQ54TV/iEScHuelRHfu4f+bt/ovAAlKyrRYYwCA9MuJQCKpF2lieEJMRmEp sBrDR4pUS0Kdtxk2HVuUUGEU7ItJ68V2yemtNhAenpai9WfKp6Uc0uesdCl5TLey48po QAbw== MIME-Version: 1.0 X-Received: by 10.180.75.197 with SMTP id e5mr1038829wiw.94.1431130775517; Fri, 08 May 2015 17:19:35 -0700 (PDT) Received: by 10.27.170.134 with HTTP; Fri, 8 May 2015 17:19:35 -0700 (PDT) In-Reply-To: <26011.1431106173@vindemiatrix.encs.concordia.ca> References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> Date: Fri, 8 May 2015 17:19:35 -0700 Message-ID: From: "Murray S. Kucherawy" To: Anne Bennett Content-Type: multipart/alternative; boundary=f46d043be0ee8080cc05159b19a0 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 00:19:39 -0000 --f46d043be0ee8080cc05159b19a0 Content-Type: text/plain; charset=UTF-8 On Fri, May 8, 2015 at 10:29 AM, Anne Bennett wrote: > > Murray S. Kucherawy writes (with respect to ATPS if I got this right): > You did. > >> There's still that pesky registration problem to address. > > Hector Santos writes: > > [...] > > Therefore, I don't think that SPF has a "registration problem". > It has plenty of other problems, but not that one. ;-) > Agreed. > But if I understand correctly, it's being suggested that for > various proposals made here to work, either the sender's mail > system or the final receiver's mail system would have to become > aware of all of the "legitimate" (definition purposely left > out!) mailing lists to which its users subscribe. > > To me, *that* is a registration problem. > Agreed again. And as Terry has said and I think we can infer about other large operators, it's incorrect to assume (and plain wrong to assert) that this is an easy problem for them to solve in a reliable way. > I believe that some people have claimed that this problem is > easily overcome (or perhaps "worked around" would be a better > expression) by examining mail headers and gathering statistics, > and this may well be the case, but addressing the problem in > this way will always depend on heuristics, just like any other > anti-spam method. > Right; the claim is that this is a well understood problem and that the cost of implementing it is low. I don't agree. In addition to the above, no two operators will have exactly the same idea of what fits here, or what components of their local system they need to include. Punting on this as an "implementation issue" leaves a pretty substantial hole in whatever gets rolled out. To me it's like buying a car with a completely absent steering mechanism, and you have to do the research to figure out which one fits and works for you, and probably build it yourself too. At a minimum, we need to describe detailed requirements of this component. Having something open source that works in general would also be helpful, but at best we only have a rough sketch of what that would look like right now. I cannot see how it would approach a reliable pass/fail result, > which I've been told is what DMARC is all about: don't make the > users have to decide anything! Handle it all before delivery! > > What am I missing? > Not a thing. -MSK --f46d043be0ee8080cc05159b19a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, May 8, 2015 at 10:29 AM, Anne Bennett <anne@= encs.concordia.ca> wrote:

Murray S. Kucherawy writes (with respect to ATPS if I got this right):
<= /blockquote>

You did.
=C2=A0
>> There's still that pesky registration problem= to address.

Hector Santos writes:

[...]

Therefore, I don't think that SPF has a "regis= tration problem".
It has plenty of other problems, but not that one.=C2=A0 ;-)

Agreed.
=C2=A0
But if I understand correctly, it's being suggested that for
various proposals made here to work, either the sender's mail
system or the final receiver's mail system would have to become
aware of all of the "legitimate" (definition purposely left
out!) mailing lists to which its users subscribe.

To me, *that* is a registration problem.

Agreed again.=C2=A0 And as Terry has said and I think we can infer about = other large operators, it's incorrect to assume (and plain wrong to ass= ert) that this is an easy problem for them to solve in a reliable way.
= =C2=A0
I believe that some people have claimed that this problem is
easily overcome (or perhaps "worked around" would be a better
expression) by examining mail headers and gathering statistics,
and this may well be the case, but addressing the problem in
this way will always depend on heuristics, just like any other
anti-spam method.

Right; the claim is t= hat this is a well understood problem and that the cost of implementing it = is low.

I don't agree.=C2=A0 In addition to the above= , no two operators will have exactly the same idea of what fits here, or wh= at components of their local system they need to include.=C2=A0 Punting on = this as an "implementation issue" leaves a pretty substantial hol= e in whatever gets rolled out.=C2=A0 To me it's like buying a car with = a completely absent steering mechanism, and you have to do the research to = figure out which one fits and works for you, and probably build it yourself= too.

At a minimum, we need to describe detailed requirem= ents of this component.=C2=A0 Having something open source that works in ge= neral would also be helpful, but at best we only have a rough sketch of wha= t that would look like right now.

I cannot see how it would approach a reliable pass/fail result,
which I've been told is what DMARC is all about: don't make the
users have to decide anything!=C2=A0 Handle it all before delivery!

What am I missing?

Not a thing.

=
-MSK
--f46d043be0ee8080cc05159b19a0-- From nobody Fri May 8 19:01:52 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8821A8890 for ; Fri, 8 May 2015 19:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2BeKmJ1yVAK for ; Fri, 8 May 2015 19:01:48 -0700 (PDT) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565001A8889 for ; Fri, 8 May 2015 19:01:47 -0700 (PDT) Received: by pdea3 with SMTP id a3so103033528pde.3 for ; Fri, 08 May 2015 19:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=b8QKwDKKCQc7mES1x6/qRWTK790Zf4rLydqXNLn1otc=; b=CT0G2pR/Zqh6O//r7J+bnG9tRmt0WEGMpjLOWh3StZnuRD9/8w1qdgbZ0w9AAMxsPR fZsfJG3Dduq3iLwBGzK7LdAFEsb1uxFxy2SIeaZrfVHnrkt4AzqcFWl8j+XQymNGLFNv OTku4yeq+SI2cL9Il8SXWJjMezDNocJBZRvhZChKmrK4WAuKg96nljZ8u8UZhsz3iZ8a 0AWGR+qlFk5gqaaTbfOTizuTzqS1VRRO7KOoXjuYJRDWnOM5LL4iHd/dz26ioTrQmWu9 9eoa6q9KwJL2u7PbehI0UD+XXA593AXHnLV5ggvuOm4XgJ8gqNhqDRJeNpdAYPYEjFH5 95lA== X-Received: by 10.66.55.74 with SMTP id q10mr1378265pap.94.1431136907532; Fri, 08 May 2015 19:01:47 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id c8sm6400745pdj.65.2015.05.08.19.01.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 May 2015 19:01:46 -0700 (PDT) Message-ID: <554D6A86.5030007@gmail.com> Date: Fri, 08 May 2015 19:01:42 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 02:01:50 -0000 On 5/8/15 5:19 PM, Murray S. Kucherawy wrote: > On Fri, May 8, 2015 at 10:29 AM, Anne Bennett > wrote: >> Murray S. Kucherawy writes (with respect to ATPS if I got this right): > You did. >>>> There's still that pesky registration problem to address. >> Hector Santos writes: >> >> [...] >> >> Therefore, I don't think that SPF has a "registration problem". >> It has plenty of other problems, but not that one. ;-) > Agreed. >> But if I understand correctly, it's being suggested that for >> various proposals made here to work, either the sender's mail >> system or the final receiver's mail system would have to become >> aware of all of the "legitimate" (definition purposely left >> out!) mailing lists to which its users subscribe. >> >> To me, *that* is a registration problem. > Agreed again. And as Terry has said and I think we can infer about other > large operators, it's incorrect to assume (and plain wrong to assert) that > this is an easy problem for them to solve in a reliable way. The current situation is NOT producing reliable results nor can it get better without additional information being made available from the DMARC domain requesting restrictive handling against non-transactional exchanges. DMARC must stop ignoring the role of Sender header fields, or make an effort to avoid disrupting legitimate, well formed, SMTP compliant, and socially beneficial exchanges. >> I believe that some people have claimed that this problem is >> easily overcome (or perhaps "worked around" would be a better >> expression) by examining mail headers and gathering statistics, >> and this may well be the case, but addressing the problem in >> this way will always depend on heuristics, just like any other >> anti-spam method. > Right; the claim is that this is a well understood problem and that the > cost of implementing it is low. For the DMARC domain, identifying legitimate third-parties can represent rather straight forward results determined by comparing recent output logs against DMARC feedback. Information that only the DMARC domain is able to authoritatively confirm. Arguing about cost misses the fact that expecting recipients to make this type of determination before imposing requested and possibly disruptive policy is simply not practical. We would love to have the opportunity to demonstrate the implementation of such a system at scale on behalf of a large provider. ATSP won't work, but can be altered to avoid requiring special DKIM signatures or indeterminate labels. Since this scheme would only come into play when handling otherwise restrictive handling, the impact would be small but highly beneficial by eliminating the disruption of valid, and socially desired messages. If there is a case to be made that restrictive handling is needed but is being misapplied against non-transactional messages, then there are two ways forward. 1) Recipients will decide the DMARC policy is too disruptive and not honor the requested handling by the disruptive domains. 2) Senders can recognize they must provide additional information to avoid disrupting socially valued services exchanging properly formed messages where the author remains apparent to recipients. > I don't agree. In addition to the above, no two operators will have > exactly the same idea of what fits here, or what components of their local > system they need to include. Punting on this as an "implementation issue" > leaves a pretty substantial hole in whatever gets rolled out. To me it's > like buying a car with a completely absent steering mechanism, and you have > to do the research to figure out which one fits and works for you, and > probably build it yourself too. Which is why we volunteered to help at implementing a solution that provides recipients DMARC domain derived information necessary to prevent unwarranted disruption of services. > At a minimum, we need to describe detailed requirements of this component. > Having something open source that works in general would also be helpful, > but at best we only have a rough sketch of what that would look like right > now. > > I cannot see how it would approach a reliable pass/fail result, A pass/fail result is possible only when DMARC domains offer necessary information that only they can assemble. The cost of sharing this information is extremely low for both the sender and the recipient. We did this as a free service for about 80% of the world's email at one time. Assembly of information may not be immediate but the collection of this information should be fairly stable. There may be some prompting required to ensure there are no gaps in coverage. >> which I've been told is what DMARC is all about: don't make the >> users have to decide anything! Handle it all before delivery! Removing risk exposure from recipients is fine. But don't toss out valued messages or obscure authors because avoiding disruption seems like too much effort. It is not. Shortcuts working without the necessary information will intimately prove even more problematic. I have an increasing number of legitimate messages ending up in my spam folder along with their look-alikes. Regards, Douglas Otis From nobody Fri May 8 19:34:20 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFF61A88DA for ; Fri, 8 May 2015 19:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eyNvHAJh6ZtN for ; Fri, 8 May 2015 19:34:19 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C881A88D1 for ; Fri, 8 May 2015 19:34:18 -0700 (PDT) Received: (qmail 56681 invoked from network); 9 May 2015 02:34:20 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 9 May 2015 02:34:20 -0000 Date: 9 May 2015 02:33:55 -0000 Message-ID: <20150509023355.56318.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <1552316227.113529.1431130088299.JavaMail.zimbra@peachymango.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: franck@peachymango.org Subject: Re: [dmarc-ietf] draft-ietf-dmarc-interoperability-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 02:34:19 -0000 In article <1552316227.113529.1431130088299.JavaMail.zimbra@peachymango.org> you write: >I went over the emails of this week, did not find any new comment/update for the above document. Do you know when you'll be posting a new draft? There's a fair amount of stuff to fix. R's, John From nobody Fri May 8 21:40:41 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E654A1A90D5 for ; Fri, 8 May 2015 21:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.08 X-Spam-Level: X-Spam-Status: No, score=-101.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asF78d4RkwjP for ; Fri, 8 May 2015 21:40:37 -0700 (PDT) Received: from mail.catinthebox.net (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id F03501A90D3 for ; Fri, 8 May 2015 21:40:36 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1396; t=1431146429; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=wuKjLBOL+K56sOU82FO3yARO/IY=; b=cDVU04kWq6WvWUY3pxrR 8xIE4sOR2j1vZaGxQrP1niv0XNimUvjJ1AZzQxpAPV1aKyw96S9pQJOu9N8f/7mV HIp/G7ZEu9QPgzhbR08OB2BJX4bVIl7tSZgwH285VEB+GULBrzAn5cbAXdNLqw1H OehAHlCirEGTJnXCcJj2Qu8= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 09 May 2015 00:40:29 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 561453069.1.748; Sat, 09 May 2015 00:40:28 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1396; t=1431146152; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=QRCQisq 7ESg2Dv0qaTM0U6179srl6E+JkKGRvcqf/Mk=; b=Mr5vZ9PAzeovKrUHvxIBNSs kvveD3NJoEDfPrg6C48fQcIaokDaPrZOAS1CZRZz8E4USQL2IUAUETZw1OALPWUL lq48jxSkGh27ItIZv2M1xyFYUcCV6lCU06QZwmWUbkzeTNaKQ+kqi+4/E7EMBswi wLpnB604uhb/Z2/r6e6E= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 09 May 2015 00:35:52 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3448688879.9.12696; Sat, 09 May 2015 00:35:52 -0400 Message-ID: <554D8FBE.6000703@isdg.net> Date: Sat, 09 May 2015 00:40:30 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 04:40:40 -0000 On 5/8/2015 8:19 PM, Murray S. Kucherawy wrote: >Punting on this as an > "implementation issue" leaves a pretty substantial hole in whatever > gets rolled out. To me it's like buying a car with a completely > absent steering mechanism, and you have to do the research to figure > out which one fits and works for you, and probably build it yourself too. I don't get the metaphor. Who will buy a car with a steering problem? Anyway.... It is an implementation issue. You can even use RFC6541 if you wish to illustrate there was a lack of adoption. The Interop report should research why. We can probably say: - Short or Long Term adoption of publishing records, - Requires DKIM Code Change, - Migration issue. ADSP was implemented and then abandoned, - It was labeled experimental. It was a moving target. ADSP was being played down. With ATPS-Rev04, no DKIM code change was required. Running code is in the field. You might want to say (repeat) why the public service domains have a harder time at publishing records or can use this technology. > At a minimum, we need to describe detailed requirements of this > component. Probably as implementation notes, but it shouldn't be a barrier. I do believe Functional Requirements should be defined because there are at least 3-4 proposals and I am about to throw in there one or two myself. -- HLS From nobody Sat May 9 02:00:28 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B7C1A7030 for ; Sat, 9 May 2015 02:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5f03yAJ3o12 for ; Sat, 9 May 2015 02:00:26 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id D5E711A711A for ; Sat, 9 May 2015 02:00:25 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 70C071C38D0; Sat, 9 May 2015 18:00:24 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 57F9111F6A1; Sat, 9 May 2015 18:00:24 +0900 (JST) From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 09 May 2015 18:00:24 +0900 Message-ID: <87y4ky2kif.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" , Anne Bennett Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 09:00:27 -0000 Murray S. Kucherawy writes: > Agreed again. And as Terry has said and I think we can infer about > other large operators, it's incorrect to assume (and plain wrong to > assert) that this is an easy problem for them to solve in a > reliable way. Please define "reliable." I gather you all think that missing some mailing lists is a bigger problem than missing all of them, but for the life of me, I cannot see why. From nobody Sat May 9 07:09:45 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A871A1AFF for ; Sat, 9 May 2015 07:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6YXJdVdCVfb for ; Sat, 9 May 2015 07:09:42 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 895671A1ABE for ; Sat, 9 May 2015 07:09:42 -0700 (PDT) Received: from [192.168.111.2] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id DD36CC40029; Sat, 9 May 2015 09:09:40 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1431180581; bh=lc9LgEGg9W5iuoFkaUw/NeHKFSIWACwpnOwSVRMEpmM=; h=In-Reply-To:References:Subject:From:Date:To:From; b=kRZOaHKbqfOIXxw9nY/wAp4+2bTJVSExUIEGMTg6CZHYBZD8m4V4lx+uV3bakszOL AR7GiEwmOaIkS26XEGmdJCpgfXG44yXQB20x/vaR8WipN840R6rJQs3SLmfAobpsA/ mRhPuSb8YQOuLkVIilO0NUnYwWBXnUJA7u1eXFJc= User-Agent: K-9 Mail for Android In-Reply-To: <87y4ky2kif.fsf@uwakimon.sk.tsukuba.ac.jp> References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <87y4ky2kif.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Sat, 09 May 2015 10:09:34 -0400 To: "dmarc@ietf.org" Message-ID: <90B1E4C8-A53D-4226-A1F6-E35CF57091C7@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 14:09:44 -0000 On May 9, 2015 5:00:24 AM EDT, "Stephen J. Turnbull" wrote: >Murray S. Kucherawy writes: > > > Agreed again. And as Terry has said and I think we can infer about > > other large operators, it's incorrect to assume (and plain wrong to > > assert) that this is an easy problem for them to solve in a > > reliable way. > >Please define "reliable." I gather you all think that missing some >mailing lists is a bigger problem than missing all of them, but for >the life of me, I cannot see why. How many solutions do you think operators will be willing to implement? As I indicated in my utility assessment framework, I think we get a maximum of one solution that requires cooperative implementations in multiple parts of the originator/mediator/receiver trilogy. Given that, it had better be reasonably comprehensive. Scott K From nobody Sat May 9 08:07:53 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42AD51A1ADC for ; Sat, 9 May 2015 08:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ar3AuieIessk for ; Sat, 9 May 2015 08:07:50 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FD731A0687 for ; Sat, 9 May 2015 08:07:50 -0700 (PDT) Received: by widdi4 with SMTP id di4so55312814wid.0 for ; Sat, 09 May 2015 08:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=erHRz8DuaRcJAvq6SEmRU8Uu/fbQYWadaKvdsWjwGrw=; b=nXU36hDcxoHsZL9pwIk2g7CnXFwTzitkAZ8kMykWR54cavYmI+c4zKGxXz80MuKwF/ C89BV1SXMSqNW0uY38mQSILCGyf61E6VOlUpvAQOw7nq7s6wncr0fRiBtmzpi7FE9vMM xlnddxJCy0jmMUPIJrljhvpvfhW3X3nTa2CSejeNxi7Y3Uoo31NFnAMEOnxRMr3s+XNl /Qy9Jutt2COgEScT4+eMqMvl9ApIwF0zwTdAfA1Hc+TNO4gFuxQiv2ftCUlRoJAh9IQo 5onOk7lF4/MnZmntlOe1G99cyJblGWO5klBT2UJe5/UwjBQw5JVhdbF8lCflZNKCOdMn WAzQ== MIME-Version: 1.0 X-Received: by 10.194.193.66 with SMTP id hm2mr5418034wjc.111.1431184069321; Sat, 09 May 2015 08:07:49 -0700 (PDT) Received: by 10.27.170.134 with HTTP; Sat, 9 May 2015 08:07:49 -0700 (PDT) In-Reply-To: <87y4ky2kif.fsf@uwakimon.sk.tsukuba.ac.jp> References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <87y4ky2kif.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Sat, 9 May 2015 08:07:49 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=047d7b874e620f6a870515a78295 Archived-At: Cc: "dmarc@ietf.org" , Anne Bennett Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 15:07:52 -0000 --047d7b874e620f6a870515a78295 Content-Type: text/plain; charset=UTF-8 On Sat, May 9, 2015 at 2:00 AM, Stephen J. Turnbull wrote: > > Agreed again. And as Terry has said and I think we can infer about > > other large operators, it's incorrect to assume (and plain wrong to > > assert) that this is an easy problem for them to solve in a > > reliable way. > > Please define "reliable." I gather you all think that missing some > mailing lists is a bigger problem than missing all of them, but for > the life of me, I cannot see why. > I'm having trouble coming up with a heuristic that is even certain to grab "most" of them. -MSK --047d7b874e620f6a870515a78295 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, May 9, 2015 at 2:00 AM, Stephen J. Turnbull <ste= phen@xemacs.org> wrote:
=C2=A0&= gt; Agreed again.=C2=A0 And as Terry has said and I think we can infer abou= t
=C2=A0> other large operators, it's incorrect to assume (and plain w= rong to
=C2=A0> assert) that this is an easy problem for them to solve in a
=C2=A0> reliable way.

Please define "reliable."=C2=A0 I gather you all think tha= t missing some
mailing lists is a bigger problem than missing all of them, but for
the life of me, I cannot see why.

I'm having trou= ble coming up with a heuristic that is even certain to grab "most"= ; of them.

-MSK
--047d7b874e620f6a870515a78295-- From nobody Sat May 9 10:09:15 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2570D1A8A71 for ; Sat, 9 May 2015 10:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.299 X-Spam-Level: *** X-Spam-Status: No, score=3.299 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsX7FEKSmObx for ; Sat, 9 May 2015 10:09:12 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 76C651A8A70 for ; Sat, 9 May 2015 10:09:11 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 04FB61C3849; Sun, 10 May 2015 02:09:10 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id D26DD11F6A1; Sun, 10 May 2015 02:09:09 +0900 (JST) From: "Stephen J. Turnbull" To: Scott Kitterman In-Reply-To: <90B1E4C8-A53D-4226-A1F6-E35CF57091C7@kitterman.com> References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <87y4ky2kif.fsf@uwakimon.sk.tsukuba.ac.jp> <90B1E4C8-A53D-4226-A1F6-E35CF57091C7@kitterman.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Sun, 10 May 2015 02:09:09 +0900 Message-ID: <87wq0h3cga.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 17:09:14 -0000 Scott Kitterman writes: > How many solutions do you think operators will be willing to > implement? As many as have an expected benefit/cost ratio greater than 1, of course. If you want numbers, my expectation is about 0.5 (the odds are perceptibly better than even that *nothing* will be done), but I would hardly be surprised by 2 or more, since it seems likely that mailing lists and 3rd-party originated messages will require different solutions, and I think the operators would like to implement given a favorable benefit-cost ratio. > As I indicated in my utility assessment framework, I think we get a > maximum of one solution that requires cooperative implementations > in multiple parts of the originator/mediator/receiver trilogy. Hm. That's strange. They've already implemented SMTP, SPF, DKIM, and DMARC. By my count, that puts them a minimum of three solutions past what what you expect. > Given that, it had better be reasonably comprehensive. I expect that levine-dkim-conditional + "register addresses found in List-Post as candidates for delegation when an authenticated user posts" is as cheap as it's going to get, and will cover more than half of mailing lists. I think that's pretty comprehensive for a start, and thus something worth thinking about and looking for improvements, rather than rejecting because it won't eliminate world poverty in 30 days. From nobody Sat May 9 10:11:30 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35CD21A8A72 for ; Sat, 9 May 2015 10:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xk-CJq1TvMKh for ; Sat, 9 May 2015 10:11:26 -0700 (PDT) Received: from mail.santronics.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id DB5A51A8A71 for ; Sat, 9 May 2015 10:11:25 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5367; t=1431191483; h=Received:Received: Subject:From:Message-Id:Date:To:Organization:List-ID; bh=zvct9oA ExjJsZeD/kuXHwjBkvRg=; b=eTgba8egPpgx5Uigx86zSbDWL49L3NC9eFajjSN id8wpVooep3eZAEniYnCPlDH7k6irGkYIk3MtV9Li+0leHnaq8R/IYvjolzKecb7 X0I+dQNRd3rd7DHf1Yj8rGp+HEMaHgKhwsNk4tser0iJslzwunOfpeBFMtmKjjgh EwS4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 09 May 2015 13:11:23 -0400 Received: from [192.168.1.67] (99-3-146-30.lightspeed.miamfl.sbcglobal.net [99.3.146.30]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 606507172.1150.1984; Sat, 09 May 2015 13:11:23 -0400 References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <87y4ky2kif.fsf@uwakimon.sk.tsukuba.ac.jp> From: Hector Santos Content-Type: multipart/alternative; boundary=Apple-Mail-94327E65-CA82-4182-B932-1AA507FBA94A X-Mailer: iPad Mail (12B435) In-Reply-To: Message-Id: <7593D515-2EEC-4ED3-8518-B7A6109E4095@isdg.net> Date: Sat, 9 May 2015 13:11:21 -0400 Cc: "dmarc@ietf.org" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) X-Comment: Missing recipient address appended by wcSMTP router. To: dmarc@ietf.org Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 17:11:29 -0000 --Apple-Mail-94327E65-CA82-4182-B932-1AA507FBA94A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Heuristics for this are quite simple to generate. But it needs verification= , confirmation, authorization before it can be automated. That is what make= s it a heuristic and doesn't belong in the SMTP transport where this protoco= l can be implemented if only from a delayed learning concept, i.e. similar t= o a grey listing concept. In general, A typical reason to automate is to r= educe the human involvement cost. It was long known this would be a complex integrated solution. No matter wh= at, the MLM receiver must also follow policy protocol, all receivers, there i= s not just one, but two at a minimum with this type of mail steam. Even if= the simplistic DNS call solution is (erroneously) pushed aside, again, the M= LM must still support the rejection at the submission point for those that d= o not wish to have a more complex, costlier, alternative delegation or any r= esigner involved. If not, it didn't solve the problem and it just made the D= KIM integration design extremely more complex! =20 -- Hector Santos http://www.santronics.com > On May 9, 2015, at 11:07 AM, Murray S. Kucherawy wro= te: >=20 >> On Sat, May 9, 2015 at 2:00 AM, Stephen J. Turnbull w= rote: >> > Agreed again. And as Terry has said and I think we can infer about >> > other large operators, it's incorrect to assume (and plain wrong to >> > assert) that this is an easy problem for them to solve in a >> > reliable way. >>=20 >> Please define "reliable." I gather you all think that missing some >> mailing lists is a bigger problem than missing all of them, but for >> the life of me, I cannot see why. >=20 > I'm having trouble coming up with a heuristic that is even certain to grab= "most" of them. >=20 > -MSK > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --Apple-Mail-94327E65-CA82-4182-B932-1AA507FBA94A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Heuristics for this are quite simple t= o generate.  But it needs verification, confirmation, authorization bef= ore it can be automated.  That is what makes it a heuristic and doesn't= belong in the SMTP transport where this protocol can be implemented if only= from a delayed learning concept, i.e. similar to a grey listing concept. &n= bsp; In general, A typical reason to automate is to reduce the human involve= ment cost.

It was long known this would be a complex integrated solut= ion.  No matter what, the MLM receiver must also follow policy p= rotocol, all receivers, there is not just one, but two at a minimum with thi= s type of mail steam.   Even if the simplistic DNS call solution is (er= roneously) pushed aside, again, the MLM must still support the rejection at t= he submission point for those that do not wish to have a more complex, costl= ier, alternative delegation or any resigner involved.  If not, it didn'= t solve the problem and it just made the DKIM integration design extremely m= ore complex!  

--
Hector Santos

On May 9, 2015, at 11:07 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:

=
On Sat, May 9, 2015 at 2:00 A= M, Stephen J. Turnbull <stephen@xemacs.org> wrote:
 > Agreed again.  And as Terry has said and I= think we can infer about
 > other large operators, it's incorrect to assume (and plain wrong t= o
 > assert) that this is an easy problem for them to solve in a
 > reliable way.

Please define "reliable."  I gather you all think that missing s= ome
mailing lists is a bigger problem than missing all of them, but for
the life of me, I cannot see why.

I'm having trouble c= oming up with a heuristic that is even certain to grab "most" of them.
-MSK
____________________= ___________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mai= lman/listinfo/dmarc
= --Apple-Mail-94327E65-CA82-4182-B932-1AA507FBA94A-- From nobody Sat May 9 10:13:28 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E4C1A0030 for ; Sat, 9 May 2015 10:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-jCeR3IzTDp for ; Sat, 9 May 2015 10:13:25 -0700 (PDT) Received: from mail.santronics.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7021A002A for ; Sat, 9 May 2015 10:13:24 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1384; t=1431191599; h=Received:Received: Subject:From:Message-Id:Date:To:Organization:List-ID; bh=HZ+UO2K BpS4uO2NA5rJ3I13SkqU=; b=AZusbCOlumqR0VXdAUo8XjudDopU3p83acarY4N /vGSuSRsXGQLFvVe2d/ZfQrnShCFkQaG3ibeurqNzsIEe2nLP7Va8267wl6+xEuY zrs3/KlQDKaGgJFH+3Fm/Ac8XVKttLDwgsqpu1MUhnOqNQmizvopnzJe6qvzrC8o fnVU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 09 May 2015 13:13:19 -0400 Received: from [192.168.1.67] (99-3-146-30.lightspeed.miamfl.sbcglobal.net [99.3.146.30]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 606622035.1150.5772; Sat, 09 May 2015 13:13:18 -0400 References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <87y4ky2kif.fsf@uwakimon.sk.tsukuba.ac.jp> <90B1E4C8-A53D-4226-A1F6-E35CF57091C7@kitterman.com> From: Hector Santos Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (12B435) In-Reply-To: <90B1E4C8-A53D-4226-A1F6-E35CF57091C7@kitterman.com> Message-Id: <797144B2-4A86-4229-B800-11BC857DA85F@isdg.net> Date: Sat, 9 May 2015 13:13:15 -0400 Cc: "dmarc@ietf.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-Comment: Missing recipient address appended by wcSMTP router. To: dmarc@ietf.org Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 17:13:26 -0000 Your bar is too unrealistically high for typical IETF project work that is s= till in the experimental stages. You should be thankful, we didn't apply t= his bar to the SPF experiment. -- Hector Santos http://www.santronics.com > On May 9, 2015, at 10:09 AM, Scott Kitterman wrote:= >=20 >> On May 9, 2015 5:00:24 AM EDT, "Stephen J. Turnbull" = wrote: >> Murray S. Kucherawy writes: >>=20 >>> Agreed again. And as Terry has said and I think we can infer about >>> other large operators, it's incorrect to assume (and plain wrong to >>> assert) that this is an easy problem for them to solve in a >>> reliable way. >>=20 >> Please define "reliable." I gather you all think that missing some >> mailing lists is a bigger problem than missing all of them, but for >> the life of me, I cannot see why. >=20 > How many solutions do you think operators will be willing to implement? As= I indicated in my utility assessment framework, I think we get a maximum of= one solution that requires cooperative implementations in multiple parts of= the originator/mediator/receiver trilogy. Given that, it had better be reas= onably comprehensive.=20 >=20 > Scott K >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >=20 From nobody Sat May 9 10:31:47 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC7A1A1ADF for ; Sat, 9 May 2015 10:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJjv82cubl3p for ; Sat, 9 May 2015 10:31:44 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id B2A7D1A0399 for ; Sat, 9 May 2015 10:31:44 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 2E8BB1C38D7; Sun, 10 May 2015 02:31:44 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 06F8211F6A1; Sun, 10 May 2015 02:31:43 +0900 (JST) From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: <5719430.pnL5xihlrb@kitterma-e6430> <553B6B4E.5040607@sonnection.nl> <553DC479.8050304@isdg.net> <3C7A2F6E6BBA4473989BB022BF4088BA@fgsr.local> <1A3319524161475D81DCAC46BC16CB49@fgsr.local> <87zj5sq4cq.fsf@uwakimon.sk.tsukuba.ac.jp> <0BE093A2A8C74D0D8E937B2C33A964B6@fgsr.local> <87k2wvp2cq.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Sun, 10 May 2015 02:31:43 +0900 Message-ID: <87vbg13beo.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] A Modest Proposal of Two Variations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 17:31:46 -0000 Murray S. Kucherawy writes: > On Wed, Apr 29, 2015 at 5:04 AM, Stephen J. Turnbull > wrote: > > The *outgoing MTA* can do this check [for a modified and relayed > > message that fails From alignment]; it has the same information > > (the "From" field, the DKIM signature, and the DNS) that the > > mediator does. > > Outgoing from the Author, or outgoing from the Mediator? Outgoing from the Mediator. > Either way, it seems to me that this is something a fully compliant > participant might do, but that broken or hostile actors won't > bother doing. Ah, but mailing lists are *already* doing it, at least GNU Mailman implements an optional check for DMARC policy at the Author Domain, and munges if and only it's reject or quarantine. It's a popular feature. I'm just saying this could be implemented in the MTA as well, and it might go on the list of things you need to implement to get a Good Housekeeping Seal of Approval. From nobody Sat May 9 10:52:44 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D621A8A7B for ; Sat, 9 May 2015 10:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SShIQqlkeVG3 for ; Sat, 9 May 2015 10:52:40 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id AB4FC1A8AB6 for ; Sat, 9 May 2015 10:52:38 -0700 (PDT) Received: from shadrach.encs.concordia.ca (mjassels@shadrach.encs.concordia.ca [132.205.47.207]) by oldperseverance.encs.concordia.ca (envelope-from mjassels@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t49HqbMw010949; Sat, 9 May 2015 13:52:37 -0400 Received: from shadrach.encs.concordia.ca (mjassels@localhost) by shadrach.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t49HqbQM006230; Sat, 9 May 2015 13:52:37 -0400 Message-Id: <201505091752.t49HqbQM006230@shadrach.encs.concordia.ca> X-Authentication-Warning: shadrach.encs.concordia.ca: mjassels owned process doing -bs To: "Stephen J. Turnbull" From: Michael Jack Assels In-reply-to: <87vbg13beo.fsf@uwakimon.sk.tsukuba.ac.jp> References: <5719430.pnL5xihlrb@kitterma-e6430> <553B6B4E.5040607@sonnection.nl> <553DC479.8050304@isdg.net> <3C7A2F6E6BBA4473989BB022BF4088BA@fgsr.local> <1A3319524161475D81DCAC46BC16CB49@fgsr.local> <87zj5sq4cq.fsf@uwakimon.sk.tsukuba.ac.jp> <0BE093A2A8C74D0D8E937B2C33A964B6@fgsr.local> <87k2wvp2cq.fsf@uwakimon.sk.tsukuba.ac.jp> <87vbg13beo.fsf@uwakimon.sk.tsukuba.ac.jp> Comments: In-reply-to "Stephen J. Turnbull" message dated "Sun, 10 May 2015 02:31:43 +0900." Date: Sat, 09 May 2015 13:52:37 -0400 X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-05-09 13:52:37 EDT Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] A Modest Proposal of Two Variations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 17:52:42 -0000 On Sun, 10 May 2015 02:31:43 +0900, "Stephen J. Turnbull" wrote: > Ah, but mailing lists are *already* doing it, at least GNU Mailman > implements an optional check for DMARC policy at the Author Domain, > and munges if and only it's reject or quarantine. It's a popular > feature. I'm just saying this could be implemented in the MTA as > well, and it might go on the list of things you need to implement to > get a Good Housekeeping Seal of Approval. Isn't the ideal objective of DMARC to be so reliable that *everybody* uses it with p=reject. At that point, 5322.From addresses will all be munged. Why not skip the complexity and start munging them all now? I'm not particularly keen on this as a solution to DMARC's MLM problem, but there's no doubt that it would settle the issue. MJA From nobody Sat May 9 11:03:50 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D191A8ACF for ; Sat, 9 May 2015 11:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxKPUFwlEyvR for ; Sat, 9 May 2015 11:03:47 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id CFF771A8AC9 for ; Sat, 9 May 2015 11:03:46 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 194F91C38D8; Sun, 10 May 2015 03:03:46 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id E0B1A11F6A1; Sun, 10 May 2015 03:03:45 +0900 (JST) From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <87y4ky2kif.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Sun, 10 May 2015 03:03:45 +0900 Message-ID: <87sib539xa.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: Anne Bennett , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 18:03:48 -0000 Murray S. Kucherawy writes: > I'm having trouble coming up with a heuristic that is even certain > to grab "most" of them. Without definitions of "certain", "'most'", and "them", how is anybody supposed to meet such a requirement? Pending receipt of such definitions, I'll go see if I can get some statistics on how many of two large collections of mailing lists add RFC 2369 List-Post fields. From nobody Sat May 9 11:12:04 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959861A8AE5 for ; Sat, 9 May 2015 11:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXYKsRFueAlV for ; Sat, 9 May 2015 11:12:01 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 440D51A8AE8 for ; Sat, 9 May 2015 11:12:01 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB606.namsdf01.sdf.exchangelabs.com (10.255.109.168) with Microsoft SMTP Server (TLS) id 15.1.172.7; Sat, 9 May 2015 18:11:58 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.5.234]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.5.234]) with mapi id 15.01.0172.012; Sat, 9 May 2015 18:11:58 +0000 From: Terry Zink To: Hector Santos , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] DMARC ATPS Interop Note Thread-Index: AQHQiP+6B7ZwIu+OF0u+XlWpPn2/QZ1w9m6AgAALsICAAA8mAIABReU9gAByf4CAAJGEAIAAVmEAgAAzUoCAAAy+4A== Date: Sat, 9 May 2015 18:11:57 +0000 Message-ID: References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <87y4ky2kif.fsf@uwakimon.sk.tsukuba.ac.jp> <90B1E4C8-A53D-4226-A1F6-E35CF57091C7@kitterman.com> <797144B2-4A86-4229-B800-11BC857DA85F@isdg.net> In-Reply-To: <797144B2-4A86-4229-B800-11BC857DA85F@isdg.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.165.40.56] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB606; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(189002)(13464003)(24454002)(377454003)(51704005)(199003)(62966003)(77156002)(93886004)(105586002)(106116001)(106356001)(76176999)(50986999)(54356999)(2656002)(2950100001)(2900100001)(33656002)(101416001)(87936001)(92566002)(2501003)(5001960100002)(5001860100001)(81156007)(97736004)(4001540100001)(5001830100001)(5001770100001)(46102003)(64706001)(66066001)(68736005)(19580395003)(19580405001)(86362001)(16601075003)(102836002)(15975445007)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB606; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005002)(5002009)(3002001); SRVR:BL2SR01MB606; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB606; x-forefront-prvs: 05715BE7FD received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2015 18:11:57.6041 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB606 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 18:12:03 -0000 The reliability aspect is realistic to set a high bar. The decision to allo= w unregulated users to publish to the zones of Hotmail.com/outlook.com/msn.= com/live.com/Hotmail.ca/outlook.ca/live.ca... etc. is one that comes with i= ts own security challenges. This now no longer a way to allow indirect mail= flow to pass DMARC, but instead how to figure out a way to secure your DNS = zone. For the amount of work that would be, I would rather just inventory a= ll mailing lists and if an email comes from it into a domain filtered by Mi= crosoft, suppress DMARC.=20 It's not just Microsoft's consumer brands. Office 365 hosts email for small= , medium, and large businesses - each with their own DNS zone. If we have 5= 00,000 domains [1] and there are 100,000 mailing lists, are we going to pub= lish DNS records for the full matrix of combinations - 50 billion? Or even = 1 billion? We don't control customer's DNS zones, so we'd have to convince = our customers to publish these records and to do it on a regular basis. I c= an see nobody agreeing to do that. And if it won't work for Office 365 then= it won't work for Hotmail, outlook.com, live.com, etc. I can't see the solution of publishing things in your DNS zone as a workabl= e solution. That's why I like the conditional @fs DKIM signature better (or= some variant of it) - it's done on the MTA level. A customer domain, examp= le.com, can sign up for the Office 365 service and not have to publish any = mailing list third party authorization in their zone. Instead, the sending = MTA adds the required DKIM signatures and the receiving MTA decodes the inc= oming receiving signatures and does the right thing. The process is transpa= rent to end users, most of whom don't want to update their DNS zones. -- Terry [1] I don't know exactly how many domains we have, I just picked this as an= example. -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Hector Santos Sent: Saturday, May 9, 2015 10:13 AM To: dmarc@ietf.org Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note Your bar is too unrealistically high for typical IETF project work that is = still in the experimental stages. You should be thankful, we didn't apply= this bar to the SPF experiment. -- Hector Santos http://www.santronics.com > On May 9, 2015, at 10:09 AM, Scott Kitterman wrote= : >=20 >> On May 9, 2015 5:00:24 AM EDT, "Stephen J. Turnbull" wrote: >> Murray S. Kucherawy writes: >>=20 >>> Agreed again. And as Terry has said and I think we can infer about >>> other large operators, it's incorrect to assume (and plain wrong to >>> assert) that this is an easy problem for them to solve in a >>> reliable way. >>=20 >> Please define "reliable." I gather you all think that missing some >> mailing lists is a bigger problem than missing all of them, but for >> the life of me, I cannot see why. >=20 > How many solutions do you think operators will be willing to implement? A= s I indicated in my utility assessment framework, I think we get a maximum = of one solution that requires cooperative implementations in multiple parts= of the originator/mediator/receiver trilogy. Given that, it had better be = reasonably comprehensive.=20 >=20 > Scott K >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >=20 _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Sat May 9 11:54:17 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB6C91A8BB4 for ; Sat, 9 May 2015 11:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TvTVRDtYHdm for ; Sat, 9 May 2015 11:54:13 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B89A1A8AF3 for ; Sat, 9 May 2015 11:54:13 -0700 (PDT) Received: from [IPv6:2600:1003:b103:2c73:fcbb:4e6b:3c11:6580] (unknown [IPv6:2600:1003:b103:2c73:fcbb:4e6b:3c11:6580]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 4C419C40029; Sat, 9 May 2015 13:54:11 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1431197652; bh=MYgCQObvSTazz2C/bR3kTxhEZkL311fa2/KdvqsV56E=; h=In-Reply-To:References:Subject:From:Date:To:From; b=xqlMJibKMXUByfTV65yRorBHLpl6IXH88Whck8xgqgnYHqYwIoe78/Ux3y2eMdpuN xCukiUht0UQlyRHED4MxZCaSbKar8Jt8LIv1qq90JS7E5rQt1D94SYVOU0pxpQr0cp 3JJl2rcrj3hRg6OY99hAu4rN4BhMc6v03U/jiQxU= User-Agent: K-9 Mail for Android In-Reply-To: <87wq0h3cga.fsf@uwakimon.sk.tsukuba.ac.jp> References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <87y4ky2kif.fsf@uwakimon.sk.tsukuba.ac.jp> <90B1E4C8-A53D-4226-A1F6-E35CF57091C7@kitterman.com> <87wq0h3cga.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Sat, 09 May 2015 14:52:52 -0400 To: "dmarc@ietf.org" Message-ID: Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 18:54:16 -0000 On May 9, 2015 1:09:09 PM EDT, "Stephen J. Turnbull" wrote: >Scott Kitterman writes: > > > How many solutions do you think operators will be willing to > > implement? > >As many as have an expected benefit/cost ratio greater than 1, of >course. > >If you want numbers, my expectation is about 0.5 (the odds are >perceptibly better than even that *nothing* will be done), but I would >hardly be surprised by 2 or more, since it seems likely that mailing >lists and 3rd-party originated messages will require different >solutions, and I think the operators would like to implement given a >favorable benefit-cost ratio. 0.5 is about my estimate too. > > As I indicated in my utility assessment framework, I think we get a > > maximum of one solution that requires cooperative implementations > > in multiple parts of the originator/mediator/receiver trilogy. > >Hm. That's strange. They've already implemented SMTP, SPF, DKIM, and >DMARC. By my count, that puts them a minimum of three solutions past >what what you expect. I meant how many solutions to the DMARC mediated sender problem. Yahoo, for example, already consider the impact of this and other breakage to be less than the benefit of p=reject. I expect their willingness to invest engineering resources in further reducing a level of breakage they've already determined is acceptable will be limited. > > Given that, it had better be reasonably comprehensive. > >I expect that levine-dkim-conditional + "register addresses found in >List-Post as candidates for delegation when an authenticated user >posts" is as cheap as it's going to get, and will cover more than half >of mailing lists. I think that's pretty comprehensive for a start, >and thus something worth thinking about and looking for improvements, >rather than rejecting because it won't eliminate world poverty in 30 >days. I think that's at least one more than gets implemented. Scott K From nobody Sat May 9 12:02:07 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12531A907A for ; Sat, 9 May 2015 12:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBBjdFbPkKKz for ; Sat, 9 May 2015 12:02:04 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A975C1A9072 for ; Sat, 9 May 2015 12:02:04 -0700 (PDT) Received: from [192.168.111.105] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id CC7EBC40029; Sat, 9 May 2015 14:02:02 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1431198122; bh=oHKOlH4UcdbYLN7Aj5045ydh3sNlSEDmGjZUGbVk+Tk=; h=In-Reply-To:References:Subject:From:Date:To:From; b=lQ7v+kvkwkH+9ek0f/jzguu1bWDsjYRL6jnSFj1cf9TISoeuqxoB4+utKpvkAIh1B dq8HZNJBH3kZmLR7kqRbzgGGpeg3dQmZr4aBjXz3ilRxCOJiZNLBxlXn96Z2rzpUUU aTSA+LcCZy35yqdDqk3/in6qUKAjKMO7gGekfiKA= User-Agent: K-9 Mail for Android In-Reply-To: <797144B2-4A86-4229-B800-11BC857DA85F@isdg.net> References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <87y4ky2kif.fsf@uwakimon.sk.tsukuba.ac.jp> <90B1E4C8-A53D-4226-A1F6-E35CF57091C7@kitterman.com> <797144B2-4A86-4229-B800-11BC857DA85F@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Sat, 09 May 2015 15:01:59 -0400 To: dmarc@ietf.org Message-ID: <8CA948BD-E833-4D05-A9A1-71497F4647FB@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 19:02:06 -0000 On May 9, 2015 1:13:15 PM EDT, Hector Santos wrote: >Your bar is too unrealistically high for typical IETF project work that >is still in the experimental stages. You should be thankful, we >didn't apply this bar to the SPF experiment. It wasn't brought to be the IETF until it had substantial deployment. Actually, the idea behind MARID was to come up with a single solution and if not for one company insisting on licensing terms that would have precluded free software implementations, I think we would have succeeded. So I disagree. I think what I'm describing isn't that different than the non-political aspects of how SPF was handled. Scott K From nobody Sat May 9 13:44:01 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3D41ACEF8 for ; Sat, 9 May 2015 13:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.263 X-Spam-Level: ** X-Spam-Status: No, score=2.263 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdB9UWeK9jkY for ; Sat, 9 May 2015 13:43:58 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 737B51ACEE9 for ; Sat, 9 May 2015 13:43:58 -0700 (PDT) Received: (qmail 31550 invoked from network); 9 May 2015 20:43:59 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 9 May 2015 20:43:59 -0000 Date: 9 May 2015 20:43:34 -0000 Message-ID: <20150509204334.64209.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <201505091752.t49HqbQM006230@shadrach.encs.concordia.ca> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: mjassels@encs.concordia.ca Subject: Re: [dmarc-ietf] A Modest Proposal of Two Variations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 20:43:59 -0000 >Isn't the ideal objective of DMARC to be so reliable that *everybody* >uses it with p=reject. No. Most domains aren't subject to significant phishing attacks, so for them it's useful for incoming mail from Paypal et al, but not for outgoing mail. > At that point, 5322.From addresses will all > be munged. Why not skip the complexity and start munging them all now? Ewwww. R's, John From nobody Sat May 9 13:47:41 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C111ACF1A for ; Sat, 9 May 2015 13:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.08 X-Spam-Level: X-Spam-Status: No, score=-101.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnbsWJrVwOON for ; Sat, 9 May 2015 13:47:36 -0700 (PDT) Received: from catinthebox.net (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D6A7E1AD05B for ; Sat, 9 May 2015 13:47:35 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5307; t=1431204446; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=z+POqfYueObgzn5J4nEIi15/Ah0=; b=EK4g+MpoAKW3lD8Bv5de iJ1oIOFRf+qnPBuj20P21dTs5tkQg7DHEUcceDMRRe1+LwiFQ3cxsyMADmTtWFr2 5pa/YwhXhgjS2x41FzyyyAnRiWoEy38XVPuzjxRGYbRv2FDw2gyQmAKa62XKLuAD rPdeLueoe4mHRQNZfbCotAw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 09 May 2015 16:47:26 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 619468749.1150.4264; Sat, 09 May 2015 16:47:25 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5307; t=1431204169; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=LCc4V8F OTk9qcwRWbYYAZQPJ3KfenG+dVndvjDCaBgQ=; b=kG9NX3fPLgnUpUS8tx9BG2J R4SJfw26rDfGZiw8jdiDnoJxoSrVFKPkrOU7QzSUGAqWWzOCWxxZDWSjLbsi7hUx jsOSgsHrgKc9pk3eFuPZp9Cijr4tJvmCzYSW+wYFhpYChEx7eCTaykZiadeW+pkG ilAePuIkmJQfOEoxNTy4= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 09 May 2015 16:42:49 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3506705910.9.14104; Sat, 09 May 2015 16:42:49 -0400 Message-ID: <554E7261.5070408@isdg.net> Date: Sat, 09 May 2015 16:47:29 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Terry Zink , "dmarc@ietf.org" References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <87y4ky2kif.fsf@uwakimon.sk.tsukuba.ac.jp> <90B1E4C8-A53D-4226-A1F6-E35CF57091C7@kitterman.com> <797144B2-4A86-4229-B800-11BC857DA85F@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 20:47:39 -0000 Hi Terry, No one ever proposed an open-ended user access to DNS or APIs that access the backend, server side files. No, thats a clear security threat. As a design rule of SE thumb, you MUST never give normal and/or unregulated users access to system level operations. That is typically reserved for system operators and administrators, "gods" of the system. A compromised system, an inside job, bad guy got in, would be the #1 security threat as it always is for anything else. When it comes to hosting, a customer with one domain has the same SMTP and mail hosting functional and technical operational needs and requirements that a customer with a million domains. If you have a problem, its a bug whether its small, mid, large and operate privately, publicly or mixed with its domains. That is how I've designed hosting products that is for all customer types. For this application need, how one registers domains is entirely up to the domain including not registering at all as a corporate policy. Thats a product feature. It SHOULD also be a product feature that domains MAY register resigner domains in DNS for the purpose of performing domain authorization queries. Either way, its a feature to have for those who can do it and many customers will have the ability to handle their delegation of resigners using DNS. If one of your domains has a tougher problem with it, then you can't do it, period. That is why microsoft.com has an SPF hardfail but the other microsoft property public service domains do not. Let me ask you this, if you implement the conditional @fs method for your MLM,, are you going to honor the restrictive policies of incoming domains, those who will not want to have resigners of any kind and will not use the conditional @fs method themselves (no need)? Will you honor this rejection policies at the MLM, and in reality, across all Microsoft domains receivers? -- HLS On 5/9/2015 2:11 PM, Terry Zink wrote: > The reliability aspect is realistic to set a high bar. The decision to allow unregulated users to publish to the zones of Hotmail.com/outlook.com/msn.com/live.com/Hotmail.ca/outlook.ca/live.ca... etc. is one that comes with its own security challenges. This now no longer a way to allow indirect mailflow to pass DMARC, but instead how to figure out a way to secure your DNS zone. For the amount of work that would be, I would rather just inventory all mailing lists and if an email comes from it into a domain filtered by Microsoft, suppress DMARC. > > It's not just Microsoft's consumer brands. Office 365 hosts email for small, medium, and large businesses - each with their own DNS zone. If we have 500,000 domains [1] and there are 100,000 mailing lists, are we going to publish DNS records for the full matrix of combinations - 50 billion? Or even 1 billion? We don't control customer's DNS zones, so we'd have to convince our customers to publish these records and to do it on a regular basis. I can see nobody agreeing to do that. And if it won't work for Office 365 then it won't work for Hotmail, outlook.com, live.com, etc. > > I can't see the solution of publishing things in your DNS zone as a workable solution. That's why I like the conditional @fs DKIM signature better (or some variant of it) - it's done on the MTA level. A customer domain, example.com, can sign up for the Office 365 service and not have to publish any mailing list third party authorization in their zone. Instead, the sending MTA adds the required DKIM signatures and the receiving MTA decodes the incoming receiving signatures and does the right thing. The process is transparent to end users, most of whom don't want to update their DNS zones. > > -- Terry > > [1] I don't know exactly how many domains we have, I just picked this as an example. > > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Hector Santos > Sent: Saturday, May 9, 2015 10:13 AM > To: dmarc@ietf.org > Cc: dmarc@ietf.org > Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note > > Your bar is too unrealistically high for typical IETF project work that is still in the experimental stages. You should be thankful, we didn't apply this bar to the SPF experiment. > > -- > Hector Santos > http://www.santronics.com > >> On May 9, 2015, at 10:09 AM, Scott Kitterman wrote: >> >>> On May 9, 2015 5:00:24 AM EDT, "Stephen J. Turnbull" wrote: >>> Murray S. Kucherawy writes: >>> >>>> Agreed again. And as Terry has said and I think we can infer about >>>> other large operators, it's incorrect to assume (and plain wrong to >>>> assert) that this is an easy problem for them to solve in a >>>> reliable way. >>> >>> Please define "reliable." I gather you all think that missing some >>> mailing lists is a bigger problem than missing all of them, but for >>> the life of me, I cannot see why. >> >> How many solutions do you think operators will be willing to implement? As I indicated in my utility assessment framework, I think we get a maximum of one solution that requires cooperative implementations in multiple parts of the originator/mediator/receiver trilogy. Given that, it had better be reasonably comprehensive. >> >> Scott K >> From nobody Sat May 9 14:44:47 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB811B29E7 for ; Sat, 9 May 2015 14:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyTNdgMOUn6H for ; Sat, 9 May 2015 14:44:44 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C6A41B29EA for ; Sat, 9 May 2015 14:44:44 -0700 (PDT) Received: by pdbqa5 with SMTP id qa5so113501058pdb.1 for ; Sat, 09 May 2015 14:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=3Nhik3axrnkXJh2TPfYQar6yqjmv+q3qSD83QCh6MTw=; b=M1x8Xhx7TDX0ChVE0enee7bDhrWaTJPRaqthKVRoPCiQM+NvTjvvn3QEmfAEXeKYlX KiZjXVfl34eqVQR6feecp7Md5kdtqOVcHvbqgMbAYc2XxQtZ6P3Tqx7ilQurhToOAQmD 4phL6Mk1ZQ/xg8IVI66gzBEggH1jPAJKT4Xi+lMp3tFlgpR1Yl24kRxxxo+tZXIZGWbU pkErF8N/EN9CGmBS7Rba9I7m7TVCguz+dDYcYqUbtmPJW5d1yC5hAQxhvPulJOnnuQni K3lvHRBZkQEbf9bX30OBaD75XRQ6oXZZJ+XUWsJIIPwzdKR+UorAiFEFD4KuAVi431Xq 06yA== X-Received: by 10.68.94.129 with SMTP id dc1mr7266525pbb.8.1431207883682; Sat, 09 May 2015 14:44:43 -0700 (PDT) Received: from US-DOUGO-MAC.local ([2601:9:7300:1510:ac95:181f:5317:c0eb]) by mx.google.com with ESMTPSA id u3sm8817170pbs.30.2015.05.09.14.44.40 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 May 2015 14:44:42 -0700 (PDT) Message-ID: <554E7FCA.9040109@gmail.com> Date: Sat, 09 May 2015 14:44:42 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <87y4ky2kif.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 21:44:46 -0000 On 5/9/15 8:07 AM, Murray S. Kucherawy wrote: > On Sat, May 9, 2015 at 2:00 AM, Stephen J. Turnbull > wrote: > >> > Agreed again. And as Terry has said and I think we can infer about >> > other large operators, it's incorrect to assume (and plain wrong to >> > assert) that this is an easy problem for them to solve in a >> > reliable way. >> >> Please define "reliable." I gather you all think that missing some >> mailing lists is a bigger problem than missing all of them, but for >> the life of me, I cannot see why. > I'm having trouble coming up with a heuristic that is even certain to grab > "most" of them. Dear Murray, I'll create another DKIM extension to implement required replication of header fields for third-party domains. This can be implemented by just those originating the messages AND those implementing DMARC. Most mailing lists should not be impacted by the required header field approach, but this should remove a presumed need for yet another DKIM signature. I will have the DKIM extension draft published shortly. Also, you seem to dismiss a sizable corpus of DMARC feedback that can be verified by recent outbound logs. Of course only a DMARC domain imposing restrictive policies will have any need to implement this scheme which they should also see as their obligation if they have any desire to have their policy requests used. That said, the update to DKIM should be able to simplify what is contained in TPA-Label. Together, these methods only require implementation by the sender AND those imposing restrictive DMARC policy. Regards, Douglas Otis From nobody Sat May 9 16:26:36 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 493821B2B3D for ; Sat, 9 May 2015 16:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szxfI5Y0w1IL for ; Sat, 9 May 2015 16:26:33 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id AF3051B2B3F for ; Sat, 9 May 2015 16:26:33 -0700 (PDT) Received: from shadrach.encs.concordia.ca (mjassels@shadrach.encs.concordia.ca [132.205.47.207]) by oldperseverance.encs.concordia.ca (envelope-from mjassels@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t49NQVJh001739; Sat, 9 May 2015 19:26:32 -0400 Received: from shadrach.encs.concordia.ca (mjassels@localhost) by shadrach.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t49NQVsV007804; Sat, 9 May 2015 19:26:31 -0400 Message-Id: <201505092326.t49NQVsV007804@shadrach.encs.concordia.ca> X-Authentication-Warning: shadrach.encs.concordia.ca: mjassels owned process doing -bs To: "John Levine" From: Michael Jack Assels In-reply-to: <20150509204334.64209.qmail@ary.lan> References: <20150509204334.64209.qmail@ary.lan> Comments: In-reply-to "John Levine" message dated "09 May 2015 20:43:34 -0000." Date: Sat, 09 May 2015 19:26:31 -0400 X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-05-09 19:26:32 EDT Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] A Modest Proposal of Two Variations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2015 23:26:35 -0000 On 09 May 2015 20:43:34 -0000, "John Levine" wrote: > >Isn't the ideal objective of DMARC to be so reliable that *everybody* > >uses it with p=reject. > > No. Most domains aren't subject to significant phishing attacks, so > for them it's useful for incoming mail from Paypal et al, but not for > outgoing mail. I take it that a *significant* phishing attack is one where the 5322.From domain is involved with money, and the hook is a URL at a free web hosting site where the phisherpholk will harvest credentials so they can get some of that money? If that's the case, then perhaps you're right. Our little university domain gets plenty of annoying but insignificant phishing attacks, with the perps looking for credentials for ordinary student/faculty accounts that they can use to launch other, sometimes significant, phishing attacks (or just send a lot of spam). However, if the whole point of p=reject is to protect a relatively small number of sensitive domains like Paypal, iTunes, et al., then maybe it would be helpful simply to say so in a forthcoming standards track RFC, perhaps with words like A domain SHOULD NOT publish a p=reject policy if it will emit mail intended to be mediated with modifications by another domain unless the mediating domain is exempted from the policy by [fill in the eventually approved mechanism(s)]. That would at least nudge errant ESPs away from their misguided ways, and the rest of us can honor p=reject without losing any sleep over it. > > At that point, 5322.From addresses will all > > be munged. Why not skip the complexity and start munging them all now? > > Ewwww. FWIW, I did write that I wasn't keen on that approach. :-) MJA From nobody Sat May 9 17:32:10 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F891B2BB7 for ; Sat, 9 May 2015 17:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.263 X-Spam-Level: ** X-Spam-Status: No, score=2.263 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtLgpa-oyAV4 for ; Sat, 9 May 2015 17:32:07 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73DE81B2BB4 for ; Sat, 9 May 2015 17:32:07 -0700 (PDT) Received: (qmail 56976 invoked from network); 10 May 2015 00:32:09 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 10 May 2015 00:32:09 -0000 Date: 10 May 2015 00:31:43 -0000 Message-ID: <20150510003143.64805.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <201505092326.t49NQVsV007804@shadrach.encs.concordia.ca> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: mjassels@encs.concordia.ca Subject: Re: [dmarc-ietf] A Modest Proposal of Two Variations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 00:32:08 -0000 >> No. Most domains aren't subject to significant phishing attacks, so >> for them it's useful for incoming mail from Paypal et al, but not for >> outgoing mail. > >I take it that a *significant* phishing attack is one where the >5322.From domain is involved with money, and the hook is a URL at a >free web hosting site where the phisherpholk will harvest credentials so >they can get some of that money? No, it's one where the volume is high enough to be annoying. Sometimes it's looking for money, sometimes it's looking to steal account credentials or other stuff. I expect your users get phished a fair amount to steal accounts. But I also expect a lot of those phishes would be unaffected by DMARC. > A domain SHOULD NOT publish a p=reject policy if it will emit mail > intended to be mediated with modifications by another domain unless > the mediating domain is exempted from the policy by [fill in the > eventually approved mechanism(s)]. Right, that horse left the barn a year and a half ago. At this point we're doing damage control, viz. my double signing proposal which would make it somewhat easier for mailing lists et al to do what they do without the problem of current approaches that all lose useful features and/or require retraining users. R's, John From nobody Sat May 9 22:33:57 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3921A0127 for ; Sat, 9 May 2015 22:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCZrVm7b-jno for ; Sat, 9 May 2015 22:33:50 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id EB6BD1A0123 for ; Sat, 9 May 2015 22:33:49 -0700 (PDT) Received: from vindemiatrix.encs.concordia.ca (vin-anne@vindemiatrix.encs.concordia.ca [132.205.47.192]) by oldperseverance.encs.concordia.ca (envelope-from anne@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t4A5XnuA027756 for ; Sun, 10 May 2015 01:33:49 -0400 Received: from vindemiatrix.encs.concordia.ca (vin-anne@localhost) by vindemiatrix.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t4A5XmHd027523 for ; Sun, 10 May 2015 01:33:48 -0400 X-Authentication-Warning: vindemiatrix.encs.concordia.ca: vin-anne owned process doing -bs To: dmarc@ietf.org In-reply-to: Your message of Fri, 08 May 2015 18:47:58 EDT References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> From: Anne Bennett Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Date: Sun, 10 May 2015 01:33:48 -0400 Message-ID: <27522.1431236028@vindemiatrix.encs.concordia.ca> X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-05-10 01:33:49 EDT Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 05:33:53 -0000 Hector, >> Now of course we all know that if I used "!all" in my SPF >> record, this would break messages from my users who: > > Do you mean "-ALL" hardfail policy? Yes, sorry. >> 1 - ... are currently offsite but set their From: line to >> my domain, then submit mail through another provider. > > Roaming user. :) ... for which I think the correct solution is SMTP AUTH to *my* relay. >> 2 - ... post through a mailing list offsite which doesn't >> munge "From:". > > 5322.From is not SPF related. You mean the 5321.MailFrom? Yes, the SMTP "MAIL FROM". Sorry again. >> 3 - ... send to recipients who in turn forward their mail >> (without fancy workarounds) to a third site. > > A simple relay, sure, SPF has that problem you will only see > for -ALL policies. >> But if I understand correctly, it's being suggested that for >> various proposals made here to work, either the sender's mail >> system or the final receiver's mail system would have to become >> aware of all of the "legitimate" (definition purposely left >> out!) mailing lists to which its users subscribe. [...] >> I believe that some people have claimed that this problem is >> easily overcome (or perhaps "worked around" would be a better >> expression) by examining mail headers and gathering statistics, >> and this may well be the case, but addressing the problem in >> this way will always depend on heuristics, just like any other >> anti-spam method. > I agree. This is why it is a separate implementation issue. We are > looking for a deterministic protocol solution. The lack of not > having the "registration" in place first should not stop one from > "checking" to see if it exist. Certainly a protocol could be defined with "apply local policy here, and return ACCEPT or REJECT based on the results", and from the point of view of a protocol, that works and is implementable. We already have that with SMTP, where we can return "550 Get lost spammer" if we wish, based on whatever heuristics or rules we like. But I thought the point of DMARC was to determine reliably (using cryptographic keys and/or IP addresses as published by the alleged originating domain in the DNS under their control) whether the domain in the "From:" header is really responsible for originating a given message, and I thought the problem we're trying to solve here is how we can prevent DMARC from breaking "mediated" mail (such as mailing list mail). So far our options seem to be: - Pass the mail through entirely unmunged, to avoid invalidating the DKIM signature - which means giving up features that have been useful on mailing lists for decades, - Munge the "From:" header to have the mailing list "take ownership" of the message, at least for messages sent by users in p=reject domains - which is already implemented as an option in at least one major MLM, but is not popular philosophically (because people expect the From: line to specify the author of a post) or in practice (because it makes it harder for the recipient to choose to reply to the list or to the original sender as they wish), - Come up with a scheme allowing the mailing list to "re-sign" a slightly munged version of the message, which is what I think we're arguing about. The apparent problem is that a spammer or fraudster or malware propagator can do to a message anything a mailing list can do. There's a suggestion that if legitimate mailing lists can somehow be identified (the "registration problem"), all will be well. If I can summarize my understanding of the argument so far, some people are saying "apply heuristics to the registration problem, that should take care of things well enough", and others are saying "no, no, no, we had a deterministic thing of beauty with DMARC, you mustn't wreck it with non-deterministic, implementation dependent heuristics". Well, I myself wouldn't call something a thing of beauty when it wrecks the functioning of mailing lists when used as intended, but I also think it's pointless to try to specify a protocol that allows for implementation-dependent heuristic decisions to "solve this problem". Any e-mail provider can already arbitrarily decide to ignore DMARC for mail they think is list mail, if they want to. Sure, then they couldn't call themselves "DMARC compliant", but who would lose sleep over that? Honestly, are Google and Yahoo competing for each other's e-mail users by advertising that they're the best because they're DMARC compliant? Perhaps I'm naïve about the politics of all this (actually, that is certainly the case!), but I suspect that almost all sites, especially the big ones, do as they please. If I can step back a bit, all DMARC does is ensure that the site in the "From:" line signed (or, via SPF, transmitted) *this* message. A malefactor can send DKIM-signed or SPF-approved messages as easily as anyone else. Some of the proposed solutions involve a mediating site making modifications, and signing its specific modifications. A malefactor can do that too, of course, but is this really any worse than the original situation? A receiver doesn't stop checking a message after it passes DMARC as currently specified, because it may be that the site @spammer.com is one whose messages we don't want, or it may be that user@goodguy.com had his account phished and is suddenly sending trash. A receiver wouldn't stop checking messages after the munged and re-signed version passes a "new DMARC", for the above reasons *and* because it might not want messages from "@spamlists.com", or because "goodlist@lots-of-lists.com" could sometimes pass a bad message. Nothing about DMARC or DKIM states that a message is okay - that part is checked by other (yes, heuristic) parts of the mail system. Nothing about an expanded DMARC or DKIM with "re-signing of modifications" needs to be construed as stating that a message is okay. Hmm, Hector, I think you've forced me to convince myself that you're on the right track: I think that the "registration problem" is a red herring after all. There's no deterministic way to decide what's a legitimate mailing list (or other re-signer), any more than there's any way to deterministically decide what's a legitimate originator. Those determinations are made heuristically outside DMARC. Meanwhile, DMARC (and potentially an expanded "re-signing" version) can verify only the authenticity of the originator (and of the re-signer), and thus the authenticity of the original message (and of the modifications), which is still useful. >> What am I missing? > > Nothing. :) ... except a copy editor. ;-) Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne@encs.concordia.ca +1 514 848-2424 x2285 From nobody Sat May 9 23:01:47 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908F71A01A9 for ; Sat, 9 May 2015 23:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fYyuPvQVWUc for ; Sat, 9 May 2015 23:01:44 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E1E81A01A8 for ; Sat, 9 May 2015 23:01:44 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 381BCC40243 for ; Sun, 10 May 2015 01:01:43 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1431237703; bh=KFa8uu+BPnVhXSLkELgB4SSJG20N6H34/X0JGn+VyQ0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=sKD/lHsCtPbuZUhiCyHKgB5s0J6jyp2RL9fwFC60U0CVdFeUrQNlue9eDbolVGjF5 Rejm2bxBrbzrZjdz1IYhZYW8K5OLVVKNYPro6fDDbJVrMbi0D8icg0WoWzh1ysoHJd JVO7QFJd2RLto66EJbshCApgR3eeI9RHBRteW+RQ= From: Scott Kitterman To: dmarc@ietf.org Date: Sun, 10 May 2015 02:01:43 -0400 Message-ID: <4565565.Pr7bo1LBhp@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-51-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <27522.1431236028@vindemiatrix.encs.concordia.ca> References: <554BC30F.1020107@isdg.net> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 06:01:45 -0000 On Sunday, May 10, 2015 01:33:48 AM Anne Bennett wrote: > Hmm, Hector, I think you've forced me to convince myself that you're > on the right track: I think that the "registration problem" is a red > herring after all. There's no deterministic way to decide what's a > legitimate mailing list (or other re-signer), any more than there's any > way to deterministically decide what's a legitimate originator. Those > determinations are made heuristically outside DMARC. If that's the case, we're done. Large providers already do this reasonably well. I think you've got it backwards. There's no deterministic way to determine what's a legitimate mailing list, so any solution that insists you do so, it's feasible. Scott K From nobody Sat May 9 23:07:36 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C642F1A01F4 for ; Sat, 9 May 2015 23:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AOW0TKc8eFk for ; Sat, 9 May 2015 23:07:33 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B8781A01F0 for ; Sat, 9 May 2015 23:07:32 -0700 (PDT) Received: by wizk4 with SMTP id k4so71003018wiz.1 for ; Sat, 09 May 2015 23:07:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GobAbt0OPHdVEJNjlxg/mFlOTQFE8sYqpj3nE3N+vC0=; b=Nr1J3UGe9ahq4AZ3ex0SNmAz+LoGGXYlxEZfjK66JV6ftdg6IrOcSLOnAvojrfhmU+ xMO/UA3Tvd6m4Sd+hmslFdJyJNfHtD/XvvXvIQ3RUN9Pwf7icjfhQHMtOcZdm67yiAOt OP6gSz4BPGUvHfRt7YlP2hSHEGVGdH6PTKwtQLjzGMZQbUfsioraXyA4t6/GIN7N4Uww ywYMjbB4LDq80UbddLzYtvyyCj5s8hI15Y1q7gOt54TWB9lJ38q48bU2uLmkup5DZZy0 aAT7JGXxG2c2lcaW4h4S04RxRIeE9C45sVS9awLrl0lM/YRIwW9KZ5cYuLebgE/7Ie1n 0Apw== MIME-Version: 1.0 X-Received: by 10.180.83.195 with SMTP id s3mr10849065wiy.52.1431238051784; Sat, 09 May 2015 23:07:31 -0700 (PDT) Received: by 10.27.170.134 with HTTP; Sat, 9 May 2015 23:07:31 -0700 (PDT) In-Reply-To: <27522.1431236028@vindemiatrix.encs.concordia.ca> References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> Date: Sat, 9 May 2015 23:07:31 -0700 Message-ID: From: "Murray S. Kucherawy" To: Anne Bennett Content-Type: multipart/alternative; boundary=f46d04428d1caa6f860515b413fb Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 06:07:35 -0000 --f46d04428d1caa6f860515b413fb Content-Type: text/plain; charset=UTF-8 On Sat, May 9, 2015 at 10:33 PM, Anne Bennett wrote: > Hmm, Hector, I think you've forced me to convince myself that you're > on the right track: I think that the "registration problem" is a red > herring after all. There's no deterministic way to decide what's a > legitimate mailing list (or other re-signer), any more than there's any > way to deterministically decide what's a legitimate originator. Those > determinations are made heuristically outside DMARC. > Numerous proposals have appeared over the years to solve the Mediator problem and its ilk, all of which involve advertising in some way that two domains are related somehow. The favorite example is "A can sign B's mail", with the implication being "and you should act as if B signed it". There are several problems with an approach like this: 1) The favorite way to advertise and check this is DNS. There are several arguments about why this needs to be avoided, so doing it again always draws them out again. 2) There isn't a nice way so far to do this at other than the domain level. That means any actor inside "A" can sign mail that claims to come from "B". So if "A" is compromised, "B" is hosed. The "B"s of the world tend not to be so thrilled with this. 3) Very large operators have millions or even billions of users. For "A can sign B's mail" to work, the set "A" for those operators is potentially enormous. (I think Yahoo quoted numbers well into five figures.) The "B's of the world tend not to be thrilled with this at all either, because every domain in the set "A" is a potential exposure. How do we populate the set? Either we do it (a) heuristically, because as you said it's not deterministic; (b) via a central authority (trusted by whom, exactly?); or (c) by letting the users of "B" populate it (which is obviously, one would hope, a huge abuse vector). This "How do we populate the set?" is "the registration problem". There are some implicit "safely" and "at scale" adverbs in there too, just for flavor. So suppose you come up with a heuristic that works for you. It reliably (magically?) adds a domain to the set "A" when a user at your domain subscribes to a list operated by a mediator within that domain, and reliably (magically?) removes it the minute all such relationships with that domain are broken. You are still faced with (1) and (2) above. Moreover, the magic you have to come up with would presumably watch your incoming and outgoing mail looking for things that look like lists, and update "A" when such are observed. Now I'm a Bad Guy(tm). I want to be able to send people mail that they believe is at least endorsed by you. I send mail to a random user at your site that looks like list traffic coming from BadGuyDomain.com. Your heuristic adds that domain to "A" because you don't want to mess with that user's list experience. Voila, I am now able to phish as you. So yes, DMARC doesn't necessarily need to spell out a solution to the registration problem. But that's not the issue; the concern is whether endorsing a solution that requires a registration step, regardless of how it's accomplished, is a pragmatic thing to pursue in the first place. -MSK --f46d04428d1caa6f860515b413fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, May 9, 2015 at 10:33 PM, Anne Bennett <anne@= encs.concordia.ca> wrote:
Hmm= , Hector, I think you've forced me to convince myself that you're on the right track: I think that the "registration problem" is a = red
herring after all.=C2=A0 There's no deterministic way to decide what= 9;s a
legitimate mailing list (or other re-signer), any more than there's any=
way to deterministically decide what's a legitimate originator.=C2=A0 T= hose
determinations are made heuristically outside DMARC.
<= br>
Numerous proposals have appeared over the years to solve the Media= tor problem and its ilk, all of which involve advertising in some way that = two domains are related somehow.=C2=A0 The favorite example is "A can = sign B's mail", with the implication being "and you should ac= t as if B signed it".

There are several problem= s with an approach like this:

1) The favorite way to adve= rtise and check this is DNS.=C2=A0 There are several arguments about why th= is needs to be avoided, so doing it again always draws them out again.
<= br>
2) There isn't a nice way so far to do this at other than= the domain level.=C2=A0 That means any actor inside "A" can sign= mail that claims to come from "B".=C2=A0 So if "A" is = compromised, "B" is hosed.=C2=A0 The "B"s of the world = tend not to be so thrilled with this.

3) Very large opera= tors have millions or even billions of users.=C2=A0 For "A can sign B&= #39;s mail" to work, the set "A" for those operators is pote= ntially enormous.=C2=A0 (I think Yahoo quoted numbers well into five figure= s.)=C2=A0 The "B's of the world tend not to be thrilled with this = at all either, because every domain in the set "A" is a potential= exposure.=C2=A0 How do we populate the set?=C2=A0 Either we do it (a) heur= istically, because as you said it's not deterministic; (b) via a centra= l authority (trusted by whom, exactly?); or (c) by letting the users of &qu= ot;B" populate it (which is obviously, one would hope, a huge abuse ve= ctor).

This "How do we populate the set?" is &q= uot;the registration problem".=C2=A0 There are some implicit "saf= ely" and "at scale" adverbs in there too, just for flavor.
So suppose you come up with a heuristic that works for you= .=C2=A0 It reliably (magically?) adds a domain to the set "A" whe= n a user at your domain subscribes to a list operated by a mediator within = that domain, and reliably (magically?) removes it the minute all such relat= ionships with that domain are broken.=C2=A0 You are still faced with (1) an= d (2) above.

Moreover, the magic you have to come up with would pres= umably watch your incoming and outgoing mail looking for things that look l= ike lists, and update "A" when such are observed.=C2=A0 Now I'= ;m a Bad Guy(tm).=C2=A0 I want to be able to send people mail that they bel= ieve is at least endorsed by you.=C2=A0 I send mail to a random user at you= r site that looks like list traffic coming from BadGuyDomain.com.=C2=A0 You= r heuristic adds that domain to "A" because you don't want to= mess with that user's list experience.=C2=A0 Voila, I am now able to p= hish as you.

So yes, DMARC doesn't necessarily need t= o spell out a solution to the registration problem.=C2=A0 But that's no= t the issue; the concern is whether endorsing a solution that requires a re= gistration step, regardless of how it's accomplished, is a pragmatic th= ing to pursue in the first place.

-MSK
--f46d04428d1caa6f860515b413fb-- From nobody Sat May 9 23:14:11 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC57D1A01F4 for ; Sat, 9 May 2015 23:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nn96T1uCwly6 for ; Sat, 9 May 2015 23:14:08 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FD691A0196 for ; Sat, 9 May 2015 23:14:08 -0700 (PDT) Received: by wizk4 with SMTP id k4so71079054wiz.1 for ; Sat, 09 May 2015 23:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BC8/u3KQKWdAwS/VZq7UR3e9y6ozzR4XaLp1uV+aVi4=; b=JsSuKZ4ku5uDEJCfXb7JQp6eOA4f1MA+TmoI9taULk3wAthlXpx/GKNrNjTeThghfB ujL5Eq4EYY0fR6SVfqjOOomBFyoXNppEJ3Vc0Z2R0w1xcGyODDcN/NvxeQJqEqmM8Q1E EYBAasHw2prfDp1ETgpF9irFc1F33cQlYNteCqhUzM1ey6qSL9fwftCEJeIpByuzzAHb ShT9eoO5jv26Ao5yjz9YVgtsfd4p3JGK65krzfLJ77KvcLm3UCcGulAX5T0tny0YWgxX p8abYTsLDp0x13g5F2M0QAtKH2u4RpA8o+5uZBuCJUz9iiI5XLAERO5i4bBgfnlau2Yt e8NQ== MIME-Version: 1.0 X-Received: by 10.194.242.101 with SMTP id wp5mr9663626wjc.4.1431238447247; Sat, 09 May 2015 23:14:07 -0700 (PDT) Received: by 10.27.170.134 with HTTP; Sat, 9 May 2015 23:14:07 -0700 (PDT) In-Reply-To: <27522.1431236028@vindemiatrix.encs.concordia.ca> References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> Date: Sat, 9 May 2015 23:14:07 -0700 Message-ID: From: "Murray S. Kucherawy" To: Anne Bennett Content-Type: multipart/alternative; boundary=089e01419f523cb6360515b42ba9 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 06:14:09 -0000 --089e01419f523cb6360515b42ba9 Content-Type: text/plain; charset=UTF-8 On Sat, May 9, 2015 at 10:33 PM, Anne Bennett wrote: > Hmm, Hector, I think you've forced me to convince myself that you're > on the right track: I think that the "registration problem" is a red > herring after all. There's no deterministic way to decide what's a > legitimate mailing list (or other re-signer), any more than there's any > way to deterministically decide what's a legitimate originator. Those > determinations are made heuristically outside DMARC. > I suppose the tl;dr version of my last reply is: The registration problem is not a red herring because it doesn't exist, but because it is intractable. Thus, any response to the third-party problem that relies on a solution to that problem (which includes ATPS, DSAP, and TPA) is probably not viable. -MSK --089e01419f523cb6360515b42ba9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, May 9, 2015 at 10:33 PM, Anne Bennett <anne@= encs.concordia.ca> wrote:
Hmm, Hector, I think y= ou've forced me to convince myself that you're
on the right track: I think that the "registration problem" is a = red
herring after all.=C2=A0 There's no deterministic way to decide what= 9;s a
legitimate mailing list (or other re-signer), any more than there's any=
way to deterministically decide what's a legitimate originator.=C2=A0 T= hose
determinations are made heuristically outside DMARC.
<= br>
I suppose the tl;dr version of my last reply is:

The registration problem is not a red herring because it doesn't = exist, but because it is intractable.=C2=A0 Thus, any response to the third= -party problem that relies on a solution to that problem (which includes AT= PS, DSAP, and TPA) is probably not viable.

-MSK
=
--089e01419f523cb6360515b42ba9-- From nobody Sat May 9 23:30:00 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEB91A0276 for ; Sat, 9 May 2015 23:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjFRBiVQKA7l for ; Sat, 9 May 2015 23:29:57 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (mail-sn2ln0090.outbound.o365filtering.com [IPv6:2a01:111:f400:7c04::90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96F6E1A0263 for ; Sat, 9 May 2015 23:29:56 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB606.namsdf01.sdf.exchangelabs.com (10.255.109.168) with Microsoft SMTP Server (TLS) id 15.1.172.7; Sun, 10 May 2015 06:29:30 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.5.234]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.5.234]) with mapi id 15.01.0172.012; Sun, 10 May 2015 06:29:30 +0000 From: Terry Zink To: "Murray S. Kucherawy" , Anne Bennett Thread-Topic: [dmarc-ietf] DMARC ATPS Interop Note Thread-Index: AQHQiP+6B7ZwIu+OF0u+XlWpPn2/QZ1w9m6AgAALsICAAA8mAIABReU9gABY5gCAAgPMRoAACzCAgAAD/VA= Date: Sun, 10 May 2015 06:29:28 +0000 Message-ID: References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.165.40.56] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB606; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51444003)(377454003)(51704005)(24454002)(199003)(189002)(93886004)(62966003)(77156002)(2656002)(76176999)(54356999)(50986999)(106356001)(106116001)(19580395003)(19580405001)(5001830100001)(87936001)(5001860100001)(101416001)(97736004)(5001770100001)(4001540100001)(81156007)(64706001)(66066001)(86362001)(105586002)(46102003)(33656002)(2900100001)(2950100001)(92566002)(102836002)(5001960100002)(68736005)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB606; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005002)(5002009)(3002001); SRVR:BL2SR01MB606; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB606; x-forefront-prvs: 05724A8921 received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2015 06:29:28.4689 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB606 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 06:29:59 -0000 PiBJIHN1cHBvc2UgdGhlIHRsO2RyIHZlcnNpb24gb2YgbXkgbGFzdCByZXBseSBpczoNCj4NCj4g VGhlIHJlZ2lzdHJhdGlvbiBwcm9ibGVtIGlzIG5vdCBhIHJlZCBoZXJyaW5nIGJlY2F1c2UgaXQg ZG9lc24ndCBleGlzdCwgYnV0IGJlY2F1c2UgaXQgDQo+IGlzIGludHJhY3RhYmxlLsKgIFRodXMs IGFueSByZXNwb25zZSB0byB0aGUgdGhpcmQtcGFydHkgcHJvYmxlbSB0aGF0IHJlbGllcyBvbiBh IHNvbHV0aW9uIA0KPiB0byB0aGF0IHByb2JsZW0gKHdoaWNoIGluY2x1ZGVzIEFUUFMsIERTQVAs IGFuZCBUUEEpIGlzIHByb2JhYmx5IG5vdCB2aWFibGUuDQoNCisxLg0KDQotLSBUZXJyeQ0KDQpG cm9tOiBkbWFyYyBbbWFpbHRvOmRtYXJjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBN dXJyYXkgUy4gS3VjaGVyYXd5DQpTZW50OiBTYXR1cmRheSwgTWF5IDksIDIwMTUgMTE6MTQgUE0N ClRvOiBBbm5lIEJlbm5ldHQNCkNjOiBkbWFyY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtkbWFy Yy1pZXRmXSBETUFSQyBBVFBTIEludGVyb3AgTm90ZQ0KDQpPbiBTYXQsIE1heSA5LCAyMDE1IGF0 IDEwOjMzIFBNLCBBbm5lIEJlbm5ldHQgPGFubmVAZW5jcy5jb25jb3JkaWEuY2E+IHdyb3RlOg0K SG1tLCBIZWN0b3IsIEkgdGhpbmsgeW91J3ZlIGZvcmNlZCBtZSB0byBjb252aW5jZSBteXNlbGYg dGhhdCB5b3UncmUNCm9uIHRoZSByaWdodCB0cmFjazogSSB0aGluayB0aGF0IHRoZSAicmVnaXN0 cmF0aW9uIHByb2JsZW0iIGlzIGEgcmVkDQpoZXJyaW5nIGFmdGVyIGFsbC7CoCBUaGVyZSdzIG5v IGRldGVybWluaXN0aWMgd2F5IHRvIGRlY2lkZSB3aGF0J3MgYQ0KbGVnaXRpbWF0ZSBtYWlsaW5n IGxpc3QgKG9yIG90aGVyIHJlLXNpZ25lciksIGFueSBtb3JlIHRoYW4gdGhlcmUncyBhbnkNCndh eSB0byBkZXRlcm1pbmlzdGljYWxseSBkZWNpZGUgd2hhdCdzIGEgbGVnaXRpbWF0ZSBvcmlnaW5h dG9yLsKgIFRob3NlDQpkZXRlcm1pbmF0aW9ucyBhcmUgbWFkZSBoZXVyaXN0aWNhbGx5IG91dHNp ZGUgRE1BUkMuDQoNCkkgc3VwcG9zZSB0aGUgdGw7ZHIgdmVyc2lvbiBvZiBteSBsYXN0IHJlcGx5 IGlzOg0KVGhlIHJlZ2lzdHJhdGlvbiBwcm9ibGVtIGlzIG5vdCBhIHJlZCBoZXJyaW5nIGJlY2F1 c2UgaXQgZG9lc24ndCBleGlzdCwgYnV0IGJlY2F1c2UgaXQgaXMgaW50cmFjdGFibGUuwqAgVGh1 cywgYW55IHJlc3BvbnNlIHRvIHRoZSB0aGlyZC1wYXJ0eSBwcm9ibGVtIHRoYXQgcmVsaWVzIG9u IGEgc29sdXRpb24gdG8gdGhhdCBwcm9ibGVtICh3aGljaCBpbmNsdWRlcyBBVFBTLCBEU0FQLCBh bmQgVFBBKSBpcyBwcm9iYWJseSBub3QgdmlhYmxlLg0KLU1TSw0K From nobody Sun May 10 07:04:52 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26301A90C1 for ; Sun, 10 May 2015 07:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.802 X-Spam-Level: X-Spam-Status: No, score=-100.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_22=0.6, J_CHICKENPOX_46=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6xu5y5kGWuw for ; Sun, 10 May 2015 07:04:48 -0700 (PDT) Received: from mail.catinthebox.net (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5C81A90BF for ; Sun, 10 May 2015 07:04:47 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2611; t=1431266677; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=PQ46N076aeGVFAOjzCb98QsTSHU=; b=AuDeRgJCBkXOxLZ6CMZU p4tXfGDJPBP5O9Id/WaW6MhEYBdQXvAT4bfz8FpObq+rcCgGxgakDfDeOS4xUUCp E0QTwpH6bj3oJIrCjbOIum3OANwnmGkJXMevxYj4B3algpbAJgyO7Yuzex75icmT aE2U/Ri7mOP9u7M/Y0gXHqg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 10 May 2015 10:04:37 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from opensite.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 681699919.3360.5192; Sun, 10 May 2015 10:04:36 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2611; t=1431266400; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=nN/ucK5 MyDnCEja/e9TSfwpuCzljDrxJjBs3JbQVquY=; b=FxakyIjQCVUU62qdou89uiz oHbsIjGv5o35Q875H+5Z+m+5wEXgXNkZRXxMjtamM+rTZO22qY3HQzdEavGxHDZs OvjEUY1esEwm+eihzwfModYobGa6eJGzhoL/Dw2JxYc/LOs1qEEp9PyAJsxqyHLb jmfCPqMUXQWFeom11aig= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 10 May 2015 10:00:00 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3568936223.9.12856; Sun, 10 May 2015 09:59:59 -0400 Message-ID: <554F6571.8090600@isdg.net> Date: Sun, 10 May 2015 10:04:33 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Anne Bennett References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 14:04:51 -0000 On 5/10/2015 2:14 AM, Murray S. Kucherawy wrote: > On Sat, May 9, 2015 at 10:33 PM, Anne Bennett > wrote: > > Hmm, Hector, I think you've forced me to convince myself that you're > on the right track: I think that the "registration problem" is a red > herring after all. There's no deterministic way to decide what's a > legitimate mailing list (or other re-signer), any more than > there's any > way to deterministically decide what's a legitimate originator. Those > determinations are made heuristically outside DMARC. > > > I suppose the tl;dr version of my last reply is: > > The registration problem is not a red herring because it doesn't > exist, but because it is intractable. Thus, any response to the > third-party problem that relies on a solution to that problem (which > includes ATPS, DSAP, and TPA) is probably not viable. Thats a fine opinion, but you have no evidence to show whether it was possible or not because the efforts to do were crippled or hampered by other focuses. Brush off work, crippling it should not be used as evidence of lack of traction or difficulty in publishing records. Besides the trust focus during DKIM-WG, ADSP was being down played and the MLM was encouraged not to support it. With the level of demotion that existed primarily because of its conflict with the MLM, it was hard to imagine anyone that wasn't nimble and flexible to support it. It wasn't complete. It was all in pieces. But you replaced ADSP with DMARC and when you did so, you didn't update ATPS to work off DMARC where it was suppose to be at. So that was the proper next step. It isn't an equal situation until then. Now you got DMARC support -- meaning, RECEIVERS are doing the lookup for these records and actually honoring the rejection policy. Therefore, ATPS-rev04 should be updated for DMARC or revert rfc6541 to make it work off the DMARC record. Then maybe the Yahoos will *think* about it, because they would have a choice to do so. When ready, they can add simple tag(s) to DMARC: [atps=y; [atpsh=hash-method;]] All optional and give the receivers a simple choice to look it up: if dmarc["atps'] == "y" and author is not the signer then do a atps(author, signer) lookup That's the optimized solution. At this point we don't really need the dmarc "atps=y" signal. We can use use the idea that the author does not equal the signer. I would like to see ATPS-rev04 resurrected with the DMARC optimizing hook or off the mismatch of author and signer. -- HLS From nobody Sun May 10 07:05:15 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8BBD1A90BF for ; Sun, 10 May 2015 07:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbK1Yi-FtGGT for ; Sun, 10 May 2015 07:05:10 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 981931A90C7 for ; Sun, 10 May 2015 07:05:10 -0700 (PDT) Received: from vindemiatrix.encs.concordia.ca (vin-anne@vindemiatrix.encs.concordia.ca [132.205.47.192]) by oldperseverance.encs.concordia.ca (envelope-from anne@encs.concordia.ca) (8.13.7/8.13.7) with ESMTP id t4AE59bG022867 for ; Sun, 10 May 2015 10:05:09 -0400 Received: from vindemiatrix.encs.concordia.ca (vin-anne@localhost) by vindemiatrix.encs.concordia.ca (8.14.4/8.14.4/Submit) with ESMTP id t4AE59PT014448 for ; Sun, 10 May 2015 10:05:09 -0400 X-Authentication-Warning: vindemiatrix.encs.concordia.ca: vin-anne owned process doing -bs To: "dmarc@ietf.org" In-reply-to: Your message of Sat, 09 May 2015 23:07:31 PDT References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> From: Anne Bennett Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Date: Sun, 10 May 2015 10:05:09 -0400 Message-ID: <14447.1431266709@vindemiatrix.encs.concordia.ca> X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2015-05-10 10:05:09 EDT Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 14:05:14 -0000 Murray, >> I think that the "registration problem" is a red >> herring after all. There's no deterministic way to decide what's a >> legitimate mailing list (or other re-signer), any more than there's any >> way to deterministically decide what's a legitimate originator. Those >> determinations are made heuristically outside DMARC. > Numerous proposals have appeared over the years to solve the Mediator > problem and its ilk, all of which involve advertising in some way that > two domains are related somehow. The favorite example is "A can sign B's > mail", with the implication being "and you should act as if B signed it". Ah, okay; in that case I will respond to your summary: > The registration problem is not a red herring because it doesn't > exist, but because it is intractable. Thus, any response to the > third-party problem that relies on a solution to that problem > (which includes ATPS, DSAP, and TPA) is probably not viable. I agree. But I think that some of the "re-signing" schemes being proposed at the moment do *not* require this type of registration, so in those cases, the registration problem wouldn't apply. If A is not "signing B's mail", but rather, "signing its own modifications to B's message", then the evaluation of the two signatures doesn't require a published or pre-existing relationship between the two domains. Under at least one of the proposals, it can be determined that "yes, A signed the mods, and if the mods are removed to re-generate the original message, B signed the original message". If we have that, then I think the question becomes: if this is to be a DMARC-like scheme, how do we tie A's signature to some kind of relevant header field, since the "From:" header is already "reserved" for the original signer. Now despite injunctions on this list against referring to the user interface, the fact is that DMARC uses the "holy From: header" to extract the "alignable domain". Unless I'm gravely mistaken, the reason for that *is* indeed that this field is shown to the user (in some form) by every user agent out there, and the user is thought to place a fair deal of confidence in the "truth" of that header. Unless we can state something similar with respect to another header, I suspect that anything we propose will be considered to be watering down DMARC to an unacceptable extent. :-( Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 anne@encs.concordia.ca +1 514 848-2424 x2285 From nobody Sun May 10 07:37:49 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531BF1A0235 for ; Sun, 10 May 2015 07:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.08 X-Spam-Level: X-Spam-Status: No, score=-101.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1V2E9nNWkgc for ; Sun, 10 May 2015 07:37:47 -0700 (PDT) Received: from mail.catinthebox.net (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0791A01E2 for ; Sun, 10 May 2015 07:37:47 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1370; t=1431268663; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=/2y0MduUVV49BD928H+LbYWZmqk=; b=ZFGStPWPH4RAkXCa89pf rBdLFwmKTVEfGhrkzRtBdwmOTHCDQiF2Hezinxcl7RWltQRWm/bUkqt8K5mHozk/ MPSXHWn8sS+DBbx2TNZ/AVOKRAPpcORH55DhvVjTm5uVU8ScKGZE23xGzSqVRyLL B5u1XLPo5lclbHa2qFuVWDg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 10 May 2015 10:37:43 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from opensite.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 683684985.3360.3676; Sun, 10 May 2015 10:37:42 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1370; t=1431268387; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=632MQwk BIsDB0NHjax5aAjiGdYwD8zqRSk5gVf43TJM=; b=VsdlDONexCUve/UQi2zTbKO jB1bNaaJ9WTKDVkrA8UHUJRPZmWXBdHEXD99eaJT83JMJFpDs3iFLjsWvHw+OcI7 DoHBKS1BjJz9ROekbY9paq+bdzeLgLxnfGvBmY8nfVE+CGr2Hc8q5FymHBTfzUXp /knDp9T1pnJDXv9OgLeg= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 10 May 2015 10:33:07 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3570923270.9.14196; Sun, 10 May 2015 10:33:06 -0400 Message-ID: <554F6D34.7040507@isdg.net> Date: Sun, 10 May 2015 10:37:40 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <87y4ky2kif.fsf@uwakimon.sk.tsukuba.ac.jp> <90B1E4C8-A53D-4226-A1F6-E35CF57091C7@kitterman.com> <797144B2-4A86-4229-B800-11BC857DA85F@isdg.net> <8CA948BD-E833-4D05-A9A1-71497F4647FB@kitterman.com> In-Reply-To: <8CA948BD-E833-4D05-A9A1-71497F4647FB@kitterman.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 14:37:48 -0000 On 5/9/2015 3:01 PM, Scott Kitterman wrote: > On May 9, 2015 1:13:15 PM EDT, Hector Santos wrote: >> Your bar is too unrealistically high for typical IETF project work that >> is still in the experimental stages. You should be thankful, we >> didn't apply this bar to the SPF experiment. > > It wasn't brought to be the IETF until it had substantial deployment. > > Actually, the idea behind MARID was to come up with a single solution and if not for one company insisting on licensing terms that would have precluded free software implementations, I think we would have succeeded. > > So I disagree. I think what I'm describing isn't that different than the non-political aspects of how SPF was handled. > Scott, MARID got started when Microsoft introduced CEP, the XML version of SPF. As an early explorer before MARID, I supported CEP as well as most of the LMAP ideas such as DMP which predated SPF. LMAP was a framework for an IP Domain Association protocol; LMAP = IP::DOMAIN and we had the same resistance and arguments about complexity, DNS management issues, false positive, DoS issues, overhead and waste issues, name it, the same arguments. Yet, you pleaded to consider the small guy and not allow "complexity" to not hamper progress. http://www.imc.org/ietf-mxcomp/mail-archive/msg02197.html -- HLS From nobody Sun May 10 08:11:26 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAC51A1A45 for ; Sun, 10 May 2015 08:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.899 X-Spam-Level: *** X-Spam-Status: No, score=3.899 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybLR-RFlvwac for ; Sun, 10 May 2015 08:11:24 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 422631A1A42 for ; Sun, 10 May 2015 08:11:23 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 8AECF1C38F1; Mon, 11 May 2015 00:11:22 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 64DAC11F6A1; Mon, 11 May 2015 00:11:22 +0900 (JST) From: "Stephen J. Turnbull" To: Michael Jack Assels In-Reply-To: <201505092326.t49NQVsV007804@shadrach.encs.concordia.ca> References: <20150509204334.64209.qmail@ary.lan> <201505092326.t49NQVsV007804@shadrach.encs.concordia.ca> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Mon, 11 May 2015 00:11:22 +0900 Message-ID: <87pp6831t1.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org, John Levine Subject: Re: [dmarc-ietf] A Modest Proposal of Two Variations X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 15:11:26 -0000 Michael Jack Assels writes: > A domain SHOULD NOT publish a p=reject policy if it will emit mail > intended to be mediated with modifications by another domain unless > the mediating domain is exempted from the policy by [fill in the > eventually approved mechanism(s)]. That won't work; you don't want to exempt mediating domains, you want to exempt specific mail flows destined for those domains. Anyway, I seem to recall that discouraging wording was in drafts around a year ago (but not at the level of SHOULD NOT, since searching for SHOULD NOT doesn't find it). But even a SHOULD NOT wouldn't have any effect, as representatives of the "errant domains" take the postion that "we didn't *want* to, but we were *forced* to publish p=reject". > That would at least nudge errant ESPs away from their misguided > ways, Yahoo! claims that malicious mail flows of over 1 million messages per minute went away like magic when they published p=reject. An RFC nudge won't be noticed compared to the business consequences of that. > and the rest of us can honor p=reject without losing any > sleep over it. But that's not a problem any more. Go ahead, honor p=reject. Mailing lists have been forced to adopt mitigation measures because the errant domains themselves honor p=reject, and I don't know what 3rd-party originators have done -- mostly closed up shop, I suppose. From nobody Sun May 10 08:53:51 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE7B1A1B64 for ; Sun, 10 May 2015 08:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.137 X-Spam-Level: X-Spam-Status: No, score=-101.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Va2lWpDL0eR9 for ; Sun, 10 May 2015 08:53:48 -0700 (PDT) Received: from dkim.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C8CBF1A1BD9 for ; Sun, 10 May 2015 08:53:47 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2905; t=1431273217; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=9Ds7R0KgAiP3vzA74xpshngeK4E=; b=XpNxQ35RTFfiPTiBQQ1B Yz3agnqUWBWAfcYqmUDLak87sTOMhnfWTZIBzDI3Nu7My6EcNJCBA4LAMs9WCn+k 7SqcvTyl1tg4kBUa69wXrDV2FAFss2KZyoLlX+9jDf7MoGCI6t7I+MigtViwV5zE njTdhU9TDyO0LoeWaJzqUHE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 10 May 2015 11:53:37 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 688240074.3360.3156; Sun, 10 May 2015 11:53:37 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2905; t=1431272938; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=f76EA3E y9e/EcfBAljPeTxhNiuDZvLM6mlEQUuatZgM=; b=hCJwXRYcO9dfy50ovrn0VKz goRbz2sMiAdVjAAmUh62XVBVvc1fDb+rUwt7UdFFyvk45JgwUbkRzh4kCVMSJ8Hc NVzyC2CX9gwQ4YbX9qblrKiXnH92Mn555cBqm7VHRxQsCEZ3/qPjSG5zTPaD0Hce A2Nrk7pTqZ7XNPoFEW0w= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 10 May 2015 11:48:58 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3575474441.9.13640; Sun, 10 May 2015 11:48:58 -0400 Message-ID: <554F7EFB.1070104@isdg.net> Date: Sun, 10 May 2015 11:53:31 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> <14447.1431266709@vindemiatrix.encs.concordia.ca> In-Reply-To: <14447.1431266709@vindemiatrix.encs.concordia.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 15:53:50 -0000 >> The registration problem is not a red herring because it doesn't >> exist, but because it is intractable. Thus, any response to the >> third-party problem that relies on a solution to that problem >> (which includes ATPS, DSAP, and TPA) is probably not viable. > > I agree. > > But I think that some of the "re-signing" schemes being proposed at > the moment do *not* require this type of registration, so in those > cases, the registration problem wouldn't apply. If A is not "signing > B's mail", but rather, "signing its own modifications to B's message", > then the evaluation of the two signatures doesn't require a published > or pre-existing relationship between the two domains. The signers still needs a "database" to determine when to add the double signature and the MLM receiver still needs to support the detection of this in order to allow it or not if missing. IOW, the MLM receiver still needs to reject the MLM submission and the final receivers still need support it as well otherwise the bounces will still occur that causes automated unsubscribe problems. So no matter what, the MLM still needs to support it. - Signer needs to know when it double signs, - MLM receiver filters restrictive domains, allows double signers, resigns doubles. - End-User Receivers support the resigned double signers. So there are changes at three places with a registration concern as well. At best, with the alternative to the DNS lookup, you have done two things; - got the DNS administrator out the picture and - maybe less endorsement requirement from the DNS community. But it comes with a higher risk of security problems -- potential, theoretical. Doesn't mean it can happen and probably a way to get around that too, for example, its possible to have a double From: exploit: From: user1@domain1 <---- unprotected, unsigned from From: user2@domain2 <---- hash bound DKIM protected If the MUA displayed the first one, you have fraud, phishing potential, etc. We addressed that by making it a responsibility of the receiver to check for a valid RFC5322 first. But DKIM should also check it too just in case the MTA doesn't check it. Doing a munge of the 5322.From is a old industry taboo. If any system does it, to me, and strongly believe many of my industry peers as well, they are renegades, no control and liable to legal issue. I wouldn't trust them. Its an ethical thing and I would probably appeal any recommendation to do so within an IETF mail protocol document. Its the same exploitable idea of a Double From and it will probably encourage filter writers to seek out a From Munged transaction detection strategy and immediately reject it. Now we are creating wars when you do that and the IETF should not encourage such mail matters. From Munging SHOULD NOT be an recommendation coming from the IETF. -- HLS From nobody Sun May 10 08:55:25 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67051A6EDA for ; Sun, 10 May 2015 08:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.899 X-Spam-Level: *** X-Spam-Status: No, score=3.899 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-Df_J-8yUq8 for ; Sun, 10 May 2015 08:55:23 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 37D4E1A1BD9 for ; Sun, 10 May 2015 08:55:23 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id A1FDD1C387F; Mon, 11 May 2015 00:55:22 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 83A1311F6A1; Mon, 11 May 2015 00:55:22 +0900 (JST) From: "Stephen J. Turnbull" To: Scott Kitterman In-Reply-To: References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <87y4ky2kif.fsf@uwakimon.sk.tsukuba.ac.jp> <90B1E4C8-A53D-4226-A1F6-E35CF57091C7@kitterman.com> <87wq0h3cga.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Mon, 11 May 2015 00:55:22 +0900 Message-ID: <87oals2zrp.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 15:55:24 -0000 Scott Kitterman writes: > Yahoo, for example, already consider the impact of this and other > breakage to be less than the benefit of p=reject. True, but the benefit of p=reject is huge: Yahoo! claims malicious mailflows of more than a million messages per minute disappeared like magic when they published p=reject. Such a flow surely stressed their systems, and I'm sure they consider the potential for high losses due to contact-list-based phishing to be important, if only for the damage to their reputation that would ensue. > I expect their willingness to invest engineering resources in > further reducing a level of breakage they've already determined is > acceptable will be limited. Of course it's limited. But the only cap I can be sure of is the difference between benefit of p=reject (see above) and cost (1 day of manager-admin meetings to decide to do it, and 15 seconds of admin time to change the DNS record, ie, basically zero). I believe that difference to be orders of magnitude larger than the cost of implementing a dozen delegation protocols, and therefore irrelevant. What matters is the benefit that the p=reject domains perceive to improving service to their mailbox users. I have no information about that. Of course I suspect that the value to them of such improvements is close to nil, but until they actually say that, I'm going to hope. If you have better information about how much they value such improvements, I'd love to hear about it. But I rather doubt you do; the techs surely don't have the authority to say they will do it, and at best a guess of what they need to offer management to get permission, and management won't discuss the value of a bird in the bush (not if they have half a brain amongst them, anyway). From nobody Sun May 10 09:48:24 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653811A8757 for ; Sun, 10 May 2015 09:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.298 X-Spam-Level: * X-Spam-Status: No, score=1.298 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-dkXi8RRh9i for ; Sun, 10 May 2015 09:48:22 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8725F1A8755 for ; Sun, 10 May 2015 09:48:22 -0700 (PDT) Received: from [IPv6:2600:1003:b122:3899:88b3:1f33:16f2:e65f] (unknown [IPv6:2600:1003:b122:3899:88b3:1f33:16f2:e65f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 18659C40029; Sun, 10 May 2015 11:48:21 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1431276501; bh=GrzqbjV3Nit7xpzWZ5C0LEtH17577Gf3sziAVmun1J4=; h=In-Reply-To:References:Subject:From:Date:To:From; b=q0zkXmgMS/pIEY91lL1DQRsCCfkPn+R1aKYKdKsHimi3lqmdb9sJgHBw0M9ziLinU qTQ0ZmXPHlKnke7CF219wc0fvVs3nDCmT0OSTlN6WQLX2dUZZeDFbgCapxCrRyI5qB Aq1+zro5M1oponaQbk32jgtW5WETOE+d4yiP+db8= User-Agent: K-9 Mail for Android In-Reply-To: <87oals2zrp.fsf@uwakimon.sk.tsukuba.ac.jp> References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <87y4ky2kif.fsf@uwakimon.sk.tsukuba.ac.jp> <90B1E4C8-A53D-4226-A1F6-E35CF57091C7@kitterman.com> <87wq0h3cga.fsf@uwakimon.sk.tsukuba.ac.jp> <87oals2zrp.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Sun, 10 May 2015 12:48:13 -0400 To: "dmarc@ietf.org" Message-ID: Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 16:48:24 -0000 On May 10, 2015 11:55:22 AM EDT, "Stephen J. Turnbull" wrote: >Scott Kitterman writes: > > > Yahoo, for example, already consider the impact of this and other > > breakage to be less than the benefit of p=reject. > >True, but the benefit of p=reject is huge: Yahoo! claims malicious >mailflows of more than a million messages per minute disappeared like >magic when they published p=reject. Such a flow surely stressed their >systems, and I'm sure they consider the potential for high losses due >to contact-list-based phishing to be important, if only for the damage >to their reputation that would ensue. > > > I expect their willingness to invest engineering resources in > > further reducing a level of breakage they've already determined is > > acceptable will be limited. > >Of course it's limited. But the only cap I can be sure of is the >difference between benefit of p=reject (see above) and cost (1 day of >manager-admin meetings to decide to do it, and 15 seconds of admin >time to change the DNS record, ie, basically zero). I believe that >difference to be orders of magnitude larger than the cost of >implementing a dozen delegation protocols, and therefore irrelevant. > >What matters is the benefit that the p=reject domains perceive to >improving service to their mailbox users. I have no information about >that. Of course I suspect that the value to them of such improvements >is close to nil, but until they actually say that, I'm going to hope. > >If you have better information about how much they value such >improvements, I'd love to hear about it. But I rather doubt you do; >the techs surely don't have the authority to say they will do it, and >at best a guess of what they need to offer management to get >permission, and management won't discuss the value of a bird in the >bush (not if they have half a brain amongst them, anyway). I don't have any particular insight. I do think that the group ought to be paying close attention to those who do. As I attempted to communicate in my assessment framework proposal, whatever solution the group coalesces around has to be workable for entities from the largest to the smallest. I think we have three outcomes: 1. We develop something that's broadly deployable 2. Single actor approaches such as from rewriting dominate the solution space 3. Mediated mail communication becomes rare Scott K From nobody Sun May 10 09:54:11 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DD61A0302 for ; Sun, 10 May 2015 09:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.163 X-Spam-Level: ** X-Spam-Status: No, score=2.163 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_ABOUTYOU=0.5, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mWkEaffw4dT for ; Sun, 10 May 2015 09:54:09 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B11A1A0277 for ; Sun, 10 May 2015 09:54:09 -0700 (PDT) Received: (qmail 71641 invoked from network); 10 May 2015 16:54:11 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 10 May 2015 16:54:11 -0000 Date: 10 May 2015 16:53:45 -0000 Message-ID: <20150510165345.68133.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <14447.1431266709@vindemiatrix.encs.concordia.ca> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: anne@encs.concordia.ca Subject: Re: [dmarc-ietf] double signing and what DMARC actually does X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 16:54:11 -0000 >Under at least one of the proposals, it can be determined that "yes, A >signed the mods, and if the mods are removed to re-generate the original >message, B signed the original message". If we have that, then I think >the question becomes: if this is to be a DMARC-like scheme, how do we tie >A's signature to some kind of relevant header field, since the "From:" >header is already "reserved" for the original signer. You don't even need to be able to tell what part of the message is attributable to which party. All you need to know is that the first signer considers it to be close enough. Remember the key axiom of mail reputation: you cannot say good things about yourself, only neutral or bad things. (This should be obvious if you think about it for a moment, since any assertion a nice sender can make, a nasty sender can also make.) Good stuff has to come from trusted third parties, and given the difficulty of establishing trust, that means the number of third parties has to be small. Hence DMARC answers the question "is this a bad message?" It only tells you whether a message is so awful that the recipient should throw it away. Once it's passed that test, the recipient then does whatever it does with any other mail to decide how spammy it is and what to do with it.* If the SPF or DKIM identity happens to belong to someone the receiver likes or trusts, that's fine but it has nothing to do with DMARC. That means that if a message has passed through two entities or mediators or whatever, the recipient does not care what part of the message originated where because it's going to deliver or reject the whole message, not the individual parts. If my MTA gets a 419 from a mailing list, it doesn't care whether the list is leaking 419s from the original sender, or the list is 419-izing innocent mail. It's going to bin it either way. That's why I made my double signing proposal the way I did, it's just enough that the original signer can say, yeah, close enough. The other more complex proposals can tell the recipient lots of other stuff, but it's not stuff that is useful to the recipient (except perhaps for exotic forensic purposes) so there's no value to the extra complication. R's, John * - someone will probably disagree with this, but he is wrong From nobody Sun May 10 10:06:00 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFDCD1A19E5 for ; Sun, 10 May 2015 10:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.199 X-Spam-Level: * X-Spam-Status: No, score=1.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnd7it2fkrUO for ; Sun, 10 May 2015 10:05:57 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id C9A131A044F for ; Sun, 10 May 2015 10:05:56 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 6A7861C3855; Mon, 11 May 2015 02:05:55 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 4D2BC11F6A1; Mon, 11 May 2015 02:05:55 +0900 (JST) From: "Stephen J. Turnbull" To: Anne Bennett In-Reply-To: <27522.1431236028@vindemiatrix.encs.concordia.ca> References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Mon, 11 May 2015 02:05:55 +0900 Message-ID: <87mw1c2wi4.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 17:05:59 -0000 Anne Bennett writes: > >> But if I understand correctly, it's being suggested that for > >> various proposals made here to work, either the sender's mail > >> system or the final receiver's mail system would have to become > >> aware of all "All" has been asserted. Why it needs to be "all" has not been explained, and when I ask that question, the response I get is "because I don't think you can get close to 'all'". (I expect the next round to go "So, why do we need to get 'close to "all"'?" "Because I don't think you can get close to 'close to "all"'. Young man, you are very clever, but it's 'can't get close to' all the way down!" ;-) > >> of the "legitimate" (definition purposely left > >> out!) mailing lists to which its users subscribe. [...] > But I thought the point of DMARC was to determine reliably > (using cryptographic keys and/or IP addresses as published by > the alleged originating domain in the DNS under their control) > whether the domain in the "From:" header is really responsible > for originating a given message, It's only half-reliable. A DMARC pass is reliable per protocol. A DMARC fail is 100% unreliable (SHOULD NOT be considered to provide any new information that isn't available outside of the DMARC protocol). > and I thought the problem we're trying to solve here is how we can > prevent DMARC from breaking "mediated" mail (such as mailing list > mail). > > - Munge the "From:" header to have the mailing list "take ownership" > of the message, at least for messages sent by users in p=reject > domains - which is already implemented as an option in at least one > major MLM, but is not popular philosophically (because people > expect the From: line to specify the author of a post) It's worse than that. RFC 5322 (like all of its predecessors) *specifies* that the content of the From field is the author's mailbox (or authors' mailboxes) and optionally name(s) or other description. > or in practice (because it makes it harder for the recipient to > choose to reply to the list or to the original sender as they > wish), > > - Come up with a scheme allowing the mailing list to "re-sign" > a slightly munged version of the message, which is what > I think we're arguing about. > Well, I myself wouldn't call something a thing of beauty when it > wrecks the functioning of mailing lists when used as intended, but I > also think it's pointless to try to specify a protocol that allows for > implementation-dependent heuristic decisions to "solve this > problem". "Legitimate" is always heuristically determined by the receiver, as you argue below. So people who argue that policy should be an absolute determinant of disposition just don't use the same Internet the rest of us do. > Any e-mail provider can already arbitrarily decide to ignore DMARC for > mail they think is list mail, if they want to. That doesn't help. To solve the problem lists face, *all* recipients *must* ignore DMARC. Otherwise subscribers at domains that *do* respect p=reject get their bounce counts increased while not receiving desired mail. > Sure, then they couldn't call themselves "DMARC compliant", but who > would lose sleep over that? Nobody, since they *can* call themselves conforming as long as they report. Accepting mail from a p=reject domain that fails the From alignment test is explicitly permitted (with "MAY"). > If I can step back a bit, all DMARC does is ensure that the site in > the "From:" line signed (or, via SPF, transmitted) *this* message. > A malefactor can send DKIM-signed or SPF-approved messages as easily as > anyone else. And in fact, any malefactor can send from Yahoo! or AOL, and get those domains to sign their messages. It's more difficult, but they can even send malicious mail "From" those domains, which will be signed if it does escape the outgoing filters. > Some of the proposed solutions involve a mediating site making > modifications, and signing its specific modifications. We already do sign messages, although in most cases it is not possible to identify the specific modifications with current protocols. I am sure that many large providers already maintain reputation databases for quite a few mailing lists, and those signatures help get our mail through to their mailboxes. > Nothing about DMARC or DKIM states that a message is okay - that part > is checked by other (yes, heuristic) parts of the mail system. > Nothing about an expanded DMARC or DKIM with "re-signing of > modifications" needs to be construed as stating that a message is > okay. > > Hmm, Hector, I think you've forced me to convince myself that you're > on the right track: I think that the "registration problem" is a red > herring after all. It's not a red herring. Identifying lists and other frequent senders of indirect mail, and only authorize resigning by those who pass further heuristic tests for "legitimacy", is an useful heuristic. Without a plausible approach involving reasonable cost to generating such a list, delegation protocols won't fly. I just don't think solving the "registration problem" should be a blocker for developing a delegation protocol, because the List-Post heuristic is a good start for any size of domain. I'm sure the large domains can do *much* better for themselves, and for smaller domains we can help develop substantial improvements, including sample implementations in software. From nobody Sun May 10 10:25:03 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2D41A8764 for ; Sun, 10 May 2015 10:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5gueoOutWk9 for ; Sun, 10 May 2015 10:25:01 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C66021A86FA for ; Sun, 10 May 2015 10:25:00 -0700 (PDT) Received: by wgic8 with SMTP id c8so83222605wgi.1 for ; Sun, 10 May 2015 10:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NB7Mx9WWZzkxkOaah7+XV4vR0nmo6CvV3C6D/HA8emM=; b=zsypGgGFFvnyDiObizcuL6HpuxvhKzTpdAQL/H/YSVO3tpHClN+kziYIg/EwqBwNBJ GfDXBLt+J39+MJbgs/v8RjNzlagiiJb1IQJHZ7oJVzINEmZ4afsKIz3f5ckFgpacwo1U 5EAmoWvJea2HjdFeiLnMN/FOCHcVdHzhu5Li/SjtjnzD7aCnE0GK3WJey7HWtMit+wMH TC+Ps1HxdI/Ehre/NAbwTT/7KRdehNyOyct00da16qgHsxOfP31yjOCy5qTsS5TOxOXt 9n+iSetlWMnzKfVr8gtTPdFywW3pkjeC+WNvCBxCwJdlDbvxwocgR6rAh0YZ4zHj9k33 kkUA== MIME-Version: 1.0 X-Received: by 10.194.242.101 with SMTP id wp5mr13247815wjc.4.1431278699452; Sun, 10 May 2015 10:24:59 -0700 (PDT) Received: by 10.27.170.134 with HTTP; Sun, 10 May 2015 10:24:59 -0700 (PDT) In-Reply-To: <20150510165345.68133.qmail@ary.lan> References: <14447.1431266709@vindemiatrix.encs.concordia.ca> <20150510165345.68133.qmail@ary.lan> Date: Sun, 10 May 2015 10:24:59 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=089e01419f52749f0a0515bd8ac6 Archived-At: Cc: Anne Bennett , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] double signing and what DMARC actually does X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 17:25:02 -0000 --089e01419f52749f0a0515bd8ac6 Content-Type: text/plain; charset=UTF-8 On Sun, May 10, 2015 at 9:53 AM, John Levine wrote: > >Under at least one of the proposals, it can be determined that "yes, A > >signed the mods, and if the mods are removed to re-generate the original > >message, B signed the original message". If we have that, then I think > >the question becomes: if this is to be a DMARC-like scheme, how do we tie > >A's signature to some kind of relevant header field, since the "From:" > >header is already "reserved" for the original signer. > > You don't even need to be able to tell what part of the message is > attributable to which party. All you need to know is that the first > signer considers it to be close enough. > > Remember the key axiom of mail reputation: you cannot say good things > about yourself, only neutral or bad things. (This should be obvious > if you think about it for a moment, since any assertion a nice sender > can make, a nasty sender can also make.) Good stuff has to come from > trusted third parties, and given the difficulty of establishing trust, > that means the number of third parties has to be small. > This is an interesting observation when compared to DKIM and SPF, where you only actually know something about the message when they report a "pass". But that's authentication, not reputation. -MSK --089e01419f52749f0a0515bd8ac6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, May 10, 2015 at 9:53 AM, John Levine <johnl@taugh.c= om> wrote:
>Under at least one of the proposa= ls, it can be determined that "yes, A
>signed the mods, and if the mods are removed to re-generate the origina= l
>message, B signed the original message".=C2=A0 If we have that, th= en I think
>the question becomes: if this is to be a DMARC-like scheme, how do we t= ie
>A's signature to some kind of relevant header field, since the &quo= t;From:"
>header is already "reserved" for the original signer.

You don't even need to be able to tell what part of the message is
attributable to which party.=C2=A0 All you need to know is that the first signer considers it to be close enough.

Remember the key axiom of mail reputation: you cannot say good things
about yourself, only neutral or bad things.=C2=A0 (This should be obvious if you think about it for a moment, since any assertion a nice sender
can make, a nasty sender can also make.)=C2=A0 Good stuff has to come from<= br> trusted third parties, and given the difficulty of establishing trust,
that means the number of third parties has to be small.

This is an interesting observation when compared to DKIM a= nd SPF, where you only actually know something about the message when they = report a "pass".=C2=A0 But that's authentication, not reputat= ion.

-MSK
--089e01419f52749f0a0515bd8ac6-- From nobody Sun May 10 10:37:11 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0671A8757 for ; Sun, 10 May 2015 10:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2UyMLcfawUe for ; Sun, 10 May 2015 10:37:08 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBEEB1A026E for ; Sun, 10 May 2015 10:37:07 -0700 (PDT) Received: by wgbhc8 with SMTP id hc8so9586452wgb.2 for ; Sun, 10 May 2015 10:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=71PDA9eZQphFhbNJaV4HHp/ohGPW1p4jaksfWDYr4zc=; b=jE5HRwrFtR+Yj7nCJDm10L8ZwsNweM5xOEJPS3D5D6Qs/1KKv5nR080BWRal8Ig2q0 bryd1D6UnMficIjKc9lR2XFSlojH+TzhgeAeEtI3akkoJZTdwm2N/7oKXDdDY3kEV5Gd MsmiHh2AQfTond3cfjbCrbcD6P5asQRMARy4EqvZz+SbaqdzRsYMtw4e31pjHtmA9KsF WbgpLkPGolX8jm91q2dd8UV7CSBmahby+vdyEQALndhQQjFRxRamFrGfwh3bqb0fu5br bfPiZbTOSmpgJTGOAyRoFID9ffQFOkIGC7hLKhou/LpemPfIA8Ayh/ejvtJdh3/IEIog Z6rA== MIME-Version: 1.0 X-Received: by 10.194.61.208 with SMTP id s16mr13611726wjr.135.1431279426679; Sun, 10 May 2015 10:37:06 -0700 (PDT) Received: by 10.27.170.134 with HTTP; Sun, 10 May 2015 10:37:06 -0700 (PDT) In-Reply-To: <14447.1431266709@vindemiatrix.encs.concordia.ca> References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> <14447.1431266709@vindemiatrix.encs.concordia.ca> Date: Sun, 10 May 2015 10:37:06 -0700 Message-ID: From: "Murray S. Kucherawy" To: Anne Bennett Content-Type: multipart/alternative; boundary=047d7b86d3e6cd385b0515bdb526 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 17:37:10 -0000 --047d7b86d3e6cd385b0515bdb526 Content-Type: text/plain; charset=UTF-8 On Sun, May 10, 2015 at 7:05 AM, Anne Bennett wrote: > But I think that some of the "re-signing" schemes being proposed at > the moment do *not* require this type of registration, so in those > cases, the registration problem wouldn't apply. If A is not "signing > B's mail", but rather, "signing its own modifications to B's message", > then the evaluation of the two signatures doesn't require a published > or pre-existing relationship between the two domains. > Yes, exactly; re-signing in some way that is entirely self-contained (i.e., does not mandate further queries to establish a relationship between A and B) appears to be far more promising than anything requiring a registration component. The theory behind some of my proposals tries to extend the basic notion of DKIM, which "allows a domain to take some responsibility for a message"; the idea in the extensions is to allow the different actors to claim responsibility for different parts of the content, and let the receiver decide what to do with that additional information. You allude to this here: Under at least one of the proposals, it can be determined that "yes, A > signed the mods, and if the mods are removed to re-generate the original > message, B signed the original message". If we have that, then I think > the question becomes: if this is to be a DMARC-like scheme, how do we tie > A's signature to some kind of relevant header field, since the "From:" > header is already "reserved" for the original signer. > In general, what you're hoping to do is confirm a relationship between A and B. A system involving a registration scheme seeks to query a registry for such relationships. The favorite way to do this is the DNS of B, where the set A would be published somehow. These other re-signing methods (and their variants) are seeking to confirm this relationship via two signatures that are somehow associated. That is, for a registration scheme, you might be testing for the existence of a DNS record called A._related._dmarc.B. For a re-signing scheme, you're looking for a signature from A that is somehow endorsed (for some definition thereof) by a signature from B. The beauty of that mechanism is that the signer gets to decide when to apply that endorsement, and with what parameters. In fact, it's possible that A doesn't even know that B is doing it. B could do it for all messages, which is simpler but increases exposure; it could decide to apply the aforementioned heuristics and only include the endorsement when it feels it's appropriate, which is safer but requires a lot more internal infrastructure to support. Both camps are enabled. > Now despite injunctions on this list against referring to the user > interface, the fact is that DMARC uses the "holy From: header" to extract > the "alignable domain". Unless I'm gravely mistaken, the reason for > that *is* indeed that this field is shown to the user (in some form) > by every user agent out there, and the user is thought to place a fair > deal of confidence in the "truth" of that header. Unless we can state > something similar with respect to another header, I suspect that > anything we propose will be considered to be watering down DMARC to an > unacceptable extent. :-( > I agree with both your context and conclusion here. -MSK --047d7b86d3e6cd385b0515bdb526 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, May 10, 2015 at 7:05 AM, Anne Bennett <anne@= encs.concordia.ca> wrote:
But I think that some = of the "re-signing" schemes being proposed at
the moment do *not* require this type of registration, so in those
cases, the registration problem wouldn't apply.=C2=A0 If A is not "= ;signing
B's mail", but rather, "signing its own modifications to B= 9;s message",
then the evaluation of the two signatures doesn't require a published or pre-existing relationship between the two domains.
=
Yes, exactly; re-signing in some way that is entirely self-c= ontained (i.e., does not mandate further queries to establish a relationshi= p between A and B) appears to be far more promising than anything requiring= a registration component.

The theory behind some of my p= roposals tries to extend the basic notion of DKIM, which "allows a dom= ain to take some responsibility for a message"; the idea in the extens= ions is to allow the different actors to claim responsibility for different= parts of the content, and let the receiver decide what to do with that add= itional information.=C2=A0 You allude to this here:

Under at least one of the proposals, it can be determined that "yes, A=
signed the mods, and if the mods are removed to re-generate the original message, B signed the original message".=C2=A0 If we have that, then I= think
the question becomes: if this is to be a DMARC-like scheme, how do we tie A's signature to some kind of relevant header field, since the "Fr= om:"
header is already "reserved" for the original signer.

In general, what you're hoping to do is confir= m a relationship between A and B.=C2=A0 A system involving a registration s= cheme seeks to query a registry for such relationships.=C2=A0 The favorite = way to do this is the DNS of B, where the set A would be published somehow.= =C2=A0 These other re-signing methods (and their variants) are seeking to c= onfirm this relationship via two signatures that are somehow associated.
That is, for a registration scheme, you might be testing fo= r the existence of a DNS record called A._related._dmarc.B.=C2=A0 For a re-= signing scheme, you're looking for a signature from A that is somehow e= ndorsed (for some definition thereof) by a signature from B.=C2=A0 The beau= ty of that mechanism is that the signer gets to decide when to apply that e= ndorsement, and with what parameters.=C2=A0 In fact, it's possible that= A doesn't even know that B is doing it.=C2=A0 B could do it for all me= ssages, which is simpler but increases exposure; it could decide to apply t= he aforementioned heuristics and only include the endorsement when it feels= it's appropriate, which is safer but requires a lot more internal infr= astructure to support.=C2=A0 Both camps are enabled.
=C2=A0
Now despite injunctions on this list against referring to the user
interface, the fact is that DMARC uses the "holy From: header" to= extract
the "alignable domain".=C2=A0 Unless I'm gravely mistaken, th= e reason for
that *is* indeed that this field is shown to the user (in some form)
by every user agent out there, and the user is thought to place a fair
deal of confidence in the "truth" of that header.=C2=A0 Unless we= can state
something similar with respect to another header, I suspect that
anything we propose will be considered to be watering down DMARC to an
unacceptable extent.=C2=A0 :-(

I agree = with both your context and conclusion here.

-MSK
--047d7b86d3e6cd385b0515bdb526-- From nobody Sun May 10 10:40:39 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8C71A8782 for ; Sun, 10 May 2015 10:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.999 X-Spam-Level: * X-Spam-Status: No, score=1.999 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzCNDPueGfuT for ; Sun, 10 May 2015 10:40:35 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id B15E51A8757 for ; Sun, 10 May 2015 10:40:35 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 017F31C3892; Mon, 11 May 2015 02:40:34 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id CB47E11F6A1; Mon, 11 May 2015 02:40:34 +0900 (JST) From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Mon, 11 May 2015 02:40:34 +0900 Message-ID: <87lhgw2uwd.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" , Anne Bennett Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 17:40:37 -0000 Murray S. Kucherawy writes: > That means any actor inside "A" can sign mail that claims to come > from "B". So if "A" is compromised, "B" is hosed. The "B"s of the > world tend not to be so thrilled with this. I think only Hector and Douglas would argue with you, and I predict they will. Let's agree to disagree, and move on to something that the rest of us think might possibly work if we fix a few details. > This "How do we populate the set?" is "the registration problem". > There are some implicit "safely" and "at scale" adverbs in there > too, just for flavor. Sure, but even with the adverbs it's not a "problem" for per-message delegation proposals like yours and John's. For those proposals, we already have technology in place for incoming messages (eg, Gmail user filters) which could easily be applied to collect information from incoming messages (and optionally from the users) and add delegation fields computed *per user* per *outgoing* message. It's a *task* with *costs* that can be estimated, they're not outrageous, and they provably scale because they're already implemented at scale (for different purposes). Those costs may still be too big to be justified by the prospective benefits, but we need to come to some consensus on protocols and how much risk of abuse they entail before we can estimate benefits, and compute benefit/cost ratios. From nobody Sun May 10 10:43:23 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447481A878B for ; Sun, 10 May 2015 10:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d_Qlj0tHc3PJ for ; Sun, 10 May 2015 10:43:21 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 601211A8782 for ; Sun, 10 May 2015 10:43:21 -0700 (PDT) Received: (qmail 76059 invoked from network); 10 May 2015 17:43:23 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 10 May 2015 17:43:23 -0000 Date: 10 May 2015 17:42:58 -0000 Message-ID: <20150510174258.68962.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] double signing and what DMARC actually does X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 17:43:22 -0000 >> Remember the key axiom of mail reputation: you cannot say good things >> about yourself, only neutral or bad things. ... >This is an interesting observation when compared to DKIM and SPF, where you >only actually know something about the message when they report a "pass". >But that's authentication, not reputation. Right, the assertion is "this is me" which is neutral without something else to decide what you think of me. I find that between the axiom and your observation that third party trusted entities do not scale, you can pretty quicky tell whether a proposed hack is likely to be workable. R's, John From nobody Sun May 10 10:44:05 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47E51A878B for ; Sun, 10 May 2015 10:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ji1-RI6jOMx for ; Sun, 10 May 2015 10:44:02 -0700 (PDT) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 232971A8782 for ; Sun, 10 May 2015 10:44:02 -0700 (PDT) Received: by wgiu9 with SMTP id u9so110002365wgi.3 for ; Sun, 10 May 2015 10:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DcNqJcjD3oqb+/1Au+SRkl5umQmrndn6UAZJ7RS8gGM=; b=yNSv1LY9izUduUE8fVA7o2nKXPSPi5eIFhKyCjHMH3+YeLbscUV4MrmhyIy/UWSt1P 8ijzCb+bbBtXl780hnKur6S0jJnoh3UjnzaXeMkp/Qbl31AKV9Fuj7rbyOTDhUBx9uqX bOsM4GYS57W7rtBNAirT/Bx5667l9tzv8F8XTEn7dzxAzQtQYG6ZC5QS7aEzobRj0pg7 QAUYtkXNutZzP6xgfrO6pDaUCSYn0Ud7mWC/80R9z6ZWjFLxABM4TTWuljPKBK5KSdoA yOJ7XjU0t+uUlUbbkS+Bmcu96CgClztHzfx3jW5c8GIq5HCCFT+Ya02Kck0PLDd3mxca ivww== MIME-Version: 1.0 X-Received: by 10.194.61.208 with SMTP id s16mr13650314wjr.135.1431279840953; Sun, 10 May 2015 10:44:00 -0700 (PDT) Received: by 10.27.170.134 with HTTP; Sun, 10 May 2015 10:44:00 -0700 (PDT) In-Reply-To: <87lhgw2uwd.fsf@uwakimon.sk.tsukuba.ac.jp> References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> <87lhgw2uwd.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Sun, 10 May 2015 10:44:00 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=047d7b86d3e67e89530515bdce32 Archived-At: Cc: "dmarc@ietf.org" , Anne Bennett Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 17:44:04 -0000 --047d7b86d3e67e89530515bdce32 Content-Type: text/plain; charset=UTF-8 On Sun, May 10, 2015 at 10:40 AM, Stephen J. Turnbull wrote: > > This "How do we populate the set?" is "the registration problem". > > There are some implicit "safely" and "at scale" adverbs in there > > too, just for flavor. > > Sure, but even with the adverbs it's not a "problem" for per-message > delegation proposals like yours and John's. For those proposals, we > already have technology in place for incoming messages (eg, Gmail user > filters) which could easily be applied to collect information from > incoming messages (and optionally from the users) and add delegation > fields computed *per user* per *outgoing* message. It's a *task* with > *costs* that can be estimated, they're not outrageous, and they > provably scale because they're already implemented at scale (for > different purposes). > > Those costs may still be too big to be justified by the prospective > benefits, but we need to come to some consensus on protocols and how > much risk of abuse they entail before we can estimate benefits, and > compute benefit/cost ratios. > Right, that's also a benefit of the dual signature approaches: the decision can be made based upon the characteristics of each message, in theory, where having to consult with a registry via the DNS implies the relationship is established for all mail. In the resigning methods, the registry, if one even exists, is completely internal and detached from the protocol. -MSK --047d7b86d3e67e89530515bdce32 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, May 10, 2015 at 10:40 AM, Stephen J. Turnbull <s= tephen@xemacs.org> wrote:
=C2= =A0> This "How do we populate the set?" is "the registrat= ion problem".
=C2=A0> There are some implicit "safely" and "at scale&qu= ot; adverbs in there
=C2=A0> too, just for flavor.

Sure, but even with the adverbs it's not a "problem" f= or per-message
delegation proposals like yours and John's.=C2=A0 For those proposals, = we
already have technology in place for incoming messages (eg, Gmail user
filters) which could easily be applied to collect information from
incoming messages (and optionally from the users) and add delegation
fields computed *per user* per *outgoing* message.=C2=A0 It's a *task* = with
*costs* that can be estimated, they're not outrageous, and they
provably scale because they're already implemented at scale (for
different purposes).

Those costs may still be too big to be justified by the prospective
benefits, but we need to come to some consensus on protocols and how
much risk of abuse they entail before we can estimate benefits, and
compute benefit/cost ratios.

Right, that's a= lso a benefit of the dual signature approaches: the decision can be made ba= sed upon the characteristics of each message, in theory, where having to co= nsult with a registry via the DNS implies the relationship is established f= or all mail.=C2=A0 In the resigning methods, the registry, if one even exis= ts, is completely internal and detached from the protocol.

-MSK
--047d7b86d3e67e89530515bdce32-- From nobody Sun May 10 11:00:05 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7311A884F for ; Sun, 10 May 2015 11:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xk0kEXcMUwia for ; Sun, 10 May 2015 11:00:02 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB1DF1A8843 for ; Sun, 10 May 2015 11:00:01 -0700 (PDT) Received: by widdi4 with SMTP id di4so81210024wid.0 for ; Sun, 10 May 2015 11:00:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SpKXpcG3ABpphPGjqhOMDaMjBM5FZ6m0kE46xfTnlHs=; b=Hgx9s2sH55cvDG/lhKBKQDUr5lLgM0dtJrKdiqk6R8ITDOppWNAx4ZV7iSbzLFvFz1 ATlaHq6P3c+DjEgUe43GT3DTaZG6LVHsMjuGWO+EQgPilnBjDJMo8vPMrflra8N5tqGW MWwhF0W6peiAiguqA9rGq/4oPn0iuU1QxHVJlXT3URTvXQxF9ws5xYXMLyVRAghNBfMc a/aVuB7bOZeri6Oc8jyF8T8WtviarGFy06A7+7jEaLg922caSKT/cu0kSLVA1hDOYds7 za1FjpLIMmiUAcFJcGZ8aq1iSkGYRli0zJi101F9w7PI/Ppno/ZI1gy/U9paOcQd3zVR /MFg== MIME-Version: 1.0 X-Received: by 10.180.99.2 with SMTP id em2mr14263542wib.59.1431280800504; Sun, 10 May 2015 11:00:00 -0700 (PDT) Received: by 10.27.170.134 with HTTP; Sun, 10 May 2015 11:00:00 -0700 (PDT) In-Reply-To: References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> <14447.1431266709@vindemiatrix.encs.concordia.ca> Date: Sun, 10 May 2015 11:00:00 -0700 Message-ID: From: "Murray S. Kucherawy" To: Anne Bennett Content-Type: multipart/alternative; boundary=f46d04426c68b020350515be0719 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 18:00:03 -0000 --f46d04426c68b020350515be0719 Content-Type: text/plain; charset=UTF-8 On Sun, May 10, 2015 at 10:37 AM, Murray S. Kucherawy wrote: > That is, for a registration scheme, you might be testing for the existence > of a DNS record called A._related._dmarc.B. For a re-signing scheme, > you're looking for a signature from A that is somehow endorsed (for some > definition thereof) by a signature from B. The beauty of that mechanism is > that the signer gets to decide when to apply that endorsement, and with > what parameters. In fact, it's possible that A doesn't even know that B is > doing it. B could do it for all messages, which is simpler but increases > exposure; it could decide to apply the aforementioned heuristics and only > include the endorsement when it feels it's appropriate, which is safer but > requires a lot more internal infrastructure to support. Both camps are > enabled. > Sorry, I sent that too quickly. A couple of other points: In both schemes, you need a "registry", which is the set A as maintained by B through whatever means B wishes. Any DNS mechanism, however, requires that all mail flows from B via A are endorsed for as long as that DNS record is published (or cached); with the re-signing scheme, B gets to choose which specific messages carry that endorsement, via whatever logic it cares to apply, and for how long the endorsements are effective, and with what cryptographic strength and other parameters. We have evidence in hand that the queryable registry solutions are not attractive, evidence in the form of ATPS (RFC6541) for which the adoption rate was above zero by only a vanishingly small amount despite three years of open publication and an open source implementation. Despite other claims, there has never been evidence shown of interoperability of ATPS. The posting at the top of this thread makes such a claim, but it describes a single pre-RFC implementation interoperating with itself, rather than distinct implementations interoperating together; it is the latter that we tend to consider probative in IETF work. -MSK --f46d04426c68b020350515be0719 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, May 10, 2015 at 10:37 AM, Murray S. Kucherawy <= superuser@gmail.com> wrote:
That is, for a registration scheme, you might be testi= ng for the existence of a DNS record called A._related._dmarc.B.=C2=A0 For = a re-signing scheme, you're looking for a signature from A that is some= how endorsed (for some definition thereof) by a signature from B.=C2=A0 The= beauty of that mechanism is that the signer gets to decide when to apply t= hat endorsement, and with what parameters.=C2=A0 In fact, it's possible= that A doesn't even know that B is doing it.=C2=A0 B could do it for a= ll messages, which is simpler but increases exposure; it could decide to ap= ply the aforementioned heuristics and only include the endorsement when it = feels it's appropriate, which is safer but requires a lot more internal= infrastructure to support.=C2=A0 Both camps are enabled.

Sorry, I sent that too quickly.=C2=A0 A couple of = other points:

In both schemes, you need a "registry&= quot;, which is the set A as maintained by B through whatever means B wishe= s.=C2=A0 Any DNS mechanism, however, requires that all mail flows from B vi= a A are endorsed for as long as that DNS record is published (or cached); w= ith the re-signing scheme, B gets to choose which specific messages carry t= hat endorsement, via whatever logic it cares to apply, and for how long the= endorsements are effective, and with what cryptographic strength and other= parameters.

We have evidence in hand that the queryable = registry solutions are not attractive, evidence in the form of ATPS (RFC654= 1) for which the adoption rate was above zero by only a vanishingly small a= mount despite three years of open publication and an open source implementa= tion.=C2=A0 Despite other claims, there has never been evidence shown of in= teroperability of ATPS.=C2=A0 The posting at the top of this thread makes s= uch a claim, but it describes a single pre-RFC implementation interoperatin= g with itself, rather than distinct implementations interoperating together= ; it is the latter that we tend to consider probative in IETF work.

=
-MSK
--f46d04426c68b020350515be0719-- From nobody Sun May 10 11:04:18 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134021A001A for ; Sun, 10 May 2015 11:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alaEHwQbx_xA for ; Sun, 10 May 2015 11:04:15 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76B431A8851 for ; Sun, 10 May 2015 11:04:15 -0700 (PDT) Received: by widdi4 with SMTP id di4so81282383wid.0 for ; Sun, 10 May 2015 11:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n+ClX1odrukRMalCy7QWgYj/5w5S9U+khPt0+JLhzPM=; b=UwaGvHQmOjUVTSu8UCZz7OtTFGGT7uQhKoIz+ZBzAtDDDgE4UGorp3ldeOQfRw95kT 2d5/5FrOmvjjmKFOZPoYe0lAhXbRMcUuDnY8q7xMQWzBg+Ps0N9g6F5Rbl3e6oZivQqy 3lIFjZN0ZbpT1+wFz0aIBLjUbURhyg6KEEDgMASLt2mw/ui1Z0Lt33JV2j04B/8CTkxz IVb+Ftq27hKkuBC8jpcOxp1+4DWW3if7SBTO0Az3ucsAByB+5X3TkyR5bZ6xlMdYSAqg PEnejk2pvD5/pH7HMtD+CcQbx9y2fFhlfLhwGdcNBcBsp2xz7NjQOyOX2D199RngKUJO tNMQ== MIME-Version: 1.0 X-Received: by 10.194.242.101 with SMTP id wp5mr13462058wjc.4.1431281054034; Sun, 10 May 2015 11:04:14 -0700 (PDT) Received: by 10.27.170.134 with HTTP; Sun, 10 May 2015 11:04:13 -0700 (PDT) In-Reply-To: <20150510174258.68962.qmail@ary.lan> References: <20150510174258.68962.qmail@ary.lan> Date: Sun, 10 May 2015 11:04:13 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=089e01419f52ccafc00515be16cb Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] double signing and what DMARC actually does X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 18:04:17 -0000 --089e01419f52ccafc00515be16cb Content-Type: text/plain; charset=UTF-8 On Sun, May 10, 2015 at 10:42 AM, John Levine wrote: > I find that between the axiom and your observation that third party > trusted entities do not scale, you can pretty quicky tell whether a > proposed hack is likely to be workable. > A re-signing scheme also has to have some mechanism for deciding which third parties get the endorsement ("@fs=") from the author domain. One might think of that as a "registry" with similar problems to those we've been discussing, but it's just an entirely private one. So I'm not sure we can plainly say registries are off the table, because you always have to have some way to decide whether to affirm the relationship. It's a matter of the method by which you do so. But in your case, that registry doesn't need to be published anywhere; it's implicit in the signature parameters, and is much easier to control tightly, because it's per-message, and DKIM has a lot of parameters to play with. -MSK --089e01419f52ccafc00515be16cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, May 10, 2015 at 10:42 AM, John Levine <johnl@taugh.= com> wrote:
I find that between the axiom and yo= ur observation that third party
trusted entities do not scale, you can pretty quicky tell whether a
proposed hack is likely to be workable.

A re-signing scheme also has to have some mechanism for deciding which thi= rd parties get the endorsement ("@fs=3D") from the author domain.= =C2=A0 One might think of that as a "registry" with similar probl= ems to those we've been discussing, but it's just an entirely priva= te one.=C2=A0 So I'm not sure we can plainly say registries are off the= table, because you always have to have some way to decide whether to affir= m the relationship.=C2=A0 It's a matter of the method by which you do s= o.

But in your case, that registry doesn't need to be published = anywhere; it's implicit in the signature parameters, and is much easier= to control tightly, because it's per-message, and DKIM has a lot of pa= rameters to play with.

-MSK
--089e01419f52ccafc00515be16cb-- From nobody Sun May 10 11:18:30 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDFD1A88A9 for ; Sun, 10 May 2015 11:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.498 X-Spam-Level: ** X-Spam-Status: No, score=2.498 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jf5h7jV134qs for ; Sun, 10 May 2015 11:18:28 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 451231A88BF for ; Sun, 10 May 2015 11:18:23 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 742BD1C38D0; Mon, 11 May 2015 03:18:22 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 4A79F11F6A1; Mon, 11 May 2015 03:18:22 +0900 (JST) From: "Stephen J. Turnbull" To: Scott Kitterman In-Reply-To: References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <87y4ky2kif.fsf@uwakimon.sk.tsukuba.ac.jp> <90B1E4C8-A53D-4226-A1F6-E35CF57091C7@kitterman.com> <87wq0h3cga.fsf@uwakimon.sk.tsukuba.ac.jp> <87oals2zrp.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Mon, 11 May 2015 03:18:22 +0900 Message-ID: <87ioc02t5d.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 18:18:29 -0000 Scott Kitterman writes: > I don't have any particular insight. I do think that the group > ought to be paying close attention to those who do. What is the sound of a closed mouth speaking? > As I attempted to communicate in my assessment framework proposal, > whatever solution the group coalesces around has to be workable for > entities from the largest to the smallest. I think that's very desirable, but to me it's not obviously a blocker. That's my current opinion, I'll think about it more. > I think we have three outcomes: > > 1. We develop something that's broadly deployable > > 2. Single actor approaches such as from rewriting dominate the > solution space > > 3. Mediated mail communication becomes rare In 1, s/we/somebody/, and I agree completely. From nobody Sun May 10 11:34:04 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403A31A8906 for ; Sun, 10 May 2015 11:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CW5IbEbSGq1p for ; Sun, 10 May 2015 11:33:58 -0700 (PDT) Received: from mail.santronics.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2F31A88ED for ; Sun, 10 May 2015 11:33:58 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=10050; t=1431282831; h=Received:Received: Message-Id:From:Subject:Date:To:Organization:List-ID; bh=kFJJea0 Vm1YhozYUo4rMMzm7w4s=; b=nk0ryEBgV6Lgtf7MW4w1gpCDca+7DFMM67YIS2b xy2UuVp5CIsXwzLFaYXxhSez/DeJBCR15Q77qtyeBRqmLcJmRtWTw/dGUsfZq1MI KLfyIbwuaWqPAigTXbEosGng7Hc2wRlrfNh9HGS/ICUQCqGaNbBw6URojkiombRI PVtw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 10 May 2015 14:33:51 -0400 Received: from [192.168.1.67] (adsl-184-33-248-166.mia.bellsouth.net [184.33.248.166]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 697852403.3360.2356; Sun, 10 May 2015 14:33:49 -0400 References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> <14447.1431266709@vindemiatrix.encs.concordia.ca> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-E77CE5C5-8F27-4D08-BD62-300F792455C0 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (12B435) From: Hector Santos Date: Sun, 10 May 2015 14:33:50 -0400 To: "Murray S. Kucherawy" Archived-At: Cc: "dmarc@ietf.org" , Anne Bennett Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 18:34:02 -0000 --Apple-Mail-E77CE5C5-8F27-4D08-BD62-300F792455C0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On May 10, 2015, at 2:00 PM, Murray S. Kucherawy wro= te: >=20 >> On Sun, May 10, 2015 at 10:37 AM, Murray S. Kucherawy wrote: >> That is, for a registration scheme, you might be testing for the existenc= e of a DNS record called A._related._dmarc.B. For a re-signing scheme, you'= re looking for a signature from A that is somehow endorsed (for some definit= ion thereof) by a signature from B. The beauty of that mechanism is that th= e signer gets to decide when to apply that endorsement, and with what parame= ters. In fact, it's possible that A doesn't even know that B is doing it. B= could do it for all messages, which is simpler but increases exposure; it c= ould decide to apply the aforementioned heuristics and only include the endo= rsement when it feels it's appropriate, which is safer but requires a lot mo= re internal infrastructure to support. Both camps are enabled. >=20 > Sorry, I sent that too quickly. A couple of other points: >=20 > In both schemes, you need a "registry", which is the set A as maintained b= y B through whatever means B wishes. Any DNS mechanism, however, requires t= hat all mail flows from B via A are endorsed for as long as that DNS record i= s published (or cached); with the re-signing scheme, B gets to choose which s= pecific messages carry that endorsement, via whatever logic it cares to appl= y, and for how long the endorsements are effective, and with what cryptograp= hic strength and other parameters. >=20 > We have evidence in hand that the queryable registry solutions are not att= ractive, evidence in the form of ATPS (RFC6541) for which the adoption rate w= as above zero by only a vanishingly small amount despite three years of open= publication and an open source implementation. Despite other claims, there= has never been evidence shown of interoperability of ATPS. The posting at t= he top of this thread makes such a claim, but it describes a single pre-RFC i= mplementation interoperating with itself, rather than distinct implementatio= ns interoperating together; it is the latter that we tend to consider probat= ive in IETF work. First, ATPS was hampered by the fact ADSP was being demoted. Second, RFC6541 raised the barrier by extended it off the DKIM signature. W= e were already tired of more changes to DKIM, we did not need more. Instant= barrier to adoption. Third, ATPS was an experiment and the author was included stuff, "it won't w= ork anyway". It can't do that. Doesn't help the technical marketing. It= doesn't. So yes. It was poorly proposed in my opinion, but it was understandable giv= en the focus to use thrust rather than policy. =20 But we can't compare the situation because now you have interest in a "Super= -ADSP" [sic], which mean the 3rd party hook off DMARC should of be the prope= r integrated step. FInally. It is running code between different operators and the IETF take it= into account. Which means I can send mail to a list, expected it to be resi= gned and my own system and others can do the lookup for the resigner authori= zation. You forget that a system can support it for authorization but doe= s not itself need or can publish records. In all, all your points and my points should be part the interoperating repo= rt but I totally disagree it is not an overall IETF technical protocol feasi= ble solution. It will probably never be a feasible solution for the limited= domains in question, no matter what is done. But that should not stop the p= rotocol from being part of the DKIM policy layer. It didn't stop any other s= imilar DNS application. Now, If we are trying to avoid the intense IETF D= NS community review sure to follow, I can see a valid point, but avoiding it= is just as bad. I suggest that a proper DNS lookup model is still the prop= er most feasible solution and that will be presented during review. At some= point we need to stop the DKIM changes. You just made it a STD. Maybe we c= ould probably retract that STD status with and addendum if it a going to con= tinue to change. -- Hector Santos http://www.santronics.com --Apple-Mail-E77CE5C5-8F27-4D08-BD62-300F792455C0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


On May 10, 2015, at= 2:00 PM, Murray S. Kucherawy <sup= eruser@gmail.com> wrote:

On Sun, May 10, 2015 at 10:37 AM, Murray S. Kucherawy <superuser= @gmail.com> wrote:
That is, for a registration scheme, you might be testing for the ex= istence of a DNS record called A._related._dmarc.B.  For a re-signing s= cheme, you're looking for a signature from A that is somehow endorsed (for s= ome definition thereof) by a signature from B.  The beauty of that mech= anism is that the signer gets to decide when to apply that endorsement, and w= ith what parameters.  In fact, it's possible that A doesn't even know t= hat B is doing it.  B could do it for all messages, which is simpler bu= t increases exposure; it could decide to apply the aforementioned heuristics= and only include the endorsement when it feels it's appropriate, which is s= afer but requires a lot more internal infrastructure to support.  Both c= amps are enabled.

Sorry, I sent th= at too quickly.  A couple of other points:

In both sc= hemes, you need a "registry", which is the set A as maintained by B through w= hatever means B wishes.  Any DNS mechanism, however, requires that all m= ail flows from B via A are endorsed for as long as that DNS record is publis= hed (or cached); with the re-signing scheme, B gets to choose which specific= messages carry that endorsement, via whatever logic it cares to apply, and f= or how long the endorsements are effective, and with what cryptographic stre= ngth and other parameters.

We have evidence in hand that t= he queryable registry solutions are not attractive, evidence in the form of A= TPS (RFC6541) for which the adoption rate was above zero by only a vanishing= ly small amount despite three years of open publication and an open source i= mplementation.  Despite other claims, there has never been evidence sho= wn of interoperability of ATPS.  The posting at the top of this thread m= akes such a claim, but it describes a single pre-RFC implementation interope= rating with itself, rather than distinct implementations interoperating toge= ther; it is the latter that we tend to consider probative in IETF work.
<= /div>

First, ATPS was hampered by the= fact ADSP was being demoted.

Second, RFC6541 raise= d the barrier by extended it off the DKIM signature.  We were already t= ired of more changes to DKIM, we did not need more.  Instant barrier to= adoption.

Third,  ATPS was an experiment and t= he author was included stuff, "it won't work anyway".   It can't do tha= t.  Doesn't help the  technical marketing.  It doesn't.
=

So yes. It was poorly proposed in my opinion,  but i= t was understandable given the focus to use thrust rather than policy.
=
 
But we can't compare the situation because now you hav= e interest in a "Super-ADSP" [sic], which mean the 3rd party hook off DMARC s= hould of be the proper integrated step.

FInally. It= is running code between different operators and the IETF take it into accou= nt. Which means I can send mail to a list, expected it to be resigned and my= own system and others can do the lookup for the resigner authorization. &nb= sp; You forget that a system can support it for authorization  but does= not itself need or can publish records.

In all, al= l your points and my points should be part the interoperating report but I t= otally disagree it is not an overall IETF technical protocol feasible soluti= on.  It will probably never be a feasible solution for the limited doma= ins in question, no matter what is done.  But that should not stop the p= rotocol from being part of the DKIM policy layer.  It didn't stop any o= ther similar DNS application.   Now,  If we are trying to avoid th= e intense IETF  DNS community review sure to follow, I can see a valid p= oint, but avoiding it is just as bad.  I suggest that a proper DNS look= up model is still the proper most feasible solution and that will be present= ed during review.  At some point we need to stop the DKIM changes. &nbs= p;You just made it a STD.  Maybe we could probably retract that STD sta= tus with and addendum if it a going to continue to change.
= --Apple-Mail-E77CE5C5-8F27-4D08-BD62-300F792455C0-- From nobody Sun May 10 12:54:28 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C50EB1A9046 for ; Sun, 10 May 2015 12:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.563 X-Spam-Level: * X-Spam-Status: No, score=1.563 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xY6k94qpSnOg for ; Sun, 10 May 2015 12:54:24 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34ABA1A9040 for ; Sun, 10 May 2015 12:54:24 -0700 (PDT) Received: (qmail 90897 invoked from network); 10 May 2015 19:54:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=16310.554fb772.k1505; bh=8b3Rqoks27zw4uGG8RfrAsq1/z+PGhljPSit3+MfwoM=; b=Z7nTvmdUDZKDQrUuP1pt7lmUi1Om/XzLRsb9nRmpXklXnIe4Q+2u37AEGiFyFiuTwEKhMxLosNsgwv1h87QKLBvmPyupiTfp86IeQ8t6TJMW3772K0Cos/O7C4q5SRTIlzWukLhkPdEdW/ViwZFcf5Pd67H+Qh0+nLJ5UeVJPpzcEgs5UGFvvHwzXXjbrOvHntWRSb4MG8Gkl8/7x8FKSOhsiDBecOC212Bcf+YFt2uSJE/1UbdBofa31BL2ZCo7 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=16310.554fb772.k1505; bh=8b3Rqoks27zw4uGG8RfrAsq1/z+PGhljPSit3+MfwoM=; b=PKo9vA4sMcCWA8cvq7V1lhtCv3IWNpvGCmIfWSjuL4z2Lub5irF16WvDKwGZz4CgF/K+sDCxAkYn23oZYAuuEyFbJUCcwjGPmc3xbHq8K5IdQ9MQTyYw6qcvHZ7n5owRmsawsmkxgNYbjg6PzBlKo27/DqhS9JEXEc4BeAY/ioKgXw1KP5or/Fqlb25pK+8cOTE6GPTnWugbM2gwwYaw8eKTIciV3Fzq9vDlIEUnxvBXTWVhVVqBuYxAeEQK30Vl Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 10 May 2015 19:54:26 -0000 Date: 10 May 2015 15:54:21 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20150510174258.68962.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] double signing and what DMARC actually does X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 19:54:25 -0000 > A re-signing scheme also has to have some mechanism for deciding which > third parties get the endorsement ("@fs=") from the author domain. One > might think of that as a "registry" with similar problems to those we've > been discussing, but it's just an entirely private one. So I'm not sure we > can plainly say registries are off the table, because you always have to > have some way to decide whether to affirm the relationship. It's a matter > of the method by which you do so. Yeah. I think there's a general rule in there, but it's subtle. It's clear that a whitelist that resenders sign up for won't work, largely because any such list big enough to be interesting is also big enough to have entries that don't belong on it (Marx' Rule, see *). It's less clear what the rule should be for private white or other lists. For the current question of a private list of mailing lists that get special treatment on outgoing mail, it still seems to me that small systems can just allow double signing for everything, and large systems can come up with a pretty good list of their own from a combination of their own incoming mail and the DMARC aggregate reports. The reports will tell you what IPs are sending mail with a combination of your own DKIM signature (valid or broken) and a second signature, so if a host is doing that, and the IP's reputation is not awful, the second signature is an excellent candidate for that list. I have about 35,000 aggregate reports here, should do a little data mining and see how well it works. R's, John * - http://www.brainyquote.com/quotes/quotes/g/grouchomar122546.html From nobody Sun May 10 14:39:04 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1821AC3F6 for ; Sun, 10 May 2015 14:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epzKTJ56cKe0 for ; Sun, 10 May 2015 14:39:00 -0700 (PDT) Received: from groups.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id CFE151AC3F5 for ; Sun, 10 May 2015 14:38:59 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1305; t=1431293938; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=7j/C9CQL55rbMDeoZzaq81KJpVA=; b=lV/8OXoCFJNp9UyHwC37 VW0VMpM+9MQqPvLdVTekB/yj40hrtNTbaZg71V1BKWv1xF8mPD6VWJWOZ3XxVjin FWOJTw2kw3WGXryW6/q3sn1o+Q6QcB3PXNLGpnXwQcNDKg0j+B7kTBamT4h6vHcb wQ1ooHw2BVvQyqaTgJ3G5X4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 10 May 2015 17:38:58 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 708960360.3360.1056; Sun, 10 May 2015 17:38:57 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1305; t=1431293661; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Ksgn09l 4ve/16e/CZgfrSF1C9vNqVinaWb3987szJ0Q=; b=ioZbv2yF9HK4rCjQK+uB5HG BePDpV6RiH3i1thdttqUjT2Dztr+efhjf4izBs71oTTxT9ImY7GYKfFVJOJK9pQ+ Dcol/m9F9Yi6labllJvn5JpDKzDVZhNM9zYRcmgvLLH0fhWy6HfQ7vQOMLZVO2// oCFlPhmzA92sxvstws/8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 10 May 2015 17:34:21 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3596196941.9.13044; Sun, 10 May 2015 17:34:20 -0400 Message-ID: <554FCFEE.9010007@isdg.net> Date: Sun, 10 May 2015 17:38:54 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150510174258.68962.qmail@ary.lan> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] double signing and what DMARC actually does X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 21:39:02 -0000 On 5/10/2015 3:54 PM, John R Levine wrote: > For the current question of a private list of mailing lists that get > special treatment on outgoing mail, it still seems to me that small > systems can just allow double signing for everything, and large > systems can come up with a pretty good list of their own from a > combination of their own incoming mail and the DMARC aggregate > reports. The reports will tell you what IPs are sending mail with a > combination of your own DKIM signature (valid or broken) and a second > signature, so if a host is doing that, and the IP's reputation is not > awful, the second signature is an excellent candidate for that list. > > I have about 35,000 aggregate reports here, should do a little data > mining and see how well it works. I agree. Small systems can manage their DNS resigner management. Generally, the Mail/DNS team are the same folks. Larger systems do have the mail reporting data and SMTP rejection signals with the programming resources and tools to come up with up with administrative system scripts, including creating/updating zone files, if allowed. It can be prepared it so it is readable by the DKIM signer engine. It doesn't have to be done via the DNS protocol but it can certainly by managed as well. -- HLS From nobody Sun May 10 16:37:30 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7871A1B40 for ; Sun, 10 May 2015 16:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_19=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PJbek5JFmIF for ; Sun, 10 May 2015 16:37:27 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFBAA1A1B3C for ; Sun, 10 May 2015 16:37:27 -0700 (PDT) Received: by qkhg7 with SMTP id g7so77613988qkh.2 for ; Sun, 10 May 2015 16:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Vmb/aj5OQp6/fvRzllIyKcOHKlrICpFwflqkX4aEmcw=; b=WIsev6Ph8X+xyRCbaDoaGzkMkD56RBkQwXSOgDEGYk+6crt/0mz7XOB8H5v1qpGUyM IPHaQZLB/C7hbP9emj1lBR//KPHRZzOqhABthcUdjbu2qPV1VCgzo+2M/0lHl+FsD/Od BAcy2x0YkM7yXBXcp2pIqlz0u0UL56tgKeNdoPZcBoUGpf2ho7jsoby+s/jUc0va9mbc tsaADHWNkRKAotgHOdxDb1UuIngKGY7E9T1WY3JMhaXaXh1LHIVlcKCIxMIyNVxWtbDw sUvgZAUCvCMyHk+wlYkJqTuyqrKWMyH52j6c06m8jsbDp8lEIBetVLrGln8SCO50TPrQ c5pg== X-Received: by 10.140.29.133 with SMTP id b5mr9960268qgb.3.1431301047026; Sun, 10 May 2015 16:37:27 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id w67sm9248239qgw.41.2015.05.10.16.37.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 May 2015 16:37:26 -0700 (PDT) Message-ID: <554FEBB4.5050805@gmail.com> Date: Sun, 10 May 2015 16:37:24 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> <14447.1431266709@vindemiatrix.encs.concordia.ca> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 23:37:29 -0000 On 5/10/15 11:00 AM, Murray S. Kucherawy wrote: > Sorry, I sent that too quickly. A couple of other points: > > In both schemes, you need a "registry", which is the set A as maintained by > B through whatever means B wishes. Any DNS mechanism, however, requires > that all mail flows from B via A are endorsed for as long as that DNS > record is published (or cached); with the re-signing scheme, B gets to > choose which specific messages carry that endorsement, via whatever logic > it cares to apply, and for how long the endorsements are effective, and > with what cryptographic strength and other parameters. > > We have evidence in hand that the queryable registry solutions are not > attractive, evidence in the form of ATPS (RFC6541) for which the adoption > rate was above zero by only a vanishingly small amount despite three years > of open publication and an open source implementation. Dear Murray, ATPS included an onerous task for any third-party service likely used on a gratis basis. Each third-party was expected to learn specific hash algorithms of each From domain. A difficult process on top of changing their structure of DKIM signatures repeated tens of thousands of times for each different first party domain. In addition, reputations based on the third-party relationship could not be leveraged because of the optional hashing. Very close to what is likely to become yet another signature scheme. At least John's scheme does not have third-parties guessing about parameters needed in new signatures. Guessing based on an option that should have never been allowed. ATPS self imposed two monstrous hurdles avoided by TPA-Label. DMARC signaling easily supplants rationale used by ATPS to justify its new DKIM signature. Even an alternative of having a DMARC domain adding limited signatures replayed by third parties where the entire message body can change along with selected header fields. People need time to respond and to then receive a subsequent posting. A period likely longer than many days. I just responded to a posting on another list about a week after the initial posting. There are only so many hours in a day. In the event of a limited signature scheme becoming exploited, what response is available to the DMARC domain? Wait for the x=parameter to timeout? I will propose a scheme similar to John's limited signature that includes a means to revoke implied authorizations based on detected abuse. Regards, Douglas Otis From nobody Sun May 10 22:08:17 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193231A0027 for ; Sun, 10 May 2015 22:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfNAC_PHrYkt for ; Sun, 10 May 2015 22:08:14 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 334471A0024 for ; Sun, 10 May 2015 22:08:14 -0700 (PDT) Received: by widdi4 with SMTP id di4so82549392wid.0 for ; Sun, 10 May 2015 22:08:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XXjUlQ+ptErAA2VAzAqEsDWz5HbiujgTynkgHVYCS5Y=; b=ny6cKzBZCfwJaTLt4OmB6++OqbeZdESGe9P5D3lmIuipLcK4zUqDyOENEndIeDgwgj G1B52pkVOAzNUSoL+v7gXTGIZvWwiqHvr81FiMbKZ09u/IjZGWjH8JhMPrn2aVPHB3pH RRFB3RdzRljrUJi2aHQBxyGuH5MimYdbMEA0HqYj0MBshjWnTqZ2tJ2/TY5vUzTAt9I/ wS07Zi1HgSYyJzlPXJRGmdRkPul2KIVnYLEcJ8BrKR+vVlsx1QF/AERlGS/uM8c2XzS9 ctHyac2HLe3RWd8DPnQ+5GiS2MCfpC/ZkkSRDXZ9WJ6CkcIG5n60MKSPi4O41KxfTl2e D5ig== MIME-Version: 1.0 X-Received: by 10.194.61.208 with SMTP id s16mr16972035wjr.135.1431320892837; Sun, 10 May 2015 22:08:12 -0700 (PDT) Received: by 10.27.170.134 with HTTP; Sun, 10 May 2015 22:08:12 -0700 (PDT) In-Reply-To: <554FEBB4.5050805@gmail.com> References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> <14447.1431266709@vindemiatrix.encs.concordia.ca> <554FEBB4.5050805@gmail.com> Date: Sun, 10 May 2015 22:08:12 -0700 Message-ID: From: "Murray S. Kucherawy" To: Douglas Otis Content-Type: multipart/alternative; boundary=047d7b86d3e66094a00515c75dfc Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 05:08:16 -0000 --047d7b86d3e66094a00515c75dfc Content-Type: text/plain; charset=UTF-8 On Sun, May 10, 2015 at 4:37 PM, Douglas Otis wrote: > ATPS included an onerous task for any third-party service > likely used on a gratis basis. Each third-party was expected > to learn specific hash algorithms of each From domain. A > difficult process on top of changing their structure of DKIM > signatures repeated tens of thousands of times for each > different first party domain. In addition, reputations based > on the third-party relationship could not be leveraged > because of the optional hashing. > I continue to find this repeated claim specious at best. Section 7 of ATPS describes the structure of the experiment and invites feedback from anyone who tries it. Apart from Hector's recent declaration and one hobby user of my open source implementation that enabled it, there has been no feedback from the community at large that anyone has tried it or any variant of it. Given the pain point that a widely adopted authorized third-party signatures scheme (in general, not just RFC6541) would solve, one would think we'd have heard something in this regard in the last three years. Nothing beyond what I just mentioned has materialized. If you intend to claim that this is because of specific aspects in RFC6541 of how the DNS records are generated, I suggest you consider that even small operators don't have a problem computing hashes or populating DNS zones, because computers are good at automating things. Even if they did see those things as burdens, such operators tend to be the sort to provide that kind of feedback even about a protocol they ultimately can't use. Seriously, what person in the email space that you've met in the last N years would not take an opportunity to provide feedback, constructive or otherwise? We are a rather opinionated bunch and love the sounds of our own voices. Someone would've said something by now. But it hasn't happened. TPA has existed even longer than ATPS has, and it has enjoyed similarly goose-egg-shaped amounts of adoption. DSAP was around even before that, and the story is the same. What they all have in common is that they are not even close to something that serious operators would be willing to try. They are plagued by -- you guessed it -- the registration problem. Absent a change in that posture by the community at large, this is manifestly a dead end, and we really, seriously, need to stop burning any more of our precious cycles on it. -MSK --047d7b86d3e66094a00515c75dfc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, May 10, 2015 at 4:37 PM, Douglas Otis <doug.m= tview@gmail.com> wrote:
ATPS = included an onerous task for any third-party service
likely used on a gratis basis. Each third-party was expected
to learn specific hash algorithms of each From domain.=C2=A0 A
difficult process on top of changing their structure of DKIM
signatures repeated tens of thousands of times for each
different first party domain. In addition, reputations based
on the third-party relationship could not be leveraged
because of the optional hashing.

I cont= inue to find this repeated claim specious at best.

Sectio= n 7 of ATPS describes the structure of the experiment and invites feedback = from anyone who tries it.=C2=A0 Apart from Hector's recent declaration = and one hobby user of my open source implementation that enabled it, there = has been no feedback from the community at large that anyone has tried it o= r any variant of it.

Given the pain point that a widely a= dopted authorized third-party signatures scheme (in general, not just RFC65= 41) would solve, one would think we'd have heard something in this rega= rd in the last three years.=C2=A0 Nothing beyond what I just mentioned has = materialized.

If you intend to claim that this is because= of specific aspects in RFC6541 of how the DNS records are generated, I sug= gest you consider that even small operators don't have a problem comput= ing hashes or populating DNS zones, because computers are good at automatin= g things.=C2=A0 Even if they did see those things as burdens, such operator= s tend to be the sort to provide that kind of feedback even about a protoco= l they ultimately can't use.=C2=A0 Seriously, what person in the email = space that you've met in the last N years would not take an opportunity= to provide feedback, constructive or otherwise?=C2=A0 We are a rather opin= ionated bunch and love the sounds of our own voices.=C2=A0 Someone would= 9;ve said something by now.=C2=A0 But it hasn't happened.

TPA ha= s existed even longer than ATPS has, and it has enjoyed similarly goose-egg= -shaped amounts of adoption.=C2=A0 DSAP was around even before that, and th= e story is the same.=C2=A0 What they all have in common is that they are no= t even close to something that serious operators would be willing to try.= =C2=A0 They are plagued by -- you guessed it -- the registration problem.
Absent a change in that posture by the community at large,= this is manifestly a dead end, and we really, seriously, need to stop burn= ing any more of our precious cycles on it.

-MSK
=
--047d7b86d3e66094a00515c75dfc-- From nobody Mon May 11 05:14:52 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1A81A1BA4 for ; Mon, 11 May 2015 05:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.138 X-Spam-Level: X-Spam-Status: No, score=-101.138 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVEh9X9VSjcI for ; Mon, 11 May 2015 05:14:48 -0700 (PDT) Received: from mail.santronics.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 19D211A1BAC for ; Mon, 11 May 2015 05:14:46 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4685; t=1431346479; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=7d0baig+qo/80dqfcp8bQ9nSRLU=; b=eyQR/tLPEkDqkI3eznsj MhmkTvKbM7hZk6SJhEmE4CZgD3wPsoq9B0u8uqy/cjm0kdVbwwqtZPiP1UUxUP1Q qS9qYLQJP8pyBtm7uYGCEef/IPz9x4HyIZIXJ+1nB512kS5OzGaBHGZTvcEQytAA grLFklOLfpSu5amsT+bTz/s= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 11 May 2015 08:14:39 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from opensite.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 761501169.5664.616; Mon, 11 May 2015 08:14:39 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4685; t=1431346202; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=f7R19bN sdKyt26LDCLqLJNhZ22MfqOHp1Dkqc7c+7qE=; b=INFd+/wpKLBmlOuQtbESPIj zCpR82zsRBEdWwFC/H/Npw5a73tiS50zHwtRi7SpQDOffmpXzmjsFkZS3uVlB5Tp J/DT+FnN62r00a3HOV2GojZiXHk0i4Vn7HgCYHyeCJRfD+8hcvZ8guzeOSpdMcAS 8TJ/pxuFjYHdophV7pNM= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 11 May 2015 08:10:02 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3648738504.9.12304; Mon, 11 May 2015 08:10:02 -0400 Message-ID: <55509D2E.6070604@isdg.net> Date: Mon, 11 May 2015 08:14:38 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Douglas Otis References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> <14447.1431266709@vindemiatrix.encs.concordia.ca> <554FEBB4.5050805@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 12:14:50 -0000 I don't think it correct to be implying "we gave it an old college try" when in fact, everything was being done to kill policy ideas. Murray, Crocker and Levine where the key IETF cogs working on the DKIM project and all three were pushing a Trust Model, removing the author domain from the picture and in fact, militantly refused to even define the author identity in the DKIM-BIS work which became a STD. Levine was advocating the receiver do not support ADSP and therefore alleviating the MLM problem. Levine refused to update ADSP. At this point, proposing ATPS, well, anything related to POLICY, it was pretty much too late at this point. ADSP was dead. ADSP was abandoned in the DKIM-WG. But as I said, the different now that DMARC replaced ADSP. You got a whole different set of application users here that desperately need a wide policy solution. You made that happen but you didn't complete the job of making ATPS work off DMARC. So you left the holes there. Instead, you made ATPS work off DKIM and that was yet another instant barrier to adoption. It was like, "lets do this, but lets make it hard to do." It was pretty a given that it wasn't going to work. Now you have an opportunity to finally see if this going to work because the focus is with DMARC. You didn't have that POLICY focus before. It wasn't there. Until you do, you are going to continue to have this powerful proof of concept hanging over DKIM. If you updated ATPS to make it work off DMARC, and it doesn't get traction now, I will retire from the DKIM project. I put a huge investment into a commercial DKIM/ADSP/ATPS project and the rug was pulled from under me when you pushed to abandoned ADSP. I am trying to replaced ADSP with DMARC as you want and that includes having the ATPSrev4 piece. It works. Thats a given. You got to do it right. -- HLS On 5/11/2015 1:08 AM, Murray S. Kucherawy wrote: > On Sun, May 10, 2015 at 4:37 PM, Douglas Otis > wrote: > > ATPS included an onerous task for any third-party service > likely used on a gratis basis. Each third-party was expected > to learn specific hash algorithms of each From domain. A > difficult process on top of changing their structure of DKIM > signatures repeated tens of thousands of times for each > different first party domain. In addition, reputations based > on the third-party relationship could not be leveraged > because of the optional hashing. > > > I continue to find this repeated claim specious at best. > > Section 7 of ATPS describes the structure of the experiment and > invites feedback from anyone who tries it. Apart from Hector's recent > declaration and one hobby user of my open source implementation that > enabled it, there has been no feedback from the community at large > that anyone has tried it or any variant of it. > > Given the pain point that a widely adopted authorized third-party > signatures scheme (in general, not just RFC6541) would solve, one > would think we'd have heard something in this regard in the last three > years. Nothing beyond what I just mentioned has materialized. > > If you intend to claim that this is because of specific aspects in > RFC6541 of how the DNS records are generated, I suggest you consider > that even small operators don't have a problem computing hashes or > populating DNS zones, because computers are good at automating > things. Even if they did see those things as burdens, such operators > tend to be the sort to provide that kind of feedback even about a > protocol they ultimately can't use. Seriously, what person in the > email space that you've met in the last N years would not take an > opportunity to provide feedback, constructive or otherwise? We are a > rather opinionated bunch and love the sounds of our own voices. > Someone would've said something by now. But it hasn't happened. > > TPA has existed even longer than ATPS has, and it has enjoyed > similarly goose-egg-shaped amounts of adoption. DSAP was around even > before that, and the story is the same. What they all have in common > is that they are not even close to something that serious operators > would be willing to try. They are plagued by -- you guessed it -- the > registration problem. > > Absent a change in that posture by the community at large, this is > manifestly a dead end, and we really, seriously, need to stop burning > any more of our precious cycles on it. > > -MSK > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > From nobody Mon May 11 07:05:15 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E951A8942 for ; Mon, 11 May 2015 07:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.537 X-Spam-Level: X-Spam-Status: No, score=-100.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ln39JMYkODbS for ; Mon, 11 May 2015 07:05:06 -0700 (PDT) Received: from groups.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF401A8928 for ; Mon, 11 May 2015 07:05:05 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=7549; t=1431353095; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=KA3hk9EJfeFBE+4GENJ5jTZczjY=; b=vczdg9vghKcoD+hTBYH1 /tdrInjSBuLGRO/l48fpqSEomJ7xzHGhmigmERrxvtJRinn3XYjfrV8uw6yJvSph si67arqdNVh1OURi8sbmKvJrDk2Aa941kP1n0uZCegqb2D7PA8C9U8PMbS8icvB4 lsZBXCt1zw65cXIL6vxKhXU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 11 May 2015 10:04:55 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 768116610.1.2884; Mon, 11 May 2015 10:04:54 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=7549; t=1431352816; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=HQNdbGq kkZeb4NEZ66SmO5IAC5GKzSFqTcsRnqiUI6g=; b=dWmCSdmaniInd7sdk5ttsOG 3GqzfuV71pAY9BHsz9uZqmxsYtuedEi/KGzhwqP36jFQw10+c8zBg8JAnbGkSNhx pC7dDob3SRqnBorUy6bxMRgRpcJIa+wEua4mXNMsUZXc/5Ij2IDR5TYgZBPH+BzA SoSCLvqQ0YZykfIxmqiw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 11 May 2015 10:00:16 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3655352395.9.12888; Mon, 11 May 2015 10:00:15 -0400 Message-ID: <5550B704.4070305@isdg.net> Date: Mon, 11 May 2015 10:04:52 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Douglas Otis References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> <14447.1431266709@vindemiatrix.encs.concordia.ca> <554FEBB4.5050805@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 14:05:14 -0000 Murray, a clarification about DSAP. Of late, I've been using the term DSAP as a general methodology for a complete DKIM Signature Authorization Protocol. DSAP, TPA, ATPS are all the basic ideas. We need a generic term since there are many with all the same basic functional principles, but in different syntax languages. However, for the record, there was a 2006 DSAP I-D proposal https://tools.ietf.org/html/draft-santos-dkim-dsap-00 that I believe you referred to. I want to make a clarification above it. In general, DSAP covered the same policy ideas as with SSP using a different language. SSP covered these polices: o=? WEAK (signature optional, no third party) o=~ NEUTRAL (signature optional, 3rd party allowed) o=- STRONG (signature required, 3rd party allowed) o=! EXCLUSIVE (signature required, no 3rd party) o=. NEVER (no mail expected) o=^ USER DSAP was more about the protocol methodology covering all the possible signature boundary conditions in the Protocol State Machine for two signatures; combinations of 1st party with a 3rd party, including the lack of the signatures. It described this using two tags: 4.2. DSAP Tags: op=; 3p=; From the viewpoint of the verifier, when a message is received, there are two basic pieces of signature information to be of interest when analyzing the transaction: o Original Party Signatures (OP) * never expected * always expected * optional o 3rd Party Signatures (3P) * never expected * always expected * optional When the two signature types are combined, the possible policies are listed in this following table: +=================================================================+ | op= | 3p= | Domain Policy Semantics | |=================================================================| | empty | empty | No mail expected | |-----------------------------------------------------------------| | never | never | No signing expected | | never | always | Only 3P signing expected | | never | optional | Only 3P signing optional | |-----------------------------------------------------------------| | always | never | OP signature expected | | always | always | Both parties expected | | always | optional | OP expected, 3P may sign | |-----------------------------------------------------------------| | optional | never | Only OP signing expected | | optional | always | OP expected, 3P expected | | optional | optional | Both parties may sign. | +-----------------------------------------------------------------+ Figure 4: DSAP Message Signing Policies But for 3rd party authorization, without a complete satisfactory DNS way to do this and a desire to not do another DNS call, a minimal smaller scale method was proposed using a "3pl=" record tag: 4.3. DSAP Tag; 3pl=; The 3pl= is an optional tag that defines a list of 3rd party domains who are allowed to DKIM sign the message as a 3rd party signer. This tag is ignored unless 3rd party signing policy is expected or optional (3p=always or 3p=optional). is a comma delimited list of domain names. Example: 3pl=isp.com,outsource.com,mailinglist.com; When Doug introduced the TPA hashing idea, it fit the need for larger scale needs but it was written too complex. When you improved the TPA idea with ATPS using simple TRUE/FALSE (record exist) semantics and also using the same TPA hashing ideas, I implemented ATPS instead. It was just simpler and easier to code, test and explore. So my implementation of the DKIM policy experiment and exploration was with the small scale "3pl" tag now called "asl" for Allowed Signer List and the ATPS support for the larger scale DNS lookup: [atps=y;] [asl=resigner-domains;] That was made off ADSP and now off the DMARC record. It works. DMARC extensions are supported at implementations from a parsing standpoint. They won't abort. And for ASL, ATPS supported receivers, it works. As long as you can manage your DNS records, it works fine. I think perhaps what we need to do is step back and think about what DMARC should be doing as far as DMARC extension tags to make this all optional and available. I like the SAM idea ("Signer Authorization Method"), Doug called it Specific Advisory Method, so a tag that defines the method a signer may wish to authorize and I think we have two basic ideas: sam=atps dns lookup (default) sam=dsfs dual signature I say atps should be default because its the simplest to implement without changing dkim engines. I don't think you should push for Dual Sign method only. -- HLS On 5/11/2015 1:08 AM, Murray S. Kucherawy wrote: > On Sun, May 10, 2015 at 4:37 PM, Douglas Otis > wrote: > > ATPS included an onerous task for any third-party service > likely used on a gratis basis. Each third-party was expected > to learn specific hash algorithms of each From domain. A > difficult process on top of changing their structure of DKIM > signatures repeated tens of thousands of times for each > different first party domain. In addition, reputations based > on the third-party relationship could not be leveraged > because of the optional hashing. > > > I continue to find this repeated claim specious at best. > > Section 7 of ATPS describes the structure of the experiment and > invites feedback from anyone who tries it. Apart from Hector's recent > declaration and one hobby user of my open source implementation that > enabled it, there has been no feedback from the community at large > that anyone has tried it or any variant of it. > > Given the pain point that a widely adopted authorized third-party > signatures scheme (in general, not just RFC6541) would solve, one > would think we'd have heard something in this regard in the last three > years. Nothing beyond what I just mentioned has materialized. > > If you intend to claim that this is because of specific aspects in > RFC6541 of how the DNS records are generated, I suggest you consider > that even small operators don't have a problem computing hashes or > populating DNS zones, because computers are good at automating > things. Even if they did see those things as burdens, such operators > tend to be the sort to provide that kind of feedback even about a > protocol they ultimately can't use. Seriously, what person in the > email space that you've met in the last N years would not take an > opportunity to provide feedback, constructive or otherwise? We are a > rather opinionated bunch and love the sounds of our own voices. > Someone would've said something by now. But it hasn't happened. > > TPA has existed even longer than ATPS has, and it has enjoyed > similarly goose-egg-shaped amounts of adoption. DSAP was around even > before that, and the story is the same. What they all have in common > is that they are not even close to something that serious operators > would be willing to try. They are plagued by -- you guessed it -- the > registration problem. > > Absent a change in that posture by the community at large, this is > manifestly a dead end, and we really, seriously, need to stop burning > any more of our precious cycles on it. > > -MSK > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- HLS From nobody Mon May 11 11:57:03 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F027B1A8851 for ; Mon, 11 May 2015 11:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olE2c8PdmV_4 for ; Mon, 11 May 2015 11:57:00 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 021471ACF0A for ; Mon, 11 May 2015 11:56:46 -0700 (PDT) Received: by pdbqd1 with SMTP id qd1so152983580pdb.2 for ; Mon, 11 May 2015 11:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=5HoCIWs2GqEzo4j+11aZIi5uCgxFpjuLNJY9s6QWRwk=; b=xVWO2UHmm4/xJxzanseLDZ2mXOIXM6+38l1WYB6YKlm+miVhkMB5G5NT4pkwrnxu3+ ui+79mXQT2FsZBiXrFM5Y3/xeMX8r3IL7d1bPcHhBvPjisaBWfFuMhhcD3YQ7H2jGqGN muR0NsdnOTAqSWR4J9DZ0r5M1MC12qvN8aTubgU1Q4cz0BRA86WwdZgXma2GzM2ALCY0 UWZ5vux/Aybr+AznOLD48IRbF1gzvPsBeXXFyFw3XlVFjDW/g4y3HrjOD7Jctt8O1fjF GjUre4eu4XUBMWUv4pCYNLDbarSXyvjQpycOYCq6tmC4GLqIc/cwAkRPcNvv1xhjt9V7 vw+w== X-Received: by 10.68.233.71 with SMTP id tu7mr21542845pbc.14.1431370605724; Mon, 11 May 2015 11:56:45 -0700 (PDT) Received: from US-DOUGO-MAC.local (c-76-21-122-217.hsd1.ca.comcast.net. [76.21.122.217]) by mx.google.com with ESMTPSA id i16sm13803594pbq.79.2015.05.11.11.56.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 May 2015 11:56:44 -0700 (PDT) Message-ID: <5550FB6C.7050802@gmail.com> Date: Mon, 11 May 2015 11:56:44 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> <14447.1431266709@vindemiatrix.encs.concordia.ca> <554FEBB4.5050805@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2015 18:57:02 -0000 On 5/10/15 10:08 PM, Murray S. Kucherawy wrote: > On Sun, May 10, 2015 at 4:37 PM, Douglas Otis wrote: > >> ATPS included an onerous task for any third-party service >> likely used on a gratis basis. Each third-party was expected >> to learn specific hash algorithms of each From domain. A >> difficult process on top of changing their structure of DKIM >> signatures repeated tens of thousands of times for each >> different first party domain. In addition, reputations based >> on the third-party relationship could not be leveraged >> because of the optional hashing. > I continue to find this repeated claim specious at best. Unlike TPA-Label that required NO third-party authentication method change, ATPS imposed two significant changes onto third-parties: 1) A need for a new DKIM signature unique for _every_ Author domain seen by the mediator. 2) A need to determine an _unspecified_ hash unique for each Author domain seen by the mediator. Both of these unnecessary and difficult impositions do not align with those benefiting (the DMARC domain). This type of misaligned and overly difficult responsibility greatly impedes adoption where no conclusions can be derived from a lack of adoption. Calling these claims specious suggests: 1) Making onerous impositions on third-parties was not the cause ATPS not being adopted. How in the heck does one prove that? > Section 7 of ATPS describes the structure of the experiment and invites > feedback from anyone who tries it. Apart from Hector's recent declaration > and one hobby user of my open source implementation that enabled it, there > has been no feedback from the community at large that anyone has tried it > or any variant of it. > > Given the pain point that a widely adopted authorized third-party > signatures scheme (in general, not just RFC6541) would solve, one would > think we'd have heard something in this regard in the last three years. > Nothing beyond what I just mentioned has materialized. > > If you intend to claim that this is because of specific aspects in RFC6541 > of how the DNS records are generated, I suggest you consider that even > small operators don't have a problem computing hashes or populating DNS > zones, because computers are good at automating things. Even if they did > see those things as burdens, such operators tend to be the sort to provide > that kind of feedback even about a protocol they ultimately can't use. > Seriously, what person in the email space that you've met in the last N > years would not take an opportunity to provide feedback, constructive or > otherwise? We are a rather opinionated bunch and love the sounds of our > own voices. Someone would've said something by now. But it hasn't > happened. > > TPA has existed even longer than ATPS has, and it has enjoyed similarly > goose-egg-shaped amounts of adoption. The TPA label effort was dropped when it looked like ADSP was not going anywhere. You picked up the idea and that was fine, but I warned about a variable hash causing unreasonable complexity. The basic concept of TPA-Label remains sound and still offers a simple way to establish informal federations. Once someone attempts to offer any sort of delegation based on DKIM signatures will quickly discover a need to retract errant authorizations which DKIM can not accommodate. TPA-Label can operate from a DNS server independent of other services used by a domain. TPA-Label places the burden on the DMARC domain (or their proxy) to indicate to their recipients which of the various third-party message sources do not abuse their domain. After all, only the DMARC domain receives feedback and can compare it against outbound logs. Only they represent a reliable authority. > DSAP was around even before that, > and the story is the same. What they all have in common is that they are > not even close to something that serious operators would be willing to > try. They are plagued by -- you guessed it -- the registration problem. > > Absent a change in that posture by the community at large, this is > manifestly a dead end, and we really, seriously, need to stop burning any > more of our precious cycles on it. That is why there is an offer on the table to allow us to establish this type of feedback for any large ESP. It can be done effectively without becoming onerous. Really. Does any large ESP wish to defend public exchanges within their domain? Anything that defends open exchange is worth a few cycles. If not, DMARC should then offer a policy profile that includes Sender header field. Otherwise DMARC remains non-compatible and is disruptive of desired interchange as a result. Regards, Douglas Otis From nobody Mon May 11 19:17:14 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809BE1B2B63 for ; Mon, 11 May 2015 19:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.498 X-Spam-Level: ** X-Spam-Status: No, score=2.498 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l787hYhmzUm0 for ; Mon, 11 May 2015 19:17:10 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id EB0C51B2B60 for ; Mon, 11 May 2015 19:17:09 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 639B81C386E; Tue, 12 May 2015 11:17:08 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 3D33211F6A1; Tue, 12 May 2015 11:17:08 +0900 (JST) From: "Stephen J. Turnbull" To: Scott Kitterman In-Reply-To: <8CA948BD-E833-4D05-A9A1-71497F4647FB@kitterman.com> References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <87y4ky2kif.fsf@uwakimon.sk.tsukuba.ac.jp> <90B1E4C8-A53D-4226-A1F6-E35CF57091C7@kitterman.com> <797144B2-4A86-4229-B800-11BC857DA85F@isdg.net> <8CA948BD-E833-4D05-A9A1-71497F4647FB@kitterman.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 12 May 2015 11:17:08 +0900 Message-ID: <87fv7235gb.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 02:17:12 -0000 Scott Kitterman writes: > Actually, the idea behind MARID was to come up with a single > solution Is there something we can learn from MARID? I don't see it in the context of the current discussion, as MARID had little to say about third parties (it treated them as first parties, and handled third party issues by suggesting "certification registries"), and explicitly disclaimed authentication of authorship claims. From nobody Mon May 11 19:33:42 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C68E1B2BAF for ; Mon, 11 May 2015 19:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOIYe1RiIqwR for ; Mon, 11 May 2015 19:33:39 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A63011B2BAE for ; Mon, 11 May 2015 19:33:39 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id C1CE9C40029 for ; Mon, 11 May 2015 21:33:38 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1431398018; bh=hx8NIKIKQLiexYXSWVBEmvr0LBDtDi4jqqq5oowX4UM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=iAQs8EOo2EsyqqXz95wlgcZ1EQB4nKMU96XR6YlrkfKgnUDubPtrllILX/PNRZ/+M 1ZM2loObeTp3H1dpfb9FM7YXLLQoQFriE3dq9lXxEC0HRRNMnQkc5Jo2hvbymrVJGZ Gxb2pQtIdHQz8GMc/DhsEILdnHiDdBYFPIcGmn4k= From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 11 May 2015 22:33:40 -0400 Message-ID: <11851689.hvcSbDpPUx@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-51-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <87fv7235gb.fsf@uwakimon.sk.tsukuba.ac.jp> References: <554BC30F.1020107@isdg.net> <8CA948BD-E833-4D05-A9A1-71497F4647FB@kitterman.com> <87fv7235gb.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 02:33:41 -0000 On Tuesday, May 12, 2015 11:17:08 AM Stephen J. Turnbull wrote: > Scott Kitterman writes: > > Actually, the idea behind MARID was to come up with a single > > solution > > Is there something we can learn from MARID? I don't see it in the > context of the current discussion, as MARID had little to say about > third parties (it treated them as first parties, and handled third > party issues by suggesting "certification registries"), and explicitly > disclaimed authentication of authorship claims. I think the situation is different enough in many respects that there's not much to learn from it today. I mostly responded because I think that if people do discuss history, they ought to be accurate about it. If there's a lesson to be learned it's that the complete lack of existence of those certification registries ought to perhaps give pause to those arguing for similar things now. For SPF there was a service for some time called trusted- forwarder.org, but it never really got much traction. The reasons MARID was terminated with no output (none of the SPF and Sender-ID RFCs were working group products, they were done independently after the working group was closed and both were different in important respects than what MARID was working towards) were, IMO, entirely non-technical. I'm willing to discuss them if someone wants to chat about history, but not here, I think it's off topic. Scott K From nobody Mon May 11 21:16:28 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 423B61A0127 for ; Mon, 11 May 2015 21:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.301 X-Spam-Level: X-Spam-Status: No, score=-99.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xxlqsYJmqma for ; Mon, 11 May 2015 21:16:24 -0700 (PDT) Received: from ftp.catinthebox.net (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id A42041A0125 for ; Mon, 11 May 2015 21:16:24 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1453; t=1431404181; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=j0qETQYLv4P2P2w+HXthKgJVr2c=; b=Il2DdrHjvS27vjGNlsbL rHM8ZxDZdspGKcQM5hxDdFAwBtCul+IcWOZEUs2GWc6ys3okJkt+jYaPPCrAZct5 z5JWn8B5dq79kJBJk3PhvFl5HZdigjf64zZL2mxnz27f/aIhSg7eegojC9Upe+5h V3XXoCXPT7Zr70Cmqpopfbo= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 12 May 2015 00:16:21 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 819202367.484.5492; Tue, 12 May 2015 00:16:21 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1453; t=1431403902; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=iUfz7C1 ihELp2HFzGQBMrxALg4aJAZHlwDsehbuHRRY=; b=bc8hpKljiD6Fe1K88cduCkH H2zk9auzJKVzzK/vQktxZYnZ7MRSUhO9nxHYn1A5WCcg+ZNtZSEzu6EC0+I726jZ 2LAeRQh5T62+1bRK1SeCTqmMe9GGDc6ej7xYWBUw/kLrW3xOYNi00ZtIzziberRX LGsByb6IgQrpYO/QV5rs= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 12 May 2015 00:11:42 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3706437926.9.15596; Tue, 12 May 2015 00:11:41 -0400 Message-ID: <55517E93.4030802@isdg.net> Date: Tue, 12 May 2015 00:16:19 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <87y4ky2kif.fsf@uwakimon.sk.tsukuba.ac.jp> <90B1E4C8-A53D-4226-A1F6-E35CF57091C7@kitterman.com> <797144B2-4A86-4229-B800-11BC857DA85F@isdg.net> <8CA948BD-E833-4D05-A9A1-71497F4647FB@kitterman.com> <87fv7235gb.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87fv7235gb.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 04:16:27 -0000 On 5/11/2015 10:17 PM, Stephen J. Turnbull wrote: > Scott Kitterman writes: > > > Actually, the idea behind MARID was to come up with a single > > solution > > Is there something we can learn from MARID? I don't see it in the > context of the current discussion, as MARID had little to say about > third parties (it treated them as first parties, and handled third > party issues by suggesting "certification registries"), and explicitly > disclaimed authentication of authorship claims. MARID main trust was with SPF and CEP (Micrsoft's XML version of SPF renamed to SenderID when it was changed to a SPF syntax), but the MARID group was open to other proposals to compete with the SPF solution. Those other proposals included: - Domainkeys that included a simple always/sometimes sign policy, - DKIM, a better Domainkeys with extended third party policies, - CSV/DNA, an SMTP EHLO level Reputation Method. These were the first introductions of the idea for Signature TRUST MODEL and the chain of trust which eventually became the main focus in the DKIM-WG working group. But the main focus in MARID was with the SPF idea and there was outputs from MARID -- a direction to complete the four RFCs and to treat them as experiments: RFC4405 SUBMITTER SMTP Service Extension RFC4406 Sender ID: Authenticating E-Mail RFC4407 Purported Responsible Address (PRA) RFC4408 Sender Policy Framework (SPF) -- HLS From nobody Mon May 11 21:40:36 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480671A0250 for ; Mon, 11 May 2015 21:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.479 X-Spam-Level: X-Spam-Status: No, score=-100.479 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_54=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yvj6oX9oEDBw for ; Mon, 11 May 2015 21:40:33 -0700 (PDT) Received: from ftp.catinthebox.net (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 26B5E1A0242 for ; Mon, 11 May 2015 21:40:33 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2782; t=1431405627; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=OnPcDQ2uESI4i9l8StdeXDbLPBI=; b=rtCyfUxm+VwEIcq3z9Hu vSQ5syHcYyeJwxPHD88rwiWqjeOl1HpRCUIWczefJ50B7JtARClVyw0WdiQl9xOe YtgHZbUjq4OnP7AvN+MTsPDwJPGmuZXxVOWnqn7OqZJgGvS6q7AUZiiQhfceVgmv JvEIPHUAdyBNeOJ5dhGPOyo= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 12 May 2015 00:40:27 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 820647607.484.4980; Tue, 12 May 2015 00:40:26 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2782; t=1431405345; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=B92xpyW abS40oF54/mLOYnun6rFuzwB8IvwLp3LTV9E=; b=ZwHRa5yJ1A1xS11HhUDji2s gNO2nF/ESrtbTX+xQtAFtM7ovH3iB4Nsr7ph+MFNeDdVJPqasxa9DmZL0G1eclFa SPbrKRuXwfCl8o9cPvqe91+bCYbaf6vQYaxB9MIRvxW5Crm8SMngmhJHV4fHilCc Cv0qrC8xJrt8hyVGni1Y= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 12 May 2015 00:35:45 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3707881238.9.15776; Tue, 12 May 2015 00:35:44 -0400 Message-ID: <55518437.7040104@isdg.net> Date: Tue, 12 May 2015 00:40:23 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554BC30F.1020107@isdg.net> <8CA948BD-E833-4D05-A9A1-71497F4647FB@kitterman.com> <87fv7235gb.fsf@uwakimon.sk.tsukuba.ac.jp> <11851689.hvcSbDpPUx@kitterma-e6430> In-Reply-To: <11851689.hvcSbDpPUx@kitterma-e6430> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 04:40:36 -0000 On 5/11/2015 10:33 PM, Scott Kitterman wrote: > On Tuesday, May 12, 2015 11:17:08 AM Stephen J. Turnbull wrote: >> Scott Kitterman writes: >> > Actually, the idea behind MARID was to come up with a single >> > solution >> >> Is there something we can learn from MARID? I don't see it in the >> context of the current discussion, as MARID had little to say about >> third parties (it treated them as first parties, and handled third >> party issues by suggesting "certification registries"), and explicitly >> disclaimed authentication of authorship claims. > > I think the situation is different enough in many respects that there's not > much to learn from it today. I mostly responded because I think that if > people do discuss history, they ought to be accurate about it. You should be careful of accusing me of being inaccurate. I said nothing inaccurate about MARID and the history of SPF. My point is very simple and its a fact. You should be very lucky that many folks like myself and others argued for SPF even though there were much DNS concerns and that included concerns how the larger mail providers can resolve IP transition problems and their inability to use strong policies that can offer a big payoff in results. Still to this day, most, if not all of the ESP domains, can not use a -ALL policy. > If there's a lesson to be learned it's that the complete lack of existence of > those certification registries ought to perhaps give pause to those arguing for > similar things now. For SPF there was a service for some time called trusted- > forwarder.org, but it never really got much traction. Most people didn't want centralization (yet)-- this was one of the outcomes from MARID. For the record, I am not advocating a centralized lookup. > The reasons MARID was terminated with no output (none of the SPF and Sender-ID > RFCs were working group products, they were done independently after the > working group was closed and both were different in important respects than > what MARID was working towards) were, IMO, entirely non-technical. There were plenty of outcomes from MARID and the direction to complete the RFCs were among them. SUBMITTER was the first to be completed with the first RFC#, the 4405 to 4408 series of MARID generated RFC results. For the public record, I was pointing SPF did indeed and still does have a registration problem the big domains still have. None of them can use a -ALL and if they did, we can expect they will begin to get many false positives. SPF has a higher overhead than DMARC+ATPS would have. SPF has INCLUDE statements which is functionally equivalent to a registration concept when it uses this as a means to include authorized mail senders. -- HLS From nobody Mon May 11 22:18:17 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06851A0393 for ; Mon, 11 May 2015 22:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 949iKuPh3_8S for ; Mon, 11 May 2015 22:18:14 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A7F81A0389 for ; Mon, 11 May 2015 22:18:14 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 5624FC40029 for ; Tue, 12 May 2015 00:18:13 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1431407893; bh=t4ZnkwWy6lydi0h7xYScjJI4aCv7+vxsCNN+JeMC1n0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=yGIT+WotDqjjtG/DDIafliZotwUTRYG4x4/zHvYLkmwxKkjJvqlPPs2MyYRlkBq9p HM6VAfAIRL3MvLKivAr5JbKvA29sj5b3dutXl42hoAwUoKNUvYKtDBDDUB937KfFj+ fiV9caVya/DZQHplvKiEAxecHVlKy1QCYb883wQI= From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 12 May 2015 01:18:15 -0400 Message-ID: <18373337.j52nAxqeMN@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-51-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <55517E93.4030802@isdg.net> References: <554BC30F.1020107@isdg.net> <87fv7235gb.fsf@uwakimon.sk.tsukuba.ac.jp> <55517E93.4030802@isdg.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 05:18:16 -0000 On Tuesday, May 12, 2015 12:16:19 AM Hector Santos wrote: > On 5/11/2015 10:17 PM, Stephen J. Turnbull wrote: > > Scott Kitterman writes: > > > Actually, the idea behind MARID was to come up with a single > > > solution > > > > Is there something we can learn from MARID? I don't see it in the > > context of the current discussion, as MARID had little to say about > > third parties (it treated them as first parties, and handled third > > party issues by suggesting "certification registries"), and explicitly > > disclaimed authentication of authorship claims. > > MARID main trust was with SPF and CEP (Micrsoft's XML version of SPF > renamed to SenderID when it was changed to a SPF syntax), but the > MARID group was open to other proposals to compete with the SPF > solution. Those other proposals included: > > - Domainkeys that included a simple always/sometimes sign policy, > - DKIM, a better Domainkeys with extended third party policies, > - CSV/DNA, an SMTP EHLO level Reputation Method. > > These were the first introductions of the idea for Signature TRUST > MODEL and the chain of trust which eventually became the main focus in > the DKIM-WG working group. > > But the main focus in MARID was with the SPF idea and there was > outputs from MARID -- a direction to complete the four RFCs and to > treat them as experiments: > > RFC4405 SUBMITTER SMTP Service Extension > RFC4406 Sender ID: Authenticating E-Mail > RFC4407 Purported Responsible Address (PRA) > RFC4408 Sender Policy Framework (SPF) Don't take my word for it. Here's the list of active/published documents for MARID: https://datatracker.ietf.org/wg/marid/documents/ [Note to save everyone time, none are listed] As indicated when the working group closed [1] none of the follow-on experimental documents were products of the working group, in fact, deviations from what the working group had agreed on were the source of one appeal. [1] http://www.imc.org/ietf-mxcomp/mail-archive/msg05054.html Going back and trying to justify things in this working group based on a revisionist history of a decade old failed working group isn't going to get us anywhere. Scott K From nobody Mon May 11 22:29:08 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5AE1A039F for ; Mon, 11 May 2015 22:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XRl-8xdk3VO for ; Mon, 11 May 2015 22:29:04 -0700 (PDT) Received: from mail.santronics.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id F02B81A0399 for ; Mon, 11 May 2015 22:29:03 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1454; t=1431408537; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=q2FinOYZzewawyFv47PPJ7v3QuY=; b=tTtbyuaiaMiA2I8xz3G6 xZ4rX4hGFbyrNuE8+zFiKOjQCpoWWBA7xvq2I8Ez45Knmb2WgyLlxDMzRa5GxOsk j1fELXaM91+v4ug/R1JiXkn7i7UBI4f7wET4tuX+KmDSMSdJJF+IWtQQtfgISqDl dFSq8sBrjs6avOraHa3mEPI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 12 May 2015 01:28:57 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 823557790.484.888; Tue, 12 May 2015 01:28:56 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1454; t=1431408256; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=170FX5u O9rQWoJY6vEe0M6mgiyM7ZeKgtHJxDYVa0zo=; b=xsGM9tg0nTxFdEoOFbJ0iZh STsA3Z7Fmjp7xJUnAMBOp9g6t9nj6aiNFH66bjUluydnwL7hq3VvzOQAmBUr9hOi Kn9udRHOzpnGJ2pL8cpW59Lg35dz7QqqQFJ4RWiPd4yHWHJ9vX9WU4G24v95m+1N YkTz0PpVrn2f2OwedKFk= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 12 May 2015 01:24:16 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3710792270.9.16192; Tue, 12 May 2015 01:24:15 -0400 Message-ID: <55518F96.8040708@isdg.net> Date: Tue, 12 May 2015 01:28:54 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> <14447.1431266709@vindemiatrix.encs.concordia.ca> <554FEBB4.5050805@gmail.com> <5550FB6C.7050802@gmail.com> In-Reply-To: <5550FB6C.7050802@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 05:29:06 -0000 On 5/11/2015 2:56 PM, Douglas Otis wrote: > > On 5/10/15 10:08 PM, Murray S. Kucherawy wrote: >> On Sun, May 10, 2015 at 4:37 PM, Douglas Otis wrote: >> >>> ATPS included an onerous task for any third-party service >>> likely used on a gratis basis. Each third-party was expected >>> to learn specific hash algorithms of each From domain. A >>> difficult process on top of changing their structure of DKIM >>> signatures repeated tens of thousands of times for each >>> different first party domain. In addition, reputations based >>> on the third-party relationship could not be leveraged >>> because of the optional hashing. >> >> I continue to find this repeated claim specious at best. >> > Unlike TPA-Label that required NO third-party authentication > method change, ATPS imposed two significant changes onto > third-parties: > > 1) A need for a new DKIM signature unique for _every_ Author > domain seen by the mediator. It should be off the DMARC record now. > 2) A need to determine an _unspecified_ hash unique for each > Author domain seen by the mediator. Do we really need a hash? I agree. This required new tools (Hash calculators, wizard, command line tools, DNS tools, etc) for DNS admin and sysops to be programmed. Makes it harder to explore. > Both of these unnecessary and difficult impositions do not > align with those benefiting (the DMARC domain). +1. -- HLS From nobody Mon May 11 22:44:17 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5480F1A004D for ; Mon, 11 May 2015 22:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5ozKNF_U7g9 for ; Mon, 11 May 2015 22:44:13 -0700 (PDT) Received: from mail.santronics.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 787D81A004A for ; Mon, 11 May 2015 22:44:13 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3942; t=1431409447; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=l2dNvM9KBwTZ4YbOC3UIyY9C2Ug=; b=rKNHmlUVA5YarbbzWFbA 5T9mw9pTsCOEnACfkHAZ8IOdnxn/0sLTGsilp08N2evod9rHB0mHa1rxsAdLN92g /vbHmHNc+q5lxf7pcW7WVJZovqZNQDK8I23KdIDc7YdPvmKfOC47zOlEXYjPHiRK JDh+0PpwaNEwtb2F2H6RZnM= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 12 May 2015 01:44:07 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 824467900.484.4436; Tue, 12 May 2015 01:44:06 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3942; t=1431409168; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=z+xnALY bwWqmB7RMvUvRdA4/9wN3Cuq+68fqsLN1U5s=; b=2yzvWDLoRX8jVAUNA6MCK/M SSbdp6dIIY3bUJ50iIiuStMCPvpnxnAo7ogdjKFdwxS9tUHxcnWLeIuKsSlYQ5Fd 7LrJ7UndaL8HaP1Q0LDogLKxf3lIhb8kCdOsl1/rXhawnAzswFFOw8ky85W0r/TR NwByAeafK8ty8DU3IXEw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 12 May 2015 01:39:28 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3711704316.9.16364; Tue, 12 May 2015 01:39:27 -0400 Message-ID: <55519326.9050406@isdg.net> Date: Tue, 12 May 2015 01:44:06 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554BC30F.1020107@isdg.net> <87fv7235gb.fsf@uwakimon.sk.tsukuba.ac.jp> <55517E93.4030802@isdg.net> <18373337.j52nAxqeMN@kitterma-e6430> In-Reply-To: <18373337.j52nAxqeMN@kitterma-e6430> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 05:44:15 -0000 On 5/12/2015 1:18 AM, Scott Kitterman wrote: > On Tuesday, May 12, 2015 12:16:19 AM Hector Santos wrote: >> On 5/11/2015 10:17 PM, Stephen J. Turnbull wrote: >>> Scott Kitterman writes: >>> > Actually, the idea behind MARID was to come up with a single >>> > solution >>> >>> Is there something we can learn from MARID? I don't see it in the >>> context of the current discussion, as MARID had little to say about >>> third parties (it treated them as first parties, and handled third >>> party issues by suggesting "certification registries"), and explicitly >>> disclaimed authentication of authorship claims. >> >> MARID main trust was with SPF and CEP (Micrsoft's XML version of SPF >> renamed to SenderID when it was changed to a SPF syntax), but the >> MARID group was open to other proposals to compete with the SPF >> solution. Those other proposals included: >> >> - Domainkeys that included a simple always/sometimes sign policy, >> - DKIM, a better Domainkeys with extended third party policies, >> - CSV/DNA, an SMTP EHLO level Reputation Method. >> >> These were the first introductions of the idea for Signature TRUST >> MODEL and the chain of trust which eventually became the main focus in >> the DKIM-WG working group. >> >> But the main focus in MARID was with the SPF idea and there was >> outputs from MARID -- a direction to complete the four RFCs and to >> treat them as experiments: >> >> RFC4405 SUBMITTER SMTP Service Extension >> RFC4406 Sender ID: Authenticating E-Mail >> RFC4407 Purported Responsible Address (PRA) >> RFC4408 Sender Policy Framework (SPF) > > Don't take my word for it. Here's the list of active/published documents for > MARID: > > https://datatracker.ietf.org/wg/marid/documents/ > > [Note to save everyone time, none are listed] > > As indicated when the working group closed [1] none of the follow-on > experimental documents were products of the working group, in fact, deviations > from what the working group had agreed on were the source of one appeal. > > [1] http://www.imc.org/ietf-mxcomp/mail-archive/msg05054.html > > Going back and trying to justify things in this working group based on a > revisionist history of a decade old failed working group isn't going to get us > anywhere. I wasn't revising anything. I lived it, I produced products from it. Did you? Its called Engineering Synergism. Maybe RFC4408 didn't change much from the original draft, but RFC4405/6/7 were produced because of all of the related discussions in MARID. How do you think CEP morphed to SenderID, PRA and Submitter? You also had the sparks of getting other ideas moving along like DKIM. The time was not totally a waste and we learned from it. Synergism. There was a direction. Finally, you seem to forget the IESG Note that was added to all four documents. Skip the link, here it is: IESG Note The following documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) are published simultaneously as Experimental RFCs, although there is no general technical consensus and efforts to reconcile the two approaches have failed. As such these documents have not received full IETF review and are published "AS-IS" to document the different approaches as they were considered in the MARID working group. The IESG takes no position about which approach is to be preferred and cautions the reader that there are serious open issues for each approach and concerns about using them in tandem. The IESG believes that documenting the different approaches does less harm than not documenting them. The community is invited to observe the success or failure of the two approaches during the two years following publication, in order that a community consensus can be reached in the future. The work wasn't so independent and a coincidence that these four docs inserted the IESG note. Thanks -- HLS From nobody Tue May 12 17:42:44 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9541E1A88AF for ; Tue, 12 May 2015 17:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23LgFrpOuRk1 for ; Tue, 12 May 2015 17:42:41 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 906C31A8881 for ; Tue, 12 May 2015 17:42:41 -0700 (PDT) Received: by pacwv17 with SMTP id wv17so31819228pac.0 for ; Tue, 12 May 2015 17:42:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=+cr8xeMkEgoTHAPaDI5UsXLHoZ/QXas4opox1Lnj6aw=; b=QpU47esPHLVwq5Zi51pn6hP12VavCE+OlupevV1VE24xmUqJDtARxDxZzK5h/+LO8T Wmr/mSnqB21PI+FGqbzZ1tV3YTnbRCEvjcJllt7FPtyhxYuwB/h999NHKGx29q1SpSw5 v2Yfy8FZN0zB95ofYwRYpk6Vy2SMUwsffFpJWXPAH7WhuY7n8zHXTNEw4H0291o5Xt29 h67Z3Y1OcdJ0zI/aLx6hYc9oo0HQv+vEtakMT1Bl2a47j+NwVoT0n/KP9I88sH7q6/FW 9hw7ki2FHm2OSihR97C09ghZM6AHsmqZolBYq3N5TZcAVtoxBVoEm2QnLOM1RyNjcgvq jkuA== X-Received: by 10.68.246.38 with SMTP id xt6mr32232656pbc.20.1431477761171; Tue, 12 May 2015 17:42:41 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id wt1sm17377326pbc.4.2015.05.12.17.42.37 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 May 2015 17:42:39 -0700 (PDT) Message-ID: <55529DFB.3010704@gmail.com> Date: Tue, 12 May 2015 17:42:35 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> <14447.1431266709@vindemiatrix.encs.concordia.ca> <554FEBB4.5050805@gmail.com> <5550FB6C.7050802@gmail.com> <55518F96.8040708@isdg.net> In-Reply-To: <55518F96.8040708@isdg.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 00:42:43 -0000 On 5/11/15 10:28 PM, Hector Santos wrote: > On 5/11/2015 2:56 PM, Douglas Otis wrote: >> >> On 5/10/15 10:08 PM, Murray S. Kucherawy wrote: >>> On Sun, May 10, 2015 at 4:37 PM, Douglas Otis >>> wrote: >>>> ATPS included an onerous task for any third-party service >>>> likely used on a gratis basis. Each third-party was >>>> expected >>>> to learn specific hash algorithms of each From domain. A >>>> difficult process on top of changing their structure of >>>> DKIM >>>> signatures repeated tens of thousands of times for each >>>> different first party domain. In addition, reputations >>>> based >>>> on the third-party relationship could not be leveraged >>>> because of the optional hashing. >>> I continue to find this repeated claim specious at best. >>> >> Unlike TPA-Label that required NO third-party authentication >> method change, ATPS imposed two significant changes onto >> third-parties: >> >> 1) A need for a new DKIM signature unique for _every_ Author >> domain seen by the mediator. > > It should be off the DMARC record now. Dear Hector, Yes. DMARC uses SMTP outbound registration confirmation to mitigate DKIM failure. Sender header fields indicate the domain responsible for issuing a message when present. DMARC failed to accommodate the Sender header field for those domains handling normal email exchange. Ignoring the Sender header field is appropriate only when just direct or transactional messages are issued by a domain asserting restrictive DMARC policy. In these cases, there would be little chance either DKIM or outbound registration would be negatively affected. DMARC being unable to assert the domain handles normal email exchanges likely to affect both DKIM and SMTP outbound registration makes its resulting policy requests unreliable and incompatible with RFC5322. Restrictive DMARC policy necessitate special handling of third-party services to retain defined roles of From header fields per RFC5322. Rather than assisting other domains mitigate misapplied policy, domains abusing DMARC are causing munged From header fields and misapplied policy having a dangerous outcome of legitimate messages being misplaced into Spam folders. As such, DMARC should signal when specific authorizations can be obtained by using a uniform reference to either a specific or a default domain or that the Sender header field may offer an optional alignment when likely visible to the recipient. >> 2) A need to determine an _unspecified_ hash unique for each >> Author domain seen by the mediator. > Do we really need a hash? I agree. This required new > tools (Hash calculators, wizard, command line tools, DNS > tools, etc) for DNS admin and sysops to be programmed. > Makes it harder to explore. Third-party authorizations should be uniform, small, and hard to explore. Even to the point of publishing a wildcard mitigating the generation of a large number of RRsets as seen with DNS-SD that even expects this type exploring behavior causing a real DDoS concern. >> Both of these unnecessary and difficult impositions do not >> align with those benefiting (the DMARC domain). Many have not realized double signing is wide open to abuse and will need similar DNS publishing techniques to adhere to a broken window theory. http://en.wikipedia.org/wiki/Broken_windows_theory Few things are more reprehensible than using DMARC to abuse legitimate uses of email just to continue ignoring compromised accounts. TPA-Label did not presume DKIM use, but draft-levine-dkim-conditional would allow a simpler TPA-Label listing scheme signaled using DMARC. Ignore all additional constraints in TPA-Label, since a combined strategy should safely handle a wider range of messages. It seems some have had some difficulty understanding the rate of message handling involved by larger ESPs which makes conditional handling fairly difficult to instrument. Here again, TPA-Label helps. Unlike SPF's high overhead of complex chained resource records, draft-levine-dkim-conditional together with TPA-Label would allow simple single resource record listings. Their retraction allows a quick abuse response. Restoration can be just as quick once abusive accounts have been disabled or disinfected. This represents a simple lightweight scheme that should significantly reduce the rate of abuse by keeping the Sending domains fully in the loop and easily instrumented. Regards, Douglas Otis From nobody Tue May 12 18:58:48 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524FE1A8992 for ; Tue, 12 May 2015 18:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.799 X-Spam-Level: * X-Spam-Status: No, score=1.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gec5srATKy-X for ; Tue, 12 May 2015 18:58:46 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 85BB21A88DC for ; Tue, 12 May 2015 18:58:45 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 6F33D1C3878; Wed, 13 May 2015 10:58:43 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 558D81A3398; Wed, 13 May 2015 10:58:43 +0900 (JST) From: "Stephen J. Turnbull" To: Douglas Otis In-Reply-To: <55529DFB.3010704@gmail.com> References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> <14447.1431266709@vindemiatrix.encs.concordia.ca> <554FEBB4.5050805@gmail.com> <5550FB6C.7050802@gmail.com> <55518F96.8040708@isdg.net> <55529DFB.3010704@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 13 May 2015 10:58:43 +0900 Message-ID: <87a8x92q7g.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 01:58:48 -0000 Douglas Otis writes: > DMARC being unable to assert the domain I'm not sure what you mean by "assert the domain". AFAICS no new protocol is needed to validate Sender -- SPF and DKIM allow that already, and it's not obvious to me where the big threat is from a misaligned or spoofed Sender. (A BCP might say that Sender should be aligned with the SPF domain if available, and otherwise with a valid DKIM signer otherwise). I suppose some receivers already use this information in their reputational models. > Many have not realized double signing is wide open to abuse Please present your threat analysis. As far as I can see, double signing is no more vulnerable than the current practice for mailing lists when relaying mail from p=none sites. It would increase the attack surface for the kind of abuse that caused some major sites to publish p=reject last April, but it's something that can be turned on incrementally as a matter of local policy (just as DMARC itself was), and it can be turned off as fast as you can propagate the config change to your SMTP server farm (unlike p=reject itself, which suffers from DNS caching lag). I wouldn't call that "wide open". Steve From nobody Wed May 13 10:05:58 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F062A1B30A0 for ; Wed, 13 May 2015 10:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsZiOYNiAumq for ; Wed, 13 May 2015 10:05:51 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16A7A1B308E for ; Wed, 13 May 2015 10:05:51 -0700 (PDT) Received: by pabtp1 with SMTP id tp1so56483748pab.2 for ; Wed, 13 May 2015 10:05:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=KyjU4HMqL1ePzC9meiJ9juKqmcMxD9xHPz9BbudV2eI=; b=FRnH0yNW34MmpXoYg9tsG+JnSmjyQb9F5acFU7SHj5LHueWVqDD3DBjv99wSgx4DoL QLP43ckEfmvweQDoh7CMAMt/Yxq28qG2b1Y0PXbhOPU62YJIo+7egu8JJ5omcr2J48Qy LoPLJx7iEkGryzFNSfw/fbKY3Q/yCdmOLA0XV0rF3mCw0m7KCgB38Y2dmgklrHhX2UBZ jDYDJ1Eu68mWE8vjlE+ClmBvT7NwUpgDm9nwf/XAAjuX5I34IZJBM/xLZuAjMN/u8DYX +qsFAEetDM43UThnRtkMqNc8A4+1kUqOPGkiVchhozMBUFssGXnrR5kfopniPJ/cSV4P S6nw== X-Received: by 10.68.206.7 with SMTP id lk7mr1404249pbc.52.1431536750660; Wed, 13 May 2015 10:05:50 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id xz3sm19851233pbc.13.2015.05.13.10.05.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 May 2015 10:05:49 -0700 (PDT) Message-ID: <5553846B.2090806@gmail.com> Date: Wed, 13 May 2015 10:05:47 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Stephen J. Turnbull" References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> <14447.1431266709@vindemiatrix.encs.concordia.ca> <554FEBB4.5050805@gmail.com> <5550FB6C.7050802@gmail.com> <55518F96.8040708@isdg.net> <55529DFB.3010704@gmail.com> <87a8x92q7g.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87a8x92q7g.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 17:05:52 -0000 On 5/12/15 6:58 PM, Stephen J. Turnbull wrote: > Douglas Otis writes: > > > DMARC being unable to assert the domain > > I'm not sure what you mean by "assert the domain". AFAICS no new > protocol is needed to validate Sender -- SPF and DKIM allow that > already, and it's not obvious to me where the big threat is from a > misaligned or spoofed Sender. (A BCP might say that Sender should be > aligned with the SPF domain if available, and otherwise with a valid > DKIM signer otherwise). I suppose some receivers already use this > information in their reputational models. > > > Many have not realized double signing is wide open to abuse > > Please present your threat analysis. As far as I can see, double > signing is no more vulnerable than the current practice for mailing > lists when relaying mail from p=none sites. It would increase the > attack surface for the kind of abuse that caused some major sites to > publish p=reject last April, but it's something that can be turned on > incrementally as a matter of local policy (just as DMARC itself was), > and it can be turned off as fast as you can propagate the config > change to your SMTP server farm (unlike p=reject itself, which suffers > from DNS caching lag). > > I wouldn't call that "wide open". > > Steve > > From nobody Wed May 13 14:38:29 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369AF1AD0C9 for ; Wed, 13 May 2015 14:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADz3rAN-CwPp for ; Wed, 13 May 2015 14:38:26 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5A561B2D9D for ; Wed, 13 May 2015 14:38:26 -0700 (PDT) Received: by pdbnk13 with SMTP id nk13so63648716pdb.0 for ; Wed, 13 May 2015 14:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=N/dpuKnzgN+d61MK0q8hii7lF/MHzvSAWmXyvmeIK2A=; b=kH6/3oodkZPpIAedmsyPY3eiBLe2gN67XtYvW9AZo5Y+xHoqHByZI7muaiwK51ctBN +ZoROmGfy0C/AzJB6TO6RsBgHwCBAWVlj9ndBD8tGJ2rrVdxurBssaq/YR/Q4mc71Amh jYVxcl91vjs8yxRdrqXxvlF7T9B7Ih3zsEE84160ev+f9tX5WPdYGRYtc2AJx9AJkIxH mZafI/rtksfA+7gTNe9d2r30Y+rIFRJbcmVc4/xQDmIPnxyuWjrMC5qIksp394p8OV8w dIC2ZIGbIvSMgH18me1ycFrj6BYe+gVHLoeAYi7cTrQxkrk4SiBSbBdGvGnAP1ZlcM2G qsEw== X-Received: by 10.66.159.68 with SMTP id xa4mr1654921pab.105.1431553106408; Wed, 13 May 2015 14:38:26 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id dp4sm17897859pbb.82.2015.05.13.14.38.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 May 2015 14:38:25 -0700 (PDT) Message-ID: <5553C44C.7040307@gmail.com> Date: Wed, 13 May 2015 14:38:20 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Stephen J. Turnbull" References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> <14447.1431266709@vindemiatrix.encs.concordia.ca> <554FEBB4.5050805@gmail.com> <5550FB6C.7050802@gmail.com> <55518F96.8040708@isdg.net> <55529DFB.3010704@gmail.com> <87a8x92q7g.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87a8x92q7g.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 21:38:28 -0000 On 5/12/15 6:58 PM, Stephen J. Turnbull wrote: > Douglas Otis writes: > > > DMARC being unable to assert the domain > > I'm not sure what you mean by "assert the domain". AFAICS no new > protocol is needed to validate Sender -- SPF and DKIM allow that > already, and it's not obvious to me where the big threat is from a > misaligned or spoofed Sender. (A BCP might say that Sender should be > aligned with the SPF domain if available, and otherwise with a valid > DKIM signer otherwise). I suppose some receivers already use this > information in their reputational models. Dear Stephen, Perhaps my intent was obscured by thoughts of what's next. Of course, nothing prevents DKIM/SPF alignment with the Sender header field. Restating: Ignoring the Sender header field is appropriate ONLY when just direct or transactional messages are issued by a domain. Only then are conflicts with RFC5322 avoided when asserting restrictive DMARC policy. Restrictive conflicts are due to the fact that DMARC lacks a means to assert the domain handles NORMAL email exchanges. In effect NORMAL messages will affect both DKIM and SMTP outbound registration alignment fields. Handling NORMAL email exchanges WILL cause policy requests based ONLY on From alignment to be UNRELIABLE and INCOMPATIBLE with RFC5322. Currently ALL DMARC policy assertions ignore the role of the Sender header field. DMARC wrongly assumed the domain would limit its email to only direct or transactional messages. When the Sender and the From header field differ, ONLY the Sender header field can be expected to establish domain alignments with SMTP outbound registration. UNTIL DMARC provides a provision to assert the handling of NORMAL email to permit conditional alignment with the Sender header field, no BCP can offer a solution. Conditional alignment might include the identifier likely being visible in the message or accompanied with an explicit DMARC authorization. A receiver can never reliably resolve a policy conflict caused by NORMAL email exchanges without input from the DMARC domain. Either SMTP needs to redefine roles for Sender and From header fields OR DMARC must include provisions to properly include the role of Sender. > > Many have not realized double signing is wide open to abuse > > Please present your threat analysis. As far as I can see, double > signing is no more vulnerable than the current practice for mailing > lists when relaying mail from p=none sites. It would increase the > attack surface for the kind of abuse that caused some major sites to > publish p=reject last April, but it's something that can be turned on > incrementally as a matter of local policy (just as DMARC itself was), > and it can be turned off as fast as you can propagate the config > change to your SMTP server farm (unlike p=reject itself, which suffers > from DNS caching lag). > > I wouldn't call that "wide open". Even assuming a new scheme might extend DKIM expiry carried within the DKIM signature to an authorized signature, this would be problematic since mailing-lists expect conversations to extend over fairly long periods. Authorized DKIM signatures via double signing sidesteps restrictive DMARC policy where a resulting message can be replayed to any number of recipients well beyond the control of the DMARC domain. This is a general feature of DKIM so no special analysis is necessary. The authorization is wide open since DKIM does not facilitate a means to squelch any resulting phishing campaign. How is double signing better than simply including the Sender header field? Acceptance can also be based on the Sender header field with an expectation greater effort is made to ensure the Sender identity: 1) is included in the message. 2) can be validated. Our practice was to ensure a response to abuse within 15 minutes using 5 minute TTLs. Consider the broken window theory. Being unable to respond in a timely and effective manner makes authorizations wide open. This lack of control will encourage higher levels of abuse. However, use of the Sender header field would ensure the sending entity is held accountable. Regards, Douglas Otis P.S. Sorry about the empty response I think was caused by a trackpad bump. From nobody Wed May 13 21:05:58 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3BC1B330C for ; Wed, 13 May 2015 21:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.899 X-Spam-Level: *** X-Spam-Status: No, score=3.899 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GijXGi9YYDwi for ; Wed, 13 May 2015 21:05:54 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 158AB1B330F for ; Wed, 13 May 2015 21:05:53 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 0CD271C38A2; Thu, 14 May 2015 13:05:52 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id E02DB1A3398; Thu, 14 May 2015 13:05:51 +0900 (JST) From: "Stephen J. Turnbull" To: Douglas Otis In-Reply-To: <5553C44C.7040307@gmail.com> References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> <14447.1431266709@vindemiatrix.encs.concordia.ca> <554FEBB4.5050805@gmail.com> <5550FB6C.7050802@gmail.com> <55518F96.8040708@isdg.net> <55529DFB.3010704@gmail.com> <87a8x92q7g.fsf@uwakimon.sk.tsukuba.ac.jp> <5553C44C.7040307@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 14 May 2015 13:05:51 +0900 Message-ID: <87vbfv2480.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 04:05:57 -0000 Douglas Otis writes: > Dear Stephen, > > Perhaps my intent was obscured by thoughts of what's next. > Of course, nothing prevents DKIM/SPF alignment with the > Sender header field. Restating: If it's signed by upstream and altered as RFC 5322 suggests it should be for mail which is received and reinjected, it will break the original signature if Sender was signed upstream. So what you're proposing, AFAICS, is already available and widely practiced: Mediators resign, and receiver ignore the broken upstream signature if the Mediator has a good reputation. Too bad for "policy", but the only people who actually *want* policy are the banks. Yahoo! and AOL at least have made it quite plain that they're happy to see mailing lists and other third parties working around p=reject. The only addition that TPA etc provides from the point of view of the user is a protocol for consulting the Author Domain for information about Mediators, but experience shows that Author Domains are not interested in providing such information. For example, when MLM admins ask them why mail isn't getting to subscribers, they refuse to answer in any specifics. They simply point to their AUP and third party acceptance policies, if any. Some domains even try to hide policy rejections completely by using a generic "permanent failure" status code. > Ignoring the Sender header field is appropriate ONLY when > just direct or transactional messages are issued by a > domain. If Dave Crocker had his way, we'd ignore From, too (I'm exaggerating here a bit). I can't agree with that extreme position (which I believe Dave doesn't actually espouse): even if we have no published proof that phishing via contact lists is substantially more effective than use of sibling domains etc, the theoretical risk is too clear to ignore. In any case we do have public proof that spammers think it works, and graphs that show that DMARC p=reject can prevent spikes as high as 6-10 times the background level of spam. > Only then are conflicts with RFC5322 avoided when asserting > restrictive DMARC policy. Restrictive conflicts are due to the > fact that DMARC lacks a means to assert the domain handles NORMAL > email exchanges. That's right, and AFAICS it's very difficult to improve the protocol because no Author Domain would want to grant carte blanche to 3rd party *domains*, unless it's known that they run as tight a ship as the Author Domain itself does. By "tight ship" I mean something like a domain that effectively represent a single trusted user with a relationship to the Author Domain. But the domains that are abusing p=reject have relationships with millions of domains, few of which are single-user and very few of which are trusted not to abuse "on behalf of" signing privileges. The mailing lists I care about don't qualify. Many of the innovative 3rd-party services (greeting cards, send-an-interesting-article, etc) are not going to qualify either, especially the startups. Many of these services look an awful lot like spam, too, even though recipients will tell you that they aren't. > In effect NORMAL messages will affect both DKIM and SMTP outbound > registration alignment fields. Handling NORMAL email exchanges > WILL cause policy requests based ONLY on From alignment to be > UNRELIABLE and INCOMPATIBLE with RFC5322. Yes, we know that. It was predicted well in advance of the empirical proof, as people involved in the early development of DMARC came to Mailman at least a year before the April Debacle with patches designed to break RFC 5322 conformance on behalf of posters at p=reject domains. > Currently ALL DMARC policy assertions ignore the role of the > Sender header field. Which seems theoretically correct to me, as (unlike From) Sender is not arguably a field reserved to Author Domains. Of course a Mediator can make an assertion about Sender by DKIM signing it, but it seems rather unlikely to me that Author Domains would want to make assertions about Sender along the lines of "if Sender is signed, consider the message to be authentic". At this point, of course you and Hector will bring up TPA and POLICY and claim it would be cheap and effective. But as a mailing list advocate with extensive experience of trying to get on the registries of the p=reject domains, of just trying to get information about why my mailing list seems to be banned, or even just getting confirmation that it *is* banned, TPA/POLICY strikes me as miscalculated chemotherapy -- you kill the patient before the cancer. > DMARC wrongly assumed the domain would limit its email to only > direct or transactional messages. When the Sender and the From > header field differ, ONLY the Sender header field can be expected > to establish domain alignments with SMTP outbound registration. That assumes that anybody actually wants to establish domain alignments, other than their own. I don't think that they do. I think they really want something much more flexible than that, able to assert that individual senders have their trust. If they really want to assert trust in anybody else at all. I see no convincing evidence that the p=reject domains would want to participate in these protocols, except to make arrangements with commercial partners (think Intuit's invoicing service) more standard and perhaps less costly. Mailing lists, they'd love to help us as long as it costs nothing to them. > Conditional alignment might include the identifier likely > being visible in the message or accompanied with an explicit > DMARC authorization. A receiver can never reliably resolve > a policy conflict caused by NORMAL email exchanges without > input from the DMARC domain. Of course they can. If Google Groups includes an A-R that shows that a message from a Yahoo! user was From-aligned, and signs that as well as the rest of the message, I'm sure that Gmail at least will consider that a reliable resolution, and ignore the lack of From alignment of the message as distributed by Groups. I would myself (if I ever subscribed to a Google Group :-). Thus we already have a mechanism by which Receivers can make their own decisions based on their own chains of trust, but DMARC purports to take that decision out of their hands. It fails to do so, of course, and IMHO that failure is a good thing. > Either SMTP needs to redefine roles for Sender and From header > fields OR DMARC must include provisions to properly include the > role of Sender. I disagree. AFAICS the Sender field has no interesting role here. The From field is singled out entirely because of its potential role in phishing attacks and recommender spam, that is, because of its role in identifying authors to end users. What matters to authentication of the sender is simply the security of IP addresses (in the case of SPF) and the security of signatures and the DNS (for both SPF and DKIM). By the nature of the protocols using the DNS, they also serve to identify the sending domain. > > > Many have not realized double signing is wide open to abuse > > > > Please present your threat analysis. > Even assuming a new scheme might extend DKIM expiry carried > within the DKIM signature to an authorized signature, this > would be problematic since mailing-lists expect > conversations to extend over fairly long periods. That's irrelevant. The whole point of the double-signing schemes is that they are per-message. The relevant period of conversation is the chain of SMTP transactions and Mediation from the boundary MX of the Author Domain to the boundary MX of the subscriber's domain. > Authorized DKIM signatures via double signing sidesteps > restrictive DMARC policy It's not a sidestep. It's a deliberate modification of the policy, applied to a single message. > where a resulting message can be replayed to any number of > recipients well beyond the control of the DMARC domain. This is a > general feature of DKIM so no special analysis is necessary. The > authorization is wide open since DKIM does not facilitate a means > to squelch any resulting phishing campaign. The time limit on delegation automatically squelches the phishing campaign within a few minutes, and once the decision to shut off delegation is taken, it would be effective in seconds, I suppose. I do not intend to downplay the bad consequences were such a campaign to actually occur, simply to point out that unlike the use of p=reject which requires action on the part of the Author Domain's administrator to squelch a malmail campaign (and requires some minutes to do so), the squelching that occurs with the delegation proposals is an inherent part of the protocol. Of course a new opportunity arises with each message sent by the duped author, but even here those messages can be shut down instantly (ie, delegation signatures are not added to any outgoing messages) at the administrator's decision. Messages already in the pipeline will continue to provide an attack vector, but they expire as quickly (or perhaps more so) than the TTL on DNS records. > How is double signing better than simply including the Sender > header field? Author Domains can make assertions about specific Mediators on a per message basis. While delegation may be too costly in practice to attract use, it's designed that way. This is better than any protocol based on Sender and a registry, because registry upkeep is clearly prohibitively costly when making per message distinctions or differentiating between different Mediators sharing a domain. > Acceptance can also be based on the Sender header field with an > expectation greater effort is made to ensure the Sender identity: > > 1) is included in the message. > 2) can be validated. (1) is already done because the sender's signature identifies it. (2) is extremely controversial because it requires solving the registration problem. I don't think it can be done in real time, and mailing lists already have enough problems getting the big providers to recognize their existence as anything except undesirable bulk mailers. > Our practice was to ensure a response to abuse within 15 minutes > using 5 minute TTLs. Consider the broken window theory. Being > unable to respond in a timely and effective manner "Unable"? I don't think you understand the proposed protocol. > makes authorizations wide open. This lack of control will > encourage higher levels of abuse. However, use of the Sender > header field would ensure the sending entity is held accountable. That's wishful thinking. Senders are already held accountable by RBLs and the like. The problem is that spammers have as many new senders as they need, while Mediators tend to have fixed identities, so that while such "accountability" raises costs for spammers, it kills mailing lists (or at the very least puts them on the disabled list until reputation can be repaired). From nobody Wed May 13 22:42:58 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7AF1B3388 for ; Wed, 13 May 2015 22:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTVa2SNScYSl for ; Wed, 13 May 2015 22:42:54 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A9A41B3387 for ; Wed, 13 May 2015 22:42:54 -0700 (PDT) Received: by wguv19 with SMTP id v19so1440432wgu.1 for ; Wed, 13 May 2015 22:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=syIsqfdTW5YW2eTQLHeRXdWx/kjsDjHJ99YIfFlphYk=; b=cOiF4yQkupCOAksDj72C7Ptwpt+40//QLSbBlj99gjKLKZTwkYtGCeZ5xDv50Wfilc 0nGIg2z2q9cjFcNjT7nfOYcYzgfmKtOPv8UGbPHuP+shmd4w/FNFpY3epbMk2PmlF38X oOKMkdK3HXl+Ijs4dpFojEYqX4BQQ+oNoOZmshUtaR00j/KB0gnfqOU4Qt6U5rSvyru+ 2ScRxQGHe+OUsk2sl3sD0Zb6fO3O31COeJGSLxwo17dkwLMf8Wsi+n8jSsl4QvQPgbve OWZ5LYgI9hSf9Wmv9QP1Ewh51fbs4W/GDwp+TxUDLm970qqWjSeJwqkJquLjmUrxl3Xz N+pw== MIME-Version: 1.0 X-Received: by 10.180.106.73 with SMTP id gs9mr21163155wib.52.1431582172977; Wed, 13 May 2015 22:42:52 -0700 (PDT) Received: by 10.27.170.134 with HTTP; Wed, 13 May 2015 22:42:52 -0700 (PDT) In-Reply-To: <87vbfv2480.fsf@uwakimon.sk.tsukuba.ac.jp> References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> <14447.1431266709@vindemiatrix.encs.concordia.ca> <554FEBB4.5050805@gmail.com> <5550FB6C.7050802@gmail.com> <55518F96.8040708@isdg.net> <55529DFB.3010704@gmail.com> <87a8x92q7g.fsf@uwakimon.sk.tsukuba.ac.jp> <5553C44C.7040307@gmail.com> <87vbfv2480.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Wed, 13 May 2015 22:42:52 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=f46d04428fcee31e62051604321f Archived-At: Cc: "dmarc@ietf.org" , Douglas Otis Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 05:42:56 -0000 --f46d04428fcee31e62051604321f Content-Type: text/plain; charset=UTF-8 On Wed, May 13, 2015 at 9:05 PM, Stephen J. Turnbull wrote: > > Currently ALL DMARC policy assertions ignore the role of the > > Sender header field. > > Which seems theoretically correct to me, as (unlike From) Sender is > not arguably a field reserved to Author Domains. Of course a Mediator > can make an assertion about Sender by DKIM signing it, but it seems > rather unlikely to me that Author Domains would want to make > assertions about Sender along the lines of "if Sender is signed, > consider the message to be authentic". > +1 here, and to pretty much all of this message. Moreover, current use of Sender by both producing agents and consuming agents is inconsistent. Suddenly relying upon it in addition to or instead of From for much of anything creates the need for a lot of people to change how they do things, and that seems unlikely in anything but a long time frame. So, too, is it unlikely that anything registering a No-Really-THIS-Is-The-Really-Real-Sender header field will gain widespread adoption. What gets added from here forward really needs to be as innocuous as possible. I believe we're in a position where things like SPF and DKIM are still young enough that their implementations are malleable, but trying to get every MLM, MTA, MUA, and MSA out there to suddenly use Sender universally and in a common way seems far less likely to be successful. -MSK --f46d04428fcee31e62051604321f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, May 13, 2015 at 9:05 PM, Stephen J. Turnbull <st= ephen@xemacs.org> wrote:
=C2=A0= > Currently ALL DMARC policy assertions ignore the role of the
=C2=A0> Sender header field.

Which seems theoretically correct to me, as (unlike From) Sender is<= br> not arguably a field reserved to Author Domains.=C2=A0 Of course a Mediator=
can make an assertion about Sender by DKIM signing it, but it seems
rather unlikely to me that Author Domains would want to make
assertions about Sender along the lines of "if Sender is signed,
consider the message to be authentic".

=
+1 here, and to pretty much all of this message.

Moreover, current use of Sender by both producing agents and consum= ing agents is inconsistent.=C2=A0 Suddenly relying upon it in addition to o= r instead of From for much of anything creates the need for a lot of people= to change how they do things, and that seems unlikely in anything but a lo= ng time frame.

So, too, is it unlikely that anything registering a N= o-Really-THIS-Is-The-Really-Real-Sender header field will gain widespread a= doption.

What gets added from here forward really needs t= o be as innocuous as possible.=C2=A0 I believe we're in a position wher= e things like SPF and DKIM are still young enough that their implementation= s are malleable, but trying to get every MLM, MTA, MUA, and MSA out there t= o suddenly use Sender universally and in a common way seems far less likely= to be successful.

-MSK
--f46d04428fcee31e62051604321f-- From nobody Thu May 14 00:51:52 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD32C1B34E4 for ; Thu, 14 May 2015 00:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.899 X-Spam-Level: *** X-Spam-Status: No, score=3.899 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JB-70kD9S53B for ; Thu, 14 May 2015 00:51:45 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id B726C1B34E5 for ; Thu, 14 May 2015 00:51:45 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 4AFE01C393B; Thu, 14 May 2015 16:51:44 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 319391A3398; Thu, 14 May 2015 16:51:44 +0900 (JST) From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> <14447.1431266709@vindemiatrix.encs.concordia.ca> <554FEBB4.5050805@gmail.com> <5550FB6C.7050802@gmail.com> <55518F96.8040708@isdg.net> <55529DFB.3010704@gmail.com> <87a8x92q7g.fsf@uwakimon.sk.tsukuba.ac.jp> <5553C44C.7040307@gmail.com> <87vbfv2480.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 14 May 2015 16:51:44 +0900 Message-ID: <87mw171trj.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" , Douglas Otis Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 07:51:48 -0000 Murray S. Kucherawy writes: > What gets added from here forward really needs to be as innocuous > as possible. I believe we're in a position where things like SPF > and DKIM are still young enough that their implementations are > malleable, I'm not sure what you mean. Now that I actually know what those protocols do (and DMARC itself, for that matter), I don't really see how they can be much improved. Do you mean the policy engines that make decisions based on the output of SPF and DKIM implementations? Going way out on a limb here, it's not even clear to me that getting the simple delegation protocols[1] implemented would be of that much incremental benefit to mailing lists and other forwarding Mediators given that everybody and their brother seems to be taking a Monty- Pythonic "wink, wink, nudge, nudge, say no more, eh?!" approach to p=reject as receivers. What would be ideal from my point of view (as a mailing list advocate, though I don't claim to represent all MLM developers in this) would be (1) The DMARC standard itself to achnowledge that "p=reject" really means "we are very worried about the security implications of our domain in the From field" (with different spin depending on whether you're a bank or a large mailbox provider that has leaked a lot of personal information to spammers, but basically the same semantics for the mail system), and therefore Receiving systems SHOULD treat a message that fails the From alignment test with great care, including such measures as quarantining the message in a special folder, deactivating links and attachments in the displayed message, or displaying a warning message that the message is likely to be inauthentic. Receiving systems MAY reject such messages outright. Receiving systems MAY treat as authentic a message that would otherwise be quarantined or rejected under this protocol in the presence of strong evidence of authenticity such as a valid signature of important header fields and body by a well-trusted Mediator (see Security Considerations for discussion). I think this has almost no chance of actually happening, but it's what I'd consider ideal. (2) Some kind of Authentication-Results protocol, which would be one of the "important header fields" mentioned in point (1). There would need to be provision for multiple fields of this type, so it would need to include the identity of the authenticating agent. It occurs to me that this field might need a weak signature of its own to establish authenticity in the presence of a chain of Mediators. This doesn't depend on (1) to be useful in the de facto presence of people acting as in (1). (3) I would really like to see some provision for reporting to mailbox users when their mail is being discarded due to publication of p=reject by their mailbox providers, especially in cases where a Mediator is willing to put its reputation on the line by signing the forwarded message. Note that this would only be a burden to abusers of p=reject, as in the case of transactional mail the responsible author is the corporate entity, not the employee. So no further report would be appropriate in that case, as the organization is already receiving the DMARC reports. > but trying to get every MLM, MTA, MUA, and MSA out there to > suddenly use Sender universally and in a common way seems far less > likely to be successful. We can't even get the (displayed) From used in a common way, viz the "From on behalf of " usage. Technically, I understand the point they're making, but real people think of on-behalf-of as the kind of thing lawyers do: "Dear Miscreant: I am writing on behalf of Mr. Offended Easley as his attorney. Cease and desist. Sincerely, Beagle Leagle, JD" (and of course the actual RFC 5322 Sender is Ms. Para Leagle). Some real people do find that confusing. Footnotes: [1] I'm of two minds regarding your (Murray's) more complex part-by- part signing scheme. On the one hand, it's way cool, and should be implemented for that reason alone. On the other, it looks expensive and fragile and I suspect it won't get a lot of uptake for that reason. From nobody Thu May 14 04:54:10 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6BB21A8854 for ; Thu, 14 May 2015 04:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHbumWlZOvRh for ; Thu, 14 May 2015 04:54:06 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5E8B1A884B for ; Thu, 14 May 2015 04:54:05 -0700 (PDT) Received: by wicnf17 with SMTP id nf17so91200137wic.1 for ; Thu, 14 May 2015 04:54:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cgL05gyAMllTkZwZRiHppJeqHbjhmM8TaezQNIdXFN4=; b=RsDpl5z6hZ/riP7DKbEjXf8ct+L0ENwr/s1gdkSoiHuNzEM5e5DzyEkYYTDxSNBybC xjNNWPZ5haAYmNdbimqogy7PdMwMvlfIZ9Pw1E4CdDjXYXqrgpkBZruHcnU9tmC6c3ti qxYihdj83XHSvNFmTy0sL0H5djFoxUEN7p5+tA3pNl5nHcElAddcHi0dRbg+9DvHO675 gMM4s79ZRPcMOCWHT9edliR+ehVSwp1AZutyW8nlg59R6STG1GjfwaHoTwon5PrqyU+2 YbYcjVvHx+jdB2pCUQ+GqkMaudbKczEoPkVOqbbYRPYwJEuk8G1tDIMh8Cdy1LeWi+Bp Ch+w== MIME-Version: 1.0 X-Received: by 10.180.99.2 with SMTP id em2mr48316079wib.59.1431604444567; Thu, 14 May 2015 04:54:04 -0700 (PDT) Received: by 10.27.170.134 with HTTP; Thu, 14 May 2015 04:54:04 -0700 (PDT) In-Reply-To: <87mw171trj.fsf@uwakimon.sk.tsukuba.ac.jp> References: <554BC30F.1020107@isdg.net> <4087F3E9-540E-45C7-9AE1-2B71FC90CB5F@kitterman.com> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> <14447.1431266709@vindemiatrix.encs.concordia.ca> <554FEBB4.5050805@gmail.com> <5550FB6C.7050802@gmail.com> <55518F96.8040708@isdg.net> <55529DFB.3010704@gmail.com> <87a8x92q7g.fsf@uwakimon.sk.tsukuba.ac.jp> <5553C44C.7040307@gmail.com> <87vbfv2480.fsf@uwakimon.sk.tsukuba.ac.jp> <87mw171trj.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Thu, 14 May 2015 04:54:04 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=f46d04426c6860a0f105160962ef Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 11:54:09 -0000 --f46d04426c6860a0f105160962ef Content-Type: text/plain; charset=UTF-8 On Thu, May 14, 2015 at 12:51 AM, Stephen J. Turnbull wrote: > > What gets added from here forward really needs to be as innocuous > > as possible. I believe we're in a position where things like SPF > > and DKIM are still young enough that their implementations are > > malleable, > > I'm not sure what you mean. Now that I actually know what those > protocols do (and DMARC itself, for that matter), I don't really see > how they can be much improved. Do you mean the policy engines that > make decisions based on the output of SPF and DKIM implementations? > I'm saying that incremental changes to DKIM, SPF, and DMARC are far more likely to succeed than anything along the lines of "Everyone start using and paying attention to Sender", "Let's register yet another Sender-type field", or "Registration scheme X". The operational changes required for those three families of solutions are too enormous and involve too many wildcards for me to believe they stand a chance of success. -MSK --f46d04426c6860a0f105160962ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, May 14, 2015 at 12:51 AM, Stephen J. Turnbull <s= tephen@xemacs.org> wrote:
=C2= =A0> What gets added from here forward really needs to be as innocuous =C2=A0> as possible.=C2=A0 I believe we're in a position where thing= s like SPF
=C2=A0> and DKIM are still young enough that their implementations are =C2=A0> malleable,

I'm not sure what you mean.=C2=A0 Now that I actually know what = those
protocols do (and DMARC itself, for that matter), I don't really see how they can be much improved.=C2=A0 Do you mean the policy engines that make decisions based on the output of SPF and DKIM implementations?

I'm saying that incremental changes to DKI= M, SPF, and DMARC are far more likely to succeed than anything along the li= nes of "Everyone start using and paying attention to Sender", &qu= ot;Let's register yet another Sender-type field", or "Registr= ation scheme X".=C2=A0 The operational changes required for those thre= e families of solutions are too enormous and involve too many wildcards for= me to believe they stand a chance of success.

-MSK
<= /div>
--f46d04426c6860a0f105160962ef-- From nobody Thu May 14 16:06:57 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3601A9140 for ; Thu, 14 May 2015 16:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gr2kAX6Qkasu for ; Thu, 14 May 2015 16:06:53 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4583F1A1A32 for ; Thu, 14 May 2015 16:06:53 -0700 (PDT) Received: by pdbqb6 with SMTP id qb6so2148107pdb.0 for ; Thu, 14 May 2015 16:06:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=OlJVyehiWJDwUzwisNhitFMLnaSaejJR0pPk3mgcBuI=; b=MivoEwFvZZYx30bfIdmU519GUwM/Uf6DvTUVHxBVp1xZ+1EkPpN7E2l1WRmobU2dfy tnilFw3H4fL4H1tyEIaRsAzaWZO6ja+1L2OaW9EuGYpw+t1uLgul6Dd24m6FuOWjh2sM x+vVI3vMkKssHyHeNcpK+GXR+75eGntjLqE4QstIl1p06gngeFSsjAtE+X319KqDXSgd QQdp3GEKMRPprY/ulu0k2N/Uuif+Euc6P8EGcCeJVEog5CMja/4r1HJjcFanpYCbd9rj je/Y7peCXFkUFuvNIT8dZpyeDuUAlRYoIGQEAy0mxWNTcx+DUNqPzNA0Q/keBIAeh1/f ZKSQ== X-Received: by 10.66.221.193 with SMTP id qg1mr12182136pac.134.1431644785799; Thu, 14 May 2015 16:06:25 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id eo3sm225194pbd.66.2015.05.14.16.06.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 May 2015 16:06:24 -0700 (PDT) Message-ID: <55552A6C.5060101@gmail.com> Date: Thu, 14 May 2015 16:06:20 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554BC30F.1020107@isdg.net> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> <14447.1431266709@vindemiatrix.encs.concordia.ca> <554FEBB4.5050805@gmail.com> <5550FB6C.7050802@gmail.com> <55518F96.8040708@isdg.net> <55529DFB.3010704@gmail.com> <87a8x92q7g.fsf@uwakimon.sk.tsukuba.ac.jp> <5553C44C.7040307@gmail.com> <87vbfv2480.fsf@uwakimon.sk.tsukuba.ac.jp> <87mw171trj.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] Simple authorization offers reasonable control over messaging resources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 23:06:56 -0000 On 5/14/15 4:54 AM, Murray S. Kucherawy wrote: > On Thu, May 14, 2015 at 12:51 AM, Stephen J. Turnbull > wrote: > >> > What gets added from here forward really needs to be as innocuous >> > as possible. I believe we're in a position where things like SPF >> > and DKIM are still young enough that their implementations are >> > malleable, >> >> I'm not sure what you mean. Now that I actually know what those >> protocols do (and DMARC itself, for that matter), I don't really see >> how they can be much improved. Do you mean the policy engines that >> make decisions based on the output of SPF and DKIM implementations? >> > I'm saying that incremental changes to DKIM, SPF, and DMARC are far more > likely to succeed than anything along the lines of "Everyone start using > and paying attention to Sender", "Let's register yet another Sender-type > field", or "Registration scheme X". The operational changes required for > those three families of solutions are too enormous and involve too many > wildcards for me to believe they stand a chance of success. Dear Murray, The Sender header field when present has been defined for decades to represent the sending agent! DMARC improved delivery registration accuracy for TRANSACTIONAL messages based on the SMTP MailFrom parameter (bounce address) or DKIM (unrelated to any field) where either is allowed to fail. For TRANSACTIONAL email, combining these two marginal authorization schemes easily adjusted to relate with the From header field offered a low percentage authorization failure to better ensure compliance with a restrictive policy. The expediency this allowed did not justify disrupting valid and legitimate exchanges not limited to transactional or direct messaging configurations. Neither DKIM nor SPF authenticate an actual message source, but simple authorization offers reasonable control over messaging resources. DMARC is fine when messages are limited to direct exchange, but fail badly when exchanges make use of the Sender header field that may signify use of mediators or other resources. At one time DMARC even recommended against issuing non-transactional messages, but acknowledgement of DMARC's potential disruption of normal email interchange was dropped. Commercially available products for years have been able to clearly indicate the entity trusted at providing a message. It seems DMARC assumes recipients are too easily misled and can't be trusted to deal with S/MIME, OpenPGP, or MUAs that verify and display the Sender header field and think everyone is better able to deal with munged From header fields. The TPA-Label is able to thwart wildcards simply by publishing a negative wildcarded label. A practice that won't work with DNS-SD. A sender must have reasonable control over the resources they authorize. Any double signing scheme relaying authorization to a third-party via DKIM can not control the authorized resources since the entire message body may change and DKIM can be replayed to any destination by design. Without adequate control, authorization protections fail simply because neither SPF or DKIM are able to authenticate the source, nor can DKIM offer an expedient authorization retraction in say a 5 to 15 minute range. While I commend efforts made at fleshing out your version of the ATPS protocol, due to the inherent hurdles introduced for third-parties it was unlikely this scheme would be adopted. The lesson is DKIM offers a poor method to signal changes beyond those already expected. There was no reason to change how a third-party is verified since they too can use DKIM and SPF or even DANE or the HELO parameter for that matter. The correct place to signal such change is at the DMARC assertion. See Third-Party Authorization example of: "sam=tpa; and tpa=third-party-authority.example.com;" https://tools.ietf.org/html/draft-otis-dmarc-escape-02#section-4 This scheme involves a simple DNS server operating an isolated zone separated from other domain services and can even be published by a different domain. This approach allows the _tpa zone to be maintained as a community effort or as a specialty service to ensure the sender has reasonable and nearly immediate control over the resources they authorize. By being able to include policy for the Sender header field, DMARC can become compatible with RFC5322. While some might describe this a complex authorization scheme, it can be combined with draft-levine-dkim-conditional to offer a resource record where only the base portion of the domain might be included to guard against domain hash collisions. TPA-Label that had the goal of reducing collateral damage caused by compromised accounts or resources, can be combined with draft-levine-dkim-conditional to signal when this limited signature should be included and which domain needs to be authorized. Because this uses very simple resource records, is should scale far better than SPF and yet permit a means to establish an informal federation scheme to better protect email infrastructure with low latency abuse responses. TPA-Label does not make handling third-party messages harder. Instead, TPA-Label offers a simple way to signal which domains require exceptional handling. Without such a feature, DMARC can not be seen as being compatible with RFC5322. Again, we will happily help any large ESP configure and maintain their services to make use of this scheme and even offer the needed resources. Regards, Douglas Otis From nobody Thu May 14 23:27:14 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD851ACE6C for ; Thu, 14 May 2015 23:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkMpmSlWfy-U for ; Thu, 14 May 2015 23:27:09 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43CC01ACE63 for ; Thu, 14 May 2015 23:27:09 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB604.namsdf01.sdf.exchangelabs.com (10.255.109.166) with Microsoft SMTP Server (TLS) id 15.1.172.7; Fri, 15 May 2015 06:27:06 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.5.234]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.5.234]) with mapi id 15.01.0172.012; Fri, 15 May 2015 06:27:06 +0000 From: Terry Zink To: Douglas Otis , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Simple authorization offers reasonable control over messaging resources Thread-Index: AQHQjpqwTsF5j4YCp0ahJkVLZQMWO518kDbA Date: Fri, 15 May 2015 06:27:05 +0000 Message-ID: References: <554BC30F.1020107@isdg.net> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> <14447.1431266709@vindemiatrix.encs.concordia.ca> <554FEBB4.5050805@gmail.com> <5550FB6C.7050802@gmail.com> <55518F96.8040708@isdg.net> <55529DFB.3010704@gmail.com> <87a8x92q7g.fsf@uwakimon.sk.tsukuba.ac.jp> <5553C44C.7040307@gmail.com> <87vbfv2480.fsf@uwakimon.sk.tsukuba.ac.jp> <87mw171trj.fsf@uwakimon.sk.tsukuba.ac.jp> <55552A6C.5060101@gmail.com> In-Reply-To: <55552A6C.5060101@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.165.40.56] x-microsoft-exchange-diagnostics: 1; BL2SR01MB604; 3:6OGFkxe3DSugf2cl/RBHI4dSMUKZB0VTAqs8rBz4uC9kIFrwkpB7y1J5R6QGWK2qHPKTayDicozU03voroMt90CRb8kcPV88UTLfqrtVBoKLFRgYi22nFMOacnxkwCa4CCaoaNjPW8NumJpU3sJktg==; 10:kOhLMA+jRRqyxlvuLl1IGSC2ZqFm91N3k8U4qOxaGXSNTzB6E0kog1YYSpzaZVlCofmKbjonsSgOWuxhAY08WmFu0my3vCPFjM0zAwc6eF8=; 6:UTCVv63xSJoIpbLjrkrS8gDfF0L1h/YUd2NgRQ+Qe0HYXrupOUPtxkNkM2gWkVk4 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB604; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(24454002)(13464003)(189002)(199003)(479174004)(2950100001)(105586002)(97736004)(5001860100001)(106116001)(106356001)(54356999)(76176999)(50986999)(5001770100001)(5001830100001)(5001960100002)(107886002)(2900100001)(19580405001)(19580395003)(86362001)(15975445007)(68736005)(102836002)(4001540100001)(81156007)(92566002)(87936001)(2501003)(2656002)(101416001)(64706001)(66066001)(93886004)(77156002)(62966003)(33656002)(46102003)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB604; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005002)(5002009)(3002001); SRVR:BL2SR01MB604; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB604; x-forefront-prvs: 0577AD41D6 received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2015 06:27:05.7225 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB604 Archived-At: Subject: Re: [dmarc-ietf] Simple authorization offers reasonable control over messaging resources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 06:27:12 -0000 > The Sender header field when present has been defined for > decades to represent the sending agent! Maybe, maybe not. Outlook desktop client shows the Sender: header as " on behalf of <5322.from>", but neither Hotmail/outlook.com nor Gmail do= . They just show the 5322.From address regardless of whether or not there i= s a Sender: header. This Sender: DMARC fix requires a change in the way the= se clients render email. Given the marginal additional benefit to receivin= g mailing list traffic that won't implement any of the published workaround= s (not modifying content, fiddling around with Reply-To and From addresses,= changing the From: domain to be the mailing list domain), I can't see why = Gmail or Hotmail would want to make a change like that. I agree with Murray= that it isn't worth pursuing, the cost/benefit ratio isn't there. > Again, we will happily help any large ESP configure and > maintain their services to make use of this scheme and even > offer the needed resources. Doug, who is this "we" you keep referring to who will happily maintain some= one else's DNS zone? Your employer? Are you volunteering them on their beha= lf? Is this a free service of theirs? If not, why would anyone agree to a s= olution that is hard to manage at scale but, lucky for you, just so happens= to benefit your employer? The TPA authorization DNS zone publishing has been pushed by yourself and a= nother board participant and has received universally negative feedback, or= at best neutral feedback. The people here are smart and have as much exper= ience as anyone else and they understand what you are saying. But they stil= l don't agree, including me. I think it's time to make like the movie Froze= n and let it go. -- Terry -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Douglas Otis Sent: Thursday, May 14, 2015 4:06 PM To: dmarc@ietf.org Subject: [dmarc-ietf] Simple authorization offers reasonable control over m= essaging resources On 5/14/15 4:54 AM, Murray S. Kucherawy wrote: > On Thu, May 14, 2015 at 12:51 AM, Stephen J. Turnbull > wrote: > >> > What gets added from here forward really needs to be as innocuous >> > as possible. I believe we're in a position where things like SPF >> > and DKIM are still young enough that their implementations are >> > malleable, >> >> I'm not sure what you mean. Now that I actually know what those >> protocols do (and DMARC itself, for that matter), I don't really see >> how they can be much improved. Do you mean the policy engines that >> make decisions based on the output of SPF and DKIM implementations? >> > I'm saying that incremental changes to DKIM, SPF, and DMARC are far more > likely to succeed than anything along the lines of "Everyone start using > and paying attention to Sender", "Let's register yet another Sender-type > field", or "Registration scheme X". The operational changes required for > those three families of solutions are too enormous and involve too many > wildcards for me to believe they stand a chance of success. Dear Murray, The Sender header field when present has been defined for decades to represent the sending agent! DMARC improved delivery registration accuracy for TRANSACTIONAL messages based on the SMTP MailFrom parameter (bounce address) or DKIM (unrelated to any field) where either is allowed to fail. For TRANSACTIONAL email, combining these two marginal authorization schemes easily adjusted to relate with the From header field offered a low percentage authorization failure to better ensure compliance with a restrictive policy. The expediency this allowed did not justify disrupting valid and legitimate exchanges not limited to transactional or direct messaging configurations. Neither DKIM nor SPF authenticate an actual message source, but simple authorization offers reasonable control over messaging resources. DMARC is fine when messages are limited to direct exchange, but fail badly when exchanges make use of the Sender header field that may signify use of mediators or other resources. At one time DMARC even recommended against issuing non-transactional messages, but acknowledgement of DMARC's potential disruption of normal email interchange was dropped. Commercially available products for years have been able to clearly indicate the entity trusted at providing a message.=20 It seems DMARC assumes recipients are too easily misled and can't be trusted to deal with S/MIME, OpenPGP, or MUAs that verify and display the Sender header field and think everyone is better able to deal with munged From header fields. The TPA-Label is able to thwart wildcards simply by publishing a negative wildcarded label. A practice that won't work with DNS-SD. A sender must have reasonable control over the resources they authorize. Any double signing scheme relaying authorization to a third-party via DKIM can not control the authorized resources since the entire message body may change and DKIM can be replayed to any destination by design. Without adequate control, authorization protections fail simply because neither SPF or DKIM are able to authenticate the source, nor can DKIM offer an expedient authorization retraction in say a 5 to 15 minute range. While I commend efforts made at fleshing out your version of the ATPS protocol, due to the inherent hurdles introduced for third-parties it was unlikely this scheme would be adopted. The lesson is DKIM offers a poor method to signal changes beyond those already expected. There was no reason to change how a third-party is verified since they too can use DKIM and SPF or even DANE or the HELO parameter for that matter. The correct place to signal such change is at the DMARC assertion. See Third-Party Authorization example of: "sam=3Dtpa; and tpa=3Dthird-party-authority.example.com;" https://tools.ietf.org/html/draft-otis-dmarc-escape-02#section-4 This scheme involves a simple DNS server operating an isolated zone separated from other domain services and can even be published by a different domain. This approach allows the _tpa zone to be maintained as a community effort or as a specialty service to ensure the sender has reasonable and nearly immediate control over the resources they authorize. By being able to include policy for the Sender header field, DMARC can become compatible with RFC5322. While some might describe this a complex authorization scheme, it can be combined with draft-levine-dkim-conditional to offer a resource record where only the base portion of the domain might be included to guard against domain hash collisions. TPA-Label that had the goal of reducing collateral damage caused by compromised accounts or resources, can be combined with draft-levine-dkim-conditional to signal when this limited signature should be included and which domain needs to be authorized. Because this uses very simple resource records, is should scale far better than SPF and yet permit a means to establish an informal federation scheme to better protect email infrastructure with low latency abuse responses. TPA-Label does not make handling third-party messages harder. Instead, TPA-Label offers a simple way to signal which domains require exceptional handling. Without such a feature, DMARC can not be seen as being compatible with RFC5322.=20 Again, we will happily help any large ESP configure and maintain their services to make use of this scheme and even offer the needed resources. Regards, Douglas Otis _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Fri May 15 01:33:38 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B56B1B2EAE for ; Fri, 15 May 2015 01:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45L-Hw1f7mal for ; Fri, 15 May 2015 01:33:34 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB2E31A1BDC for ; Fri, 15 May 2015 01:33:33 -0700 (PDT) Received: by wizk4 with SMTP id k4so276975351wiz.1 for ; Fri, 15 May 2015 01:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KAUBfcshIYLRgj7EcHH4WiQpTvIzUUuf+UZAtv5cEJo=; b=hVqVMytENFhNBbOBAy0ABlzZ/PKlqP7uTPCCvIYdO6ytMbRFqZvK8utw1lGYToiQm4 luL231G+Dft1yQNU0jhAwwdrJsr6dy/RYlEG+xP8PBQ4ageDKYw985m8D/4Xx3RcCbeV fz9iTC2JcQFS/Vx/7lcm6T9kCFPU9mSU4kohGXByjxcJVnXZi0Hse+JaH+YfBKH4LMhr vU29j8u3iXW878PcY6cqhFx6IfCmgVCm1gKncXrW22wEL9UkLo4B4LXZQQ4hvjsrMxkT 14Rh983Rm7yWo7uQSyq7DqDKiH48x1sdliltFLiFUgnoSqfMVsB2Nm7hucgESKswQFNL dI8g== MIME-Version: 1.0 X-Received: by 10.194.174.68 with SMTP id bq4mr560169wjc.4.1431678807849; Fri, 15 May 2015 01:33:27 -0700 (PDT) Received: by 10.27.170.134 with HTTP; Fri, 15 May 2015 01:33:27 -0700 (PDT) In-Reply-To: References: <554BC30F.1020107@isdg.net> <554BE12A.7010606@isdg.net> <26011.1431106173@vindemiatrix.encs.concordia.ca> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> <14447.1431266709@vindemiatrix.encs.concordia.ca> <554FEBB4.5050805@gmail.com> <5550FB6C.7050802@gmail.com> <55518F96.8040708@isdg.net> <55529DFB.3010704@gmail.com> <87a8x92q7g.fsf@uwakimon.sk.tsukuba.ac.jp> <5553C44C.7040307@gmail.com> <87vbfv2480.fsf@uwakimon.sk.tsukuba.ac.jp> <87mw171trj.fsf@uwakimon.sk.tsukuba.ac.jp> <55552A6C.5060101@gmail.com> Date: Fri, 15 May 2015 01:33:27 -0700 Message-ID: From: "Murray S. Kucherawy" To: Terry Zink Content-Type: multipart/alternative; boundary=089e01493680c645c305161ab2cc Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Simple authorization offers reasonable control over messaging resources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 08:33:36 -0000 --089e01493680c645c305161ab2cc Content-Type: text/plain; charset=UTF-8 On Thu, May 14, 2015 at 11:27 PM, Terry Zink wrote: > > The Sender header field when present has been defined for > > decades to represent the sending agent! > > Maybe, maybe not. Outlook desktop client shows the Sender: header as > " on behalf of <5322.from>", but neither Hotmail/outlook.com nor > Gmail do. They just show the 5322.From address regardless of whether or not > there is a Sender: header. This Sender: DMARC fix requires a change in the > way these clients render email. Given the marginal additional benefit to > receiving mailing list traffic that won't implement any of the published > workarounds (not modifying content, fiddling around with Reply-To and From > addresses, changing the From: domain to be the mailing list domain), I > can't see why Gmail or Hotmail would want to make a change like that. I > agree with Murray that it isn't worth pursuing, the cost/benefit ratio > isn't there. > The definition of Sender isn't even what I'm talking about. Its use, not its definition, are what's historically been inconsistent. In particular, as I understand it, it has not historically been the case that all message generating agents that should add Sender, to identify the "actual submittor" (RFC822), have done so. People advocating for keying DMARC on Sender in addition to or instead of >From must then necessarily imply that we should start relying on the greater Internet to begin doing correctly something that has not been done reliably for a long time. -MSK --089e01493680c645c305161ab2cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, May 14, 2015 at 11:27 PM, Terry Zink <= tzink@exchange.microsoft.com> wrote:
> The Sender header field when present has been defined for
> decades to represent the sending agent!

Maybe, maybe not. Outlook desktop client shows the Sender: header as= "<sender> on behalf of <5322.from>", but neither Hot= mail/outlook.com nor G= mail do. They just show the 5322.From address regardless of whether or not = there is a Sender: header. This Sender: DMARC fix requires a change in the = way these clients render email. Given the marginal additional benefit to=C2= =A0 receiving mailing list traffic that won't implement any of the publ= ished workarounds (not modifying content, fiddling around with Reply-To and= From addresses, changing the From: domain to be the mailing list domain), = I can't see why Gmail or Hotmail would want to make a change like that.= I agree with Murray that it isn't worth pursuing, the cost/benefit rat= io isn't there.

The definition of S= ender isn't even what I'm talking about.=C2=A0 Its use, not its def= inition, are what's historically been inconsistent.=C2=A0 In particular= , as I understand it, it has not historically been the case that all messag= e generating agents that should add Sender, to identify the "actual su= bmittor" (RFC822), have done so.

People advocating for keying D= MARC on Sender in addition to or instead of From must then necessarily impl= y that we should start relying on the greater Internet to begin doing corre= ctly something that has not been done reliably for a long time.

-MSK
--089e01493680c645c305161ab2cc-- From nobody Fri May 15 06:09:24 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39F71A1BE6 for ; Fri, 15 May 2015 06:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.101 X-Spam-Level: X-Spam-Status: No, score=-98.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_65=0.6, J_CHICKENPOX_74=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hk_cjJfuFdHV for ; Fri, 15 May 2015 06:09:21 -0700 (PDT) Received: from pop3.winserver.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 685791A86F5 for ; Fri, 15 May 2015 06:09:21 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3931; t=1431695354; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Nm0UoRhLKBwbHkGl6xctge5kU/4=; b=bUQSGbS9yqMEGcvEJdsG c5KTaJ2fhVjPxR8KsdHnX+BVnIYxgDIWEJm55XnC7gyTWNEjt4gZHTu0eTHvRAY6 9x5NYbfTJVUA5aC1HHDh9e3NpYCWP3EoEi4J3kqN3j4touiIiFpG/ZXI9H2HZjnm B7qtoLTTxO/o96R2klQsn0g= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 15 May 2015 09:09:14 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1110372258.1.6088; Fri, 15 May 2015 09:09:14 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3931; t=1431695066; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Y88f0XR ry6blhQJvDRoyBRotpml2tCb78N12mC3vkOI=; b=MPiS0UG4K04ffB+3sk4pk6U aOxyjcLXPgt2+FeDcFEyRocjGbHVZBK9WjmMQE0ZS6Y6fT8OjBjP0oqfeo5HbX1e zskgyuA5NeWpJ2W/PDFL6HKlq3aZDfPt8gk8Cz8TMm0Q2dO8s1CPnoSzUYP9xb66 bJBWUpC4zA0HiEtjWjbY= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 15 May 2015 09:04:26 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3997602004.9.17940; Fri, 15 May 2015 09:04:25 -0400 Message-ID: <5555EFFA.6050800@isdg.net> Date: Fri, 15 May 2015 09:09:14 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dmarc@ietf.org References: <554BC30F.1020107@isdg.net> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> <14447.1431266709@vindemiatrix.encs.concordia.ca> <554FEBB4.5050805@gmail.com> <5550FB6C.7050802@gmail.com> <55518F96.8040708@isdg.net> <55529DFB.3010704@gmail.com> <87a8x92q7g.fsf@uwakimon.sk.tsukuba.ac.jp> <5553C44C.7040307@gmail.com> <87vbfv2480.fsf@uwakimon.sk.tsukuba.ac.jp> <87mw171trj.fsf@uwakimon.sk.tsukuba.ac.jp> <55552A6C.5060101@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Simple authorization offers reasonable control over messaging resources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 13:09:24 -0000 On 5/15/2015 2:27 AM, Terry Zink wrote: >> The Sender header field when present has been defined for >> decades to represent the sending agent! > > Maybe, maybe not. Sender is a RFC822 header (since the 80s). Its been around for a long time. Our MLS added it along with the "Error-To" for MLM operations. No option to disable that. I believe we stole the idea from the original listserv or rather we just wanted a way to give the BOUNCE guy or your own SERVER a way distinguish the type of mail you were seeing. Error-To mean it was for the list. > The TPA authorization DNS zone publishing has been pushed by yourself and another board participant and has received universally negative feedback, or at best neutral feedback. The people here are smart and have as much experience as anyone else and they understand what you are saying. But they still don't agree, including me. I think it's time to make like the movie Frozen and let it go. > > -- Terry Terry, Once about the time, SPF was put down (not supported) by the same "smart" folks leading or participating in the DKIM project and related projects. SSP/ADSP was also put down only for the "Super ADSP" DMARC version to be resurrected by the "smart" folks. Same ideas, same problems, but with a different language. The "smart" folks also said: 1) No one will use POLICY protocols, and even if they did, 2) No one will published restrictive policies, and even if they did, 3) No receiver will honor them anyway, so whats the point? The "smart" folks were wrong on these DKIM Policy Framework counts. In other words, if by smart you mean, "consensus," then in all honesty, the consensus doesn't have a good track record in leading the DKIM project. So please excuse me, and I don't mean any disrespect, if I am not too confident or excited with the direction you would like to take this DKIM project. The odds are very high, based on history, based on the leadership of this DKIM project, we are heading down another failed path with more patch work, more kludges, more "spaghetti code" and quite frankly, inadequate integrated work. We are all tired of this, I suppose. I've been at it since 2003. The DNS Lookup query is the *ideal* IETF protocol solution and that should be one of the working documents completed and released as an Experimental Protocol. Whether the private or public domain can or can not, is not the issue because that is always going to be the case. Many will say its really not for the hotmail.coms, its too spam polluted. That was what was meant when many didn't believe domains will not publish records. So it was surprising Yahoo.com created a hard policy, its also spam polluted. But policy advocates can also understand why it was done. You can instantly begin to clean up a domain by using tight SMTP policies. The small nimbler guys were able to do it and prove it for a long time and we also serve ISPs, ESPs and MLMs operations with our wares! If you want an IETF solution, the DNS Lookup query is the easiest. Bottom line. The registration thing is a side track and maybe "smarter" people than us can figure that out -- and I predict someone will. So I highly recommend the IETF get ready for it, we prepare the DNS I/O protocol model for this, in the same way we did with DKIM STD for the Trust as a function of the SDID. Policy = DKIM_POLICY(ADID, SDID=NULL) Trust = DKIM_TRUST(SDID, AUID=NULL) Note the ADID and AUID are different. These were the conceptual DKIM POLICY+TRUST modelings we been fussing with for a long time. Lets not make it so complicated, get back to basic and get it done already -- independent of registration part. I am sure we will have plenty to say about this component and for the most part, MOST people can handle it. Maybe the hotmails can't and thats normal. It can't handle SPF either anyway. -- HLS From nobody Fri May 15 08:07:14 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3601A8798 for ; Fri, 15 May 2015 08:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.299 X-Spam-Level: * X-Spam-Status: No, score=1.299 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_65=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyZHKeiFtBGk for ; Fri, 15 May 2015 08:07:11 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A5791A0078 for ; Fri, 15 May 2015 08:07:11 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES532.agna.amgreetings.com ([::1]) with mapi id 14.03.0210.002; Fri, 15 May 2015 11:07:09 -0400 From: "MH Michael Hammer (5304)" To: Hector Santos , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Simple authorization offers reasonable control over messaging resources Thread-Index: AQHQjpqvQnRqgH0keky4r+cZnlnjOp181iuAgABwXAD//9hG4A== Date: Fri, 15 May 2015 15:07:09 +0000 Message-ID: References: <554BC30F.1020107@isdg.net> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> <14447.1431266709@vindemiatrix.encs.concordia.ca> <554FEBB4.5050805@gmail.com> <5550FB6C.7050802@gmail.com> <55518F96.8040708@isdg.net> <55529DFB.3010704@gmail.com> <87a8x92q7g.fsf@uwakimon.sk.tsukuba.ac.jp> <5553C44C.7040307@gmail.com> <87vbfv2480.fsf@uwakimon.sk.tsukuba.ac.jp> <87mw171trj.fsf@uwakimon.sk.tsukuba.ac.jp> <55552A6C.5060101@gmail.com> <5555EFFA.6050800@isdg.net> In-Reply-To: <5555EFFA.6050800@isdg.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.222] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [dmarc-ietf] Simple authorization offers reasonable control over messaging resources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 15:07:13 -0000 > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Hector Santos > Sent: Friday, May 15, 2015 9:09 AM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Simple authorization offers reasonable control = over > messaging resources >=20 > On 5/15/2015 2:27 AM, Terry Zink wrote: > >> The Sender header field when present has been defined for decades to > >> represent the sending agent! > > > > Maybe, maybe not. >=20 > Sender is a RFC822 header (since the 80s). Its been around for a long tim= e. > Our MLS added it along with the "Error-To" for MLM operations. > No option to disable that. I believe we stole the idea from the origin= al > listserv or rather we just wanted a way to give the BOUNCE guy or your ow= n > SERVER a way distinguish the type of mail you were seeing. Error-To mean= it > was for the list. >=20 We need to be careful when we assert meanings to terms in older RFCs. If yo= u look at RFC822 Appendix A, none of the examples for the Sender field use = a fully qualified hostname where the sender is in a different domain than F= rom. This implies that the original intent of the Sender field was not to a= uthorize unrelated 3rd parties to be the Sender on behalf of the From (part= y).=20 > > The TPA authorization DNS zone publishing has been pushed by yourself > and another board participant and has received universally negative > feedback, or at best neutral feedback. The people here are smart and have > as much experience as anyone else and they understand what you are > saying. But they still don't agree, including me. I think it's time to ma= ke like > the movie Frozen and let it go. > > > > -- Terry >=20 > Terry, >=20 > Once about the time, SPF was put down (not supported) by the same > "smart" folks leading or participating in the DKIM project and related > projects. >=20 > SSP/ADSP was also put down only for the "Super ADSP" DMARC version to > be resurrected by the "smart" folks. Same ideas, same problems, but with= a > different language. >=20 I disagree with this assertion Hector. I was one of the folks arguing in fa= vor of policy over reputation. ADSP was moved forward but in the end was f= undamentally broken. DMARC is not "Super ADSP", there are some fundamental = differences. I declined to participate in the predecessor project to DMARC = because I felt it to had issues (and in hindsight I guess I was right - it = was stillborn).=20 > The "smart" folks also said: >=20 > 1) No one will use POLICY protocols, and even if they did, > 2) No one will published restrictive policies, and even if they did, > 3) No receiver will honor them anyway, so whats the point? >=20 > The "smart" folks were wrong on these DKIM Policy Framework counts. >=20 > In other words, if by smart you mean, "consensus," then in all honesty, t= he > consensus doesn't have a good track record in leading the DKIM project. >=20 Sometimes consensus works - sometimes it doesn't. Sometimes not attempting = consensus works - sometimes it doesn't (MARID working group). > So please excuse me, and I don't mean any disrespect, if I am not too > confident or excited with the direction you would like to take this DKIM > project. The odds are very high, based on history, based on the leadershi= p of > this DKIM project, we are heading down another failed path with more patc= h > work, more kludges, more "spaghetti code" and quite frankly, inadequate > integrated work. >=20 This is one of the reasons I have held back from participating in the discu= ssions/attempts to come up with authorizations for unrelated 3rd parties. E= ven recognizing the resistance from various quarters, 3rd parties and inter= mediaries (which modify messages) taking responsibility for messages they e= mit is ultimately the cleanest and most workable approach. Yes it requires = change on the part of some (I'm waiting for shouts of "GET OFF MY VIRTUAL L= AWN"). > We are all tired of this, I suppose. I've been at it since 2003. The DNS = Lookup > query is the *ideal* IETF protocol solution and that should be one of the > working documents completed and released as an Experimental Protocol. >=20 > Whether the private or public domain can or can not, is not the issue > because that is always going to be the case. Many will say its > really not for the hotmail.coms, its too spam polluted. That was what wa= s > meant when many didn't believe domains will not publish records. > So it was surprising Yahoo.com created a hard policy, its also spam pollu= ted. >=20 It isn't about whether a domain is spam polluted (as you call it), it is wh= ether a domain can be abused by mail claiming to be from it but which emana= tes from somewhere else. These are two different issues. It is also about w= hether a domain owner/administrator has the right/authority to determine ho= w it's domain is used. > But policy advocates can also understand why it was done. You can instan= tly > begin to clean up a domain by using tight SMTP policies. > The small nimbler guys were able to do it and prove it for a long time an= d we > also serve ISPs, ESPs and MLMs operations with our wares! >=20 > If you want an IETF solution, the DNS Lookup query is the easiest. > Bottom line. The registration thing is a side track and maybe "smarter" > people than us can figure that out -- and I predict someone will. So I h= ighly > recommend the IETF get ready for it, we prepare the DNS I/O protocol mode= l > for this, in the same way we did with DKIM STD for the Trust as a functio= n of > the SDID. >=20 > Policy =3D DKIM_POLICY(ADID, SDID=3DNULL) > Trust =3D DKIM_TRUST(SDID, AUID=3DNULL) >=20 > Note the ADID and AUID are different. >=20 > These were the conceptual DKIM POLICY+TRUST modelings we been fussing > with for a long time. >=20 > Lets not make it so complicated, get back to basic and get it done alread= y -- > independent of registration part. I am sure we will have plenty to say a= bout > this component and for the most part, MOST people can handle it. Maybe > the hotmails can't and thats normal. It can't handle SPF either anyway. >=20 From nobody Fri May 15 08:52:11 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1130F1A00FF for ; Fri, 15 May 2015 08:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e7SoZT_za570 for ; Fri, 15 May 2015 08:52:08 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF03E1A0054 for ; Fri, 15 May 2015 08:52:08 -0700 (PDT) Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t4FFq4gD022484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 15 May 2015 08:52:08 -0700 Message-ID: <55561623.8010209@dcrocker.net> Date: Fri, 15 May 2015 08:52:03 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "dmarc@ietf.org" References: <554BC30F.1020107@isdg.net> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> <14447.1431266709@vindemiatrix.encs.concordia.ca> <554FEBB4.5050805@gmail.com> <5550FB6C.7050802@gmail.com> <55518F96.8040708@isdg.net> <55529DFB.3010704@gmail.com> <87a8x92q7g.fsf@uwakimon.sk.tsukuba.ac.jp> <5553C44C.7040307@gmail.com> <87vbfv2480.fsf@uwakimon.sk.tsukuba.ac.jp> <87mw171trj.fsf@uwakimon.sk.tsukuba.ac.jp> <55552A6C.5060101@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 15 May 2015 08:52:08 -0700 (PDT) Archived-At: Subject: [dmarc-ietf] Sender: vs. From: (was Re: Simple authorization offers reasonable control over messaging resources) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 15:52:10 -0000 On 5/14/2015 11:27 PM, Terry Zink wrote: >> The Sender header field when present has been defined for decades >> to represent the sending agent! > > Maybe, maybe not. Sorry, but there isn't much maybe about it. The definition in the spec has been clear since the construct was invented, in 1977. /Usage/ has varied quite a bit, as with so much of email, with implementations re-purposing the field in various ways, thereby effectively defeating useful interoperability. And 'display' of the field is an entirely separate issue. Commentary about DMARC usually does cite 'display' as the essential requirement, which drives selection of the From field. IMO it continues to be a significantly misleading point, since end-user viewing of the From field is largely irrelevant to any real-world efficacy. This appears to be an indelicate point to raise, since it's being consistently ignored as discussions about DMARC continue (everywhere, not just here.) On the other hand, the rfc5322.From field is the only field with a content-related identifier that is /always/ present. Hence, a receiving filtering engine has a place that it always can always look, for a claim of authorship. By its nature, a mechanism like DMARC must begin with an identifier selected by the receiving filtering engine. Hence, there must (always) be an identifier reliably associated with the message. Its semantics must pertain to something semantically interesting. DMARC chose "content authorship", which is pretty obviously reasonable. With that claimed content responsibility, the engine can proceed with an analysis that relates the identifier to a reputation. One aspect of reputation is "is the identifier authorized for use?" DMARC answers that question. One could imagine a "handling responsibility" as being a reasonable alternative choice, too, but it's much weaker. Worse, it invites a problematic disconnect between content responsibility and handling responsibility, which thereby invites gaming the system. Choosing content responsibility is therefore much more appealing, albeit simplistic in a way that causes problems with the entirely legitimate scenarios that the community has been seeing. In particular, DMARC requires very tight coupling between content and handling responsibility, which differs from many, long-standing, legitimate scenarios. Choosing a properly-available Sender: field creates a much better semantic, in terms of pointing to the responsible operational agent. But it is not an operationally practical choice. The problem is that when that identifier is different from the content identifier, we have the task of figuring out whether the identity in the Sender: field is 'authorized' to operate on behalf of the identity in the From: field.[*] d/ [*] In case folk miss the point, the Sender identifier is /always/ present, even when the Sender: field is not. If this isn't clear to anyone, I encourage re-reading Section 3.4.2 of RFC 5322. -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri May 15 10:30:48 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4AB1A883F for ; Fri, 15 May 2015 10:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.379 X-Spam-Level: X-Spam-Status: No, score=-98.379 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5n8p1d9m0Db for ; Fri, 15 May 2015 10:30:45 -0700 (PDT) Received: from ftp.catinthebox.net (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id A0C1A1A8843 for ; Fri, 15 May 2015 10:30:44 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3642; t=1431711040; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=cN5BOIgOyQicx1eTImt1dTj9Uis=; b=g693Hdm9qsOQMQ6AFh5T RaXDGxHEcVuAnwE5cDsTxuNgW4hVETFt8O3yHeEnfbRzToEvCjRZoS0pojtngrYr OAuWHKKQ85fcABiakgvtN8CgGGDCE/ESz4mOa3opH3HsqAc2PdPbDZygQEh2QPzt 090V4Yr7LAQJfQzA+hHgP4s= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 15 May 2015 13:30:40 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1126057582.1.4664; Fri, 15 May 2015 13:30:39 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3642; t=1431710752; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=nfIhgJX LMLuhrKfGJ9p6y7ELOdC8pDQsF0H5eFx8R8k=; b=SlkULOr3UrUMX7oIHIOy5RY XO0amKI0o4SeUDFh9Hpp8CiYJx5w9WGrmN0kEhmqrmubBMw8URKD8nq5IYxLKXJR 8rQR+x4P4/PR43Sa7eUjYvoG8bZE04Gl/LqNG2+M6+UhxFqVJggd9u4nyeXkiTpx knIv3CqY2G4LpU3+WQQY= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 15 May 2015 13:25:52 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4013287738.9.18056; Fri, 15 May 2015 13:25:51 -0400 Message-ID: <55562D40.1000504@isdg.net> Date: Fri, 15 May 2015 13:30:40 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "MH Michael Hammer (5304)" References: <554BC30F.1020107@isdg.net> <14447.1431266709@vindemiatrix.encs.concordia.ca> <554FEBB4.5050805@gmail.com> <5550FB6C.7050802@gmail.com> <55518F96.8040708@isdg.net> <55529DFB.3010704@gmail.com> <87a8x92q7g.fsf@uwakimon.sk.tsukuba.ac.jp> <5553C44C.7040307@gmail.com> <87vbfv2480.fsf@uwakimon.sk.tsukuba.ac.jp> <87mw171trj.fsf@uwakimon.sk.tsukuba.ac.jp> <55552A6C.5060101@gmail.com> <5555EFFA.6050800@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Simple authorization offers reasonable control over messaging resources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 17:30:47 -0000 On 5/15/2015 11:07 AM, MH Michael Hammer (5304) wrote: >>> Maybe, maybe not. >> >> Sender is a RFC822 header (since the 80s). Its been around for a long time. >> Our MLS added it along with the "Error-To" for MLM operations. >> No option to disable that. I believe we stole the idea from the original >> listserv or rather we just wanted a way to give the BOUNCE guy or your own >> SERVER a way distinguish the type of mail you were seeing. Error-To mean it >> was for the list. >> > We need to be careful when we assert meanings to terms in older RFCs. If you look at RFC822 Appendix A, none of the examples for the Sender field use a fully qualified hostname where the sender is in a different domain than From. This implies that the original intent of the Sender field was not to authorize unrelated 3rd parties to be the Sender on behalf of the From (party). > I don't recall being interested in payload authorization when Sender: and Error-To: were added. It was more about providing all the help in delivering the "bounce" back to the sender to help in some MLM related process before List-* headers days. There were still SLIP/UUCP transports which didn't use the Return-Path, instead used a top "From " meta-header. >> SSP/ADSP was also put down only for the "Super ADSP" DMARC version to >> be resurrected by the "smart" folks. Same ideas, same problems, but with a >> different language. >> > > I disagree with this assertion Hector. I was one of the folks arguing in favor of policy over reputation. ADSP was moved forward but in the end was fundamentally broken. DMARC is not "Super ADSP", there are some fundamental differences. I declined to participate in the predecessor project to DMARC because I felt it to had issues (and in hindsight I guess I was right - it was stillborn). > Then DMARC should perhaps remove its reference as "Super ADSP." ADSP and DMARC have the same overall ideas of using an Author policy concept. Same problem exist. Same basic issues. Broken for all the same basic reasons. We just didn't have the urgency back then to address the problem because of the reputation/trust focus as a solution. I don't think many took DMARC serious because it was a "Reporting" tool. I just saw it proving using redundant reports what we already knew without reports. Its not rocket science. ADSP DISCARD worked for filtering spoofs and it needed a 3rd party hook to it to protect the MLM resigner market. We all agreed that a resign needed to be done in order to resolve the integrity issue. > It isn't about whether a domain is spam polluted (as you call it), it is whether a domain can be abused by mail claiming to be from it but which emanates from somewhere else. These are two different issues. It is also about whether a domain owner/administrator has the right/authority to determine how it's domain is used. > Its about many things. Laid out all the possible policy boundary conditions that can be expected when it comes to 1st party signers and resigners. Thats fundamental in all this because we need to take the author domain at its word at some point. Does the author domain have an exclusive signing policy? Does the author domain allow resigners? Does the domain only allow authorized resigners, if so, how? and so on. we only got stuck on that last one. We been able to separate the issue into a "BIG DATA" registration concern and not a big issue for a smaller network of potential resigners. You have to be able to describe this policy via the DMARC lookup. Then the receivers will have a better want to handle it. -- HLS From nobody Fri May 15 11:03:47 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B51AD1A0399 for ; Fri, 15 May 2015 11:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.379 X-Spam-Level: X-Spam-Status: No, score=-98.379 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZFLld1ytoHq for ; Fri, 15 May 2015 11:03:45 -0700 (PDT) Received: from ftp.catinthebox.net (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id BB5411A037E for ; Fri, 15 May 2015 11:03:44 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1254; t=1431713016; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=NltuYgv39q4Ox4DcpmmKjKl4DRE=; b=c/l/6wumczmX/v1fbXBi jDds/bPQHSdwWEVsdp1pPpr5OG1XO4XdUj2klfWJGFcnxeH+aGxo8KWYYBbdegFD 1NiX5eJZfQcRfIKCj+23JGq9Ri4x7GTGkM9fTi682oetXHExYImt2hryosFBQyRu Iik+jGn8wh5LMEzR6N3UZFM= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 15 May 2015 14:03:36 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1128032804.1.256; Fri, 15 May 2015 14:03:34 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1254; t=1431712731; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=u6qmMQ+ zphpn0V/2U8lcv0eZvnwCbueJEWmDFAUDSec=; b=gTgfd9SF92/1hy+n17rF02W dwcgyBNgaEnnN+LGTRlvFZYBkYqW0HX0Ucs80os9ifxB/yEjn3rS/UQKNFnZiJve vYrJcm7UwGE01zABpiBkUrvt9EGKHpsBAKJSDB0o3QVtc31maYWdVQlBtKrWhYdv nij9jC1H0SiLBgxkzdRA= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 15 May 2015 13:58:51 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4015267129.9.17336; Fri, 15 May 2015 13:58:50 -0400 Message-ID: <555634FB.5080403@isdg.net> Date: Fri, 15 May 2015 14:03:39 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "MH Michael Hammer (5304)" References: <554BC30F.1020107@isdg.net> <14447.1431266709@vindemiatrix.encs.concordia.ca> <554FEBB4.5050805@gmail.com> <5550FB6C.7050802@gmail.com> <55518F96.8040708@isdg.net> <55529DFB.3010704@gmail.com> <87a8x92q7g.fsf@uwakimon.sk.tsukuba.ac.jp> <5553C44C.7040307@gmail.com> <87vbfv2480.fsf@uwakimon.sk.tsukuba.ac.jp> <87mw171trj.fsf@uwakimon.sk.tsukuba.ac.jp> <55552A6C.5060101@gmail.com> <5555EFFA.6050800@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Simple authorization offers reasonable control over messaging resources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 18:03:45 -0000 On 5/15/2015 11:07 AM, MH Michael Hammer (5304) wrote: > > This is one of the reasons I have held back from participating in the discussions/attempts to come up with authorizations for unrelated 3rd parties. Even recognizing the resistance from various quarters, 3rd parties and intermediaries (which modify messages) taking responsibility for messages they emit is ultimately the cleanest and most workable approach. Yes it requires change on the part of some (I'm waiting for shouts of "GET OFF MY VIRTUAL LAWN"). > I noticed that with your ag.com, you only have an SPF -ALL record. No ADSP, no DMARC. I also notice that you didn't sign your mail. So I don't know if you have a DKIM public key. So basically, you decided not to have any assertions made on your ag.com from a DKIM, Trust and Reputation, Policy standpoint. The odds are high that if you are going to get spoofed, it will have to be sent from a different an unauthorized IP address. With a SPF -ALL, it lowers the need for DMARC, ADSP. Thats another reason why there is less urgency. DMARC is really a helper for SPF softfail (~ALL) or neutral (?ALL) policies. During the DKIM-WG, Microsoft did talk about using ADSP DISCARD with a SPF SOFTFAIL. -- HLS From nobody Fri May 15 11:30:50 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7389F1A1BFF for ; Fri, 15 May 2015 11:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_14=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EW0Ve64QHGcu for ; Fri, 15 May 2015 11:30:47 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.31]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7B381A1B7F for ; Fri, 15 May 2015 11:30:45 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES533.agna.amgreetings.com ([::1]) with mapi id 14.03.0210.002; Fri, 15 May 2015 14:30:44 -0400 From: "MH Michael Hammer (5304)" To: Hector Santos Thread-Topic: [dmarc-ietf] Simple authorization offers reasonable control over messaging resources Thread-Index: AQHQjpqvQnRqgH0keky4r+cZnlnjOp181iuAgABwXAD//9hG4IAAefyA///ATyA= Date: Fri, 15 May 2015 18:30:43 +0000 Message-ID: References: <554BC30F.1020107@isdg.net> <14447.1431266709@vindemiatrix.encs.concordia.ca> <554FEBB4.5050805@gmail.com> <5550FB6C.7050802@gmail.com> <55518F96.8040708@isdg.net> <55529DFB.3010704@gmail.com> <87a8x92q7g.fsf@uwakimon.sk.tsukuba.ac.jp> <5553C44C.7040307@gmail.com> <87vbfv2480.fsf@uwakimon.sk.tsukuba.ac.jp> <87mw171trj.fsf@uwakimon.sk.tsukuba.ac.jp> <55552A6C.5060101@gmail.com> <5555EFFA.6050800@isdg.net> <555634FB.5080403@isdg.net> In-Reply-To: <555634FB.5080403@isdg.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.222] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Simple authorization offers reasonable control over messaging resources X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 18:30:48 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSGVjdG9yIFNhbnRvcyBb bWFpbHRvOmhzYW50b3NAaXNkZy5uZXRdDQo+IFNlbnQ6IEZyaWRheSwgTWF5IDE1LCAyMDE1IDI6 MDQgUE0NCj4gVG86IE1IIE1pY2hhZWwgSGFtbWVyICg1MzA0KQ0KPiBDYzogZG1hcmNAaWV0Zi5v cmcNCj4gU3ViamVjdDogUmU6IFtkbWFyYy1pZXRmXSBTaW1wbGUgYXV0aG9yaXphdGlvbiBvZmZl cnMgcmVhc29uYWJsZSBjb250cm9sIG92ZXINCj4gbWVzc2FnaW5nIHJlc291cmNlcw0KPiANCj4g T24gNS8xNS8yMDE1IDExOjA3IEFNLCBNSCBNaWNoYWVsIEhhbW1lciAoNTMwNCkgd3JvdGU6DQo+ ID4NCj4gDQo+ID4gVGhpcyBpcyBvbmUgb2YgdGhlIHJlYXNvbnMgSSBoYXZlIGhlbGQgYmFjayBm cm9tIHBhcnRpY2lwYXRpbmcgaW4gdGhlDQo+IGRpc2N1c3Npb25zL2F0dGVtcHRzIHRvIGNvbWUg dXAgd2l0aCBhdXRob3JpemF0aW9ucyBmb3IgdW5yZWxhdGVkIDNyZA0KPiBwYXJ0aWVzLiBFdmVu IHJlY29nbml6aW5nIHRoZSByZXNpc3RhbmNlIGZyb20gdmFyaW91cyBxdWFydGVycywgM3JkIHBh cnRpZXMNCj4gYW5kIGludGVybWVkaWFyaWVzICh3aGljaCBtb2RpZnkgbWVzc2FnZXMpIHRha2lu ZyByZXNwb25zaWJpbGl0eSBmb3INCj4gbWVzc2FnZXMgdGhleSBlbWl0IGlzIHVsdGltYXRlbHkg dGhlIGNsZWFuZXN0IGFuZCBtb3N0IHdvcmthYmxlIGFwcHJvYWNoLg0KPiBZZXMgaXQgcmVxdWly ZXMgY2hhbmdlIG9uIHRoZSBwYXJ0IG9mIHNvbWUgKEknbSB3YWl0aW5nIGZvciBzaG91dHMgb2Yg IkdFVA0KPiBPRkYgTVkgVklSVFVBTCBMQVdOIikuDQo+ID4NCj4gDQo+IEkgbm90aWNlZCB0aGF0 IHdpdGggeW91ciBhZy5jb20sIHlvdSBvbmx5IGhhdmUgYW4gU1BGIC1BTEwgcmVjb3JkLiAgTm8g QURTUCwNCj4gbm8gRE1BUkMuICBJIGFsc28gbm90aWNlIHRoYXQgeW91IGRpZG4ndCBzaWduIHlv dXIgbWFpbC4gIFNvIEkgZG9uJ3Qga25vdyBpZiB5b3UNCj4gaGF2ZSBhIERLSU0gcHVibGljIGtl eS4NCj4gDQoNCkFnLmNvbSBpcyBub3QgYSBkb21haW4gSSBjb250cm9sIC0gaXQgaXMgY29udHJv bGxlZCBieSBteSBjb3Jwb3JhdGUgcGFyZW50IChlbnRlcnByaXNlKSBhbmQgdXNlZCBmb3IgZW50 ZXJwcmlzZSBtYWlsLg0KDQpUaGUgd2Vic2l0ZSBkb21haW5zIEknbSByZXNwb25zaWJsZSBmb3Ig aGF2ZSBiZWVuIHB1Ymxpc2hpbmcgYW4gU1BGIC1hbGwsIERLSU0gc2lnbiBhbGwgbWFpbCBhbmQg cHVibGlzaCBhIERNQVJDIHA9bm9uZS4gVGhlIFNQRiwgREtJTSBhbmQgdGhlIGVxdWl2YWxlbnQg b2YgRE1BUkMgcD1ub25lIHRocm91Z2ggcHJpdmF0ZSBjaGFubmVscyAoeWVzLCBJIGhlbHBlZCBj cmVhdGUgRE1BUkMpIGhhdmUgYmVlbiBpbiBwbGFjZSBzaW5jZSAyMDA3IGFuZCB3b3JraW5nIHF1 aXRlIG5pY2VseSB0aGFuayB5b3UuIElmIHlvdSBnbyBiYWNrIHRvIHRoZSBka2ltLW9wcyBsaXN0 IGFyY2hpdmUgeW91IHdpbGwgZmluZCBhbiBlbWFpbCBmcm9tIG1lIGFzc2VydGluZyB0aGF0IGFu eW9uZSBzaG91bGQgZmVlbCBmcmVlIHRvIHRocm93IGF3YXkgZW1haWwgdGhhdCBmYWlsZWQgdG8g dmFsaWRhdGUgb3VyIChkb21haW5zKSBES0lNIHNpZ25hdHVyZSBvciBhbGlnbmVkIFNQRi4gVGhl IG9ubHkgdGhpbmcgSSBoYWQgdG8gZG8gd2hlbiB0aGUgRE1BUkMgc3BlYyB3YXMgY29tcGxldGVk IHdhcyBwdWJsaXNoIGEgcD1ub25lIHJlY29yZC4NCg0KPiBTbyBiYXNpY2FsbHksIHlvdSBkZWNp ZGVkIG5vdCB0byBoYXZlIGFueSBhc3NlcnRpb25zIG1hZGUgb24geW91ciBhZy5jb20NCj4gZnJv bSBhIERLSU0sIFRydXN0IGFuZCBSZXB1dGF0aW9uLCBQb2xpY3kgc3RhbmRwb2ludC4gIFRoZSBv ZGRzIGFyZSBoaWdoIHRoYXQNCj4gaWYgeW91IGFyZSBnb2luZyB0byBnZXQgc3Bvb2ZlZCwgaXQg d2lsbCBoYXZlIHRvIGJlIHNlbnQgZnJvbSBhIGRpZmZlcmVudCBhbg0KPiB1bmF1dGhvcml6ZWQg SVAgYWRkcmVzcy4NCj4gDQoNCkkgY2FuJ3QgZGVjaWRlIHBvbGljeSBmb3IgYSBkb21haW4gSSBk b24ndCBjb250cm9sLiBJbiB0aGlzIGNhc2UgSSdtIGEgdXNlciBsaWtlIGFueSBvdGhlci4gSSBo YXZlLCBvZiBjb3Vyc2UsIGV4cHJlc3NlZCBteSBvcGluaW9uLiBUaGlzIGlzIG5vIGRpZmZlcmVu dCB0aGFuIGlmIEkgc3Vic2NyaWJlZCB0byB0aGUgbGlzdCBmcm9tIEdtYWlsIG9yIHNvbWUgb3Ro ZXIgc2VydmljZSBwcm92aWRlci4NCg0KPiBXaXRoIGEgU1BGIC1BTEwsIGl0IGxvd2VycyB0aGUg bmVlZCBmb3IgRE1BUkMsIEFEU1AuICBUaGF0cyBhbm90aGVyIHJlYXNvbg0KPiB3aHkgdGhlcmUg aXMgbGVzcyB1cmdlbmN5Lg0KPiANCg0KTW9zdCBtYWlsYm94IHByb3ZpZGVycyBJJ20gYXdhcmUg b2YgZG8gbm90IHJlamVjdCBtYWlsIHNvbGVseSBvbiB0aGUgYmFzaXMgb2YgYW4gU1BGIC1hbGwg ZmFpbHVyZS4gVGhlcmUgYXJlIGZhciB0b28gbWFueSBpbmNvcnJlY3RseSBwdWJsaXNoZWQvcHJv YmxlbWF0aWNhbCByZWNvcmRzIG91dCB0aGVyZSB0aGF0IHRoZXkgd2lzaCB0byB0YWtlIHRoYXQg cmlzay4gVGhpcyBpcyBvbmUgb2YgdGhlIHJlYXNvbnMgdGhhdCBETUFSQyB3YXMgZGV2ZWxvcGVk Lg0KDQo+IERNQVJDIGlzIHJlYWxseSBhIGhlbHBlciBmb3IgU1BGIHNvZnRmYWlsICh+QUxMKSBv ciBuZXV0cmFsICg/QUxMKSBwb2xpY2llcy4NCg0KWW91IHBsYWNlIHRvbyBtdWNoIGVtcGhhc2lz IG9uIFNQRi4gVGhlcmUgaXMgYSByZWFzb24gdGhhdCBETUFSQyBwb2xpY3kgaXMgb25seSBjb25z aWRlcmVkIGlmIGJvdGggKGFsaWduZWQpIFNQRiBBTkQgREtJTSBmYWlsIHRvIHZhbGlkYXRlLg0K DQo+IA0KPiBEdXJpbmcgdGhlIERLSU0tV0csICBNaWNyb3NvZnQgZGlkIHRhbGsgYWJvdXQgdXNp bmcgQURTUCBESVNDQVJEIHdpdGggYQ0KPiBTUEYgU09GVEZBSUwuDQo+IA0KDQpMb3RzIG9mIHRo aW5ncyB3ZXJlIHRhbGtlZCBhYm91dCBpbiB0aGUgREtJTSB3b3JraW5nIGdyb3VwLiBUaGF0IG1p Z2h0IGJlIG9uZSByZWFzb24gaXQgdG9vayBzbyBsb25nIGZvciB0aGUgZ3JvdXAgdG8gZ2V0IHRo aW5ncyBkb25lLg0KDQo= From nobody Fri May 15 12:36:17 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6BD31A8890 for ; Fri, 15 May 2015 12:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFirlUFo-9-I for ; Fri, 15 May 2015 12:36:13 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E45B1A86EA for ; Fri, 15 May 2015 12:35:55 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so46021818wic.0 for ; Fri, 15 May 2015 12:35:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=tmpJq4I8K5XwKIk4g8OwoLNbBppNmvNd/RVrFkjUC48=; b=JbAmPCVJd1DooTHGQoLS7Ssve+898TBhKzAe18uDvfbJyDv7hDISK/hELGAIiwx26p 1dCkEzjU2Wlyp+nIdvkf8PMaI7eupURboaHqmEPLf2WhKXnlww2UDC5kTyiRb6QwFcJX 6Is8gYGfvWT2GF2Gk3PJV8O/XV02NAKx1Y/1t8rkj/xTCfQcg42Wy04xxuXBVv2PtoLl M6fUABdMJAli9DxDsjeAsa+s0ZdPL8TFFoqvWzz62QGD3FpjiN7CPd0yJxxite9K/91c cht6tvaX3wU7dLdWUR/ZMokXqSPuNwCFnq0xDUTb9dRrnYapxSy6szCBEeRB4LOr6u9f NEuA== MIME-Version: 1.0 X-Received: by 10.194.193.66 with SMTP id hm2mr20842665wjc.111.1431718554069; Fri, 15 May 2015 12:35:54 -0700 (PDT) Received: by 10.27.170.134 with HTTP; Fri, 15 May 2015 12:35:54 -0700 (PDT) In-Reply-To: <55561623.8010209@dcrocker.net> References: <554BC30F.1020107@isdg.net> <554D3D1E.9050509@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> <14447.1431266709@vindemiatrix.encs.concordia.ca> <554FEBB4.5050805@gmail.com> <5550FB6C.7050802@gmail.com> <55518F96.8040708@isdg.net> <55529DFB.3010704@gmail.com> <87a8x92q7g.fsf@uwakimon.sk.tsukuba.ac.jp> <5553C44C.7040307@gmail.com> <87vbfv2480.fsf@uwakimon.sk.tsukuba.ac.jp> <87mw171trj.fsf@uwakimon.sk.tsukuba.ac.jp> <55552A6C.5060101@gmail.com> <55561623.8010209@dcrocker.net> Date: Fri, 15 May 2015 12:35:54 -0700 Message-ID: From: "Murray S. Kucherawy" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=047d7b874e62d56fc7051623f3fe Archived-At: Subject: Re: [dmarc-ietf] Sender: vs. From: (was Re: Simple authorization offers reasonable control over messaging resources) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 19:36:14 -0000 --047d7b874e62d56fc7051623f3fe Content-Type: text/plain; charset=UTF-8 On Fri, May 15, 2015 at 8:52 AM, Dave Crocker wrote: > > [*] In case folk miss the point, the Sender identifier is /always/ > present, even when the Sender: field is not. If this isn't clear to > anyone, I encourage re-reading Section 3.4.2 of RFC 5322. > Did you mean 3.6.2? -MSK --047d7b874e62d56fc7051623f3fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, May 15, 2015 at 8:52 AM, Dave Crocker <dhc@dcrocke= r.net> wrote:

[*] In case folk miss the point, the Sender identifier is /always/
present, even when the Sender: field is not.=C2=A0 If this isn't clear = to
anyone, I encourage re-reading Section 3.4.2 of RFC 5322.

Did you mean= 3.6.2?

-MSK
--047d7b874e62d56fc7051623f3fe-- From nobody Fri May 15 13:13:59 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 119461A1B84 for ; Fri, 15 May 2015 13:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfUoNgfPyI3G for ; Fri, 15 May 2015 13:13:56 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8736A1A1B51 for ; Fri, 15 May 2015 13:13:56 -0700 (PDT) Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t4FKDoEK032654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 15 May 2015 13:13:54 -0700 Message-ID: <5556537E.1080809@dcrocker.net> Date: Fri, 15 May 2015 13:13:50 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , "dmarc@ietf.org" References: <554BC30F.1020107@isdg.net> <14447.1431266709@vindemiatrix.encs.concordia.ca> <554FEBB4.5050805@gmail.com> <5550FB6C.7050802@gmail.com> <55518F96.8040708@isdg.net> <55529DFB.3010704@gmail.com> <87a8x92q7g.fsf@uwakimon.sk.tsukuba.ac.jp> <5553C44C.7040307@gmail.com> <87vbfv2480.fsf@uwakimon.sk.tsukuba.ac.jp> <87mw171trj.fsf@uwakimon.sk.tsukuba.ac.jp> <55552A6C.5060101@gmail.com> <55561623.8010209@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 15 May 2015 13:13:54 -0700 (PDT) Archived-At: Subject: Re: [dmarc-ietf] Sender: vs. From: (was Re: Simple authorization offers reasonable control over messaging resources) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 20:13:58 -0000 On 5/15/2015 12:35 PM, Murray S. Kucherawy wrote: > On Fri, May 15, 2015 at 8:52 AM, Dave Crocker > wrote: > > [*] In case folk miss the point, the Sender identifier is /always/ > present, even when the Sender: field is not. If this isn't clear to > anyone, I encourage re-reading Section 3.4.2 of RFC 5322. > > > Did you mean 3.6.2? wtf. I read 3.6.2. I thought 3.6.2. I proofread 3.6.2. How the heck did 3.4.2 show up? grrr. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri May 15 13:28:51 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0411A874F for ; Fri, 15 May 2015 13:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmKH7lssVkP3 for ; Fri, 15 May 2015 13:28:48 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB0FF1A8748 for ; Fri, 15 May 2015 13:28:48 -0700 (PDT) Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t4FKSjSZ000493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 15 May 2015 13:28:48 -0700 Message-ID: <555656FC.5010609@dcrocker.net> Date: Fri, 15 May 2015 13:28:44 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "dmarc@ietf.org" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 15 May 2015 13:28:48 -0700 (PDT) Archived-At: Subject: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 20:28:50 -0000 G'day. In looking for ways to make a DMARC-style function succeed when the message transits an intermediary, the current approach has mostly been proposing one or another wholesale solution. This creates a complex space for discussion and tends towards some version of deadly embrace. It might be helpful to consider /basic types/ of changes that are reasonable/unreasonable for intermediaries, distinct from how they might fit into an entire solution. Reasonable vs. unreasonable pertain to at least two axes: 1. Amount of work 2. Policy/Principle Some choices entail too much work or run afoul of basic operational policies. Others might entail some work, but not too much, and might not be considered as significant violations of established policies. Here be dragons, of course, but let's try to have the discussion anyhow. Obviously, there will not be unanimity among all intermediaries, for any proposal. So the question really is about plausible rough consensus among a 'substantial' amount of the community. The first question is: what are the 'types' of changes that have been or might be proposed? This should turn into some sort of taxonomy, eventually, but for now an undisciplined core dump(*) of choices would be best. Examples: Modifying the rfc5322.From display-name Modifying the rfc5322.From address Modifying the footer of the message body (first body-part.) Modifying the rfc5322.Subject preface Performing DMARC validation upon receipt Performing DKIM/SPF validation upon receipt DKIM-signing all outbound mail. Registering the intermediary with all potential sites posting to it Registering the intermediary with all potential sites receiving from it Your turn... d/ (*) it occurs to me that the term might now be archaic, since 'core' hasn't been used in quite a long time. if so, i guess 'memory dump' would be the term? -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri May 15 13:38:10 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982011A8A5E for ; Fri, 15 May 2015 13:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78T0bZByHc9e for ; Fri, 15 May 2015 13:38:05 -0700 (PDT) Received: from pop3.winserver.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0B41A88CE for ; Fri, 15 May 2015 13:37:25 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1181; t=1431722236; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=BKBP+EnB57sIiu66GFz+34rMgDU=; b=oBLF/Y8YCDNSFQRY+PFZ TSNrlTvSNCtIKIRk1gTkLUaX22yOcurcHDeCVBdX0OhgCHITQ74T9vO8FZjlE8B5 tsaN+c9rTPB9Fh7Xr2ZFwN0K3r28H6hrm0WLn7DQ9KBUaqjesN/XlC8fWLbnJm3X biwTGKjs6XS9a6JdiYe6UFk= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 15 May 2015 16:37:16 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1137252993.1.760; Fri, 15 May 2015 16:37:15 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1181; t=1431721951; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=2paBRGi bl15+5dnoRl60BVSKRIrUJVXHWVosXJa43vs=; b=TazeWjEwKtKQxlXtj/6CeXE 38iFqI+e4S80C9pJfeNWldlnIuw4LmvcNBGC4c63FhVDOpS12DaGZMeuZ6RIzjPQ S/bElNvYsnmzw9ClgXg/yVsctqhMFuH7bPiSFB9WGhIg7xT1ldq3MCS14jpEs2Ox iP25/+jWwro7sNV9wwMQ= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 15 May 2015 16:32:31 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4024487145.9.17220; Fri, 15 May 2015 16:32:30 -0400 Message-ID: <55565900.5090704@isdg.net> Date: Fri, 15 May 2015 16:37:20 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dmarc@ietf.org References: <554BC30F.1020107@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> <14447.1431266709@vindemiatrix.encs.concordia.ca> <554FEBB4.5050805@gmail.com> <5550FB6C.7050802@gmail.com> <55518F96.8040708@isdg.net> <55529DFB.3010704@gmail.com> <87a8x92q7g.fsf@uwakimon.sk.tsukuba.ac.jp> <5553C44C.7040307@gmail.com> <87vbfv2480.fsf@uwakimon.sk.tsukuba.ac.jp> <87mw171trj.fsf@uwakimon.sk.tsukuba.ac.jp> <55552A6C.5060101@gmail.com> <55561623.8010209@dcrocker.net> In-Reply-To: <55561623.8010209@dcrocker.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Sender: vs. From: (was Re: Simple authorization offers reasonable control over messaging resources) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 20:38:07 -0000 On 5/15/2015 11:52 AM, Dave Crocker wrote: > > But it is not an operationally practical choice. The problem is that > when that identifier is different from the content identifier, we have > the task of figuring out whether the identity in the Sender: field is > 'authorized' to operate on behalf of the identity in the From: field.[*] and one way to get that authorization bit is to hash bind the 5322.Sender: > [*] In case folk miss the point, the Sender identifier is /always/ > present, even when the Sender: field is not. If this isn't clear to > anyone, I encourage re-reading Section 3.4.2 of RFC 5322. There are defaults and overrides. RFC4407 "Purported Responsible Address (PRA)" has done some project research work in this area: https://tools.ietf.org/html/rfc4407 Abstract This document defines an algorithm by which, given an e-mail message, one can extract the identity of the party that appears to have most proximately caused that message to be delivered. This identity is called the Purported Responsible Address (PRA). and the steps to get the PRA is outlined: https://tools.ietf.org/html/rfc4407#section-2 -- HLS From nobody Fri May 15 15:42:10 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984FB1A8034 for ; Fri, 15 May 2015 15:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJVW1vvYZjTs for ; Fri, 15 May 2015 15:42:06 -0700 (PDT) Received: from dkim.winserver.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id AE3541A89E9 for ; Fri, 15 May 2015 15:42:06 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3181; t=1431729716; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=WjrT5aW87bkQ/8Hr5bvRfyYRCX4=; b=QoFa7CFLjL7pwKqISCvU yoX4ozbVNv9qlEG0js/osRXSbBwfEx8P8oDXDRsFa1CNH4yBGtgJm39qgWoCmXOC OemTM53o3iCebU/O91LUss0qmU4cMUIdUc2YamevrF/Csm3BI3erz/QwislCaVRM /lWSfkpzWEXuxWOVURMMakA= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 15 May 2015 18:41:56 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1144733132.1.5844; Fri, 15 May 2015 18:41:55 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3181; t=1431729427; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=4OJB85m wDSt56wjQIBazvWUIgZmLAqhlNcBXFXxlIvo=; b=BzU1qUVm649qRs8Y50ANoKL qwmXa00PiQD3YKCXCz8C9fQD2P3x5CbtTkrC7zYAWHEOaaT0Eu9V0k6Z3ymFRGg+ OpTk3FmVv1G9DZZmJPAq6xYSG0d2mD86XG7GT3YyztHeYgbh0DrwI4/CIZpDrRuA qCfpvLgb6sxEwU0Z6rVU= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 15 May 2015 18:37:07 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4031963598.9.17908; Fri, 15 May 2015 18:37:07 -0400 Message-ID: <55567634.1060305@isdg.net> Date: Fri, 15 May 2015 18:41:56 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dmarc@ietf.org References: <555656FC.5010609@dcrocker.net> In-Reply-To: <555656FC.5010609@dcrocker.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 22:42:09 -0000 Dave, You should give DMARC+ATPSrev4 a shot. It works great. No change to any DKIM engine is required as the ATPS-RFC6541 version requires. It was relatively simple to migrate from ADSP+ATPSrev4 to DMARC+ATPSrev4. Take the same existing code and swap with it with DMARC. We need to keep in mind that ADSP was made historic and replaced with DMARC referenced as the "Super ADSP" version. So it should of been documented with migration and implementation semantics. There are still ADSP processors and there are still ADSP published domains, for example, paypal.com. But I don't wish to make two calls. ADSP needs to be deprecated if we are going to use DMARC. Since DMARC is selected to replaced ADSP, we should make ATPSrev4 piggy back off DMARC now. Once the mechanics are in place, then we can adequately begin to explore the adoption and its barriers. I believe we will see either a short or even long term migration/adoption as it was with SPF. Not everyone could use SPF in the same way not all domain will be able to use DMARC and/or ATPSrev4. Thanks -- HLS On 5/15/2015 4:28 PM, Dave Crocker wrote: > G'day. > > In looking for ways to make a DMARC-style function succeed when the > message transits an intermediary, the current approach has mostly been > proposing one or another wholesale solution. This creates a complex > space for discussion and tends towards some version of deadly embrace. > > It might be helpful to consider /basic types/ of changes that are > reasonable/unreasonable for intermediaries, distinct from how they might > fit into an entire solution. > > Reasonable vs. unreasonable pertain to at least two axes: > > 1. Amount of work > > 2. Policy/Principle > > Some choices entail too much work or run afoul of basic operational > policies. Others might entail some work, but not too much, and might > not be considered as significant violations of established policies. > > Here be dragons, of course, but let's try to have the discussion anyhow. > > Obviously, there will not be unanimity among all intermediaries, for any > proposal. So the question really is about plausible rough consensus > among a 'substantial' amount of the community. > > The first question is: what are the 'types' of changes that have been > or might be proposed? This should turn into some sort of taxonomy, > eventually, but for now an undisciplined core dump(*) of choices would > be best. > > Examples: > > Modifying the rfc5322.From display-name > > Modifying the rfc5322.From address > > Modifying the footer of the message body (first body-part.) > > Modifying the rfc5322.Subject preface > > Performing DMARC validation upon receipt > > Performing DKIM/SPF validation upon receipt > > DKIM-signing all outbound mail. > > Registering the intermediary with all potential sites posting to it > > Registering the intermediary with all potential sites receiving from > it > > > > Your turn... > > > > d/ > > > (*) it occurs to me that the term might now be archaic, since 'core' > hasn't been used in quite a long time. if so, i guess 'memory dump' > would be the term? > From nobody Fri May 15 17:09:57 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14371A9131 for ; Fri, 15 May 2015 17:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nv9uilQnopS5 for ; Fri, 15 May 2015 17:09:52 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (mail-sn2ln0088.outbound.o365filtering.com [IPv6:2a01:111:f400:7c04::88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C19E1A9121 for ; Fri, 15 May 2015 17:09:51 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) with Microsoft SMTP Server (TLS) id 15.1.172.7; Sat, 16 May 2015 00:09:31 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.5.234]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.5.234]) with mapi id 15.01.0172.012; Sat, 16 May 2015 00:09:30 +0000 From: Terry Zink To: Hector Santos , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy Thread-Index: AQHQj2BkgrGT+FsrXEG4ccrPqZVG+519uTIQ Date: Sat, 16 May 2015 00:09:29 +0000 Message-ID: References: <555656FC.5010609@dcrocker.net> <55567634.1060305@isdg.net> In-Reply-To: <55567634.1060305@isdg.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.159.79] x-microsoft-exchange-diagnostics: 1; BL2SR01MB605; 3:re3utt4euAFAba7liKTrqxrwrgCNnzZUp5UZLYNbGRRnDMmoK2OSe/zhJRTtEsYoVRaxYEGDgoVYvOosBDIpVCKl+PvofRTyICdXsIubuahePUPt+R9M3j8XmPPBL3asAF30fpmgbQCWL6Pe4xCKoA==; 10:fo95FzsU+BjehZUXbIA9DONBBlbVg8r2T0fEeKPPMVFdUYZIZ17c71O2S+ei6R0rNb6ZBfa45QNYsqw32nFBFuL0uZzRJ9kRxQ470SnWpQk=; 6:RWmfZMpXMzGlPobFD92xS6AIJBRsTaMRJVc+v5sCJzTJaXlF72YhQyG7daRrtKuv x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB605; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(199003)(51704005)(24454002)(377454003)(13464003)(189002)(479174004)(105586002)(106356001)(106116001)(54356999)(50986999)(76176999)(189998001)(68736005)(86362001)(102836002)(15975445007)(2501003)(2656002)(77156002)(62966003)(19580395003)(19580405001)(87936001)(101416001)(33656002)(561944003)(66066001)(46102003)(64706001)(97736004)(92566002)(4001540100001)(5001770100001)(2900100001)(2950100001)(81156007)(107886002)(5001830100001)(5001860100001)(5001960100002)(48203002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB605; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005002)(5002009)(3002001); SRVR:BL2SR01MB605; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB605; x-forefront-prvs: 057859F9C5 received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 May 2015 00:09:29.2524 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB605 Archived-At: Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 00:09:55 -0000 Hector, > You should give DMARC+ATPSrev4 a shot. It works great. My perception of your +1 to your solution is this: "I run my own mail serve= r and moderate my own DNS zone. I have a couple of users on my domain. Ever= ything works so easy." Yet you then admit: > not all domains will be able to use DMARC and/or ATPSrev4. The "not all domains" who won't use this will be large senders and receiver= s who account for the majority of phishing targets and email receivers. And= if you haven't solved it for the majority of phishing targets and potentia= l victims, how can you call this a solution? At best, it's having done some= thing interesting and a self-pat-on-the-back, but most of the problem is no= t solved. And if most of the problem is not solved nor will be, why pursue = it? How do you get around this? Who do you expect to implement it? -- Terry -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Hector Santos Sent: Friday, May 15, 2015 3:42 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediarie= s - Effort and Policy Dave, You should give DMARC+ATPSrev4 a shot. It works great. No change to=20 any DKIM engine is required as the ATPS-RFC6541 version requires. It=20 was relatively simple to migrate from ADSP+ATPSrev4 to DMARC+ATPSrev4.=20 Take the same existing code and swap with it with DMARC. We need to=20 keep in mind that ADSP was made historic and replaced with DMARC=20 referenced as the "Super ADSP" version. So it should of been=20 documented with migration and implementation semantics. There are=20 still ADSP processors and there are still ADSP published domains, for=20 example, paypal.com. But I don't wish to make two calls. ADSP needs=20 to be deprecated if we are going to use DMARC. Since DMARC is selected=20 to replaced ADSP, we should make ATPSrev4 piggy back off DMARC now. Once the mechanics are in place, then we can adequately begin to=20 explore the adoption and its barriers. I believe we will see either a short or even long term=20 migration/adoption as it was with SPF. Not everyone could use SPF in=20 the same way not all domain will be able to use DMARC and/or ATPSrev4. Thanks --=20 HLS On 5/15/2015 4:28 PM, Dave Crocker wrote: > G'day. > > In looking for ways to make a DMARC-style function succeed when the > message transits an intermediary, the current approach has mostly been > proposing one or another wholesale solution. This creates a complex > space for discussion and tends towards some version of deadly embrace. > > It might be helpful to consider /basic types/ of changes that are > reasonable/unreasonable for intermediaries, distinct from how they might > fit into an entire solution. > > Reasonable vs. unreasonable pertain to at least two axes: > > 1. Amount of work > > 2. Policy/Principle > > Some choices entail too much work or run afoul of basic operational > policies. Others might entail some work, but not too much, and might > not be considered as significant violations of established policies. > > Here be dragons, of course, but let's try to have the discussion anyhow. > > Obviously, there will not be unanimity among all intermediaries, for any > proposal. So the question really is about plausible rough consensus > among a 'substantial' amount of the community. > > The first question is: what are the 'types' of changes that have been > or might be proposed? This should turn into some sort of taxonomy, > eventually, but for now an undisciplined core dump(*) of choices would > be best. > > Examples: > > Modifying the rfc5322.From display-name > > Modifying the rfc5322.From address > > Modifying the footer of the message body (first body-part.) > > Modifying the rfc5322.Subject preface > > Performing DMARC validation upon receipt > > Performing DKIM/SPF validation upon receipt > > DKIM-signing all outbound mail. > > Registering the intermediary with all potential sites posting to it > > Registering the intermediary with all potential sites receiving from > it > > > > Your turn... > > > > d/ > > > (*) it occurs to me that the term might now be archaic, since 'core' > hasn't been used in quite a long time. if so, i guess 'memory dump' > would be the term? > _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Fri May 15 17:20:51 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA741A8763 for ; Fri, 15 May 2015 17:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0f3uI6J9EVyk for ; Fri, 15 May 2015 17:20:47 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D59CE1A9234 for ; Fri, 15 May 2015 17:20:46 -0700 (PDT) Received: by pacwv17 with SMTP id wv17so36618847pac.2 for ; Fri, 15 May 2015 17:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=4ing2xSW4GKiM+PImlZFCr/+Mt9Nis4Lhrj4Rf3WX3o=; b=YFWXjJ8iC90GY0Ga8N7ClTFHj3gl9w9k7u0RVyYpQM3AdYiWBvKUB4Mwa8vFCzRvBu 4UsQ20ursCWWiJY6VhaYW/2SpbGZJvkEMCnzqfPrV7JTmksuj0gcZHtOdY4KgTECFhDc jGs/FGRzM+YA9F53nPaSBktLO72y9ycswsG/FH1c66vSXnjjfgVRm2dur5PZzDFLO8Df fvqB+8eSliS/kd/+dRuOd6+MdXzppFrIBk7Rv7fvkfqG6k03UYYLVeY724NjHGvfR/Tg If2Gp/pFGN0DBnBIcu8jJGsCOrJC0Q3KRxR51HU1bOm+u7LBwJORdeZNIbdpa5/QWc7x YHaQ== X-Received: by 10.70.37.225 with SMTP id b1mr20815615pdk.35.1431735646489; Fri, 15 May 2015 17:20:46 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id pw9sm2982306pac.27.2015.05.15.17.20.40 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 May 2015 17:20:42 -0700 (PDT) Message-ID: <55568D55.2090603@gmail.com> Date: Fri, 15 May 2015 17:20:37 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <554BC30F.1020107@isdg.net> <27522.1431236028@vindemiatrix.encs.concordia.ca> <14447.1431266709@vindemiatrix.encs.concordia.ca> <554FEBB4.5050805@gmail.com> <5550FB6C.7050802@gmail.com> <55518F96.8040708@isdg.net> <55529DFB.3010704@gmail.com> <87a8x92q7g.fsf@uwakimon.sk.tsukuba.ac.jp> <5553C44C.7040307@gmail.com> <87vbfv2480.fsf@uwakimon.sk.tsukuba.ac.jp> <87mw171trj.fsf@uwakimon.sk.tsukuba.ac.jp> <55552A6C.5060101@gmail.com> <55561623.8010209@dcrocker.net> In-Reply-To: <55561623.8010209@dcrocker.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Sender: vs. From: (was Re: Simple authorization offers reasonable control over messaging resources) X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 00:20:50 -0000 On 5/15/15 8:52 AM, Dave Crocker wrote: > On 5/14/2015 11:27 PM, Terry Zink wrote: >>> The Sender header field when present has been defined for decades >>> to represent the sending agent! >> Maybe, maybe not. > > Sorry, but there isn't much maybe about it. > > The definition in the spec has been clear since the construct was > invented, in 1977. > > /Usage/ has varied quite a bit, as with so much of email, with > implementations re-purposing the field in various ways, thereby > effectively defeating useful interoperability. > > And 'display' of the field is an entirely separate issue. Commentary > about DMARC usually does cite 'display' as the essential requirement, > which drives selection of the From field. > > IMO it continues to be a significantly misleading point, since end-user > viewing of the From field is largely irrelevant to any real-world > efficacy. This appears to be an indelicate point to raise, since it's > being consistently ignored as discussions about DMARC continue > (everywhere, not just here.) > > On the other hand, the rfc5322.From field is the only field with a > content-related identifier that is /always/ present. > > Hence, a receiving filtering engine has a place that it always can > always look, for a claim of authorship. By its nature, a mechanism like > DMARC must begin with an identifier selected by the receiving filtering > engine. Hence, there must (always) be an identifier reliably associated > with the message. Its semantics must pertain to something semantically > interesting. DMARC chose "content authorship", which is pretty > obviously reasonable. > > With that claimed content responsibility, the engine can proceed with an > analysis that relates the identifier to a reputation. One aspect of > reputation is "is the identifier authorized for use?" DMARC answers > that question. > > One could imagine a "handling responsibility" as being a reasonable > alternative choice, too, but it's much weaker. Worse, it invites a > problematic disconnect between content responsibility and handling > responsibility, which thereby invites gaming the system. > > Choosing content responsibility is therefore much more appealing, albeit > simplistic in a way that causes problems with the entirely legitimate > scenarios that the community has been seeing. In particular, DMARC > requires very tight coupling between content and handling > responsibility, which differs from many, long-standing, legitimate > scenarios. > > Choosing a properly-available Sender: field creates a much better > semantic, in terms of pointing to the responsible operational agent. > > But it is not an operationally practical choice. The problem is that > when that identifier is different from the content identifier, we have > the task of figuring out whether the identity in the Sender: field is > 'authorized' to operate on behalf of the identity in the From: field.[*] > > > d/ > > > [*] In case folk miss the point, the Sender identifier is /always/ > present, even when the Sender: field is not. If this isn't clear to > anyone, I encourage re-reading Section 3.4.2 of RFC 5322. Dear Dave, Also notice the attention to the Sender header field by section 7.1 of RFC5321 in the following statement: ,-- Efforts to make it more difficult for users to set envelope return path and header "From" fields to point to valid addresses other than their own are largely misguided: they frustrate legitimate applications in which mail is sent by one user on behalf of another, in which error (or normal) replies should be directed to a special address, or in which a single message is sent to multiple recipients on different hosts. (Systems that provide convenient ways for users to alter these header fields on a per-message basis should attempt to establish a primary and permanent mailbox address for the user so that Sender header fields within the message data can be generated sensibly.) '-- Operational practicality varies dramatically by domain based on the type of email handled. For transactional email, with some exceptions, policy based solely on the From can be operationally convenient. When handling a normal range of email configurations as typified for most ordinary users, restrictive policy based solely on the From header field domain will be highly disruptive of otherwise legitimate and properly formed messages often supporting important functions relied upon by a very large number of communities. Unfortunately, DMARC removed admonishments on limiting the types of email to be used by the domain asserting restrictive policies and simply notes in Section 10.5 incompatibilities when mediators such as mailing-lists are used. This appears to indicate DMARC proponents have entrenched into a view DMARC can force From header field munging and abandonment of RFC5322 defined roles and the functions defined by RFC5321, and submission practices defined by RFC4409. Rather than striking up the theme for Frozen, the theme for Jaws seems more appropriate as basic email specifications are crossed out in red. Without question, abuse monitoring represents a level of effort. Feedback provided by DMARC permits rapid and automatic identification of essential exceptions otherwise hidden without DMARC domain distribution of this information. Defending even simple url feed services that attract children as followers as well as various Ad feeds represent extremely difficult and serious challenges. A challenge greatly assisted by maintaining a type of informal federation. Larger providers are certainly less concerned about becoming blocked and may choose to ignore difficult aspects of their message distribution. Placing this effort onto recipients who lack necessary tools to rapidly identify abuse will cause a general erosion of security. It seems unimaginable recipients will disregard offers by the DMARC domain of authoritative threat related information. The authorization of those maintaining trusted resources provides an authoritative source of abuse related information approaching the level of a binary yes/no result. The DMARC domain remains the sole arbiter of reputation. Attempts to distribute this information within DKIM siglets by initial messages entails a similar data set but that can't be easily updated. Why not expand DMARC to include assertions of an offering of domain relationships within a single cache-able DNS transaction? Nothing else offers less overhead. Such a change can prevent the munging of From header fields or placement of otherwise valid and legitimate messages into spam folders. Of course, dmarc-wg can decide everyone wanting to use email must now use a new From header field designated specifically for that purpose to avoid the previously defined header field now laden with restrictive DMARC policies. https://tools.ietf.org/html/draft-otis-dmarc-escape-02 defines one such possibility. im-from = "IM-From:" (mailbox-list / address-list) CRLF address = mailbox / group group = display-name ":" [group-list] ";" [CFWS] mailbox = name-addr / addr-spec addr-spec = local-part "@" domain ["/" resourcepart] The resourcepart could be used to be compatible with XMPP. This element could be ignored when determining designated MTAs, but can isolate message sources to better identify the agent involved to better deal with any possible abuse. Regards, Douglas Otis From nobody Fri May 15 17:59:51 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E971ACAD4 for ; Fri, 15 May 2015 17:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.302 X-Spam-Level: X-Spam-Status: No, score=-99.302 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfMLbFUnKGDO for ; Fri, 15 May 2015 17:59:47 -0700 (PDT) Received: from mail.winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6568C1AC82C for ; Fri, 15 May 2015 17:59:47 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2782; t=1431737978; h=Received:Received: Message-Id:From:Subject:Date:To:Organization:List-ID; bh=74bocdI r6uxZXdbx5vX7WNlqWr4=; b=YcXBZuR8oitBtGqKj9bb17j1i/Mv3R1EshL3gmi oB4DgmnFG2k4QUUgkcXYg6eYHbSf0+GGyK2ZnCyWgXJrACSK007vgxjX0/NInmx9 4y5z4r2pXoSuCXMky/ks3nKmPXW2xjIjWJolaDCsmfk1ObhlkJm5O6steCDccYQv 69oY= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 15 May 2015 20:59:38 -0400 Received: from [192.168.1.67] (99-3-146-30.lightspeed.miamfl.sbcglobal.net [99.3.146.30]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1152995990.1.5480; Fri, 15 May 2015 20:59:38 -0400 References: <555656FC.5010609@dcrocker.net> <55567634.1060305@isdg.net> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <8A9DBFEF-2202-412C-B067-1B594DC4E05F@isdg.net> X-Mailer: iPad Mail (12B435) From: Hector Santos Date: Fri, 15 May 2015 20:59:40 -0400 To: Terry Zink Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 00:59:50 -0000 > On May 15, 2015, at 8:09 PM, Terry Zink wro= te: >=20 > Hector, >=20 >> You should give DMARC+ATPSrev4 a shot. It works great. >=20 > My perception of your +1 to your solution is this: "I run my own mail serv= er and moderate my own DNS zone. I have a couple of users on my domain. Ever= ything works so easy." I suppose you never heard of Wildcat!? While mail is only a small part of o= ur integrated hosting products, a huge investment was made to add DKIM+ADSP+= ATPSrev4 for our product line. ADSP was an IETF proposed standard.[*] It s= upports a several hundred customers in the field, including MLMs, ESPs, and n= o so much anymore ISPs. We abandoned our PPP server long ago, but there migh= t be a few still using our RADIUS server. Our WINServer.com is a support site for our customers. Yes, we all use the= same stuff. So whatever we do, they benefit. We have a AutoUpdate Plan (AU= P) that people paid monthly, quarterly and yearly. One AUP and customers in= stantly get updates. We have to make sure it works out of the box, especial= ly if new stuff is enabled. [*] DMARC is not a proposed standard. >=20 > Yet you then admit: >=20 >> not all domains will be able to use DMARC and/or ATPSrev4. >=20 > The "not all domains" who won't use this will be large senders and receive= rs who account for the majority of phishing targets and email receivers. And= if you haven't solved it for the majority of phishing targets and potential= victims, how can you call this a solution? At best, it's having done someth= ing interesting and a self-pat-on-the-back, but most of the problem is not s= olved. And if most of the problem is not solved nor will be, why pursue it? >=20 > How do you get around this? Who do you expect to implement it? As with most things, it's all optional and the reason why it's optional is b= ecause not all can use or benefit from the technology. There are plenty of I= ETF protocols that are not useful to all and rarely can't be enforced. It s= till applied and used by many anyway. The only problem here is a registration and I don't buy you say that it's pr= oblem for Microsoft.com or anyone else. This may not be understood but it d= oesn't say good things for the IETF if it says to the world -- don't bother w= ith future DNS applications any more. No one will publish records. =20 At the end of the day, there will be domains that won't be able to use the t= echnology and more than likely hotmail.com won't be able to get their SPF no= r their ATPSrev4 network in order. But Microsoft.com and millions of other d= omains can, and millions more won't need too. It's a feature, an option. -- Hector Santos http://www.santronics.com= From nobody Fri May 15 18:42:54 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80D71A9149 for ; Fri, 15 May 2015 18:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLgyPJmyrqcm for ; Fri, 15 May 2015 18:42:52 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 399B01A907A for ; Fri, 15 May 2015 18:42:52 -0700 (PDT) Received: by pdeq5 with SMTP id q5so37788944pde.1 for ; Fri, 15 May 2015 18:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=1NiJ6eIZsd5epU+G4MBXIlDpcgKsltMecpr/q7icHq0=; b=0qUuTOcTZs9QxFqFT1Wv7y3hS9aSSWHHcxw9tZE0ENKWVrnvRYj2rfS63vlEAim+HT fBX1behL5rqn8v/WnZA64gu5qTt7DqIXwuAe5s05yezX5NBc1x9laf8cUqwFCM9aNBHw 2mt3zNDer96U9dXO/dDsZvnWPxoVeATKSXMkbVjjMNXGoIBwEEQr76hd7TiTRfQtYRpo C/Y3TQGQl+2uQvqBYJ+SRokDkowD8N6d8NFxb2/AR/NqnkNK7CXCU+XOww1h3dQ6dRS+ T+fVFRHjPdkB80xUWEV9nu9/0UGc9G8h7fuHf+cqxfxxr0Wndp6KIx3slivCoLwIh3eD CveQ== X-Received: by 10.68.227.42 with SMTP id rx10mr23421556pbc.28.1431740571871; Fri, 15 May 2015 18:42:51 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id oj10sm3074495pdb.38.2015.05.15.18.42.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 May 2015 18:42:50 -0700 (PDT) Message-ID: <5556A096.6070709@gmail.com> Date: Fri, 15 May 2015 18:42:46 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <555656FC.5010609@dcrocker.net> <55567634.1060305@isdg.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 01:42:53 -0000 On 5/15/15 5:09 PM, Terry Zink wrote: > Hector, > >> You should give DMARC+ATPSrev4 a shot. It works great. > My perception of your +1 to your solution is this: "I run my own mail server and moderate my own DNS zone. I have a couple of users on my domain. Everything works so easy." > > Yet you then admit: > >> not all domains will be able to use DMARC and/or ATPSrev4. > The "not all domains" who won't use this will be large senders and receivers who account for the majority of phishing targets and email receivers. And if you haven't solved it for the majority of phishing targets and potential victims, how can you call this a solution? At best, it's having done something interesting and a self-pat-on-the-back, but most of the problem is not solved. And if most of the problem is not solved nor will be, why pursue it? > > How do you get around this? Who do you expect to implement it? Dear Terry, I can't speak for Hector nor would I include ATPS, but a very small group of us managed this type of feedback largely operated automatically to deal with mailing-lists, dial-ups, open-proxies, etc. Each category triggered different testing and investigative criteria. The collected dataset then applied against inbound email seen by about 70% of the entire world's email users. This service was initially free and pre-built into the various mail programs. This approach scales to very high levels while causing very low overhead. In contrast, SPF and reverse look ups represent orders of magnitude greater overhead. We handled various European schools such as Ja.net and even several of the largest ESPs, some of whom are participating on this list but may not be aware of our prior involvement. Beyond just DMARC feedback, protection will require feedback augmented with mail-traps that are separately available as a service. With DMARC forcing all messages to be authorized in some manner, the type of gaming that can be involved becomes much easier to exclude. There is no silver bullet, but once this type of feedback is instantiated, the abuse seen by recipients should be greatly reduced with far less ending up in spam folders. The best part is this can retain full SMTP compatibility. As some of the larger DMARC domains start offering third-party specific feedback, the value of such authoritative data will be high and should spur greater adoption. Regards, Douglas Otis From nobody Sat May 16 11:11:43 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE4E1A0019 for ; Sat, 16 May 2015 11:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.522 X-Spam-Level: *** X-Spam-Status: No, score=3.522 tagged_above=-999 required=5 tests=[BAYES_95=3, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdGG7J_bnPIA for ; Sat, 16 May 2015 11:11:40 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E50A1A0007 for ; Sat, 16 May 2015 11:11:40 -0700 (PDT) Received: by iesa3 with SMTP id a3so57106777ies.2 for ; Sat, 16 May 2015 11:11:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=LGqHzDXMaJH2Dn+wWgfL9nMKFHNbbkBMx532s4H0sSI=; b=BoXfos5JYOe4HeXMBTSwnDFZJfAV6L0Zj+dfkHH37mG4Ep6Yh3q08Cl6GiJx4/ACUB R76WVsDV5VEqqKcd7zIDu02ya09tlOsjvAnuFVF2PYYPI7EXKmbLllkgp2sNj0AjmfqE 4K1sf+QurxdFWAJWiHWWDxTrmJtYiNCtEoa84= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=LGqHzDXMaJH2Dn+wWgfL9nMKFHNbbkBMx532s4H0sSI=; b=Ym8rDSkClpyznLuVh0xpExFedh90dN301MV83z5emldX1dmvN5a5Q25iKdtg0J3sS/ TpsSdZqNGJ79FlLKx6I6C5nUNdwVqMjZ+y5E+dCwMY1qY9CpRxZ67PFStH7L68E897ya 4iOmELFmvyxWgighEscA3iIes6fivJZL5U0GB9Dcws2PuJQfsxJiTyuBgrJGz95Kvsuh cNAchoqBdkuiJ5PrcG93cyJSqqcKvIjOuR+4Dm2ZVXM8iPXxq33uAXgUpviOuM1W+mWe bQoq+Gih4K0ILtLlxJT4Z757GJjzjgzAqumI+2BRwg08Waf5D8/ejMi+yXCURYK7zBLp WFzQ== X-Gm-Message-State: ALoCoQmvVAC71OcIjKLXJYDx0bCfEp9ElUNY487EH0JO5jGkxy6vBqRPSTiC2BnZ5fNdJ+C93Veu MIME-Version: 1.0 X-Received: by 10.107.8.144 with SMTP id h16mr20933379ioi.38.1431799899828; Sat, 16 May 2015 11:11:39 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.36.3.148 with HTTP; Sat, 16 May 2015 11:11:39 -0700 (PDT) In-Reply-To: <8A9DBFEF-2202-412C-B067-1B594DC4E05F@isdg.net> References: <555656FC.5010609@dcrocker.net> <55567634.1060305@isdg.net> <8A9DBFEF-2202-412C-B067-1B594DC4E05F@isdg.net> Date: Sat, 16 May 2015 08:11:39 -1000 X-Google-Sender-Auth: OoPr8WQPPgUcWyHcpgs_KprRxmQ Message-ID: From: "Kurt Andersen (b)" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a113f91566b4ab0051636e40f Archived-At: Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 18:11:42 -0000 --001a113f91566b4ab0051636e40f Content-Type: text/plain; charset=UTF-8 On May 15, 2015 2:59 PM, "Hector Santos" wrote: > > > On May 15, 2015, at 8:09 PM, Terry Zink > wrote: > > > With all due respect to the amazing abilities of this list to bikeshed, could we try to return this particular thread to the question(s) raised by Dave? To wit: It might be helpful to consider /basic types/ of changes that are > reasonable/unreasonable for intermediaries, distinct from how they might > fit into an entire solution. > --Kurt Andersen --001a113f91566b4ab0051636e40f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On May 15, 2015 2:59 PM, "= Hector Santos" <hsantos@isdg.net> wrote:

> On May 15, 2015, at 8:09 PM, Terry Zink <tzink@exchange.microsoft.com>= ; wrote:
>

With all due respect to the amazin= g abilities of this list to bikeshed, could we try to return this particula= r thread to the question(s) raised by Dave? To wit:

It might be helpful to consider /basic ty= pes/ of changes that are reasonable/unreasonable for intermediaries, distin= ct from how they might fit into an entire solution.
<= br>
--Kurt Andersen
--001a113f91566b4ab0051636e40f-- From nobody Sat May 16 12:05:29 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08E51A1A4D for ; Sat, 16 May 2015 12:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.302 X-Spam-Level: X-Spam-Status: No, score=-99.302 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDSlzOuwiOfN for ; Sat, 16 May 2015 12:05:26 -0700 (PDT) Received: from listserv.winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B81C51A1A32 for ; Sat, 16 May 2015 12:05:25 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3425; t=1431803117; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=ufgBWl2sdkAD0Yvt68Z2kZxQ37M=; b=lok1nvOPwkNFkiIKqM4g QcTIsXx7gHqPuOjJajr54sbAtztDEATybmhRjiFe2HDOnGkYPT2lMSOSiskpH8OQ gIZKJJHK8tau0bfDzUN356edpZ+OACTUkhJ8K/dEgJrXiWVjR3O7cC0gcWT3GNpJ nFAglDXXHO3XRnfQ/tJYo9w= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 16 May 2015 15:05:17 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1218133958.1982.3068; Sat, 16 May 2015 15:05:17 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3425; t=1431802828; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=yqUP+QJ 8AswVEBanMCOf3Ajrokfs4tX87/Ia+MS8HDM=; b=gxzLHd4/XE4OYKese98Y+Zo DvBlwKRactg5vD20vJUxfEt3Ye/SkvOyhwh/ec1SrnzZ4YD87tt5Nci1DOV9V/CK q3dyDwjiJF2BQGQtuwnc/6W2jSDkZPvJLWlwJPO1unwHVcIkxr+thIKusM2Qm/uq ydkzpNcW5vvniiFK9v6Y= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 16 May 2015 15:00:28 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4105364129.9.17916; Sat, 16 May 2015 15:00:27 -0400 Message-ID: <555794F0.4020600@isdg.net> Date: Sat, 16 May 2015 15:05:20 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dmarc@ietf.org References: <555656FC.5010609@dcrocker.net> In-Reply-To: <555656FC.5010609@dcrocker.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 19:05:28 -0000 Dave, In the 2006 DSAP I-D, I wrote down and implemented what I felt were reasonable integration changes for our list server package (MLS): https://tools.ietf.org/html/draft-santos-dkim-dsap-00#section-3.3 3.3. Mailing List Servers Mailing List Servers (MLS) applications who are compliant with DKIM and DSAP operations, SHOULD adhere to the following guidelines: Subscription Controls MLS subscription processes should perform a DSAP check to determine if a subscribing email domain DSAP policy is restrictive in regards to mail integrity changes or 3rd party signatures. The MLS SHOULD only allow original domain policies who allow 3rd party signatures. Message Content Integrity Change List Servers which will alter the message content SHOULD only do so for original domains with optional DKIM signing practices and it should remove the original signature if present. If the List Server is not going to alter the message, it SHOULD NOT remove the signature, if present. When it, DKIM+ADSP+ATPSrev4, was finally implemented, very little change was done to the MLS itself as long as its entry points did all the ADSP (and now DMARC) checking. It really hasn't deviated other than we are replacing ADSP with DMARC, with the same issues, same needs, long worked out. -- HLS On 5/15/2015 4:28 PM, Dave Crocker wrote: > G'day. > > In looking for ways to make a DMARC-style function succeed when the > message transits an intermediary, the current approach has mostly been > proposing one or another wholesale solution. This creates a complex > space for discussion and tends towards some version of deadly embrace. > > It might be helpful to consider /basic types/ of changes that are > reasonable/unreasonable for intermediaries, distinct from how they might > fit into an entire solution. > > Reasonable vs. unreasonable pertain to at least two axes: > > 1. Amount of work > > 2. Policy/Principle > > Some choices entail too much work or run afoul of basic operational > policies. Others might entail some work, but not too much, and might > not be considered as significant violations of established policies. > > Here be dragons, of course, but let's try to have the discussion anyhow. > > Obviously, there will not be unanimity among all intermediaries, for any > proposal. So the question really is about plausible rough consensus > among a 'substantial' amount of the community. > > The first question is: what are the 'types' of changes that have been > or might be proposed? This should turn into some sort of taxonomy, > eventually, but for now an undisciplined core dump(*) of choices would > be best. > > Examples: > > Modifying the rfc5322.From display-name > > Modifying the rfc5322.From address > > Modifying the footer of the message body (first body-part.) > > Modifying the rfc5322.Subject preface > > Performing DMARC validation upon receipt > > Performing DKIM/SPF validation upon receipt > > DKIM-signing all outbound mail. > > Registering the intermediary with all potential sites posting to it > > Registering the intermediary with all potential sites receiving from > it > > > > Your turn... > > > > d/ > > > (*) it occurs to me that the term might now be archaic, since 'core' > hasn't been used in quite a long time. if so, i guess 'memory dump' > would be the term? > From nobody Sat May 16 14:17:00 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7587B1A1AC1 for ; Sat, 16 May 2015 14:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Z6n1vhBcjCT for ; Sat, 16 May 2015 14:16:57 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 514141A1AAA for ; Sat, 16 May 2015 14:16:57 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 4D156C401B4 for ; Sat, 16 May 2015 16:16:56 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1431811016; bh=lyhVvDxgcwcgPf3dRyZbV+yhUBhcox8OsJyjZbjI5No=; h=From:To:Subject:Date:In-Reply-To:References:From; b=WHiAb3davKh+OVM72WS+RCKYujhPcpNmURBoM7zT4y+pG98yokR7yxqJObCI6ejzN YvA5pgViGlY6xWdc+yAZ4LAY0Rw9jDyjjqFRxuVPf5X0+fUyrWTGqZFrhg8n2HKA+Z CSC6omlcmiKLcVHC8c/g6d7vmxlYeab3P/n/Jmv0= From: Scott Kitterman To: dmarc@ietf.org Date: Sat, 16 May 2015 17:16:56 -0400 Message-ID: <10034618.CIMjht0PXi@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-51-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <555656FC.5010609@dcrocker.net> References: <555656FC.5010609@dcrocker.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2015 21:16:58 -0000 On Friday, May 15, 2015 01:28:44 PM Dave Crocker wrote: > G'day. > > In looking for ways to make a DMARC-style function succeed when the > message transits an intermediary, the current approach has mostly been > proposing one or another wholesale solution. This creates a complex > space for discussion and tends towards some version of deadly embrace. > > It might be helpful to consider /basic types/ of changes that are > reasonable/unreasonable for intermediaries, distinct from how they might > fit into an entire solution. > > Reasonable vs. unreasonable pertain to at least two axes: > > 1. Amount of work > > 2. Policy/Principle > > Some choices entail too much work or run afoul of basic operational > policies. Others might entail some work, but not too much, and might > not be considered as significant violations of established policies. > > Here be dragons, of course, but let's try to have the discussion anyhow. > > Obviously, there will not be unanimity among all intermediaries, for any > proposal. So the question really is about plausible rough consensus > among a 'substantial' amount of the community. > > The first question is: what are the 'types' of changes that have been > or might be proposed? This should turn into some sort of taxonomy, > eventually, but for now an undisciplined core dump(*) of choices would > be best. > > Examples: > > Modifying the rfc5322.From display-name > > Modifying the rfc5322.From address > > Modifying the footer of the message body (first body-part.) > > Modifying the rfc5322.Subject preface > > Performing DMARC validation upon receipt > > Performing DKIM/SPF validation upon receipt > > DKIM-signing all outbound mail. > > Registering the intermediary with all potential sites posting to it > > Registering the intermediary with all potential sites receiving from > it > > > > Your turn... Performing prosepective DMARC validation on receipt to determine if mail would be subject to p=reject processing on the distant end if reransmited. Scott K From nobody Sun May 17 09:56:02 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666341A0130 for ; Sun, 17 May 2015 09:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.702 X-Spam-Level: X-Spam-Status: No, score=-98.702 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iJ59wTSoTDP for ; Sun, 17 May 2015 09:55:59 -0700 (PDT) Received: from mail.winserver.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 280D31A0233 for ; Sun, 17 May 2015 09:55:58 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=879; t=1431881750; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=MdAo74QYZkHE/p3DR65FZtOQwWE=; b=hi8lLzuwhoM96tY1y+Gk S4iQgK0Xd4OsyyDCvseuXLIflX04moN9wLq++nQhSE6lEBPU+ttlJCQQ0kkrAiwz bUSCgMTw0l9fv8x7xMiCjmH2pZjq/peEAYK5NcJyPRrNBNDp5RTNoZ6JbKX7LFRZ AQmh3/8hRqWyvJHGbnpJdCg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 17 May 2015 12:55:50 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1296765045.4424.3872; Sun, 17 May 2015 12:55:49 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=879; t=1431881461; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=82CsAfV 1JLtOHJS9LeZxe4DbQB6L9/wxkfaDdfo9qA8=; b=mQTSS3bHqFB2Ya+96PFDRaB XBgkSo2dQD8BiE+KhXZ5Tvh8xg4s9B9Js/Za3XhmuI7r5tU053g29bLcamRoAOyX lqtmRDA2lIiTZ0yzSe5Px583J6uLW6p+E8YourpZk5UZrh8dYfq2+CLtqxVmOPQg nb21GNUKRE+XzjYvrc8M= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 17 May 2015 12:51:01 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4183997379.9.18568; Sun, 17 May 2015 12:51:00 -0400 Message-ID: <5558C812.1060409@isdg.net> Date: Sun, 17 May 2015 12:55:46 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Scott Kitterman References: <555656FC.5010609@dcrocker.net> <10034618.CIMjht0PXi@kitterma-e6430> In-Reply-To: <10034618.CIMjht0PXi@kitterma-e6430> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 16:56:01 -0000 On 5/16/2015 5:16 PM, Scott Kitterman wrote: > > Performing prosepective DMARC validation on receipt to determine if mail would > be subject to p=reject processing on the distant end if reransmited. > Right, controlling the entry points and that can include the subscription process. Take a look at this subscription site for an example of how it works. I just updated it for DMARC. Try to subscribe using a restrictive domain, like a yahoo.com account: http://www.winserver.com/public/code/html-subscribe?list=list-dkim Note: This is just controlling the manual subscription process. Lets keep in mind that you can distribute to restrictive domains, its the submission that is mostly problematic so there are many implementation notes that can be created. For example, that the MLM can automatically make the subscriber a Read Only Member. -- HLS From nobody Sun May 17 11:29:32 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F265F1A0022 for ; Sun, 17 May 2015 11:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.837 X-Spam-Level: X-Spam-Status: No, score=-97.837 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zvnDtKiDF99 for ; Sun, 17 May 2015 11:29:29 -0700 (PDT) Received: from ntbbs.santronics.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id DD0A51A0021 for ; Sun, 17 May 2015 11:29:28 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1521; t=1431887364; atps=isdg.net; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=on9gKHH2U/DkTBE0JxKBlZXJkMI=; b=SdvOmLRx2BrqBQbf7iUBSS/FhOFTW87axdqdDkVH0/3By3yfL0N/6OwAjbNV+B S4M3RWSK7kZmA5m66FzGshY+aKAQRxVkzDUzdI0UPMzMAfOBv+6w7p+xpDhk1t+0 bQcwo8mJqj1MgClXPW0GAxIuTxHyFl10f6CEGPm1uJ4ZM= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 17 May 2015 14:29:24 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1302380176.4424.3152; Sun, 17 May 2015 14:29:24 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1521; t=1431887075; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=9+G9zMP 04hWQPwwObFXiDaEwZwwRsgWxonsNETfdocU=; b=YWq3W7JCe5xL+C/j0SxduT4 cqH20kp7j/edavRboM8pvGZIZ2w66J3ZNnO0pAaMn0lumJnGPv4Y3kXuFGn9hnYP sgKsU81T5dxeorwwUsczarwQ1acRi8qMUNrR24OEftERDeUqILxJE+rMsFyGSn/x 1smSFUEXwtOuOYIzw5gg= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 17 May 2015 14:24:35 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4189611473.9.20440; Sun, 17 May 2015 14:24:35 -0400 Message-ID: <5558DE01.7090001@isdg.net> Date: Sun, 17 May 2015 14:29:21 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dmarc@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] ATPS-RFC6541Testing X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 18:29:31 -0000 Scanning and Reading DMARC reports, I see there are many reports from an "OpenDMARC Filter" which includes testing for "dkim-adsp" and "dkim-atps" protocols. An example Auth-Res: Authentication-Results: ****************.net; dkim=pass (1024-bit key; unprotected) header.d=ietf.org header.i=@ietf.org header.b=ftopcwZG; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=isdg.net header.i=@isdg.net header.b=hi8lLzuw; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=beta.winserver.com header.i=@beta.winserver.com header.b=mQTSS3bH; dkim-adsp=fail (unprotected policy); dkim-atps=neutral The dkim-atps result is neutral because RFC6541 requires two tags to be added to the DKIM-Signature in order to trigger the atps call: ' adps=author-domain; atpsh=sha1; Anticipating some future need to add "user tags" to the DKIM signing engine: # USER DEFINED TAGS: # # The UserTags are experimental. They are additonal signed "tag=value;" # information added to the signed signature. The tag MUST NOT conflict # with an DKIM standard tag. I was able to add the above user tags for outbound mail. In theory, those OpenDMARC Filter engines with DKIM-atps SHOULD find an atps record for the ietg.org 3rd party list resigner, which we have for our isdg.net zone file: pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT ( "v=atps01; d=ietf.org;" ) This is a test message to feed the OpenDmarc Filter Engines. -- HLS From nobody Sun May 17 11:49:04 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CABB21A8ABB for ; Sun, 17 May 2015 11:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.499 X-Spam-Level: **** X-Spam-Status: No, score=4.499 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzeo-K-1QGZS for ; Sun, 17 May 2015 11:49:01 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 278A81A8978 for ; Sun, 17 May 2015 11:49:00 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id BB9861C3885; Mon, 18 May 2015 03:48:58 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 8F2EC1A3398; Mon, 18 May 2015 03:48:58 +0900 (JST) From: "Stephen J. Turnbull" To: Scott Kitterman In-Reply-To: <10034618.CIMjht0PXi@kitterma-e6430> References: <555656FC.5010609@dcrocker.net> <10034618.CIMjht0PXi@kitterma-e6430> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Mon, 18 May 2015 03:48:58 +0900 Message-ID: <87wq07yr8l.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 18:49:02 -0000 Scott Kitterman writes: > Performing prosepective DMARC validation on receipt to determine if > mail would be subject to p=reject processing on the distant end if > reransmited. I assume you mean "... and prospectively reject"? (GNU Mailman at least already provides options to munge From or wrap the message, conditional on the result of such a test.) For completeness it should be listed, but practically speaking, for tens of thousands of lists it just ain't gonna happen, sorry. The Author Domains that *want* "POLICY" control already have a local policy in place prohibiting their users from posting to mailing lists and the like, and are a very small problem because indirect messages from them are very few. It's the p=reject abusers that are the problem, but *they* *want* mailing lists to distribute their users' posts, despite what "POLICY" advocates claim is implied by publishing p=reject. Those users *want* to post, and they blame the *list*, not their mailbox providers, if anything goes wrong or if their posts are treated differently from users at other providers. List owners by and large are not RFC zealots, quite the reverse, and quickly cave in to the importunate posters. Bottom line: The only people who want this policy are some of us in this working group. Nobody[1] actually involved does. Even my colleagues at GNU Mailman who are sympathetic to the idea of prospectively doing what the policy requests have found that in practice it's socially untenable on lists they administer. Footnotes: [1] Well, I do, but my lists are special cases. My public lists have less than 0.5% p=reject subscribers and less than 0.1% posts from them, so I can tell them where to go, and my university lists are covered by Japanese Ministry of Education policy deprecating use of Yahoo! mailboxes (without reference to p=reject and including domains that publish p=none!) From nobody Sun May 17 11:51:41 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DF71A01E2 for ; Sun, 17 May 2015 11:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.701 X-Spam-Level: X-Spam-Status: No, score=-98.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVmL7BUm8EKu for ; Sun, 17 May 2015 11:51:38 -0700 (PDT) Received: from ntbbs.santronics.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 754A41A01CB for ; Sun, 17 May 2015 11:51:38 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2698; t=1431888695; atps=isdg.net; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=lnVLFSwiQ4ingkWF9RJD9zZTZw0=; b=k3uvxG5Zel+6QTuDAJu8qS7dkYw05LGMaG010Ef+AkkAx7s14h2+OFriImsLs3 qCwcvPUbwMloNHuDuwyv+Bs1fcTqCtaDp1HnCQrQeDutI9tSgI3su7OaGuRKS+3f bzdZA1KU2qh3AcCwcW30J6wNF3nTik8VUePyUkpl2Lx5k= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 17 May 2015 14:51:35 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1303710241.4424.1368; Sun, 17 May 2015 14:51:34 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2698; t=1431888405; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=tqGci0N bAMZSFlB+Jr2R3HDxUp/l7YauMtB0L6I7i+A=; b=jYTEya5PSiMrJEWLts/PmQA 1cQtdOCq7hZsMQ5Dd11Ow1gaqJs6QZjNlbNkgtjq8v33a37Gv0J5Ts5l9yEk5LV9 D7bMjt1OtVJI67gKEES4+ewsDIybIDpnBEqLf16PRRwUYk70Jth6yG0iOOyaOYoF BWSoO/YDUr3km7/yglTw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 17 May 2015 14:46:45 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4190940332.9.20036; Sun, 17 May 2015 14:46:43 -0400 Message-ID: <5558E332.5080309@isdg.net> Date: Sun, 17 May 2015 14:51:30 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dmarc@ietf.org References: <5558DE01.7090001@isdg.net> In-Reply-To: <5558DE01.7090001@isdg.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] ATPS-RFC6541Testing X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 18:51:39 -0000 On 5/17/2015 2:29 PM, Hector Santos wrote: > Scanning and Reading DMARC reports, I see there are many reports from > an "OpenDMARC Filter" which includes testing for "dkim-adsp" and > "dkim-atps" protocols. An example Auth-Res: > > Authentication-Results: ****************.net; > dkim=pass (1024-bit key; unprotected) header.d=ietf.org > header.i=@ietf.org header.b=ftopcwZG; > dkim=fail reason="signature verification failed" (1024-bit key; > unprotected) header.d=isdg.net > header.i=@isdg.net header.b=hi8lLzuw; > dkim=fail reason="signature verification failed" (1024-bit key; > unprotected) > header.d=beta.winserver.com header.i=@beta.winserver.com > header.b=mQTSS3bH; > dkim-adsp=fail (unprotected policy); dkim-atps=neutral > > The dkim-atps result is neutral because RFC6541 requires two tags to > be added to the DKIM-Signature in order to trigger the atps call: > ' > adps=author-domain; atpsh=sha1; > > Anticipating some future need to add "user tags" to the DKIM signing > engine: > > # USER DEFINED TAGS: > # > # The UserTags are experimental. They are additonal signed "tag=value;" > # information added to the signed signature. The tag MUST NOT conflict > # with an DKIM standard tag. > > I was able to add the above user tags for outbound mail. In theory, > those OpenDMARC Filter engines with DKIM-atps SHOULD find an atps > record for the ietg.org 3rd party list resigner, which we have for our > isdg.net zone file: > > pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT ( "v=atps01; d=ietf.org;" ) > > This is a test message to feed the OpenDmarc Filter Engines. > Got the report results from one and it still shows dkim-atps=neutral. Authentication-Results: jacobrideout.net; dkim=pass (1024-bit key; unprotected) header.d=ietf.org header.i=@ietf.org header.b=Cy3wnoYE; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=isdg.net header.i=@isdg.net header.b=SdvOmLRx; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=beta.winserver.com header.i=@beta.winserver.com header.b=YWq3W7JC; dkim-adsp=fail (unprotected policy); dkim-atps=neutral I can't tell why it would fail, but here's the problem with ATPS-RFC6541, the version as an DKIM signature tag extension. The failure of the DKIM-signature d=isdg.net which has the extra "atps=" and "atpsh=" tags causes the verifier to see the signature as invalid and ignored as if it never existed. So ATPS will not be activated because the resigner destroyed it. This is why ATPS-Rev04 which was a ADSP extension works because the "atps=" tags would be off the policy record instead. -- HLS From nobody Sun May 17 13:15:12 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8ED31ACD5E for ; Sun, 17 May 2015 13:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.898 X-Spam-Level: * X-Spam-Status: No, score=1.898 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzDBf7u0HCxy for ; Sun, 17 May 2015 13:15:08 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 696151ACD5A for ; Sun, 17 May 2015 13:15:08 -0700 (PDT) Received: from [192.168.111.105] (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 8A016C400DB; Sun, 17 May 2015 15:15:07 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1431893707; bh=q+H6nh2d+YdKno4vo/X8B4eBwcvtiyMBORRGRiaxnxU=; h=In-Reply-To:References:Subject:From:Date:To:From; b=Zgmbq/XrW3nEtI857Z3VCOf7YkIGEh0INLQFVpUV79zZNs58XwcKsjATdily6J7AI OX3J32LC1+WGlDs7+1FwhlNB2gsGdT80rmA7CghUDACoiRpm8aI6V43Wje/2qkeQ6U eGiefl2G0iBx1bJKMAoEgiZxuxvUn5pTEPxvMNuQ= User-Agent: K-9 Mail for Android In-Reply-To: <87wq07yr8l.fsf@uwakimon.sk.tsukuba.ac.jp> References: <555656FC.5010609@dcrocker.net> <10034618.CIMjht0PXi@kitterma-e6430> <87wq07yr8l.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Sun, 17 May 2015 16:15:04 -0400 To: dmarc@ietf.org Message-ID: Archived-At: Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 May 2015 20:15:10 -0000 On May 17, 2015 2:48:58 PM AST, "Stephen J. Turnbull" wrote: >Scott Kitterman writes: > > > Performing prosepective DMARC validation on receipt to determine if > > mail would be subject to p=reject processing on the distant end if > > reransmited. > >I assume you mean "... and prospectively reject"? (GNU Mailman at >least already provides options to munge From or wrap the message, >conditional on the result of such a test.) > >For completeness it should be listed, but practically speaking, for >tens of thousands of lists it just ain't gonna happen, sorry. > >The Author Domains that *want* "POLICY" control already have a local >policy in place prohibiting their users from posting to mailing lists >and the like, and are a very small problem because indirect messages >from them are very few. > >It's the p=reject abusers that are the problem, but *they* *want* >mailing lists to distribute their users' posts, despite what "POLICY" >advocates claim is implied by publishing p=reject. Those users *want* >to post, and they blame the *list*, not their mailbox providers, if >anything goes wrong or if their posts are treated differently from >users at other providers. List owners by and large are not RFC >zealots, quite the reverse, and quickly cave in to the importunate >posters. > >Bottom line: The only people who want this policy are some of us in >this working group. Nobody[1] actually involved does. Even my >colleagues at GNU Mailman who are sympathetic to the idea of >prospectively doing what the policy requests have found that in >practice it's socially untenable on lists they administer. > >Footnotes: >[1] Well, I do, but my lists are special cases. My public lists have >less than 0.5% p=reject subscribers and less than 0.1% posts from >them, so I can tell them where to go, and my university lists are >covered by Japanese Ministry of Education policy deprecating use of >Yahoo! mailboxes (without reference to p=reject and including domains >that publish p=none!) Dave asked for a comprehensive list, not just a list of ideas that are of general utility. It does solve the problem of others getting bounced off the list due to their ADMD honoring the p=reject, but as you saw wouldn't be acceptable in many cases. Scott K From nobody Sun May 17 21:26:59 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57471A1A45 for ; Sun, 17 May 2015 21:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3m5xwCYgViFf for ; Sun, 17 May 2015 21:26:56 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E34701A1A57 for ; Sun, 17 May 2015 21:26:55 -0700 (PDT) Received: by wibt6 with SMTP id t6so55061982wib.0 for ; Sun, 17 May 2015 21:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7s7nL2fAEEFnk/GuD4thRiF/TIjNdCQ7kMWZX/SsZHM=; b=JEfcQDPY9HwvurR+axwTzVP8TwUAxp1y13uGfUnIaFhLs0xqKk5sntTI6iclzy06gj UNqFIZYNrOh/w26gTBeGzFeYa+vT/PFIvlqYOHzZo+ieDNKcwJVU3IWhHsONf1Kf+tVH DdZrWlyMY2ayO+bVZh19EmlpeydKuK8fTTUqzdvoGV9d3UmoBTnUnE4rLhGzXz48bNng ZYD/eP/lN6bm+3gP00LmfjPLVR/M061vwolAePCeSIbULOPr8sMTr631elPuE7qSETGD OXkzqHomJtISTVKQTVI5OxXXfPJtpQkoT8pI8I1r9SZtCIStoyVhp1hNt6+CSWNTKKyv wbLQ== MIME-Version: 1.0 X-Received: by 10.194.174.68 with SMTP id bq4mr24415462wjc.4.1431923214591; Sun, 17 May 2015 21:26:54 -0700 (PDT) Received: by 10.27.170.134 with HTTP; Sun, 17 May 2015 21:26:54 -0700 (PDT) In-Reply-To: <555656FC.5010609@dcrocker.net> References: <555656FC.5010609@dcrocker.net> Date: Sun, 17 May 2015 21:26:54 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=089e014936808d2d960516539ab0 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 04:26:58 -0000 --089e014936808d2d960516539ab0 Content-Type: text/plain; charset=UTF-8 On Fri, May 15, 2015 at 1:28 PM, Dave Crocker wrote: > Performing DKIM/SPF validation upon receipt > There already exist several implementations of each of these, so I would say that they are currently deployed rather widely, making our cost near-zero. Plus, any DMARC operator already has at least one of them going. DKIM-signing all outbound mail. > Let's say that's close to zero cost as well. One thing absent from your list is conditional signatures, which is John's idea, and is a special case of both of these. I've implemented it now in libopendkim as a compile-time experimental feature, and it took me about four hours including testing. I just have to add it to the plugin that uses the library, and it'll be available for others to play with. -MSK --089e014936808d2d960516539ab0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, May 15, 2015 at 1:28 PM, Dave Crocker <dhc@dcrocke= r.net> wrote:
=C2=A0=C2=A0 Performing DKIM/SPF v= alidation upon receipt

There already ex= ist several implementations of each of these, so I would say that they are = currently deployed rather widely, making our cost near-zero.=C2=A0 Plus, an= y DMARC operator already has at least one of them going.

=C2=A0 =C2=A0DKIM-signing all outbound mail.

Let's say that's close to zero cost as well.

One thing absent from your list is conditional signatures, which is John&= #39;s idea, and is a special case of both of these.=C2=A0 I've implemen= ted it now in libopendkim as a compile-time experimental feature, and it to= ok me about four hours including testing.=C2=A0 I just have to add it to th= e plugin that uses the library, and it'll be available for others to pl= ay with.

-MSK
--089e014936808d2d960516539ab0-- From nobody Sun May 17 22:45:31 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECCE71A0196 for ; Sun, 17 May 2015 19:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.899 X-Spam-Level: *** X-Spam-Status: No, score=3.899 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-FO_TVBfFxn for ; Sun, 17 May 2015 19:38:53 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 791611A0194 for ; Sun, 17 May 2015 19:38:52 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 682E51C3831; Mon, 18 May 2015 11:38:51 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 48C491A3398; Mon, 18 May 2015 11:38:51 +0900 (JST) From: "Stephen J. Turnbull" To: Scott Kitterman In-Reply-To: References: <555656FC.5010609@dcrocker.net> <10034618.CIMjht0PXi@kitterma-e6430> <87wq07yr8l.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Mon, 18 May 2015 11:38:51 +0900 Message-ID: <87twvazk1w.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: X-Mailman-Approved-At: Sun, 17 May 2015 22:45:30 -0700 Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 02:38:56 -0000 Scott Kitterman writes: > On May 17, 2015 2:48:58 PM AST, "Stephen J. Turnbull" wrote: > >Scott Kitterman writes: > > > > > Performing prosepective DMARC validation on receipt to determine if > > > mail would be subject to p=reject processing on the distant end if > > > reransmited. > > > >I assume you mean "... and prospectively reject"? (GNU Mailman at > >least already provides options to munge From or wrap the message, > >conditional on the result of such a test.) > > > >For completeness it should be listed, > Dave asked for a comprehensive list, An acknowledgment of that is the first thing I wrote after asking the qualifying question, as you see. > as you saw wouldn't be acceptable in many cases. The argument supports a stronger conclusion than that IMHO. Had there been a wiki page for this list I wouldn't have posted here, but I'm new and don't know the procedures for starting a page, and others had posted to the list -- I just wanted the argument, and the stronger conclusion, on the record in case I'm not around when the wiki page or BCP or whatever does get initialized. From nobody Mon May 18 10:58:20 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8E71AD0B3 for ; Mon, 18 May 2015 10:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OlhxrL1SeXz for ; Mon, 18 May 2015 10:58:15 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id AD54C1AD084 for ; Mon, 18 May 2015 10:58:09 -0700 (PDT) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3lr7Nt35zcz1L8n8; Mon, 18 May 2015 19:58:06 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3lr7Nt1sGBz5Mgfk; Mon, 18 May 2015 19:58:06 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id DC9EE123513; Mon, 18 May 2015 19:58:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LeAOsWChgYQu; Mon, 18 May 2015 19:58:04 +0200 (CEST) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 47E0E1234B7; Mon, 18 May 2015 19:58:04 +0200 (CEST) Message-ID: <555A282B.6050906@sonnection.nl> Date: Mon, 18 May 2015 19:58:03 +0200 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dcrocker@bbiw.net, "dmarc@ietf.org" References: <555656FC.5010609@dcrocker.net> In-Reply-To: <555656FC.5010609@dcrocker.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1431971886; bh=xAxvbhbroI+aBhm/z+vHDhB/JBbUKypCkyyTRF1fkgM=; h=Message-ID:Date:From:To:Subject:From; b=WunjUu9CSXq6Tn2cd2HQ2RC8Z1lRL7w7KVUnKmILARmMboyJY38Et2a0/J5B2E6En 4Zg7GDdEYatxOImGl08qmr47XsU9b5aV50tgmAzm2haTQ+anZYLdYepzhamrkbqnaw qYLyQAWc06HSv1ivo4DPdO2q8zo9iT2JXiTfoTss= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3lr7Nt35zcz1L8n8 Archived-At: Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 17:58:19 -0000 On 05/15/2015 10:28 PM, Dave Crocker wrote: > G'day. > > In looking for ways to make a DMARC-style function succeed when the > message transits an intermediary, the current approach has mostly been > proposing one or another wholesale solution. This creates a complex > space for discussion and tends towards some version of deadly embrace. > > It might be helpful to consider /basic types/ of changes that are > reasonable/unreasonable for intermediaries, distinct from how they might > fit into an entire solution. > > Reasonable vs. unreasonable pertain to at least two axes: > > 1. Amount of work > > 2. Policy/Principle > > Some choices entail too much work or run afoul of basic operational > policies. Others might entail some work, but not too much, and might > not be considered as significant violations of established policies. > > Here be dragons, of course, but let's try to have the discussion anyhow. > > Obviously, there will not be unanimity among all intermediaries, for any > proposal. So the question really is about plausible rough consensus > among a 'substantial' amount of the community. > > The first question is: what are the 'types' of changes that have been > or might be proposed? Please define 'changes'. Do you mean: changes which solve the 'p=reject' problem for mail that is sent via an intermediary? Or just 'any' changes that might help us a fraction to come closer to a solution. > This should turn into some sort of taxonomy, > eventually, but for now an undisciplined core dump(*) of choices would > be best. > > Examples: > > Modifying the rfc5322.From display-name > > Modifying the rfc5322.From address > > Modifying the footer of the message body (first body-part.) > > Modifying the rfc5322.Subject preface > > Performing DMARC validation upon receipt > > Performing DKIM/SPF validation upon receipt + add an Authentication-Results header. > > DKIM-signing all outbound mail. + include Authentication-Results in the DKIM-signature of the intermediary. > > Registering the intermediary with all potential sites posting to it > > Registering the intermediary with all potential sites receiving from > it /rolf From nobody Mon May 18 11:49:35 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C961B2A22 for ; Mon, 18 May 2015 11:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.499 X-Spam-Level: X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Um86WSmxsf85 for ; Mon, 18 May 2015 11:49:29 -0700 (PDT) Received: from mail-pa0-x243.google.com (mail-pa0-x243.google.com [IPv6:2607:f8b0:400e:c03::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB7E1B2A20 for ; Mon, 18 May 2015 11:49:29 -0700 (PDT) Received: by pablf10 with SMTP id lf10so1537584pab.1 for ; Mon, 18 May 2015 11:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ioZ8PuGML7Q3w4jpBaZzGuS0z+VUkNyb+1drbtN+UN0=; b=u+ZqVtFqzj+7SaULQ+re6EXqTJFlWKUiarAjaOGGuh8kEqPs6Vx7DhmwgWbcbQRe6m 45JJAulu5cH/YqfL/NiSd00e4mWzkK5AGPUHEMsbZTBJotOumdRKjFwK7jq/0Ve3kppj tzmaDXkeR4xu16EobGgDk6IH8890KT4cHz3eLsAbhv1VrQ2vfPohL728wTO9NXyHkxwT ubjKyFWXqkcV1vvFyg4NhmZJlc0coCs4K0/PQRQHsakVxFROWKDFcajKBMUhrx9KU0HQ hCJ3MoUwuSEIow+YFqt7nk2S6khXtY1KpT/zu7b0VJF3mzo+sXSHwpXS30e/fRkrsZQh 850g== X-Received: by 10.68.231.98 with SMTP id tf2mr47193775pbc.12.1431974968910; Mon, 18 May 2015 11:49:28 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id w6sm3188459pbt.3.2015.05.18.11.49.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 May 2015 11:49:27 -0700 (PDT) Message-ID: <555A3433.6070109@gmail.com> Date: Mon, 18 May 2015 11:49:23 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <555656FC.5010609@dcrocker.net> <10034618.CIMjht0PXi@kitterma-e6430> <87wq07yr8l.fsf@uwakimon.sk.tsukuba.ac.jp> <87twvazk1w.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87twvazk1w.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 18:49:33 -0000 On 5/17/15 7:38 PM, Stephen J. Turnbull wrote: > Scott Kitterman writes: >> On May 17, 2015 2:48:58 PM AST, "Stephen J. Turnbull" >> wrote: >>> Scott Kitterman writes: >>> >>>> Performing prosepective DMARC validation on receipt to >>>> determine if mail would be subject to p=reject processing on >>>> the distant end if reransmited. >>> >>> I assume you mean "... and prospectively reject"? (GNU Mailman >>> at least already provides options to munge From or wrap the >>> message, conditional on the result of such a test.) >>> >>> For completeness it should be listed, > >> Dave asked for a comprehensive list, > > An acknowledgment of that is the first thing I wrote after asking > the qualifying question, as you see. > >> as you saw wouldn't be acceptable in many cases. > > The argument supports a stronger conclusion than that IMHO. Had > there been a wiki page for this list I wouldn't have posted here, but > I'm new and don't know the procedures for starting a page, and others > had posted to the list -- I just wanted the argument, and the > stronger conclusion, on the record in case I'm not around when the > wiki page or BCP or whatever does get initialized. Dear Stephen, Wiki is fine, but traditionally anything somewhat involved should be published in the form of an Internet Draft. Reasonable tools are available. https://tools.ietf.org/html/draft-otis-dmarc-escape-02#section-4 Describes fairly easy approaches that require increasing cooperation from larger providers. 1) Conditionally permit Sender header field alignment This could be defined as a "public" policy that indicates as result of use of public mailing lists and general email use, the domain needs to allow alignment with the Sender header field. By having handling defined in such a case, it would allow recipients a safer way to override otherwise disruptive policies causing message being munged or placed into spam folders. 2) Define a replacement Author header This would better ensure email interchange rather than placing author roles into various ad hoc locations. 3) Third-Party Authorization Perhaps the effect made by option 1 or 2 may pressure providers into offering information that ONLY they have on behalf of their recipients. Such information would allow more effective and safer handling to deal of third-party sources where legitimate messages are likely disrupted with the effect of preventing open discussions with known authors. The Selection of which message are to receive a message siglet to authorize a third party domain could be accomplished using various DKIM siglets, but will require greater handling overhead and will be far less responsive when abuse is subsequently detected. Once the issue of overhead and responding to abuse are carefully considered, the general approach outline in https://tools.ietf.org/html/draft-otis-tpa-label-07 might be reconsidered. TPA-Label could even become a hybrid of https://tools.ietf.org/html/draft-levine-dkim-conditional-01 where initial signatures are confirmed by the https://tools.ietf.org/html/rfc6376 by using forensics base on the bh= and z= tag with an additional tag that indicates predefined sets of headers that must remain unchanged as well as a list of domains that may reintroduce signed messages. When an intermediary is authorized, an expanded authentication results header might prove simpler than using forensics. Either way, a hybrid approach would need less specified within TPA-Label resource records and still be able to retract specific authorizations that have gone bad. The hybrid approach would also help facilitate which outbound messages should receive the message siglets and which domains are authorized to re-sign on behalf of the DMARC domain. Various encapsulation scheme seem fairly risky since they allow unseen content to reconstruct messages that otherwise fail validation and will generally make email more confusing. Both encapsulation and DKIM siglets will allow wide-open abuse (abuse beyond the control of the DMARC domain). Regards, Douglas Otis From nobody Mon May 18 17:36:54 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA981B2C13 for ; Mon, 18 May 2015 17:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuQXsCUm1GSF for ; Mon, 18 May 2015 17:36:51 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (mail-sn2ln0090.outbound.o365filtering.com [IPv6:2a01:111:f400:7c04::90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD4BC1B2BD6 for ; Mon, 18 May 2015 17:36:50 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) with Microsoft SMTP Server (TLS) id 15.1.172.7; Tue, 19 May 2015 00:36:35 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.5.234]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.5.234]) with mapi id 15.01.0172.012; Tue, 19 May 2015 00:36:35 +0000 From: Terry Zink To: "Murray S. Kucherawy" , Dave Crocker Thread-Topic: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy Thread-Index: AQHQkSLjmR8NgZwmBEqnwBkgIc5yZJ2CdTYQ Date: Tue, 19 May 2015 00:36:34 +0000 Message-ID: References: <555656FC.5010609@dcrocker.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ed43::3] x-microsoft-exchange-diagnostics: 1; BL2SR01MB605; 3:uNjegCfrNxHJNCb48qzuBKVg6TOM9ij5XAr+PE1LhwJszIfvaGfP7YzAW2opUAv3yyC3ytg1fPNWCdeJNQBem+kC2j2OTTxO5wWNGHMjs9iTyhSqYBq5HnNBYD/UKktxWAv5gxvrtu+GV8GaTTff7g==; 10:Nsab1AKU12l+CQxQzhJPdcWYbXS6zKF25KBiOjdRRwY7HB95seD+Un2ffbFWkXEoaazWFYiDsFAi+S1/4H21SO40HPtlbghLwoNqTk8coWc=; 6:NmQguvESMpl2JrzgnFTGEfe8QPPUerMEozmQE852q7UPfojH9INghopO4OmewFev x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB605; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(189002)(377454003)(199003)(24454002)(2656002)(15975445007)(106116001)(62966003)(102836002)(19300405004)(81156007)(101416001)(19609705001)(77156002)(4001540100001)(76176999)(19580405001)(5001860100001)(54356999)(19580395003)(97736004)(50986999)(5001830100001)(5001960100002)(46102003)(2950100001)(5001770100001)(68736005)(106356001)(105586002)(19625215002)(16236675004)(92566002)(87936001)(2900100001)(64706001)(33656002)(86362001)(189998001)(48203002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB605; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005002)(5002009)(3002001); SRVR:BL2SR01MB605; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB605; x-forefront-prvs: 0581B5AB35 received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: multipart/alternative; boundary="_000_BL2SR01MB605A700BA2C4C0775AC71DA96C30BL2SR01MB605namsdf_" MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2015 00:36:34.4724 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB605 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 00:36:53 -0000 --_000_BL2SR01MB605A700BA2C4C0775AC71DA96C30BL2SR01MB605namsdf_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBJJ3ZlIGltcGxlbWVudGVkIGl0IG5vdyBpbiBsaWJvcGVuZGtpbSBhcyBhIGNvbXBpbGUtdGlt ZSBleHBlcmltZW50YWwgZmVhdHVyZSwNCj4gYW5kIGl0IHRvb2sgbWUgYWJvdXQgZm91ciBob3Vy cyBpbmNsdWRpbmcgdGVzdGluZy4gIEkganVzdCBoYXZlIHRvIGFkZCBpdCB0byB0aGUgcGx1Z2lu DQo+IHRoYXQgdXNlcyB0aGUgbGlicmFyeSwgYW5kIGl0J2xsIGJlIGF2YWlsYWJsZSBmb3Igb3Ro ZXJzIHRvIHBsYXkgd2l0aC4NCg0KQ2FuIHlvdSBnaXZlIGFuIGV4YW1wbGUgb2Ygd2hhdCB0aGUg c3RhbXBlZCBoZWFkZXJzIHdpbGwgbG9vayBsaWtlPw0KDQotLSBUZXJyeQ0KDQpGcm9tOiBkbWFy YyBbbWFpbHRvOmRtYXJjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNdXJyYXkgUy4g S3VjaGVyYXd5DQpTZW50OiBTdW5kYXksIE1heSAxNywgMjAxNSA5OjI3IFBNDQpUbzogRGF2ZSBD cm9ja2VyDQpDYzogZG1hcmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbZG1hcmMtaWV0Zl0gTG9v a2luZyBmb3IgZGVncmVlcyBvZiBmcmVlZG9tIHdpdGggSW50ZXJtZWRpYXJpZXMgLSBFZmZvcnQg YW5kIFBvbGljeQ0KDQpPbiBGcmksIE1heSAxNSwgMjAxNSBhdCAxOjI4IFBNLCBEYXZlIENyb2Nr ZXIgPGRoY0BkY3JvY2tlci5uZXQ8bWFpbHRvOmRoY0BkY3JvY2tlci5uZXQ+PiB3cm90ZToNCiAg IFBlcmZvcm1pbmcgREtJTS9TUEYgdmFsaWRhdGlvbiB1cG9uIHJlY2VpcHQNCg0KVGhlcmUgYWxy ZWFkeSBleGlzdCBzZXZlcmFsIGltcGxlbWVudGF0aW9ucyBvZiBlYWNoIG9mIHRoZXNlLCBzbyBJ IHdvdWxkIHNheSB0aGF0IHRoZXkgYXJlIGN1cnJlbnRseSBkZXBsb3llZCByYXRoZXIgd2lkZWx5 LCBtYWtpbmcgb3VyIGNvc3QgbmVhci16ZXJvLiAgUGx1cywgYW55IERNQVJDIG9wZXJhdG9yIGFs cmVhZHkgaGFzIGF0IGxlYXN0IG9uZSBvZiB0aGVtIGdvaW5nLg0KICAgREtJTS1zaWduaW5nIGFs bCBvdXRib3VuZCBtYWlsLg0KDQpMZXQncyBzYXkgdGhhdCdzIGNsb3NlIHRvIHplcm8gY29zdCBh cyB3ZWxsLg0KT25lIHRoaW5nIGFic2VudCBmcm9tIHlvdXIgbGlzdCBpcyBjb25kaXRpb25hbCBz aWduYXR1cmVzLCB3aGljaCBpcyBKb2huJ3MgaWRlYSwgYW5kIGlzIGEgc3BlY2lhbCBjYXNlIG9m IGJvdGggb2YgdGhlc2UuICBJJ3ZlIGltcGxlbWVudGVkIGl0IG5vdyBpbiBsaWJvcGVuZGtpbSBh cyBhIGNvbXBpbGUtdGltZSBleHBlcmltZW50YWwgZmVhdHVyZSwgYW5kIGl0IHRvb2sgbWUgYWJv dXQgZm91ciBob3VycyBpbmNsdWRpbmcgdGVzdGluZy4gIEkganVzdCBoYXZlIHRvIGFkZCBpdCB0 byB0aGUgcGx1Z2luIHRoYXQgdXNlcyB0aGUgbGlicmFyeSwgYW5kIGl0J2xsIGJlIGF2YWlsYWJs ZSBmb3Igb3RoZXJzIHRvIHBsYXkgd2l0aC4NCi1NU0sNCg== --_000_BL2SR01MB605A700BA2C4C0775AC71DA96C30BL2SR01MB605namsdf_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFw aCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxl LXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFy Z2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7IEkndmUgaW1wbGVtZW50ZWQgaXQgbm93 IGluIGxpYm9wZW5ka2ltIGFzIGEgY29tcGlsZS10aW1lIGV4cGVyaW1lbnRhbCBmZWF0dXJlLA0K PGJyPg0KJmd0OyBhbmQgaXQgdG9vayBtZSBhYm91dCBmb3VyIGhvdXJzIGluY2x1ZGluZyB0ZXN0 aW5nLiZuYnNwOyBJIGp1c3QgaGF2ZSB0byBhZGQgaXQgdG8gdGhlIHBsdWdpbg0KPGJyPg0KJmd0 OyB0aGF0IHVzZXMgdGhlIGxpYnJhcnksIGFuZCBpdCdsbCBiZSBhdmFpbGFibGUgZm9yIG90aGVy cyB0byBwbGF5IHdpdGguPG86cD48L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5DYW4geW91IGdpdmUgYW4gZXhhbXBsZSBvZiB3aGF0IHRoZSBzdGFtcGVkIGhlYWRlcnMgd2ls bCBsb29rIGxpa2U/PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPi0tIFRlcnJ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiBkbWFyYyBbbWFpbHRvOmRtYXJjLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPk11cnJheSBTLiBLdWNoZXJhd3k8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBNYXkg MTcsIDIwMTUgOToyNyBQTTxicj4NCjxiPlRvOjwvYj4gRGF2ZSBDcm9ja2VyPGJyPg0KPGI+Q2M6 PC9iPiBkbWFyY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2RtYXJjLWlldGZd IExvb2tpbmcgZm9yIGRlZ3JlZXMgb2YgZnJlZWRvbSB3aXRoIEludGVybWVkaWFyaWVzIC0gRWZm b3J0IGFuZCBQb2xpY3k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBG cmksIE1heSAxNSwgMjAxNSBhdCAxOjI4IFBNLCBEYXZlIENyb2NrZXIgJmx0OzxhIGhyZWY9Im1h aWx0bzpkaGNAZGNyb2NrZXIubmV0IiB0YXJnZXQ9Il9ibGFuayI+ZGhjQGRjcm9ja2VyLm5ldDwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IFBlcmZvcm1pbmcgREtJTS9TUEYgdmFs aWRhdGlvbiB1cG9uIHJlY2VpcHQ8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhl cmUgYWxyZWFkeSBleGlzdCBzZXZlcmFsIGltcGxlbWVudGF0aW9ucyBvZiBlYWNoIG9mIHRoZXNl LCBzbyBJIHdvdWxkIHNheSB0aGF0IHRoZXkgYXJlIGN1cnJlbnRseSBkZXBsb3llZCByYXRoZXIg d2lkZWx5LCBtYWtpbmcgb3VyIGNvc3QgbmVhci16ZXJvLiZuYnNwOyBQbHVzLCBhbnkgRE1BUkMg b3BlcmF0b3IgYWxyZWFkeSBoYXMgYXQgbGVhc3Qgb25lIG9mIHRoZW0NCiBnb2luZy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyAmbmJzcDtES0lNLXNpZ25pbmcgYWxsIG91dGJvdW5kIG1haWwuPG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPkxldCdzIHNheSB0aGF0J3MgY2xvc2UgdG8gemVybyBjb3N0IGFzIHdl bGwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk9uZSB0aGluZyBhYnNlbnQgZnJvbSB5b3VyIGxp c3QgaXMgY29uZGl0aW9uYWwgc2lnbmF0dXJlcywgd2hpY2ggaXMgSm9obidzIGlkZWEsIGFuZCBp cyBhIHNwZWNpYWwgY2FzZSBvZiBib3RoIG9mIHRoZXNlLiZuYnNwOyBJJ3ZlIGltcGxlbWVudGVk IGl0IG5vdyBpbiBsaWJvcGVuZGtpbSBhcyBhIGNvbXBpbGUtdGltZSBleHBlcmltZW50YWwgZmVh dHVyZSwgYW5kIGl0DQogdG9vayBtZSBhYm91dCBmb3VyIGhvdXJzIGluY2x1ZGluZyB0ZXN0aW5n LiZuYnNwOyBJIGp1c3QgaGF2ZSB0byBhZGQgaXQgdG8gdGhlIHBsdWdpbiB0aGF0IHVzZXMgdGhl IGxpYnJhcnksIGFuZCBpdCdsbCBiZSBhdmFpbGFibGUgZm9yIG90aGVycyB0byBwbGF5IHdpdGgu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tTVNL PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_BL2SR01MB605A700BA2C4C0775AC71DA96C30BL2SR01MB605namsdf_-- From nobody Mon May 18 18:18:22 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D99D91B2C83 for ; Mon, 18 May 2015 18:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kf5a_nDe3NR2 for ; Mon, 18 May 2015 18:18:18 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DC8A1ACE93 for ; Mon, 18 May 2015 18:18:18 -0700 (PDT) Received: by wibt6 with SMTP id t6so3435222wib.0 for ; Mon, 18 May 2015 18:18:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w+etWsDHA1UL6Q7Y5C9P8onlALIgIL/VZVT0ufHKi1k=; b=rn5PisWLJfpPWGZ0+43yQpxFE33J8wRc8Fx4DaewXbzw6lnvC8Llo+Z1I3k07x5JKv g7bQ6oEIV51lbkJ57TXLFKtX1t993mg5HhDzGyyYmMAR2Fol/jZHPBoKpkcsKT+HV/Kk zL8i7itFMkTDpasV5G8JjngQavZbxIu9v9N3zZSs/A6Hag0RcP3SROYwW4e0fdi0mEPe hfpdL1TfF+o6dgJxL5utNJzQ3DqPFg2w4M672aH0sXsLmFZlxJd9JfNj5yWkuIuLB1Ak ee1KLcLNnIPPhykQgSdCi+veAF1LYmXQLQv7Ht/thy1HT6xEjBbLaBNambj1DIsLJL2E Sj2Q== MIME-Version: 1.0 X-Received: by 10.194.174.68 with SMTP id bq4mr33201389wjc.4.1431998296730; Mon, 18 May 2015 18:18:16 -0700 (PDT) Received: by 10.27.170.134 with HTTP; Mon, 18 May 2015 18:18:16 -0700 (PDT) In-Reply-To: References: <555656FC.5010609@dcrocker.net> Date: Mon, 18 May 2015 18:18:16 -0700 Message-ID: From: "Murray S. Kucherawy" To: Terry Zink Content-Type: multipart/alternative; boundary=089e01493680cbb203051665153b Archived-At: Cc: "dmarc@ietf.org" , Dave Crocker Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 01:18:21 -0000 --089e01493680cbb203051665153b Content-Type: text/plain; charset=UTF-8 On Mon, May 18, 2015 at 5:36 PM, Terry Zink wrote: > > I've implemented it now in libopendkim as a compile-time experimental > feature, > > and it took me about four hours including testing. I just have to add > it to the plugin > > that uses the library, and it'll be available for others to play with. > > > > Can you give an example of what the stamped headers will look like? > Ideally on receipt by a list subscriber, the message would have the following DKIM signatures: DKIM-Signature: v=1; d=authordomain.example; s=selector; ... DKIM-Signature: v=2; d=authordomain.example; s=selector; !cd=mlm.example; l=0; ... DKIM-Signature: v=1; d=mlm.example; s=foobar; ... Things of note: 1) I changed "@fs" to "!cd" versus what John specified. I prefer "!" because we're calling that a "mandatory tag", and "cd" stands for "conditional domain" rather than "forward signature". Mostly personal preference, but I'd argue they're more correct (for some value thereof); I'll change them to wherever consensus lands if we decide we want to adopt this proposal. 2) I understand there's unresolved debate about updating "v=". I'll conform to that too when we make a decision. 3) The choice to do a weak signature using "l=0" was merely exemplary. There are other choices, like which header fields to sign or use of "l=", that can result in something weaker without being that wide open. 4) Similarly, I didn't set an expiration on the !cd signature, but should. 5) I've actually listed the signatures above in the opposite order I'd expect to see them on receipt. 6) The theory is that even if the author signature fails, the conditional author signature would be more likely to pass but is not valid without the MLM signature. libopendkim would report this to the caller as valid in the crytpo sense, but also note that the condition was not satisfied, so there's an error code associated with it. 7) Ultimately the caller sees all three signatures and their respective results. If the original author signature survived, it's available to influence message disposition as well as the others. -MSK --089e01493680cbb203051665153b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, May 18, 2015 at 5:36 PM, Terry Zink <t= zink@exchange.microsoft.com> wrote:

Ideally on receipt by a lis= t subscriber, the message would have the following DKIM signatures:

=
DKIM-Signature: v=3D1; d=3Dauthordomain.example; s=3Dselector; .= ..
DKIM-Signature: v=3D2; d=3Dauthordomain.example; s=3Dselec= tor; !cd=3Dmlm.example; l=3D0; ...
DKIM-Signature: v=3D1; d= =3Dmlm.example; s=3Dfoobar; ...

Things of note:

1) I changed "@fs" to "!cd" versus what John s= pecified.=C2=A0 I prefer "!" because we're calling that a &qu= ot;mandatory tag", and "cd" stands for "conditional dom= ain" rather than "forward signature".=C2=A0 Mostly personal = preference, but I'd argue they're more correct (for some value ther= eof); I'll change them to wherever consensus lands if we decide we want= to adopt this proposal.

2) I understand there's unre= solved debate about updating "v=3D".=C2=A0 I'll conform to th= at too when we make a decision.

3) The choice to do a wea= k signature using "l=3D0" was merely exemplary.=C2=A0 There are o= ther choices, like which header fields to sign or use of "l=3D<orig= inal-length>", that can result in something weaker without being th= at wide open.

4) Similarly, I didn't set an expiratio= n on the !cd signature, but should.

5) I've actually = listed the signatures above in the opposite order I'd expect to see the= m on receipt.

6) The theory is that even if the author si= gnature fails, the conditional author signature would be more likely to pas= s but is not valid without the MLM signature.=C2=A0 libopendkim would repor= t this to the caller as valid in the crytpo sense, but also note that the c= ondition was not satisfied, so there's an error code associated with it= .

7) Ultimately the caller sees all three signatures and = their respective results.=C2=A0 If the original author signature survived, = it's available to influence message disposition as well as the others.<= br>
-MSK
--089e01493680cbb203051665153b-- From nobody Mon May 18 20:43:06 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF271B2E09 for ; Mon, 18 May 2015 20:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tnNlF0pmtxZ for ; Mon, 18 May 2015 20:43:03 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 727921B2E0B for ; Mon, 18 May 2015 20:42:50 -0700 (PDT) Received: by pabru16 with SMTP id ru16so4989414pab.1 for ; Mon, 18 May 2015 20:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=SxksCCoGzG4qHUGB1RaoFAZEA20/9m1xu+Rt/9lMBO4=; b=Z5rsFOlinp+2rb9e6wqRkPFSr/X/FdWg6qUvTi75DQSvdF3g8SlUgpEhnOC39ymAI3 YHQxL86z0Dyb0eIXeY5nd87BQx2DB2gVmfKIUnMUlwp9f704PfNUQJ2XX3c6o9E5dg+P ECDt7DAG/Vz3VRLvtIdt9YFLMJPBG5AXZjiiTed4hxmDp18rp8IaX8GL/Oz+ilL1KnaF 5bdVcVFjzLRS3LWgKVpxrOtxum9hKYk4k6ohfWUsoOl5NkhwaW9B38bu+Ha2+mu40Put vbpSg0xu59Dx0d/jFvzg7LSuqnyd3PNjtIYXs3DPGyt5BH8nYXiH1aZdQNrX4cj1Fw32 Jl6g== X-Received: by 10.68.129.72 with SMTP id nu8mr50066494pbb.145.1432006970077; Mon, 18 May 2015 20:42:50 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id ei17sm11503529pac.20.2015.05.18.20.42.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 May 2015 20:42:48 -0700 (PDT) Message-ID: <555AB134.4080503@gmail.com> Date: Mon, 18 May 2015 20:42:44 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <555656FC.5010609@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 03:43:05 -0000 On 5/18/15 6:18 PM, Murray S. Kucherawy wrote: > Ideally on receipt by a list subscriber, the message would have the > following DKIM signatures: > > DKIM-Signature: v=1; d=authordomain.example; s=selector; ... > DKIM-Signature: v=2; d=authordomain.example; s=selector; !cd=mlm.example; > l=0; ... > DKIM-Signature: v=1; d=mlm.example; s=foobar; ... > > Things of note: > > 1) I changed "@fs" to "!cd" versus what John specified. I prefer "!" > because we're calling that a "mandatory tag", and "cd" stands for > "conditional domain" rather than "forward signature". Mostly personal > preference, but I'd argue they're more correct (for some value thereof); > I'll change them to wherever consensus lands if we decide we want to adopt > this proposal. Dear Murray, Termnology: DKIM Siglet is a highly constrained DKIM signature omitting elements likely altered by a mediator. Have you given any thought about how inclusion of a siglet containing !cd=random.example.com is regimented? Regimentation can use ram based DNS in a fashion that benefits MTAs adding the siglet and those deciding whether to add the siglet by using unique labels to facilitate retraction of undesired authorization. SHA-1 received its share of Intel's attention. https://software.intel.com/en-us/articles/improving-the-performance-of-the-secure-hash-algorithm-1 This paper gives a better overview than the code added to the TPA-Label draft and illustrates a much faster approach. Faster than using any sort of disk access where a publisher handles collisions. This also provides consistent label sizes, minimal cache consumption and look up overhead. > 2) I understand there's unresolved debate about updating "v=". I'll > conform to that too when we make a decision. > > 3) The choice to do a weak signature using "l=0" was merely exemplary. > There are other choices, like which header fields to sign or use of > "l=", that can result in something weaker without being > that wide open. Once again, the siglet regimentation can also serve the function of retracting authorizations when needed. Without this ability, there is little to discourage rampant abuse. > 4) Similarly, I didn't set an expiration on the !cd signature, but should. No matter how short an expiry is set, botnets will still be able to leverage anything that gets signed beyond the DMARC domain's control. A few episodes of a botnet leveraging this weakness seems more than likely to justify abandoning the approach putting the effort back to where it started. > 5) I've actually listed the signatures above in the opposite order I'd > expect to see them on receipt. > > 6) The theory is that even if the author signature fails, the conditional > author signature would be more likely to pass but is not valid without the > MLM signature. libopendkim would report this to the caller as valid in the > crytpo sense, but also note that the condition was not satisfied, so > there's an error code associated with it. The author signature has an error code? Yikes. > 7) Ultimately the caller sees all three signatures and their respective > results. If the original author signature survived, it's available to > influence message disposition as well as the others. If the original Author signature survives, the DKIM siglet should be ignored. If there is no DKIM siglet error, and the !CD signature (DKIM siglet authorized signature) is valid, what is to be assumed by the error you noted? What am I missing? Regards, Douglas Otis From nobody Mon May 18 22:57:06 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7D361A1A67 for ; Mon, 18 May 2015 22:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G40iijju_0mm for ; Mon, 18 May 2015 22:57:02 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (mail-sn2ln0090.outbound.o365filtering.com [IPv6:2a01:111:f400:7c04::90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80C0D1A1A62 for ; Mon, 18 May 2015 22:57:02 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB604.namsdf01.sdf.exchangelabs.com (10.255.109.166) with Microsoft SMTP Server (TLS) id 15.1.172.7; Tue, 19 May 2015 05:56:46 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.5.234]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.5.234]) with mapi id 15.01.0172.012; Tue, 19 May 2015 05:56:45 +0000 From: Terry Zink To: "Murray S. Kucherawy" Thread-Topic: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy Thread-Index: AQHQkSLjmR8NgZwmBEqnwBkgIc5yZJ2CdTYQgAAL4QCAAE1PAQ== Date: Tue, 19 May 2015 05:56:44 +0000 Message-ID: <1432015208815.92898@exchange.microsoft.com> References: <555656FC.5010609@dcrocker.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [25.160.19.4] x-microsoft-exchange-diagnostics: 1; BL2SR01MB604; 3:u0WbeTz4JOg8UnxNOciEbmFTZZAmGPqd4KqLz9VWs+FVzDh6MxuuXeFGsxuq4FxgVn/VMq4wq2Qy3grNh8nZ6CTLtj6CqJ5xExk8TGCk/Afq0pqmH9+vd37zXGZ/aNCofN/mD0HZ4I+UJoA3R/dXPA==; 10:u9Llaa3VFt2q+JSyipZ1l8Wid6F5qPpbI9iZnc2qwWCMO5Adkq0bVSde8wrHn+yzZzjfg58CN5GyT8RiPyUYwh054hi5V2ZDdOgOMmjzNZM=; 6:C3nSoqEnjUEPfjl6GL1Z9qPmy3uvjMbqVX53l9Dzbc+c/p7ti8jaA3CG3A/nHYma x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB604; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(24454002)(189002)(377454003)(164054003)(199003)(86362001)(76176999)(93886004)(117636001)(19627405001)(66066001)(62966003)(106356001)(105586002)(19625215002)(106116001)(50986999)(102836002)(54356999)(77156002)(561944003)(101416001)(19580405001)(64706001)(19580395003)(5001830100001)(16236675004)(110136002)(81156007)(1411001)(68736005)(5001960100002)(2900100001)(92566002)(46102003)(2656002)(4001540100001)(87936001)(97736004)(2950100001)(5001860100001)(5001920100001)(189998001)(48203002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB604; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005002)(5002009)(3002001); SRVR:BL2SR01MB604; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB604; x-forefront-prvs: 0581B5AB35 received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: multipart/alternative; boundary="_000_143201520881592898exchangemicrosoftcom_" MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2015 05:56:44.5929 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB604 Archived-At: Cc: "dmarc@ietf.org" , Dave Crocker Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 05:57:04 -0000 --_000_143201520881592898exchangemicrosoftcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks, this is useful. What would the Authentication-Results header look like? Presumably 3 result= s for DKIM (dkim=3Dfail, dkim=3Dpass, dkim=3Dpass)? And what about DMARC? S= how one result or two? Or maybe something like dmarc=3Dconditionalpass? -- Terry ________________________________ From: Murray S. Kucherawy Sent: Monday, May 18, 2015 6:18 PM To: Terry Zink Cc: Dave Crocker; dmarc@ietf.org Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediarie= s - Effort and Policy On Mon, May 18, 2015 at 5:36 PM, Terry Zink > wrote: > I've implemented it now in libopendkim as a compile-time experimental fea= ture, > and it took me about four hours including testing. I just have to add it= to the plugin > that uses the library, and it'll be available for others to play with. Can you give an example of what the stamped headers will look like? Ideally on receipt by a list subscriber, the message would have the followi= ng DKIM signatures: DKIM-Signature: v=3D1; d=3Dauthordomain.example; s=3Dselector; ... DKIM-Signature: v=3D2; d=3Dauthordomain.example; s=3Dselector; !cd=3Dmlm.ex= ample; l=3D0; ... DKIM-Signature: v=3D1; d=3Dmlm.example; s=3Dfoobar; ... Things of note: 1) I changed "@fs" to "!cd" versus what John specified. I prefer "!" becau= se we're calling that a "mandatory tag", and "cd" stands for "conditional d= omain" rather than "forward signature". Mostly personal preference, but I'= d argue they're more correct (for some value thereof); I'll change them to = wherever consensus lands if we decide we want to adopt this proposal. 2) I understand there's unresolved debate about updating "v=3D". I'll conf= orm to that too when we make a decision. 3) The choice to do a weak signature using "l=3D0" was merely exemplary. T= here are other choices, like which header fields to sign or use of "l=3D", that can result in something weaker without being that wid= e open. 4) Similarly, I didn't set an expiration on the !cd signature, but should. 5) I've actually listed the signatures above in the opposite order I'd expe= ct to see them on receipt. 6) The theory is that even if the author signature fails, the conditional a= uthor signature would be more likely to pass but is not valid without the M= LM signature. libopendkim would report this to the caller as valid in the = crytpo sense, but also note that the condition was not satisfied, so there'= s an error code associated with it. 7) Ultimately the caller sees all three signatures and their respective res= ults. If the original author signature survived, it's available to influen= ce message disposition as well as the others. -MSK --_000_143201520881592898exchangemicrosoftcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks, this is useful.


What would the Authentication-Results header look like? Presumably 3 res= ults for DKIM (dkim=3Dfail, dkim=3Dpass, dkim=3Dpass)? And what about DMARC= ? Show one result or two? Or maybe something like dmarc=3Dconditionalpass?<= /p>


-- Terry



From: Murray S. Kucherawy &= lt;superuser@gmail.com>
Sent: Monday, May 18, 2015 6:18 PM
To: Terry Zink
Cc: Dave Crocker; dmarc@ietf.org
Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Interm= ediaries - Effort and Policy
 
On Mon, May 18, 2015 at 5:36 PM, Terry Zink <t= zink@exchange.microsoft.com> wrote:

Ideally on receipt by a list subscriber, the message would have the fo= llowing DKIM signatures:

DKIM-Signature: v=3D1; d=3Dauthordomain.example; s=3Dselector; ...
DKIM-Signature: v=3D2; d=3Dauthordomain.example; s=3Dselector; !cd=3Dm= lm.example; l=3D0; ...
DKIM-Signature: v=3D1; d=3Dmlm.example; s=3Dfoobar; ...

Things of note:

1) I changed "@fs" to "!cd" versus what John speci= fied.  I prefer "!" because we're calling that a "manda= tory tag", and "cd" stands for "conditional domain"= ; rather than "forward signature".  Mostly personal preferen= ce, but I'd argue they're more correct (for some value thereof); I'll change them to wherever consensus lands if = we decide we want to adopt this proposal.

2) I understand there's unresolved debate about updating "v=3D&qu= ot;.  I'll conform to that too when we make a decision.

3) The choice to do a weak signature using "l=3D0" was merel= y exemplary.  There are other choices, like which header fields to sig= n or use of "l=3D<original-length>", that can result in som= ething weaker without being that wide open.

4) Similarly, I didn't set an expiration on the !cd signature, but sho= uld.

5) I've actually listed the signatures above in the opposite order I'd= expect to see them on receipt.

6) The theory is that even if the author signature fails, the conditio= nal author signature would be more likely to pass but is not valid without = the MLM signature.  libopendkim would report this to the caller as val= id in the crytpo sense, but also note that the condition was not satisfied, so there's an error code associated = with it.

7) Ultimately the caller sees all three signatures and their respectiv= e results.  If the original author signature survived, it's available = to influence message disposition as well as the others.

-MSK
--_000_143201520881592898exchangemicrosoftcom_-- From nobody Mon May 18 23:05:21 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35FD1A047A for ; Mon, 18 May 2015 23:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxKRA6vvteVS for ; Mon, 18 May 2015 23:05:20 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9AE11A0161 for ; Mon, 18 May 2015 23:05:19 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so104639256wic.0 for ; Mon, 18 May 2015 23:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sQ8VTrN9HZar+xnbHHw0YYghXJTb2T10wzOnZvvfDME=; b=nZPJHzFJko428B7TWuz1luMJKAtF0aiu8uNuXFnKGyKIG4aDUBQVYNmthk+KYN4R0u 0ElV1aDmPnyED1jrkf+BMheHaoMlqiO7934w9lxg34uRnFPJSPxVbtGNs4jgGDnNYk7F fwxADXFMDNvlqdgpKV9d/pCmCaTjZCAMwCVAh1j+zBYq3pVEKBADrMlIwvwJBRVhnItf Gc4RsEI2rgV4snvGzQmuWj2ZHg748iOo95nqqYe+q+eltxiBxW+XU7apnWWij5KT6LDG 6ehmDEqZz1PVL2PUIpXB6+19Y5OFUVBTU3vMAdrNOGuoMGGuKehGK3Pk7jC0gi1p/8Ri cXzQ== MIME-Version: 1.0 X-Received: by 10.180.74.10 with SMTP id p10mr4080852wiv.94.1432015518566; Mon, 18 May 2015 23:05:18 -0700 (PDT) Received: by 10.27.170.134 with HTTP; Mon, 18 May 2015 23:05:18 -0700 (PDT) In-Reply-To: <1432015208815.92898@exchange.microsoft.com> References: <555656FC.5010609@dcrocker.net> <1432015208815.92898@exchange.microsoft.com> Date: Mon, 18 May 2015 23:05:18 -0700 Message-ID: From: "Murray S. Kucherawy" To: Terry Zink Content-Type: multipart/alternative; boundary=f46d043c08c24c0e6b0516691861 Archived-At: Cc: "dmarc@ietf.org" , Dave Crocker Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 06:05:21 -0000 --f46d043c08c24c0e6b0516691861 Content-Type: text/plain; charset=UTF-8 On Mon, May 18, 2015 at 10:56 PM, Terry Zink wrote: > Thanks, this is useful. > > What would the Authentication-Results header look like? Presumably 3 > results for DKIM (dkim=fail, dkim=pass, dkim=pass)? And what about DMARC? > Show one result or two? Or maybe something like dmarc=conditionalpass? > Three DKIM results, one DMARC "pass" result. The idea is that DKIM returns a "pass" for an aligned conditional signature, which satisfies the DKIM algorithm, so long as there's also a passing signature from the "cd" domain. Is there any use in making a distinction to your acceptance/routing of messages to know it was based on a conditional signature versus an original author signature? -MSK --f46d043c08c24c0e6b0516691861 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, May 18, 2015 at 10:56 PM, Terry Zink <= tzink@exchange.microsoft.com> wrote:

Thanks, this is useful.

What would the Authentication-Results header look like? Presumably 3 res= ults for DKIM (dkim=3Dfail, dkim=3Dpass, dkim=3Dpass)? And what about DMARC= ? Show one result or two? Or maybe something like dmarc=3Dconditionalpass?<= /p>

Three DKIM results, one DMARC "pass&q= uot; result.=C2=A0 The idea is that DKIM returns a "pass" for an = aligned conditional signature, which satisfies the DKIM algorithm, so long = as there's also a passing signature from the "cd" domain.
=
Is there any use in making a distinction to your acceptance/= routing of messages to know it was based on a conditional signature versus = an original author signature?

-MSK
<= /div> --f46d043c08c24c0e6b0516691861-- From nobody Mon May 18 23:09:58 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9760A1A1B65 for ; Mon, 18 May 2015 23:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEIbld1N89oP for ; Mon, 18 May 2015 23:09:55 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E8171A1B57 for ; Mon, 18 May 2015 23:09:55 -0700 (PDT) Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t4J69pVS017517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 18 May 2015 23:09:55 -0700 Message-ID: <555AD3AF.7060204@dcrocker.net> Date: Mon, 18 May 2015 23:09:51 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: R.E.Sonneveld@sonnection.nl, "dmarc@ietf.org" References: <555656FC.5010609@dcrocker.net> <555A282B.6050906@sonnection.nl> In-Reply-To: <555A282B.6050906@sonnection.nl> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 18 May 2015 23:09:55 -0700 (PDT) Archived-At: Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 06:09:56 -0000 On 5/18/2015 10:58 AM, Rolf E. Sonneveld wrote: >> The first question is: what are the 'types' of changes that have been >> or might be proposed? > > Please define 'changes'. Do you mean: changes which solve the 'p=reject' > problem for mail that is sent via an intermediary? Or just 'any' changes > that might help us a fraction to come closer to a solution. I meant things pretty generally, for this stage of the discussion. So I think 'any' changes that might help us a fraction. Basically, we need to develop some guidance for anyone suggesting an overall set of improvements. They need to have a way of assessing the likelihood that particular changes at the intermediary are or are not even worth discussing. Whether a particular proposal will entail enough benefit overall and small enough disruption or effort at the intermediary is a different matter. By way of example: Getting intermediaries to pay attention to dkim and spf validation is probably an easier step. However getting them all to use exactly the same wonderful MLM software that mailbox providers consider the very best for anti-spam, is probably in the realm of impossible. (And given the weaknesses of monocultures, it's also a terrible idea...) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue May 19 04:47:34 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297861B2E1F for ; Tue, 19 May 2015 04:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.497 X-Spam-Level: X-Spam-Status: No, score=0.497 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRW_P2L7KjBb for ; Tue, 19 May 2015 04:47:32 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 299081B2E17 for ; Tue, 19 May 2015 04:47:32 -0700 (PDT) Received: from [IPv6:2600:1003:b118:99b2:e03b:9605:f01b:b423] (unknown [IPv6:2600:1003:b118:99b2:e03b:9605:f01b:b423]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id AEA2BC40028; Tue, 19 May 2015 06:47:29 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1432036050; bh=fEwnyz7nLUncx4SHtGFqxHuTxy+V+GZxUK2XdgUhoRM=; h=In-Reply-To:References:Subject:From:Date:To:From; b=Yv0FmNXuq1b603t1D9pSePrWBot4Pu0mTCTbDAXDCjtaBZ6+K8X/idmHBYuxVfOOX Uv5HUo1dPzSulI0/xGUSH/bMbbn2lbxv/FkKX15ar9rLCEFShYoAlvoMtZtIcxR3yh 3tcnN/0yO/BQWKbT1pJtV2HwVQw0Xb60UFG8Xfzk= User-Agent: K-9 Mail for Android In-Reply-To: References: <555656FC.5010609@dcrocker.net> <1432015208815.92898@exchange.microsoft.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Tue, 19 May 2015 07:47:23 -0400 To: "dmarc@ietf.org" Message-ID: Archived-At: Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 11:47:33 -0000 On May 19, 2015 2:05:18 AM EDT, "Murray S. Kucherawy" wrote: >On Mon, May 18, 2015 at 10:56 PM, Terry Zink > >wrote: > >> Thanks, this is useful. >> >> What would the Authentication-Results header look like? Presumably 3 >> results for DKIM (dkim=fail, dkim=pass, dkim=pass)? And what about >DMARC? >> Show one result or two? Or maybe something like >dmarc=conditionalpass? >> >Three DKIM results, one DMARC "pass" result. The idea is that DKIM >returns >a "pass" for an aligned conditional signature, which satisfies the DKIM >algorithm, so long as there's also a passing signature from the "cd" >domain. > >Is there any use in making a distinction to your acceptance/routing of >messages to know it was based on a conditional signature versus an >original >author signature? I would think you'd have to. There's a replay risk that's unique to this type of signature, so I think treating them the same would be a naive approach. Scott K From nobody Tue May 19 06:31:23 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154151A8A98 for ; Tue, 19 May 2015 06:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3pY_tt-OdTq for ; Tue, 19 May 2015 06:31:20 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63FB81A8A7A for ; Tue, 19 May 2015 06:31:20 -0700 (PDT) Received: by wichy4 with SMTP id hy4so22553566wic.1 for ; Tue, 19 May 2015 06:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SPiw2NXUkMmqDDdLQdPT9WblmBnfojzymo1It7IrMF0=; b=wj/IKKFJ2qyyXXvuNc7BY+LIZrg0rfYHvTJxJL/gy7Wp43Z0WmJiOCD/Ka3PejGXuI iZNBl4sfSdqRFD2Tm4GgOew+Qh/s6+TlsVgMY2Vo148khI/iSuocEICffX0ONq9qs1+S Q1es0s6XXN456hQE0gOX9CC3SI/Tp5g2yReHP/oza2QhDrBzgDLY20Xx2RhT/ADnJ5IS BF+WYBsawLdEyjFIViRTNbQ3xmVYXylmb34TuSnuunf6sLg0WES+wDfUN/cgQiAT9ZBL vWWJYLCO0U0fW5adv2m5QsflMUeALtyIKnXFQ9ZEb4DWepUkzG0QDR8ynnSiDdPbqp+A B6XQ== MIME-Version: 1.0 X-Received: by 10.180.99.2 with SMTP id em2mr7583579wib.59.1432042279161; Tue, 19 May 2015 06:31:19 -0700 (PDT) Received: by 10.27.170.134 with HTTP; Tue, 19 May 2015 06:31:18 -0700 (PDT) In-Reply-To: References: <555656FC.5010609@dcrocker.net> <1432015208815.92898@exchange.microsoft.com> Date: Tue, 19 May 2015 06:31:18 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d04426c685a561505166f5382 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 13:31:22 -0000 --f46d04426c685a561505166f5382 Content-Type: text/plain; charset=UTF-8 On Tue, May 19, 2015 at 4:47 AM, Scott Kitterman wrote: > >Is there any use in making a distinction to your acceptance/routing of > >messages to know it was based on a conditional signature versus an > >original > >author signature? > > I would think you'd have to. There's a replay risk that's unique to this > type of signature, so I think treating them the same would be a naive > approach. > But is that something that an agent downstream of a verifier needs to know? A-R for SPF doesn't differentiate between "-all" and "~all", for example, nor does it relate key sizes or header field selection from DKIM. -MSK --f46d04426c685a561505166f5382 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 19, 2015 at 4:47 AM, Scott Kitterman <skli= st@kitterman.com> wrote:
<= div class=3D"h5">>Is there any use in making a distinction to your accep= tance/routing of
>messages to know it was based on a conditional signature versus an
>original
>author signature?

I would think you'd have to. There's a replay risk that= 's unique to this type of signature, so I think treating them the same = would be a naive approach.

But is that = something that an agent downstream of a verifier needs to know?

A-R for SPF doesn't differentiate between "-all" and &= quot;~all", for example, nor does it relate key sizes or header field = selection from DKIM.

-MSK
--f46d04426c685a561505166f5382-- From nobody Tue May 19 09:20:03 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461391A9124 for ; Tue, 19 May 2015 09:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbQVcDNRYNYX for ; Tue, 19 May 2015 09:20:00 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (mail-sn2ln0090.outbound.o365filtering.com [IPv6:2a01:111:f400:7c04::90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B91551A913D for ; Tue, 19 May 2015 09:19:56 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) with Microsoft SMTP Server (TLS) id 15.1.172.7; Tue, 19 May 2015 16:19:40 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.5.234]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.5.234]) with mapi id 15.01.0172.012; Tue, 19 May 2015 16:19:40 +0000 From: Terry Zink To: "Murray S. Kucherawy" , Scott Kitterman Thread-Topic: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy Thread-Index: AQHQkSLjmR8NgZwmBEqnwBkgIc5yZJ2CdTYQgAAL4QCAAE1PAYAAAuMAgABflICAAB0JAIAALQsQ Date: Tue, 19 May 2015 16:19:39 +0000 Message-ID: References: <555656FC.5010609@dcrocker.net> <1432015208815.92898@exchange.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.30] x-microsoft-exchange-diagnostics: 1; BL2SR01MB605; 3:LtGFzgIrZRT180hh8vDNS4LHUGnhS3F+14ou6HYa475REOW+qY9JBRJAame6VhyqL4r6nFIdC/L24w5e1BengGGK4pPM1eM66sAg/iIWNqqv5QnTCMHOzeV12FulDDTqCGHd0+S4f7r0igpllGJsWA==; 10:R8KMv3p9sQw5upfo2RMyvwT4JW9dU5gQi05xrl3kxLhJn537etwKJReSxmkyj1ARk+TKnenh0+j1ndZ1RcTwuie+/bmEnwFiIblHFugEB5k=; 6:UvkuzBJamNFl7gk9ZLP4IlFdRTi7SFr+Ksjg70uulDyJgu6EWGxP1yu9UJ/1FTwK x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB605; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(377454003)(199003)(189002)(24454002)(64706001)(93886004)(66066001)(2900100001)(86362001)(189998001)(33656002)(19609705001)(76176999)(4001540100001)(77156002)(62966003)(102836002)(15975445007)(106116001)(101416001)(19300405004)(5001960100002)(81156007)(2656002)(5001830100001)(19625215002)(106356001)(5001770100001)(68736005)(92566002)(16236675004)(105586002)(87936001)(5001860100001)(19580405001)(54356999)(2950100001)(46102003)(97736004)(50986999)(19580395003)(343044003)(48203002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB605; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005002)(5002009)(3002001); SRVR:BL2SR01MB605; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB605; x-forefront-prvs: 0581B5AB35 received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: multipart/alternative; boundary="_000_BL2SR01MB605E2B914F599D1870665F296C30BL2SR01MB605namsdf_" MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2015 16:19:39.9222 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB605 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 16:20:02 -0000 --_000_BL2SR01MB605E2B914F599D1870665F296C30BL2SR01MB605namsdf_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pj4gSSB3b3VsZCB0aGluayB5b3UnZCBoYXZlIHRvLiBUaGVyZSdzIGEgcmVwbGF5IHJpc2sgdGhh dCdzIHVuaXF1ZSB0byB0aGlzIHR5cGUgb2YNCj4+IHNpZ25hdHVyZSwgc28gSSB0aGluayB0cmVh dGluZyB0aGVtIHRoZSBzYW1lIHdvdWxkIGJlIGEgbmFpdmUgYXBwcm9hY2guDQoNCj4gQnV0IGlz IHRoYXQgc29tZXRoaW5nIHRoYXQgYW4gYWdlbnQgZG93bnN0cmVhbSBvZiBhIHZlcmlmaWVyIG5l ZWRzIHRvIGtub3c/DQo+IEEtUiBmb3IgU1BGIGRvZXNuJ3QgZGlmZmVyZW50aWF0ZSBiZXR3ZWVu ICItYWxsIiBhbmQgIn5hbGwiLCBmb3IgZXhhbXBsZSwgbm9yDQo+IGRvZXMgaXQgcmVsYXRlIGtl eSBzaXplcyBvciBoZWFkZXIgZmllbGQgc2VsZWN0aW9uIGZyb20gREtJTS4NCkl04oCZcyB1c2Vm dWwgZm9yIGRlYnVnZ2luZyBhZnRlcndhcmRzLiBTb21lb25lLCBzb21ld2hlcmUsIHdpbGwgc2Vu ZCBtZSBhIHNhbXBsZSBtZXNzYWdlIHRoYXQgcGFzc2VkIERNQVJDIHdoZW4gaXQgc2hvdWxkbuKA mXQgaGF2ZSAoYnV0IGluIHJlYWxpdHkgcGFzc2VkIGJlY2F1c2Ugb2YgYSBjb25kaXRpb25hbCBE S0lNKSBhbmQgaXTigJlzIHVzZWZ1bCB0byBoYXZlIHRoaXMgaW4gdGhlIHJlc3VsdHMuDQoNCkEt UiBmb3IgU1BGIGRvZXNu4oCZdCBtYXR0ZXIgZm9yIH5hbGwgYW5kIOKAk2FsbCBiZWNhdXNlIHRo ZSBJUCBpcyBmb3VuZCB3aXRoaW4gdGhlIFNQRiByZWNvcmQuIERLSU0gZm9yIGtleSBzaXplIGRv ZXNu4oCZdCBtYXR0ZXIgYmVjYXVzZSBhIHdlYWsga2V5IGlzIGlnbm9yZWQuIEkgdGhpbmsgY29u ZGl0aW9uYWwgRE1BUkMgZG9lcyBtYXR0ZXIgYmVjYXVzZSB0aGVyZeKAmXMgc3RpbGwgYSBzbWFs bCB0aW1lIHdpbmRvdyB3aGVyZSB0aGUgb3JpZ2luYWwgbWVzc2FnZS9hdXRob3IgaXMgdnVsbmVy YWJsZSB0byBhIHJlcGxheSBhdHRhY2ssIGFuZCBhIGNvbmRpdGlvbmFsIERNQVJDIHBhc3MgaXMg YWxtb3N0LCBidXQgbm90IHF1aXRlIGFzIHN0cm9uZyBhcyBhIHJlZ3VsYXIgRE1BUkMgcGFzcy4N Cg0KLS0gVGVycnkNCg0KRnJvbTogZG1hcmMgW21haWx0bzpkbWFyYy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgTXVycmF5IFMuIEt1Y2hlcmF3eQ0KU2VudDogVHVlc2RheSwgTWF5IDE5 LCAyMDE1IDY6MzEgQU0NClRvOiBTY290dCBLaXR0ZXJtYW4NCkNjOiBkbWFyY0BpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtkbWFyYy1pZXRmXSBMb29raW5nIGZvciBkZWdyZWVzIG9mIGZyZWVkb20g d2l0aCBJbnRlcm1lZGlhcmllcyAtIEVmZm9ydCBhbmQgUG9saWN5DQoNCk9uIFR1ZSwgTWF5IDE5 LCAyMDE1IGF0IDQ6NDcgQU0sIFNjb3R0IEtpdHRlcm1hbiA8c2tsaXN0QGtpdHRlcm1hbi5jb208 bWFpbHRvOnNrbGlzdEBraXR0ZXJtYW4uY29tPj4gd3JvdGU6DQo+SXMgdGhlcmUgYW55IHVzZSBp biBtYWtpbmcgYSBkaXN0aW5jdGlvbiB0byB5b3VyIGFjY2VwdGFuY2Uvcm91dGluZyBvZg0KPm1l c3NhZ2VzIHRvIGtub3cgaXQgd2FzIGJhc2VkIG9uIGEgY29uZGl0aW9uYWwgc2lnbmF0dXJlIHZl cnN1cyBhbg0KPm9yaWdpbmFsDQo+YXV0aG9yIHNpZ25hdHVyZT8NCkkgd291bGQgdGhpbmsgeW91 J2QgaGF2ZSB0by4gVGhlcmUncyBhIHJlcGxheSByaXNrIHRoYXQncyB1bmlxdWUgdG8gdGhpcyB0 eXBlIG9mIHNpZ25hdHVyZSwgc28gSSB0aGluayB0cmVhdGluZyB0aGVtIHRoZSBzYW1lIHdvdWxk IGJlIGEgbmFpdmUgYXBwcm9hY2guDQoNCkJ1dCBpcyB0aGF0IHNvbWV0aGluZyB0aGF0IGFuIGFn ZW50IGRvd25zdHJlYW0gb2YgYSB2ZXJpZmllciBuZWVkcyB0byBrbm93Pw0KQS1SIGZvciBTUEYg ZG9lc24ndCBkaWZmZXJlbnRpYXRlIGJldHdlZW4gIi1hbGwiIGFuZCAifmFsbCIsIGZvciBleGFt cGxlLCBub3IgZG9lcyBpdCByZWxhdGUga2V5IHNpemVzIG9yIGhlYWRlciBmaWVsZCBzZWxlY3Rp b24gZnJvbSBES0lNLg0KLU1TSw0K --_000_BL2SR01MB605E2B914F599D1870665F296C30BL2SR01MB605namsdf_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFw aCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxl LXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFy Z2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+ Jmd0OyZndDsgSSB3b3VsZCB0aGluayB5b3UnZCBoYXZlIHRvLiBUaGVyZSdzIGEgcmVwbGF5IHJp c2sgdGhhdCdzIHVuaXF1ZSB0byB0aGlzIHR5cGUgb2YNCjxvOnA+PC9vOnA+PC9hPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmZ3Q7IHNpZ25hdHVyZSwgc28gSSB0aGluayB0cmVhdGlu ZyB0aGVtIHRoZSBzYW1lIHdvdWxkIGJlIGEgbmFpdmUgYXBwcm9hY2guPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jmd0OyBCdXQgaXMgdGhhdCBz b21ldGhpbmcgdGhhdCBhbiBhZ2VudCBkb3duc3RyZWFtIG9mIGEgdmVyaWZpZXIgbmVlZHMgdG8g a25vdz88YnI+DQomZ3Q7IEEtUiBmb3IgU1BGIGRvZXNuJ3QgZGlmZmVyZW50aWF0ZSBiZXR3ZWVu ICZxdW90Oy1hbGwmcXVvdDsgYW5kICZxdW90O35hbGwmcXVvdDssIGZvciBleGFtcGxlLCBub3Ig PGJyPg0KJmd0OyBkb2VzIGl0IHJlbGF0ZSBrZXkgc2l6ZXMgb3IgaGVhZGVyIGZpZWxkIHNlbGVj dGlvbiBmcm9tIERLSU0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkl04oCZcyB1c2VmdWwgZm9yIGRl YnVnZ2luZyBhZnRlcndhcmRzLiBTb21lb25lLCBzb21ld2hlcmUsIHdpbGwgc2VuZCBtZSBhIHNh bXBsZSBtZXNzYWdlIHRoYXQgcGFzc2VkIERNQVJDIHdoZW4gaXQgc2hvdWxkbuKAmXQgaGF2ZSAo YnV0IGluIHJlYWxpdHkgcGFzc2VkIGJlY2F1c2UNCiBvZiBhIGNvbmRpdGlvbmFsIERLSU0pIGFu ZCBpdOKAmXMgdXNlZnVsIHRvIGhhdmUgdGhpcyBpbiB0aGUgcmVzdWx0cy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QS1SIGZv ciBTUEYgZG9lc27igJl0IG1hdHRlciBmb3IgfmFsbCBhbmQg4oCTYWxsIGJlY2F1c2UgdGhlIElQ IGlzIGZvdW5kIHdpdGhpbiB0aGUgU1BGIHJlY29yZC4gREtJTSBmb3Iga2V5IHNpemUgZG9lc27i gJl0IG1hdHRlciBiZWNhdXNlIGEgd2VhayBrZXkgaXMgaWdub3JlZC4gSQ0KIHRoaW5rIGNvbmRp dGlvbmFsIERNQVJDIGRvZXMgbWF0dGVyIGJlY2F1c2UgdGhlcmXigJlzIHN0aWxsIGEgc21hbGwg dGltZSB3aW5kb3cgd2hlcmUgdGhlIG9yaWdpbmFsIG1lc3NhZ2UvYXV0aG9yIGlzIHZ1bG5lcmFi bGUgdG8gYSByZXBsYXkgYXR0YWNrLCBhbmQgYSBjb25kaXRpb25hbCBETUFSQyBwYXNzIGlzIGFs bW9zdCwgYnV0IG5vdCBxdWl0ZSBhcyBzdHJvbmcgYXMgYSByZWd1bGFyIERNQVJDIHBhc3MuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPi0tIFRlcnJ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBk bWFyYyBbbWFpbHRvOmRtYXJjLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9i Pk11cnJheSBTLiBLdWNoZXJhd3k8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTWF5IDE5LCAy MDE1IDY6MzEgQU08YnI+DQo8Yj5Ubzo8L2I+IFNjb3R0IEtpdHRlcm1hbjxicj4NCjxiPkNjOjwv Yj4gZG1hcmNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtkbWFyYy1pZXRmXSBM b29raW5nIGZvciBkZWdyZWVzIG9mIGZyZWVkb20gd2l0aCBJbnRlcm1lZGlhcmllcyAtIEVmZm9y dCBhbmQgUG9saWN5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVl LCBNYXkgMTksIDIwMTUgYXQgNDo0NyBBTSwgU2NvdHQgS2l0dGVybWFuICZsdDs8YSBocmVmPSJt YWlsdG86c2tsaXN0QGtpdHRlcm1hbi5jb20iIHRhcmdldD0iX2JsYW5rIj5za2xpc3RAa2l0dGVy bWFuLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPiZndDtJcyB0aGVyZSBhbnkgdXNlIGluIG1ha2luZyBhIGRpc3RpbmN0 aW9uIHRvIHlvdXIgYWNjZXB0YW5jZS9yb3V0aW5nIG9mPGJyPg0KJmd0O21lc3NhZ2VzIHRvIGtu b3cgaXQgd2FzIGJhc2VkIG9uIGEgY29uZGl0aW9uYWwgc2lnbmF0dXJlIHZlcnN1cyBhbjxicj4N CiZndDtvcmlnaW5hbDxicj4NCiZndDthdXRob3Igc2lnbmF0dXJlPzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgdGhpbmsgeW91J2Qg aGF2ZSB0by4gVGhlcmUncyBhIHJlcGxheSByaXNrIHRoYXQncyB1bmlxdWUgdG8gdGhpcyB0eXBl IG9mIHNpZ25hdHVyZSwgc28gSSB0aGluayB0cmVhdGluZyB0aGVtIHRoZSBzYW1lIHdvdWxkIGJl IGEgbmFpdmUgYXBwcm9hY2guPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkJ1dCBp cyB0aGF0IHNvbWV0aGluZyB0aGF0IGFuIGFnZW50IGRvd25zdHJlYW0gb2YgYSB2ZXJpZmllciBu ZWVkcyB0byBrbm93PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5BLVIgZm9yIFNQRiBkb2Vzbid0 IGRpZmZlcmVudGlhdGUgYmV0d2VlbiAmcXVvdDstYWxsJnF1b3Q7IGFuZCAmcXVvdDt+YWxsJnF1 b3Q7LCBmb3IgZXhhbXBsZSwgbm9yIGRvZXMgaXQgcmVsYXRlIGtleSBzaXplcyBvciBoZWFkZXIg ZmllbGQgc2VsZWN0aW9uIGZyb20gREtJTS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1NU0sgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BL2SR01MB605E2B914F599D1870665F296C30BL2SR01MB605namsdf_-- From nobody Tue May 19 10:56:15 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38A11A8997 for ; Tue, 19 May 2015 10:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDfaHFGZom1X for ; Tue, 19 May 2015 10:56:12 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F16E11A1ABE for ; Tue, 19 May 2015 10:56:10 -0700 (PDT) Received: by wgjc11 with SMTP id c11so26796621wgj.0 for ; Tue, 19 May 2015 10:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QM2BjNqJpEAs3euk8QSuW5fG2zhWTFX5ioDufXlYmq8=; b=G2wcXDL5eAga1GuBCaxGXuTzsHhAn1HWGj7zf5QSj2vnhdvFd3+YMuUEbquIv5ILNJ E/dhcIV0Xm9nS6VuSmgK5peFDlfJYvgc4XxvAvK6oejloOboR1WKjk7uxgViUA5+aXxu 1nAUmFga/9qbcNCQae1o8h3/MYgUM9AowYbldnOOXIDcHPBoj5vMOvHF3FpY5YzBiGOb oxc+rt0m/GTWdSMe/cli4obXasVfFZnrRzz1DN6dXQ0EeXDbL0qjuie4uDVH9kraEf1O bUTTQfb7G9AispqRmoWG8thbxh0lmrY5HBYHPTndL9J+dLKFb6aew64wFJ+SjrB5rUBH IqFw== MIME-Version: 1.0 X-Received: by 10.194.174.68 with SMTP id bq4mr40783189wjc.4.1432058169594; Tue, 19 May 2015 10:56:09 -0700 (PDT) Received: by 10.27.170.134 with HTTP; Tue, 19 May 2015 10:56:09 -0700 (PDT) In-Reply-To: References: <555656FC.5010609@dcrocker.net> <1432015208815.92898@exchange.microsoft.com> Date: Tue, 19 May 2015 10:56:09 -0700 Message-ID: From: "Murray S. Kucherawy" To: Terry Zink Content-Type: multipart/alternative; boundary=089e014936807f1b62051673063b Archived-At: Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 17:56:14 -0000 --089e014936807f1b62051673063b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, May 19, 2015 at 9:19 AM, Terry Zink wrote: > >> I would think you'd have to. There's a replay risk that's unique to > this type of > > >> signature, so I think treating them the same would be a naive approach= . > > > > > But is that something that an agent downstream of a verifier needs to > know? > > A-R for SPF doesn't differentiate between "-all" and "~all", for > example, nor > > does it relate key sizes or header field selection from DKIM. > > It=E2=80=99s useful for debugging afterwards. Someone, somewhere, will se= nd me a > sample message that passed DMARC when it shouldn=E2=80=99t have (but in r= eality > passed because of a conditional DKIM) and it=E2=80=99s useful to have thi= s in the > results. > Sure, but can it just be in a comment if you find that useful, or is it necessary to make that fact something a consumer of the field can parse out= ? The idea behind A-R all along has been to be able to say "method X passed/failed/whatever for this message, and the things it authenticated are A and B". I've always found the details of how it came to that conclusion to be of only secondary interest because: a) They might no longer be true at the time an MUA processes that header field; this is supposed to reflect what the ingress MTA saw. b) The goal is specifically not to allow MUAs or downstream agents to repeat the authentications done at the ingress MTA, otherwise why bother having the border MTA do it? There's also a DDoS possibility if every MUA or downstream agent repeats checks. c) Having to keep all the MUAs current on message authentication techniques is a much bigger burden than just updating ingress MTAs, so that model is observed. See RFC7001, Appendix D, for details. -MSK --089e014936807f1b62051673063b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 19, 2015 at 9:19 AM, Terry Zink <t= zink@exchange.microsoft.com> wrote:

>>= ; I would think you'd have to. There's a replay risk that's uni= que to this type of

>> signature, so I think treating them the sam= e would be a naive approach.

=C2=A0

> But is that some= thing that an agent downstream of a verifier needs to know?
> A-R for SPF doesn't differentiate between "-all" and &qu= ot;~all", for example, nor
> does it relate key sizes or header field selection from DKIM.

It=E2=80=99s useful = for debugging afterwards. Someone, somewhere, will send me a sample message= that passed DMARC when it shouldn=E2=80=99t have (but in reality passed be= cause of a conditional DKIM) and it=E2=80=99s useful to have this in the results= .


Sure, but can it j= ust be in a comment if you find that useful, or is it necessary to make tha= t fact something a consumer of the field can parse out?

T= he idea behind A-R all along has been to be able to say "method X pass= ed/failed/whatever for this message, and the things it authenticated are A = and B".=C2=A0 I've always found the details of how it came to that= conclusion to be of only secondary interest because:

a) = They might no longer be true at the time an MUA processes that header field= ; this is supposed to reflect what the ingress MTA saw.

b= ) The goal is specifically not to allow MUAs or downstream agents to repeat= the authentications done at the ingress MTA, otherwise why bother having t= he border MTA do it?=C2=A0 There's also a DDoS possibility if every MUA= or downstream agent repeats checks.

c) Having to keep al= l the MUAs current on message authentication techniques is a much bigger bu= rden than just updating ingress MTAs, so that model is observed.

See RFC7001, Appendix D, for details.

-MSK
--089e014936807f1b62051673063b-- From nobody Tue May 19 11:25:35 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFDF41A00B6 for ; Tue, 19 May 2015 11:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ao5BGOhwYLiQ for ; Tue, 19 May 2015 11:25:31 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (mail-sn2ln0088.outbound.o365filtering.com [IPv6:2a01:111:f400:7c04::88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11D7D1A9129 for ; Tue, 19 May 2015 11:24:52 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB606.namsdf01.sdf.exchangelabs.com (10.255.109.168) with Microsoft SMTP Server (TLS) id 15.1.172.7; Tue, 19 May 2015 18:24:35 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.5.234]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.5.234]) with mapi id 15.01.0172.012; Tue, 19 May 2015 18:24:35 +0000 From: Terry Zink To: "Murray S. Kucherawy" Thread-Topic: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy Thread-Index: AQHQkSLjmR8NgZwmBEqnwBkgIc5yZJ2CdTYQgAAL4QCAAE1PAYAAAuMAgABflICAAB0JAIAALQsQgAAc9ICAAAbY0A== Date: Tue, 19 May 2015 18:24:35 +0000 Message-ID: References: <555656FC.5010609@dcrocker.net> <1432015208815.92898@exchange.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.30] x-microsoft-exchange-diagnostics: 1; BL2SR01MB606; 3:kfH5RIdZpAH1Ux+IPsK+qk0CLxVISuq6Fpu2F05wdwot30LPfaISzSYCv670goQNtGBKKX+8SW9R+LPhqrXkmWa/Q2sw7uai7iyOHVdv4Kq2rIfwGqDAK2SkoWjLR7ATFWyWZqnU+U9REya8mTup9g==; 10:LVES3YpIhs/pqgG2Xy/J8mEpJVDdR7jJXunGJQCy8zmO9YrugVfzEj2kYJoz3OJVt9QAyb2R3v9O1LZDwAwIG0opsC6I3wKT3xy0TQ8VpDQ=; 6:pp0If9g7QLa3waIN+Ju+Hw5017dOPZQ+F7cJDqo9iPezHnSc7kS8u1IHlh7eUe9P x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB606; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(189002)(377454003)(199003)(24454002)(19300405004)(101416001)(5001830100001)(106356001)(19625215002)(81156007)(5001960100002)(2656002)(76176999)(110136002)(4001540100001)(1411001)(102836002)(62966003)(106116001)(15975445007)(77156002)(54356999)(2950100001)(46102003)(19580405001)(19580395003)(50986999)(97736004)(68736005)(92566002)(16236675004)(5001860100001)(87936001)(105586002)(66066001)(93886004)(2900100001)(64706001)(5890100001)(33656002)(189998001)(86362001)(48203002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB606; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005002)(5002009)(3002001); SRVR:BL2SR01MB606; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB606; x-forefront-prvs: 0581B5AB35 received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: multipart/alternative; boundary="_000_BL2SR01MB605139131216D39D517127396C30BL2SR01MB605namsdf_" MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2015 18:24:35.3842 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB606 Archived-At: Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 18:25:34 -0000 --_000_BL2SR01MB605139131216D39D517127396C30BL2SR01MB605namsdf_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBTdXJlLCBidXQgY2FuIGl0IGp1c3QgYmUgaW4gYSBjb21tZW50IGlmIHlvdSBmaW5kIHRoYXQg dXNlZnVsLCBvciBpcyBpdCBuZWNlc3NhcnkgdG8NCj4gbWFrZSB0aGF0IGZhY3Qgc29tZXRoaW5n IGEgY29uc3VtZXIgb2YgdGhlIGZpZWxkIGNhbiBwYXJzZSBvdXQ/DQpQdXR0aW5nIGl0IGludG8g YSBjb21tZW50IGlzIGZpbmUsIG1heWJlIHNvbWV0aGluZyBsaWtlIOKAnGRtYXJjPXBhc3MgYWN0 aW9uPW5vbmUgaGVhZGVyLmZyb209PGRvbWFpbi5jb20+IGNvbmRpdGlvbmFsLnRvPTxtYWlsaW5n bGlzdC5uZXQ+4oCdLiBJIHRoaW5rIGl04oCZcyBwZXJtaXNzaWJsZSB0byBhZGQgYWRkaXRpb25h bCBmaWVsZHMgbGlrZSB0aGF0IGludG8gQS1SLCBpc27igJl0IGl0Pw0KDQo+IEkndmUgYWx3YXlz IGZvdW5kIHRoZSBkZXRhaWxzIG9mIGhvdyBpdCBjYW1lIHRvIHRoYXQgY29uY2x1c2lvbiB0byBi ZSBvZiBvbmx5IHNlY29uZGFyeSBpbnRlcmVzdA0KDQpJIGFncmVlIHdpdGggdGhlIHJlYXNvbnMg eW91IG91dGxpbmUsIGJ1dCB3aGVuIGRlYnVnZ2luZyBhbmQgdHJvdWJsZXNob290aW5nIHBvdGVu dGlhbGx5IHRlbnMsIGh1bmRyZWRzLCBvciB0aG91c2FuZHMgb2YgbWVzc2FnZXMgcGVyIGRheSwg aXTigJlzIG5vIGxvbmdlciBzZWNvbmRhcnkuIEl04oCZcyBhbHNvIGVhc2llciB0byBjb2xsZWN0 IHN0YXRpc3RpY3Mgb24gaG93IG1hbnkgbWVzc2FnZXMgYXJlIGNvbmRpdGlvbmFsbHkgcGFzc2lu ZyBETUFSQyBhbmQgd2hhdCBtYWlsaW5nIGxpc3Qgb3IgZm9yd2FyZGVyIGl0IGlzIGF0dGFjaGVk IHRvLg0KDQotLSBUZXJyeQ0KDQpGcm9tOiBNdXJyYXkgUy4gS3VjaGVyYXd5IFttYWlsdG86c3Vw ZXJ1c2VyQGdtYWlsLmNvbV0NClNlbnQ6IFR1ZXNkYXksIE1heSAxOSwgMjAxNSAxMDo1NiBBTQ0K VG86IFRlcnJ5IFppbmsNCkNjOiBTY290dCBLaXR0ZXJtYW47IGRtYXJjQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW2RtYXJjLWlldGZdIExvb2tpbmcgZm9yIGRlZ3JlZXMgb2YgZnJlZWRvbSB3aXRo IEludGVybWVkaWFyaWVzIC0gRWZmb3J0IGFuZCBQb2xpY3kNCg0KT24gVHVlLCBNYXkgMTksIDIw MTUgYXQgOToxOSBBTSwgVGVycnkgWmluayA8dHppbmtAZXhjaGFuZ2UubWljcm9zb2Z0LmNvbTxt YWlsdG86dHppbmtAZXhjaGFuZ2UubWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KPj4gSSB3b3VsZCB0 aGluayB5b3UnZCBoYXZlIHRvLiBUaGVyZSdzIGEgcmVwbGF5IHJpc2sgdGhhdCdzIHVuaXF1ZSB0 byB0aGlzIHR5cGUgb2YNCj4+IHNpZ25hdHVyZSwgc28gSSB0aGluayB0cmVhdGluZyB0aGVtIHRo ZSBzYW1lIHdvdWxkIGJlIGEgbmFpdmUgYXBwcm9hY2guDQoNCj4gQnV0IGlzIHRoYXQgc29tZXRo aW5nIHRoYXQgYW4gYWdlbnQgZG93bnN0cmVhbSBvZiBhIHZlcmlmaWVyIG5lZWRzIHRvIGtub3c/ DQo+IEEtUiBmb3IgU1BGIGRvZXNuJ3QgZGlmZmVyZW50aWF0ZSBiZXR3ZWVuICItYWxsIiBhbmQg In5hbGwiLCBmb3IgZXhhbXBsZSwgbm9yDQo+IGRvZXMgaXQgcmVsYXRlIGtleSBzaXplcyBvciBo ZWFkZXIgZmllbGQgc2VsZWN0aW9uIGZyb20gREtJTS4NCkl04oCZcyB1c2VmdWwgZm9yIGRlYnVn Z2luZyBhZnRlcndhcmRzLiBTb21lb25lLCBzb21ld2hlcmUsIHdpbGwgc2VuZCBtZSBhIHNhbXBs ZSBtZXNzYWdlIHRoYXQgcGFzc2VkIERNQVJDIHdoZW4gaXQgc2hvdWxkbuKAmXQgaGF2ZSAoYnV0 IGluIHJlYWxpdHkgcGFzc2VkIGJlY2F1c2Ugb2YgYSBjb25kaXRpb25hbCBES0lNKSBhbmQgaXTi gJlzIHVzZWZ1bCB0byBoYXZlIHRoaXMgaW4gdGhlIHJlc3VsdHMuDQoNClN1cmUsIGJ1dCBjYW4g aXQganVzdCBiZSBpbiBhIGNvbW1lbnQgaWYgeW91IGZpbmQgdGhhdCB1c2VmdWwsIG9yIGlzIGl0 IG5lY2Vzc2FyeSB0byBtYWtlIHRoYXQgZmFjdCBzb21ldGhpbmcgYSBjb25zdW1lciBvZiB0aGUg ZmllbGQgY2FuIHBhcnNlIG91dD8NClRoZSBpZGVhIGJlaGluZCBBLVIgYWxsIGFsb25nIGhhcyBi ZWVuIHRvIGJlIGFibGUgdG8gc2F5ICJtZXRob2QgWCBwYXNzZWQvZmFpbGVkL3doYXRldmVyIGZv ciB0aGlzIG1lc3NhZ2UsIGFuZCB0aGUgdGhpbmdzIGl0IGF1dGhlbnRpY2F0ZWQgYXJlIEEgYW5k IEIiLiAgSSd2ZSBhbHdheXMgZm91bmQgdGhlIGRldGFpbHMgb2YgaG93IGl0IGNhbWUgdG8gdGhh dCBjb25jbHVzaW9uIHRvIGJlIG9mIG9ubHkgc2Vjb25kYXJ5IGludGVyZXN0IGJlY2F1c2U6DQph KSBUaGV5IG1pZ2h0IG5vIGxvbmdlciBiZSB0cnVlIGF0IHRoZSB0aW1lIGFuIE1VQSBwcm9jZXNz ZXMgdGhhdCBoZWFkZXIgZmllbGQ7IHRoaXMgaXMgc3VwcG9zZWQgdG8gcmVmbGVjdCB3aGF0IHRo ZSBpbmdyZXNzIE1UQSBzYXcuDQpiKSBUaGUgZ29hbCBpcyBzcGVjaWZpY2FsbHkgbm90IHRvIGFs bG93IE1VQXMgb3IgZG93bnN0cmVhbSBhZ2VudHMgdG8gcmVwZWF0IHRoZSBhdXRoZW50aWNhdGlv bnMgZG9uZSBhdCB0aGUgaW5ncmVzcyBNVEEsIG90aGVyd2lzZSB3aHkgYm90aGVyIGhhdmluZyB0 aGUgYm9yZGVyIE1UQSBkbyBpdD8gIFRoZXJlJ3MgYWxzbyBhIEREb1MgcG9zc2liaWxpdHkgaWYg ZXZlcnkgTVVBIG9yIGRvd25zdHJlYW0gYWdlbnQgcmVwZWF0cyBjaGVja3MuDQpjKSBIYXZpbmcg dG8ga2VlcCBhbGwgdGhlIE1VQXMgY3VycmVudCBvbiBtZXNzYWdlIGF1dGhlbnRpY2F0aW9uIHRl Y2huaXF1ZXMgaXMgYSBtdWNoIGJpZ2dlciBidXJkZW4gdGhhbiBqdXN0IHVwZGF0aW5nIGluZ3Jl c3MgTVRBcywgc28gdGhhdCBtb2RlbCBpcyBvYnNlcnZlZC4NClNlZSBSRkM3MDAxLCBBcHBlbmRp eCBELCBmb3IgZGV0YWlscy4NCi1NU0sNCg== --_000_BL2SR01MB605139131216D39D517127396C30BL2SR01MB605namsdf_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFw aCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxl LXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFy Z2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj4mZ3Q7IFN1cmUsIGJ1dCBjYW4gaXQganVzdCBi ZSBpbiBhIGNvbW1lbnQgaWYgeW91IGZpbmQgdGhhdCB1c2VmdWwsIG9yIGlzIGl0IG5lY2Vzc2Fy eSB0bw0KPGJyPg0KJmd0OyBtYWtlIHRoYXQgZmFjdCBzb21ldGhpbmcgYSBjb25zdW1lciBvZiB0 aGUgZmllbGQgY2FuIHBhcnNlIG91dD88bzpwPjwvbzpwPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlB1dHRpbmcg aXQgaW50byBhIGNvbW1lbnQgaXMgZmluZSwgbWF5YmUgc29tZXRoaW5nIGxpa2Ug4oCcZG1hcmM9 cGFzcyBhY3Rpb249bm9uZSBoZWFkZXIuZnJvbT0mbHQ7ZG9tYWluLmNvbSZndDsgY29uZGl0aW9u YWwudG89Jmx0O21haWxpbmdsaXN0Lm5ldCZndDvigJ0uIEkgdGhpbmsgaXTigJlzIHBlcm1pc3Np YmxlDQogdG8gYWRkIGFkZGl0aW9uYWwgZmllbGRzIGxpa2UgdGhhdCBpbnRvIEEtUiwgaXNu4oCZ dCBpdD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgSSd2ZSBhbHdheXMgZm91bmQgdGhlIGRl dGFpbHMgb2YgaG93IGl0IGNhbWUgdG8gdGhhdCBjb25jbHVzaW9uIHRvIGJlIG9mIG9ubHkgc2Vj b25kYXJ5IGludGVyZXN0PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxicj4NCkkgYWdyZWUgd2l0aCB0aGUgcmVhc29u cyB5b3Ugb3V0bGluZSwgYnV0IHdoZW4gZGVidWdnaW5nIGFuZCB0cm91Ymxlc2hvb3RpbmcgcG90 ZW50aWFsbHkgdGVucywgaHVuZHJlZHMsIG9yIHRob3VzYW5kcyBvZiBtZXNzYWdlcyBwZXIgZGF5 LCBpdOKAmXMgbm8gbG9uZ2VyIHNlY29uZGFyeS4gSXTigJlzIGFsc28gZWFzaWVyIHRvIGNvbGxl Y3Qgc3RhdGlzdGljcyBvbiBob3cgbWFueSBtZXNzYWdlcyBhcmUgY29uZGl0aW9uYWxseSBwYXNz aW5nIERNQVJDDQogYW5kIHdoYXQgbWFpbGluZyBsaXN0IG9yIGZvcndhcmRlciBpdCBpcyBhdHRh Y2hlZCB0by48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+LS0gVGVycnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IE11cnJheSBTLiBLdWNoZXJhd3kgW21haWx0bzpzdXBlcnVzZXJAZ21haWwuY29t XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE1heSAxOSwgMjAxNSAxMDo1NiBBTTxicj4N CjxiPlRvOjwvYj4gVGVycnkgWmluazxicj4NCjxiPkNjOjwvYj4gU2NvdHQgS2l0dGVybWFuOyBk bWFyY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2RtYXJjLWlldGZdIExvb2tp bmcgZm9yIGRlZ3JlZXMgb2YgZnJlZWRvbSB3aXRoIEludGVybWVkaWFyaWVzIC0gRWZmb3J0IGFu ZCBQb2xpY3k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIE1h eSAxOSwgMjAxNSBhdCA5OjE5IEFNLCBUZXJyeSBaaW5rICZsdDs8YSBocmVmPSJtYWlsdG86dHpp bmtAZXhjaGFuZ2UubWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnR6aW5rQGV4Y2hhbmdl Lm1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBu YW1lPSIxNGQ2Y2Y5M2FhMDZiNzkwX19NYWlsRW5kQ29tcG9zZSI+Jmd0OyZndDsgSSB3b3VsZCB0 aGluayB5b3UnZCBoYXZlIHRvLiBUaGVyZSdzIGEgcmVwbGF5IHJpc2sgdGhhdCdzIHVuaXF1ZSB0 byB0aGlzIHR5cGUgb2YNCjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jmd0OyZndDsgc2lnbmF0dXJlLCBzbyBJIHRoaW5rIHRyZWF0aW5nIHRoZW0gdGhlIHNhbWUg d291bGQgYmUgYSBuYWl2ZSBhcHByb2FjaC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPiZndDsgQnV0 IGlzIHRoYXQgc29tZXRoaW5nIHRoYXQgYW4gYWdlbnQgZG93bnN0cmVhbSBvZiBhIHZlcmlmaWVy IG5lZWRzIHRvIGtub3c/PGJyPg0KJmd0OyBBLVIgZm9yIFNQRiBkb2Vzbid0IGRpZmZlcmVudGlh dGUgYmV0d2VlbiAmcXVvdDstYWxsJnF1b3Q7IGFuZCAmcXVvdDt+YWxsJnF1b3Q7LCBmb3IgZXhh bXBsZSwgbm9yIDxicj4NCiZndDsgZG9lcyBpdCByZWxhdGUga2V5IHNpemVzIG9yIGhlYWRlciBm aWVsZCBzZWxlY3Rpb24gZnJvbSBES0lNLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkl04oCZcyB1 c2VmdWwgZm9yIGRlYnVnZ2luZyBhZnRlcndhcmRzLiBTb21lb25lLCBzb21ld2hlcmUsIHdpbGwg c2VuZCBtZSBhIHNhbXBsZSBtZXNzYWdlIHRoYXQgcGFzc2VkDQogRE1BUkMgd2hlbiBpdCBzaG91 bGRu4oCZdCBoYXZlIChidXQgaW4gcmVhbGl0eSBwYXNzZWQgYmVjYXVzZSBvZiBhIGNvbmRpdGlv bmFsIERLSU0pIGFuZCBpdOKAmXMgdXNlZnVsIHRvIGhhdmUgdGhpcyBpbiB0aGUgcmVzdWx0cy48 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5T dXJlLCBidXQgY2FuIGl0IGp1c3QgYmUgaW4gYSBjb21tZW50IGlmIHlvdSBmaW5kIHRoYXQgdXNl ZnVsLCBvciBpcyBpdCBuZWNlc3NhcnkgdG8gbWFrZSB0aGF0IGZhY3Qgc29tZXRoaW5nIGEgY29u c3VtZXIgb2YgdGhlIGZpZWxkIGNhbiBwYXJzZSBvdXQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PlRoZSBpZGVhIGJlaGluZCBBLVIgYWxsIGFsb25nIGhhcyBiZWVuIHRvIGJlIGFibGUgdG8gc2F5 ICZxdW90O21ldGhvZCBYIHBhc3NlZC9mYWlsZWQvd2hhdGV2ZXIgZm9yIHRoaXMgbWVzc2FnZSwg YW5kIHRoZSB0aGluZ3MgaXQgYXV0aGVudGljYXRlZCBhcmUgQSBhbmQgQiZxdW90Oy4mbmJzcDsg SSd2ZSBhbHdheXMgZm91bmQgdGhlIGRldGFpbHMgb2YgaG93IGl0IGNhbWUgdG8gdGhhdA0KIGNv bmNsdXNpb24gdG8gYmUgb2Ygb25seSBzZWNvbmRhcnkgaW50ZXJlc3QgYmVjYXVzZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+YSkgVGhleSBtaWdodCBubyBsb25nZXIgYmUgdHJ1ZSBhdCB0aGUg dGltZSBhbiBNVUEgcHJvY2Vzc2VzIHRoYXQgaGVhZGVyIGZpZWxkOyB0aGlzIGlzIHN1cHBvc2Vk IHRvIHJlZmxlY3Qgd2hhdCB0aGUgaW5ncmVzcyBNVEEgc2F3LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij5iKSBUaGUgZ29hbCBpcyBzcGVjaWZpY2FsbHkgbm90IHRvIGFsbG93IE1VQXMgb3IgZG93 bnN0cmVhbSBhZ2VudHMgdG8gcmVwZWF0IHRoZSBhdXRoZW50aWNhdGlvbnMgZG9uZSBhdCB0aGUg aW5ncmVzcyBNVEEsIG90aGVyd2lzZSB3aHkgYm90aGVyIGhhdmluZyB0aGUgYm9yZGVyIE1UQSBk byBpdD8mbmJzcDsgVGhlcmUncyBhbHNvIGEgRERvUyBwb3NzaWJpbGl0eSBpZg0KIGV2ZXJ5IE1V QSBvciBkb3duc3RyZWFtIGFnZW50IHJlcGVhdHMgY2hlY2tzLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij5jKSBIYXZpbmcgdG8ga2VlcCBhbGwgdGhlIE1VQXMgY3VycmVudCBvbiBtZXNzYWdlIGF1 dGhlbnRpY2F0aW9uIHRlY2huaXF1ZXMgaXMgYSBtdWNoIGJpZ2dlciBidXJkZW4gdGhhbiBqdXN0 IHVwZGF0aW5nIGluZ3Jlc3MgTVRBcywgc28gdGhhdCBtb2RlbCBpcyBvYnNlcnZlZC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+U2VlIFJGQzcwMDEsIEFwcGVuZGl4IEQsIGZvciBkZXRhaWxzLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LU1TSzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_BL2SR01MB605139131216D39D517127396C30BL2SR01MB605namsdf_-- From nobody Tue May 19 11:39:25 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A691A0047 for ; Tue, 19 May 2015 11:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZXE0IMKSW1Z for ; Tue, 19 May 2015 11:39:22 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFE4C1A1A5A for ; Tue, 19 May 2015 11:39:21 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so126736743wic.0 for ; Tue, 19 May 2015 11:39:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3WvV8G6lt5STfM9LIxwA6Z5GyJXvvsngJfaaNDlohHQ=; b=CgP4bXgPNhgo3dm/9t05MbLNdA8bFSesekRW1nAGi6ZMhciSe9y9HoO/7MP/TK5Lbm Lg9e9jwto3gooTPK274aO1Cf/qmaGOgbCAuBBR6q0Y/HUs5n6az1/A2n/LgKcDKeJ1X2 L3iWGLcoI1c7qZhYLZCeDmaZwHmhCHm0f7c5YaxunXJN4jPe4FOKoAgLP4DTO7f0Yz8e QOpp0m2gBTbCQ5E7wRAnTTw4R6W5bBrZJnpHKoi4ILekSNeSJ0hOCU1MlJUIGkxjdtPE LzOGeSUf1NRtdv9JWdetkl+dr7Uhye5WwuVLGObSom8iuCvznyJBDPV5NmW1gEWaxcLs RDpQ== MIME-Version: 1.0 X-Received: by 10.194.61.208 with SMTP id s16mr57981404wjr.135.1432060760509; Tue, 19 May 2015 11:39:20 -0700 (PDT) Received: by 10.27.170.134 with HTTP; Tue, 19 May 2015 11:39:20 -0700 (PDT) In-Reply-To: References: <555656FC.5010609@dcrocker.net> <1432015208815.92898@exchange.microsoft.com> Date: Tue, 19 May 2015 11:39:20 -0700 Message-ID: From: "Murray S. Kucherawy" To: Terry Zink Content-Type: multipart/alternative; boundary=047d7b86d3e6ed54b9051673a02c Archived-At: Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 18:39:23 -0000 --047d7b86d3e6ed54b9051673a02c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, May 19, 2015 at 11:24 AM, Terry Zink wrote: > > Sure, but can it just be in a comment if you find that useful, or is > it necessary to > > make that fact something a consumer of the field can parse out? > > Putting it into a comment is fine, maybe something like =E2=80=9Cdmarc=3D= pass > action=3Dnone header.from=3D conditional.to=3D=E2=80=9D. I > think it=E2=80=99s permissible to add additional fields like that into A-= R, isn=E2=80=99t > it? > More like: dmarc=3Dpass header.from=3D (action=3D, cd=3D) > I've always found the details of how it came to that conclusion to be of > only secondary interest > > > I agree with the reasons you outline, but when debugging and > troubleshooting potentially tens, hundreds, or thousands of messages per > day, it=E2=80=99s no longer secondary. It=E2=80=99s also easier to collec= t statistics on > how many messages are conditionally passing DMARC and what mailing list o= r > forwarder it is attached to. > You can create whatever structure you want in the comment (between parentheses). -MSK --047d7b86d3e6ed54b9051673a02c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 19, 2015 at 11:24 AM, Terry Zink <= tzink@exchange.microsoft.com> wrote:

> Sure, but can it just be in a comment if you f= ind that useful, or is it necessary to
> make that fact something a consumer of the field can parse out?=

Putting it into a co= mment is fine, maybe something like =E2=80=9Cdmarc=3Dpass action=3Dnone hea= der.from=3D<domain.com> conditional.to=3D<mailinglist.n= et>=E2=80=9D. I think it=E2=80=99s permissible to add additional fields like that into A-R, isn=E2=80=99t it?

<= /div>

More like:

dm= arc=3Dpass header.from=3D<domain> (action=3D<foo>, cd=3D<dom= ain2>)

=C2=A0> I've always found the details of how it came= to that conclusion to be of only secondary interest


I agree with the reasons you outline, but when debugging and troubleshootin= g potentially tens, hundreds, or thousands of messages per day, it=E2=80=99= s no longer secondary. It=E2=80=99s also easier to collect statistics on ho= w many messages are conditionally passing DMARC and what mailing list or forwarder it is attached to.


You can create whatever structure you wa= nt in the comment (between parentheses).

-MSK
--047d7b86d3e6ed54b9051673a02c-- From nobody Tue May 19 12:02:04 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46571A8BBF for ; Tue, 19 May 2015 12:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.699 X-Spam-Level: * X-Spam-Status: No, score=1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_64=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emjFbgxzl0TZ for ; Tue, 19 May 2015 12:02:01 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 875BF1ACE1A for ; Tue, 19 May 2015 12:00:58 -0700 (PDT) Received: from BLUSR01MB601.namsdf01.sdf.exchangelabs.com (10.255.124.166) by BLUSR01MB602.namsdf01.sdf.exchangelabs.com (10.255.124.167) with Microsoft SMTP Server (TLS) id 15.1.178.2; Tue, 19 May 2015 19:00:56 +0000 Received: from BLUSR01MB601.namsdf01.sdf.exchangelabs.com ([169.254.1.161]) by BLUSR01MB601.namsdf01.sdf.exchangelabs.com ([169.254.1.161]) with mapi id 15.01.0178.004; Tue, 19 May 2015 19:00:56 +0000 From: Terry Zink To: "Murray S. Kucherawy" Thread-Topic: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy Thread-Index: AQHQkSLjmR8NgZwmBEqnwBkgIc5yZJ2CdTYQgAAL4QCAAE1PAYAAAuMAgABflICAAB0JAIAALQsQgAAc9ICAAAbY0IAABTkAgAACBJA= Date: Tue, 19 May 2015 19:00:55 +0000 Message-ID: References: <555656FC.5010609@dcrocker.net> <1432015208815.92898@exchange.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.30] x-microsoft-exchange-diagnostics: 1; BLUSR01MB602; 3:RoUzyjBqMFl+vegN38eBVoj4yzUuYXxl3fowUzSCV3QCgcg/8jpWpYxeDerzfvKw8VVIVTFTCmAO0LhZyTAS2oZSPvuaJSIjbqNPR33bE+hJko5Emm9eXMwmkKbpTQwmxN4Ed2dU1w34fD8Trbivlw==; 10:A35Ob2fDdsBCLMRsmIZ5NPqNRvKjmRx01hbCKTt+GQywJLfAC9T8rFQ537coE3cz7XOB1G2wkaPFO/E9VN/xO5/3Xe2Kyhi8X/VbAdr8qLo=; 6:VNvYbQsIHULRUWvTa2X+JGsVIDr4fyD2ebbkQ1Hr1NkHjOW6T2L8z1YIjX5mkOmV x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUSR01MB602; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(199003)(24454002)(377454003)(189002)(54356999)(50986999)(76176999)(46102003)(105586002)(19617315012)(106356001)(85806002)(2656002)(1411001)(87936001)(106116001)(66066001)(16236675004)(19609705001)(64706001)(33656002)(101416001)(19300405004)(93886004)(19580395003)(19580405001)(19625215002)(92566002)(5001920100001)(5001960100002)(110136002)(97736004)(81156007)(4001540100001)(5001830100001)(16601075003)(5001860100001)(2950100001)(62966003)(2900100001)(102836002)(189998001)(15975445007)(86362001)(77156002)(68736005)(5890100001)(48203002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUSR01MB602; H:BLUSR01MB601.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005002)(5002009)(3002001); SRVR:BLUSR01MB602; BCL:0; PCL:0; RULEID:; SRVR:BLUSR01MB602; x-forefront-prvs: 0581B5AB35 received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: multipart/alternative; boundary="_000_BLUSR01MB6013616DB0595915B05943396C30BLUSR01MB601namsdf_" MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2015 19:00:55.7356 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUSR01MB602 Archived-At: Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 19:02:03 -0000 --_000_BLUSR01MB6013616DB0595915B05943396C30BLUSR01MB601namsdf_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB3ZeKAmXJlIG1ha2luZyBwcm9ncmVzcyBoZXJlLiBTbywgYSBtZXNzYWdlIHdvdWxk IGxvb2sgbGlrZSB0aGlzOg0KDQpGcm9tOiBqb2VAYXV0aG9yZG9tYWluLmV4YW1wbGUNCkF1dGhl bnRpY2F0aW9uLVJlc3VsdHM6IHNwZj1wYXNzIChzZW5kZXIgSVAgaXMgeHgueHgueHgueHgpIHNt dHAubWFpbGZyb209bWxtLmV4YW1wbGU7DQogICAgZGtpbT1mYWlsIChpbnZhbGlkIGJvZHkgaGFz aCkgaGVhZGVyLmQ9YXV0aG9yZG9tYWluLmV4YW1wbGUNCiAgICBka2ltPXBhc3MgKHNpZ25hdHVy ZSB3YXMgdmVyaWZpZWQpIGhlYWRlci5kPWF1dGhvcmRvbWFpbi5leGFtcGxlOw0KICAgIGRraW09 cGFzcyAoc2lnbmF0dXJlIHdhcyB2ZXJpZmllZCkgaGVhZGVyLmQ9bWxtLmV4YW1wbGU7DQogICAg ZG1hcmM9cGFzcyBoZWFkZXIuZnJvbT1hdXRob3Jkb21haW4uZXhhbXBsZSAoYWN0aW9uPW5vbmUg Y2Q9bWxtLmV4YW1wbGUpDQpES0lNLVNpZ25hdHVyZTogdj0xOyBkPWF1dGhvcmRvbWFpbi5leGFt cGxlOyBzPXNlbGVjdG9yOyAuLi4NCkRLSU0tU2lnbmF0dXJlOiB2PTI7IGQ9YXV0aG9yZG9tYWlu LmV4YW1wbGU7IHM9c2VsZWN0b3I7ICFjZD1tbG0uZXhhbXBsZTsgbD0wOyB0PTxub3crMzAgc2Vj b25kcz4NCkRLSU0tU2lnbmF0dXJlOiB2PTE7IGQ9bWxtLmV4YW1wbGU7IHM9Zm9vYmFyOyAuLi4N ClNvbWUgcXVlc3Rpb25zOg0KDQoNCjEuICAgICAgIFRoaXMgc2hvdWxkIGJlIHJlc2lzdGFudCB0 byBhIHJlcGxheSBhdHRhY2sgMTIgaG91cnMgaW4gdGhlIGZ1dHVyZSBiZWNhdXNlIHRoZSDigJx0 PTxub3crMzAgc2Vjb25kcz7igJ0gaXMgcGFydCBvZiB0aGUgREtJTSBzaWduYXR1cmUgZm9yIHY9 MiwgYW5kIGlmIGEgcGhpc2hlciBjb3B5L3Bhc3RlcyBpdCBhbmQgY2hhbmdlcyDigJx2PTLigJ0g dG8g4oCcdj0x4oCdLCB0aGUg4oCcdD0g4oCcIHBhcnQgd2lsbCBiZSBsb25nIHBhc3QuIFJpZ2h0 Pw0KDQoNCjIuICAgICAgIFRoaXMgd2lsbCBiZSBzdXNjZXB0aWJsZSB0byBhIHJlcGxheSBhdHRh Y2sgZm9yIDMwIHNlY29uZHMgYWZ0ZXIgaW5pdGlhbGx5IHNlbmRpbmcgaXQgb3V0LCBidXQgb25s eSB0byB0aGUgbWFpbGluZyBsaXN0LiBSaWdodD8NCg0KDQozLiAgICAgICBWZXJpZmllcnMgbmVl ZCB0byBrbm93IChlbmZvcmNlPykgdGhhdCBhIERLSU0gc2lnbmF0dXJlIG9mIOKAnHY9MiAhY2Q9 PGJsYWg+4oCdIGlzIG5vdCBlbm91Z2ggdG8gdmVyaWZ5IGEgcmVhbCBzaWduYXR1cmUgd2l0aG91 dCB0aGUgY29ycmVzcG9uZGluZyDigJx2PTEgZD08YmxhaD7igJ0gYWRkaXRpb25hbCBES0lNIHNp Z25hdHVyZS4gSW4gb3RoZXIgd29yZHMg4oCcdj0yICFjZD08YmxhaD7igJ0gaXMgdXNlbGVzcyB1 bmxlc3MgcGFpcmVkIHdpdGggc29tZXRoaW5nIGVsc2UuIFJpZ2h0Pw0KDQoNCjQuICAgICAgIEhv dyBzaG91bGQgcmVwdXRhdGlvbiBlbmdpbmVzIGFjY3J1ZSB0aGlzIG1lc3NhZ2U/IFRvIGF1dGhv cmRvbWFpbi5leGFtcGxlICh0aGUgb25lIGluIHRoZSBoZWFkZXIuZnJvbSk/IE9yIHRvIG1sbS5l eGFtcGxlLCB0aGUgb25lIGluIHRoZSBzbXRwLm1haWxmcm9tIGFuZCBES0lNIGQ9IGRvbWFpbiB0 aGF0IGNvbnRhaW5lZCB0aGUgc3Ryb25nIHNpZ25hdHVyZT8NCg0KDQo1LiAgICAgICBWZXJpZmll cnMgd2lsbCBuZWVkIHRvIGNoZWNrIGF0IGxlYXN0IDMgREtJTSBzaWduYXR1cmVzLiBJcyB0aGVy ZSBhIGxpbWl0IG9uIHRoZSBhbW91bnQgb2Ygc2lnbmF0dXJlcyB0aGV5IHNob3VsZCBjaGVjaz8g UHJlc3VtYWJseSB3ZSB3b3VsZG7igJl0IHdhbnQgYSB2ZXJpZmllciB0byBjaGVjayAzMCBzaWdu YXR1cmVzLg0KDQoNCjYuICAgICAgIFdoYXQgaXMgdGhlIHByb3Bvc2VkIHQ9IHRpbWUgbGltaXQ/ IElzIDMwIHNlY29uZHMgZW5vdWdoPyBUb28gbG9uZz8gVG9vIGxpdHRsZT8NCg0KLS0gVGVycnkN Cg0KRnJvbTogTXVycmF5IFMuIEt1Y2hlcmF3eSBbbWFpbHRvOnN1cGVydXNlckBnbWFpbC5jb21d DQpTZW50OiBUdWVzZGF5LCBNYXkgMTksIDIwMTUgMTE6MzkgQU0NClRvOiBUZXJyeSBaaW5rDQpD YzogU2NvdHQgS2l0dGVybWFuOyBkbWFyY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtkbWFyYy1p ZXRmXSBMb29raW5nIGZvciBkZWdyZWVzIG9mIGZyZWVkb20gd2l0aCBJbnRlcm1lZGlhcmllcyAt IEVmZm9ydCBhbmQgUG9saWN5DQoNCk9uIFR1ZSwgTWF5IDE5LCAyMDE1IGF0IDExOjI0IEFNLCBU ZXJyeSBaaW5rIDx0emlua0BleGNoYW5nZS5taWNyb3NvZnQuY29tPG1haWx0bzp0emlua0BleGNo YW5nZS5taWNyb3NvZnQuY29tPj4gd3JvdGU6DQo+IFN1cmUsIGJ1dCBjYW4gaXQganVzdCBiZSBp biBhIGNvbW1lbnQgaWYgeW91IGZpbmQgdGhhdCB1c2VmdWwsIG9yIGlzIGl0IG5lY2Vzc2FyeSB0 bw0KPiBtYWtlIHRoYXQgZmFjdCBzb21ldGhpbmcgYSBjb25zdW1lciBvZiB0aGUgZmllbGQgY2Fu IHBhcnNlIG91dD8NClB1dHRpbmcgaXQgaW50byBhIGNvbW1lbnQgaXMgZmluZSwgbWF5YmUgc29t ZXRoaW5nIGxpa2Ug4oCcZG1hcmM9cGFzcyBhY3Rpb249bm9uZSBoZWFkZXIuZnJvbT08ZG9tYWlu LmNvbTxodHRwOi8vZG9tYWluLmNvbT4+IGNvbmRpdGlvbmFsLnRvPGh0dHA6Ly9jb25kaXRpb25h bC50bz49PG1haWxpbmdsaXN0Lm5ldDxodHRwOi8vbWFpbGluZ2xpc3QubmV0Pj7igJ0uIEkgdGhp bmsgaXTigJlzIHBlcm1pc3NpYmxlIHRvIGFkZCBhZGRpdGlvbmFsIGZpZWxkcyBsaWtlIHRoYXQg aW50byBBLVIsIGlzbuKAmXQgaXQ/DQoNCk1vcmUgbGlrZToNCmRtYXJjPXBhc3MgaGVhZGVyLmZy b209PGRvbWFpbj4gKGFjdGlvbj08Zm9vPiwgY2Q9PGRvbWFpbjI+KQ0KID4gSSd2ZSBhbHdheXMg Zm91bmQgdGhlIGRldGFpbHMgb2YgaG93IGl0IGNhbWUgdG8gdGhhdCBjb25jbHVzaW9uIHRvIGJl IG9mIG9ubHkgc2Vjb25kYXJ5IGludGVyZXN0DQoNCkkgYWdyZWUgd2l0aCB0aGUgcmVhc29ucyB5 b3Ugb3V0bGluZSwgYnV0IHdoZW4gZGVidWdnaW5nIGFuZCB0cm91Ymxlc2hvb3RpbmcgcG90ZW50 aWFsbHkgdGVucywgaHVuZHJlZHMsIG9yIHRob3VzYW5kcyBvZiBtZXNzYWdlcyBwZXIgZGF5LCBp dOKAmXMgbm8gbG9uZ2VyIHNlY29uZGFyeS4gSXTigJlzIGFsc28gZWFzaWVyIHRvIGNvbGxlY3Qg c3RhdGlzdGljcyBvbiBob3cgbWFueSBtZXNzYWdlcyBhcmUgY29uZGl0aW9uYWxseSBwYXNzaW5n IERNQVJDIGFuZCB3aGF0IG1haWxpbmcgbGlzdCBvciBmb3J3YXJkZXIgaXQgaXMgYXR0YWNoZWQg dG8uDQoNCllvdSBjYW4gY3JlYXRlIHdoYXRldmVyIHN0cnVjdHVyZSB5b3Ugd2FudCBpbiB0aGUg Y29tbWVudCAoYmV0d2VlbiBwYXJlbnRoZXNlcykuDQotTVNLDQo= --_000_BLUSR01MB6013616DB0595915B05943396C30BLUSR01MB601namsdf_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFw aCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxl LXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFy Z2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwi c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAq Lw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MjEyMTk5MzEwMDsNCgltc28tbGlzdC10eXBlOmh5 YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6Mjk1NDkyODcwIDY3Njk4NzAzIDY3Njk4NzEz IDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3 Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlz dCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9t YW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJ e21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7 DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJ e21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SSB0aGluayB3ZeKAmXJlIG1ha2luZyBwcm9ncmVz cyBoZXJlLiBTbywgYSBtZXNzYWdlIHdvdWxkIGxvb2sgbGlrZSB0aGlzOjxvOnA+PC9vOnA+PC9z cGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPjxicj4NCkZyb206IGpvZUBhdXRob3Jkb21haW4uZXhhbXBsZTxi cj4NCkF1dGhlbnRpY2F0aW9uLVJlc3VsdHM6IHNwZj1wYXNzIChzZW5kZXIgSVAgaXMgeHgueHgu eHgueHgpIHNtdHAubWFpbGZyb209bWxtLmV4YW1wbGU7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 IGRraW09ZmFpbCAoaW52YWxpZCBib2R5IGhhc2gpIGhlYWRlci5kPWF1dGhvcmRvbWFpbi5leGFt cGxlPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IGRraW09cGFzcyAoc2lnbmF0dXJlIHdhcyB2ZXJp ZmllZCkgaGVhZGVyLmQ9YXV0aG9yZG9tYWluLmV4YW1wbGU7IDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZGtpbT1wYXNzIChzaWduYXR1cmUgd2Fz IHZlcmlmaWVkKSBoZWFkZXIuZD1tbG0uZXhhbXBsZTs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsg ZG1hcmM9cGFzcyBoZWFkZXIuZnJvbT1hdXRob3Jkb21haW4uZXhhbXBsZSAoYWN0aW9uPW5vbmUg Y2Q9bWxtLmV4YW1wbGUpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5ES0lNLVNpZ25hdHVyZTogdj0xOyBkPWF1 dGhvcmRvbWFpbi5leGFtcGxlOyBzPXNlbGVjdG9yOyAuLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRLSU0t U2lnbmF0dXJlOiB2PTI7IGQ9YXV0aG9yZG9tYWluLmV4YW1wbGU7IHM9c2VsZWN0b3I7ICFjZD1t bG0uZXhhbXBsZTsgbD0wOyB0PSZsdDtub3cmIzQzOzMwIHNlY29uZHMmZ3Q7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRLSU0tU2lnbmF0dXJlOiB2PTE7IGQ9 bWxtLmV4YW1wbGU7IHM9Zm9vYmFyOyAuLi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlNv bWUgcXVlc3Rpb25zOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWlu ZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+VGhpcyBzaG91bGQgYmUgcmVzaXN0YW50IHRvIGEgcmVwbGF5IGF0dGFjayAxMiBo b3VycyBpbiB0aGUgZnV0dXJlIGJlY2F1c2UgdGhlIOKAnHQ9Jmx0O25vdyYjNDM7MzAgc2Vjb25k cyZndDvigJ0gaXMgcGFydCBvZiB0aGUgREtJTSBzaWduYXR1cmUgZm9yIHY9MiwgYW5kIGlmIGEN CiBwaGlzaGVyIGNvcHkvcGFzdGVzIGl0IGFuZCBjaGFuZ2VzIOKAnHY9MuKAnSB0byDigJx2PTHi gJ0sIHRoZSDigJx0PSDigJwgcGFydCB3aWxsIGJlIGxvbmcgcGFzdC4gUmlnaHQ/PGJyPg0KPGJy Pg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+VGhpcyB3aWxsIGJlIHN1c2NlcHRpYmxlIHRvIGEgcmVwbGF5 IGF0dGFjayBmb3IgMzAgc2Vjb25kcyBhZnRlciBpbml0aWFsbHkgc2VuZGluZyBpdCBvdXQsIGJ1 dCBvbmx5IHRvIHRoZSBtYWlsaW5nIGxpc3QuIFJpZ2h0Pzxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPlZlcmlmaWVycyBuZWVkIHRvIGtub3cgKGVuZm9yY2U/KSB0aGF0IGEgREtJTSBzaWdu YXR1cmUgb2Yg4oCcdj0yICFjZD0mbHQ7YmxhaCZndDvigJ0gaXMgbm90IGVub3VnaCB0byB2ZXJp ZnkgYSByZWFsIHNpZ25hdHVyZSB3aXRob3V0IHRoZSBjb3JyZXNwb25kaW5nIOKAnHY9MQ0KIGQ9 Jmx0O2JsYWgmZ3Q74oCdIGFkZGl0aW9uYWwgREtJTSBzaWduYXR1cmUuIEluIG90aGVyIHdvcmRz IOKAnHY9MiAhY2Q9Jmx0O2JsYWgmZ3Q74oCdIGlzIHVzZWxlc3MgdW5sZXNzIHBhaXJlZCB3aXRo IHNvbWV0aGluZyBlbHNlLiBSaWdodD88YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjtt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl Ij40LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Ib3cg c2hvdWxkIHJlcHV0YXRpb24gZW5naW5lcyBhY2NydWUgdGhpcyBtZXNzYWdlPyBUbyBhdXRob3Jk b21haW4uZXhhbXBsZSAodGhlIG9uZSBpbiB0aGUgaGVhZGVyLmZyb20pPyBPciB0byBtbG0uZXhh bXBsZSwgdGhlIG9uZSBpbiB0aGUgc210cC5tYWlsZnJvbQ0KIGFuZCBES0lNIGQ9IGRvbWFpbiB0 aGF0IGNvbnRhaW5lZCB0aGUgc3Ryb25nIHNpZ25hdHVyZT88YnI+DQo8YnI+DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5k ZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj41LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5WZXJpZmllcnMgd2lsbCBuZWVkIHRvIGNoZWNrIGF0IGxlYXN0IDMgREtJTSBzaWdu YXR1cmVzLiBJcyB0aGVyZSBhIGxpbWl0IG9uIHRoZSBhbW91bnQgb2Ygc2lnbmF0dXJlcyB0aGV5 IHNob3VsZCBjaGVjaz8gUHJlc3VtYWJseSB3ZSB3b3VsZG7igJl0IHdhbnQNCiBhIHZlcmlmaWVy IHRvIGNoZWNrIDMwIHNpZ25hdHVyZXMuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+Ni48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+V2hh dCBpcyB0aGUgcHJvcG9zZWQgdD0gdGltZSBsaW1pdD8gSXMgMzAgc2Vjb25kcyBlbm91Z2g/IFRv byBsb25nPyBUb28gbGl0dGxlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4tLSBUZXJyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTXVycmF5IFMuIEt1Y2hlcmF3eSBbbWFpbHRvOnN1cGVydXNl ckBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTWF5IDE5LCAyMDE1IDEx OjM5IEFNPGJyPg0KPGI+VG86PC9iPiBUZXJyeSBaaW5rPGJyPg0KPGI+Q2M6PC9iPiBTY290dCBL aXR0ZXJtYW47IGRtYXJjQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbZG1hcmMt aWV0Zl0gTG9va2luZyBmb3IgZGVncmVlcyBvZiBmcmVlZG9tIHdpdGggSW50ZXJtZWRpYXJpZXMg LSBFZmZvcnQgYW5kIFBvbGljeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIFR1ZSwgTWF5IDE5LCAyMDE1IGF0IDExOjI0IEFNLCBUZXJyeSBaaW5rICZsdDs8YSBocmVm PSJtYWlsdG86dHppbmtAZXhjaGFuZ2UubWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnR6 aW5rQGV4Y2hhbmdlLm1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0 Ij48YSBuYW1lPSIxNGQ2ZDZiOWJiNzhlYjY3X19NYWlsRW5kQ29tcG9zZSI+Jmd0OyBTdXJlLCBi dXQgY2FuIGl0IGp1c3QgYmUgaW4gYSBjb21tZW50IGlmIHlvdSBmaW5kIHRoYXQgdXNlZnVsLCBv ciBpcyBpdCBuZWNlc3NhcnkgdG8NCjxicj4NCiZndDsgbWFrZSB0aGF0IGZhY3Qgc29tZXRoaW5n IGEgY29uc3VtZXIgb2YgdGhlIGZpZWxkIGNhbiBwYXJzZSBvdXQ/PC9hPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPlB1dHRpbmcgaXQgaW50byBhIGNvbW1lbnQgaXMgZmluZSwgbWF5YmUgc29tZXRo aW5nIGxpa2Ug4oCcZG1hcmM9cGFzcyBhY3Rpb249bm9uZSBoZWFkZXIuZnJvbT0mbHQ7PGEgaHJl Zj0iaHR0cDovL2RvbWFpbi5jb20iIHRhcmdldD0iX2JsYW5rIj5kb21haW4uY29tPC9hPiZndDsN CjxhIGhyZWY9Imh0dHA6Ly9jb25kaXRpb25hbC50byIgdGFyZ2V0PSJfYmxhbmsiPmNvbmRpdGlv bmFsLnRvPC9hPj0mbHQ7PGEgaHJlZj0iaHR0cDovL21haWxpbmdsaXN0Lm5ldCIgdGFyZ2V0PSJf YmxhbmsiPm1haWxpbmdsaXN0Lm5ldDwvYT4mZ3Q74oCdLiBJIHRoaW5rIGl04oCZcyBwZXJtaXNz aWJsZSB0byBhZGQgYWRkaXRpb25hbCBmaWVsZHMgbGlrZSB0aGF0IGludG8gQS1SLCBpc27igJl0 IGl0Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPk1vcmUgbGlrZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ZG1hcmM9cGFzcyBoZWFkZXIu ZnJvbT0mbHQ7ZG9tYWluJmd0OyAoYWN0aW9uPSZsdDtmb28mZ3Q7LCBjZD0mbHQ7ZG9tYWluMiZn dDspPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDs8L3NwYW4+Jmd0OyBJJ3ZlIGFsd2F5cyBmb3VuZCB0aGUgZGV0YWlscyBvZiBo b3cgaXQgY2FtZSB0byB0aGF0IGNvbmNsdXNpb24gdG8gYmUgb2Ygb25seSBzZWNvbmRhcnkgaW50 ZXJlc3QNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxicj4NCkkgYWdyZWUgd2l0aCB0aGUgcmVh c29ucyB5b3Ugb3V0bGluZSwgYnV0IHdoZW4gZGVidWdnaW5nIGFuZCB0cm91Ymxlc2hvb3Rpbmcg cG90ZW50aWFsbHkgdGVucywgaHVuZHJlZHMsIG9yIHRob3VzYW5kcyBvZiBtZXNzYWdlcyBwZXIg ZGF5LCBpdOKAmXMgbm8gbG9uZ2VyIHNlY29uZGFyeS4gSXTigJlzIGFsc28gZWFzaWVyIHRvIGNv bGxlY3Qgc3RhdGlzdGljcyBvbiBob3cgbWFueSBtZXNzYWdlcyBhcmUgY29uZGl0aW9uYWxseSBw YXNzaW5nIERNQVJDDQogYW5kIHdoYXQgbWFpbGluZyBsaXN0IG9yIGZvcndhcmRlciBpdCBpcyBh dHRhY2hlZCB0by48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij5Zb3UgY2FuIGNyZWF0ZSB3aGF0ZXZlciBzdHJ1Y3R1cmUgeW91IHdhbnQgaW4g dGhlIGNvbW1lbnQgKGJldHdlZW4gcGFyZW50aGVzZXMpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LU1TSzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BLUSR01MB6013616DB0595915B05943396C30BLUSR01MB601namsdf_-- From nobody Tue May 19 12:11:41 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C011A0E10 for ; Tue, 19 May 2015 12:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQmHwAJuwBJ8 for ; Tue, 19 May 2015 12:11:38 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D61D91A006F for ; Tue, 19 May 2015 12:11:38 -0700 (PDT) Received: by pdbqa5 with SMTP id qa5so37289297pdb.0 for ; Tue, 19 May 2015 12:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=/VdQ+X0qZ3DlOKF3PrRmCSfdrJnssFTQAmrnZHTDcwc=; b=as0KkuLd81h7najC4Rt53B/BDavUGH9eD1bxR5xx5dIkCT+xJHrr8wwnmlUhWo3VfW lSezanGBciFQjimzu1FdrX2ww+7W2HAhGAX5gYi005uJ7q3WhLWBKIknu4plR4SsxBcw 5Ge30jQe3I8pNhhDUuC5d8NrhXPKXcuYTGndQLYR3iZSh0AxxX5qXu2zzSQNhBjSapji WZv6WleACuagnuPxdlnyEQZoZiP4yngM9LR7Q8CbeVAXnbYvaLnivUHT0dmKxhVTwlBH RTYtRLiQ6vgEhvQwJYCxJthSd8IyYFhxEZKkYXJPnkUoDFeD8M0jXhxCnxeDio47PC6d NURQ== X-Received: by 10.68.125.130 with SMTP id mq2mr55923305pbb.121.1432062698572; Tue, 19 May 2015 12:11:38 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id oo3sm13887471pac.31.2015.05.19.12.11.35 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 May 2015 12:11:37 -0700 (PDT) Message-ID: <555B8AE5.6000309@gmail.com> Date: Tue, 19 May 2015 12:11:33 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <555656FC.5010609@dcrocker.net> <1432015208815.92898@exchange.microsoft.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 19:11:39 -0000 On 5/19/15 4:47 AM, Scott Kitterman wrote: > On May 19, 2015 2:05:18 AM EDT, "Murray S. Kucherawy" wrote: >> On Mon, May 18, 2015 at 10:56 PM, Terry Zink >> >> wrote: >> >>> Thanks, this is useful. >>> >>> What would the Authentication-Results header look like? Presumably 3 >>> results for DKIM (dkim=fail, dkim=pass, dkim=pass)? And what about >> DMARC? >>> Show one result or two? Or maybe something like >> dmarc=conditionalpass? >> Three DKIM results, one DMARC "pass" result. The idea is that DKIM >> returns >> a "pass" for an aligned conditional signature, which satisfies the DKIM >> algorithm, so long as there's also a passing signature from the "cd" >> domain. >> >> Is there any use in making a distinction to your acceptance/routing of >> messages to know it was based on a conditional signature versus an >> original >> author signature? > I would think you'd have to. There's a replay risk that's unique to this type of signature, so I think treating them the same would be a naive approach. > > Agreed. These messages are likely be distributed to many subscribers where each message must contain two linked signatures, the siglet authorizing some third-party domain and a full signature of the third-party domain.. A reasonable expiry is required or delivery becomes unreliable. What will be considered a reasonable delivery window? It seems most MTAs will retry over a period of several days. Email should not be treated like IM unless considering a gateway to a federated IM system. The IM-From header could introduce both an alternative From header field andl act at the IM gateway. The mail transport would ignore this pseudo sub-domain which could also assist in tracking abusive sources. In which case these addresses often indicate the current instance of a on-network client denoted as a pseudo sub-domain of the email-address. Regards, Douglas Otis From nobody Tue May 19 12:15:33 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753C01A1B0C for ; Tue, 19 May 2015 12:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.702 X-Spam-Level: X-Spam-Status: No, score=-98.702 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_54=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iThZ3wmyN14i for ; Tue, 19 May 2015 12:15:30 -0700 (PDT) Received: from mail.santronics.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6EE1A0127 for ; Tue, 19 May 2015 12:15:26 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=427; t=1432062915; atps=isdg.net; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=yGUr8Jqf1YSdl85v0v15dm/9mGo=; b=QgjU6jxy3SqXncwLG4W/c+tVgGy5bYhflyV9SAaCbdtOju3Q+f/OPB+GxvoufH rSCxmQAk9mAnVZKhWNUyWYzRxKvGnY8vbbfYm8veazqtDHG3IwEprxtzG1IaHXFz j7so8srCczo+FXdqmPcZskbgwvAeNesKfNRuImjJXvCUM= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 19 May 2015 15:15:15 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1477928881.18387.5868; Tue, 19 May 2015 15:15:15 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=427; t=1432062622; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=XzZMTry ubj+4n/+zFPThjm/lXxm0tgZ8O7qsr/HANQY=; b=p1lFuL0DwN6rN75inZcJ2YO BDNzLtClac/e0i0JEzVLDaQHCfQZsTcwHL9AxW7tIGfhJM3ERQYYfOjxqQoeVx4O uK6ndrsghYHtgdjMLm5n9bq7LHK04SfUm9KDwmPUmrJvnL54biFihzovMtQEX4YF WPvQUHlczOLozkyM7prI= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 19 May 2015 15:10:22 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 70190692.9.21024; Tue, 19 May 2015 15:10:21 -0400 Message-ID: <555B8BC1.5000000@isdg.net> Date: Tue, 19 May 2015 15:15:13 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <555656FC.5010609@dcrocker.net> <1432015208815.92898@exchange.microsoft.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "dmarc@ietf.org" , Scott Kitterman , Terry Zink Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 19:15:32 -0000 On 5/19/2015 2:39 PM, Murray S. Kucherawy wrote:> > Terry Zink > Putting it into a comment is fine, maybe something like > additional fields like that into A-R, isn’t it? > > More like: > > dmarc=pass header.from= (action=, cd=) IMO, this makes it a DMARC extension. Is draft-levine-dkim-conditional a standard track DMARC extension? Isn't this more of a DKIM extension? -- HLS From nobody Tue May 19 13:02:12 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C4D1B3181 for ; Tue, 19 May 2015 13:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.401 X-Spam-Level: ** X-Spam-Status: No, score=2.401 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6, J_CHICKENPOX_54=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uk_mip-OyD5S for ; Tue, 19 May 2015 13:02:08 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB6711B317E for ; Tue, 19 May 2015 13:01:58 -0700 (PDT) Received: by wichy4 with SMTP id hy4so35754238wic.1 for ; Tue, 19 May 2015 13:01:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=anKjiIGyDKlUIr2yQImGeX/RoFxg8Y3Xu/QFoCcZW/Q=; b=rAoTD1sg6LTUEdPxrNWkAgJW11Poka+UuUgRTldQRzTEwrMsXUKX4PDFKoKeKTjY8J 7fXbODtd/QcJAHbBd6UwOMhMtHNa8z0R8iVmag1u8WkD9EDeGFdPKhvbXrC/LEv1m3wZ 3+/n1PkrsTwvntfLtbi2uGXt+5OPtnWGJ4WsAmLDXPrwOXzlsw+yckj5k6dtQ72PYoWj LkBoNLm6746HZfVEVwTZfzvo/vVOFyYbdPPXgYjUm/BlE2X8egkOsjPrNdM7r9oiqRSd 2npQt0wWtwQwHmZBE0W2AwUe9sqzmk670SkWCDYDHtXJ78DMQIFiGz3cyAtmHW+kBZkv cn4Q== MIME-Version: 1.0 X-Received: by 10.194.61.208 with SMTP id s16mr58586103wjr.135.1432065717188; Tue, 19 May 2015 13:01:57 -0700 (PDT) Received: by 10.27.170.134 with HTTP; Tue, 19 May 2015 13:01:57 -0700 (PDT) In-Reply-To: References: <555656FC.5010609@dcrocker.net> <1432015208815.92898@exchange.microsoft.com> Date: Tue, 19 May 2015 13:01:57 -0700 Message-ID: From: "Murray S. Kucherawy" To: Terry Zink Content-Type: multipart/alternative; boundary=047d7b86d3e65e3e2c051674c8f3 Archived-At: Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 20:02:10 -0000 --047d7b86d3e65e3e2c051674c8f3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, May 19, 2015 at 12:00 PM, Terry Zink wrote: > I think we=E2=80=99re making progress here. So, a message would look lik= e this: > > > From: joe@authordomain.example > Authentication-Results: spf=3Dpass (sender IP is xx.xx.xx.xx) > smtp.mailfrom=3Dmlm.example; > dkim=3Dfail (invalid body hash) header.d=3Dauthordomain.example > dkim=3Dpass (signature was verified) header.d=3Dauthordomain.example; > > dkim=3Dpass (signature was verified) header.d=3Dmlm.example; > dmarc=3Dpass header.from=3Dauthordomain.example (action=3Dnone > cd=3Dmlm.example) > > DKIM-Signature: v=3D1; d=3Dauthordomain.example; s=3Dselector; ... > > DKIM-Signature: v=3D2; d=3Dauthordomain.example; s=3Dselector; !cd=3Dmlm.= example; > l=3D0; t=3D > > DKIM-Signature: v=3D1; d=3Dmlm.example; s=3Dfoobar; ... > > Some questions: > > > > 1. This should be resistant to a replay attack 12 hours in the > future because the =E2=80=9Ct=3D=E2=80=9D is part of the = DKIM signature for > v=3D2, and if a phisher copy/pastes it and changes =E2=80=9Cv=3D2=E2=80= =9D to =E2=80=9Cv=3D1=E2=80=9D, the =E2=80=9Ct=3D =E2=80=9C > part will be long past. Right? > "t=3D" is the timestamp at which the signature is generated, while "x=3D" i= s the expiration timestamp. So, you'd do "x=3D" where "lifetime" = is the number of seconds you want the signature to be valid. If a phisher changes the "v=3D2" to "v=3D1", the signature is rendered inva= lid because that changes the part that's hashed. That attack won't work. > 2. This will be susceptible to a replay attack for 30 seconds after > initially sending it out, but only to the mailing list. Right? > It will be replayable for whatever the difference is between "t=3D" and "x= =3D", by anyone that can generate a valid signature for the "!cd" domain. > 3. Verifiers need to know (enforce?) that a DKIM signature of =E2= =80=9Cv=3D2 > !cd=3D=E2=80=9D is not enough to verify a real signature without th= e > corresponding =E2=80=9Cv=3D1 d=3D=E2=80=9D additional DKIM signatur= e. In other words =E2=80=9Cv=3D2 > !cd=3D=E2=80=9D is useless unless paired with something else. Right= ? > The idea behind changing "v=3D" is to cause verifiers that know about "v=3D= 2" to be the only ones that understand what "!cd" means, namely that the signature is not valid unless accompanied by a valid signature from the "!cd" domain. A verifier that doesn't know about "v=3D2" will simply ignor= e that signature entirely, so the condition cannot possibly be satisfied. 4. How should reputation engines accrue this message? To > authordomain.example (the one in the header.from)? Or to mlm.example, the > one in the smtp.mailfrom and DKIM d=3D domain that contained the strong > signature? > That's a good question, but one outside of John's proposal. I suppose you could accrue reputation on them severally, or jointly, or perhaps in some combinations. I don't know off the top of my head which would be best. > 5. Verifiers will need to check at least 3 DKIM signatures. Is > there a limit on the amount of signatures they should check? Presumably w= e > wouldn=E2=80=99t want a verifier to check 30 signatures. > It would be unusual to check more than three or perhaps five, I would think. It might be useful to collect information on how many we're seeing in the wild. Certainly a message bearing 20 or 30 might reasonably be regarded as a possible attack because a lot of DNS and crypto has to be done. > 6. What is the proposed t=3D time limit? Is 30 seconds enough? Too > long? Too little? > I would guess too little, but at this point that's strictly a guess. You need to leave enough time for possible network or other transmission problems between the signer and the intermediary you're trying to accommodate. -MSK --047d7b86d3e65e3e2c051674c8f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 19, 2015 at 12:00 PM, Terry Zink <= tzink@exchange.microsoft.com> wrote:

I think we=E2=80=99re making progress here. So, a message= would look like this:


From: joe@authordomain.example
Authentication-Results: spf=3Dpass (sender IP is xx.xx.xx.xx) smtp.mailfrom= =3Dmlm.example;
=C2=A0=C2=A0=C2=A0 dkim=3Dfail (invalid body hash) header.d=3Dauthordomain.= example
=C2=A0=C2=A0=C2=A0 dkim=3Dpass (signature was verified) header.d=3Dauthordo= main.example;

=C2=A0=C2=A0=C2=A0=C2=A0dki= m=3Dpass (signature was verified) header.d=3Dmlm.example;
=C2=A0=C2=A0=C2=A0 dmarc=3Dpass header.from=3Dauthordomain.example (action= =3Dnone cd=3Dmlm.example)

DKIM-Signature: v=3D1; d=3Dauthordomain= .example; s=3Dselector; ...

DKIM-Signature: v=3D2; d=3Dautho= rdomain.example; s=3Dselector; !cd=3Dmlm.example; l=3D0; t=3D<now+30 sec= onds>

DKIM-Sig= nature: v=3D1; d=3Dmlm.example; s=3Dfoobar; ...

Some questions:

=C2=A0=

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This should be resista= nt to a replay attack 12 hours in the future because the =E2=80=9Ct=3D<n= ow+30 seconds>=E2=80=9D is part of the DKIM signature for v=3D2, and if = a phisher copy/pastes it and changes =E2=80=9Cv=3D2=E2=80=9D to =E2=80=9Cv= =3D1=E2=80=9D, the =E2=80=9Ct=3D =E2=80=9C part will be long past. Right?


"t=3D" = is the timestamp at which the signature is generated, while "x=3D"= ; is the expiration timestamp. So, you'd do "x=3D<t+lifetime>= ;" where "lifetime" is the number of seconds you want the si= gnature to be valid.

If a phisher changes the "v=3D2= " to "v=3D1", the signature is rendered invalid because that= changes the part that's hashed. That attack won't work.
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This will be susceptible to a= replay attack for 30 seconds after initially sending it out, but only to t= he mailing list. Right?


It will be replayable for whatever the difference is between "= t=3D" and "x=3D", by anyone that can generate a valid signat= ure for the "!cd" domain.
=C2=A0

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Verifiers need to know (enforce?) that a DKIM signatur= e of =E2=80=9Cv=3D2 !cd=3D<blah>=E2=80=9D is not enough to verify a r= eal signature without the corresponding =E2=80=9Cv=3D1 d=3D<blah>=E2=80=9D additional DKIM signature. In other words =E2=80= =9Cv=3D2 !cd=3D<blah>=E2=80=9D is useless unless paired with somethin= g else. Right?


The idea= behind changing "v=3D" is to cause verifiers that know about &qu= ot;v=3D2" to be the only ones that understand what "!cd" mea= ns, namely that the signature is not valid unless accompanied by a valid si= gnature from the "!cd" domain.=C2=A0 A verifier that doesn't = know about "v=3D2" will simply ignore that signature entirely, so= the condition cannot possibly be satisfied.

4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 How should reputation engines accrue this message? To = authordomain.example (the one in the header.from)? Or to mlm.example, the o= ne in the smtp.mailfrom and DKIM d=3D domain that contained the strong signature?


That's a good question, but one out= side of John's proposal.=C2=A0 I suppose you could accrue reputation on= them severally, or jointly, or perhaps in some combinations.=C2=A0 I don&#= 39;t know off the top of my head which would be best.
=C2=A0<= /div>

5.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Verifiers will need to check at least 3 DKIM signature= s. Is there a limit on the amount of signatures they should check? Presumab= ly we wouldn=E2=80=99t want a verifier to check 30 signatures.

It would be unusual to check more than three or perhaps five, = I would think.=C2=A0 It might be useful to collect information on how many = we're seeing in the wild.=C2=A0 Certainly a message bearing 20 or 30 mi= ght reasonably be regarded as a possible attack because a lot of DNS and cr= ypto has to be done.

6.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 What is the proposed t=3D tim= e limit? Is 30 seconds enough? Too long? Too little?

=
I would guess too little, but at this point that's st= rictly a guess.=C2=A0 You need to leave enough time for possible network or= other transmission problems between the signer and the intermediary you= 9;re trying to accommodate.

-MSK
--047d7b86d3e65e3e2c051674c8f3-- From nobody Tue May 19 13:39:02 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 413D91B324C for ; Tue, 19 May 2015 13:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.399 X-Spam-Level: X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkPyTmS3NvqE for ; Tue, 19 May 2015 13:38:56 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12FE81B3250 for ; Tue, 19 May 2015 13:38:54 -0700 (PDT) Received: from BLUSR01MB601.namsdf01.sdf.exchangelabs.com (10.255.124.166) by BLUSR01MB603.namsdf01.sdf.exchangelabs.com (10.255.124.168) with Microsoft SMTP Server (TLS) id 15.1.178.2; Tue, 19 May 2015 20:38:52 +0000 Received: from BLUSR01MB601.namsdf01.sdf.exchangelabs.com ([169.254.1.161]) by BLUSR01MB601.namsdf01.sdf.exchangelabs.com ([169.254.1.161]) with mapi id 15.01.0178.004; Tue, 19 May 2015 20:38:52 +0000 From: Terry Zink To: "Murray S. Kucherawy" Thread-Topic: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy Thread-Index: AQHQkSLjmR8NgZwmBEqnwBkgIc5yZJ2CdTYQgAAL4QCAAE1PAYAAAuMAgABflICAAB0JAIAALQsQgAAc9ICAAAbY0IAABTkAgAACBJCAABURgIAACj5A Date: Tue, 19 May 2015 20:38:50 +0000 Message-ID: References: <555656FC.5010609@dcrocker.net> <1432015208815.92898@exchange.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.30] x-microsoft-exchange-diagnostics: 1; BLUSR01MB603; 3:XgxCg8kDTQtnzGrJhmBrL9OEk+nX+4WEuavpV5eahxlz/C9C3cMnP5OW34dW45WH62CP+Bbxjzf+9qXVnag+lUvEUa7scLRwOdcbBgb1TMngABx8ucGkxMGy4OBlHGzpYsxIebPOBbEF6fdZyD7KoQ==; 10:obgoygnjQy9ZeMIkqr7Wc8nza1RTYaWxqxeFVH3biTm3mQ+dO2ZJi4topCfqLiOVvM9atqWCqd9qNziXU9odQNM9mEQai7toE+MepAAkGLM=; 6:v9XUIOZNhlgeOt82cginjT+GrE+5T2b+t+UeqEe/EHKjispcq29hYjIQCwWOCOHo x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUSR01MB603; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(199003)(189002)(377454003)(24454002)(2656002)(85806002)(86362001)(5001860100001)(1411001)(16236675004)(87936001)(5001830100001)(19609705001)(101416001)(561944003)(2950100001)(46102003)(2900100001)(81156007)(97736004)(4001540100001)(189998001)(5001960100002)(102836002)(15975445007)(68736005)(19625215002)(110136002)(93886004)(64706001)(105586002)(77156002)(62966003)(106116001)(50986999)(76176999)(54356999)(106356001)(19580395003)(33656002)(19300405004)(66066001)(92566002)(19580405001)(48203002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUSR01MB603; H:BLUSR01MB601.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005002)(5002009)(3002001); SRVR:BLUSR01MB603; BCL:0; PCL:0; RULEID:; SRVR:BLUSR01MB603; x-forefront-prvs: 0581B5AB35 received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: multipart/alternative; boundary="_000_BLUSR01MB601EC45AB3320FA0F46564B96C30BLUSR01MB601namsdf_" MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2015 20:38:50.9764 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUSR01MB603 Archived-At: Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 20:38:59 -0000 --_000_BLUSR01MB601EC45AB3320FA0F46564B96C30BLUSR01MB601namsdf_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVhaCwgc29ycnksIEkgY29uZnVzZWQgdGhlIHQ9IHdpdGggeD0gaW4gdGhlIERLSU0gc2lnbmF0 dXJlLg0KDQotLSBUZXJyeQ0KDQpGcm9tOiBNdXJyYXkgUy4gS3VjaGVyYXd5IFttYWlsdG86c3Vw ZXJ1c2VyQGdtYWlsLmNvbV0NClNlbnQ6IFR1ZXNkYXksIE1heSAxOSwgMjAxNSAxOjAyIFBNDQpU bzogVGVycnkgWmluaw0KQ2M6IFNjb3R0IEtpdHRlcm1hbjsgZG1hcmNAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbZG1hcmMtaWV0Zl0gTG9va2luZyBmb3IgZGVncmVlcyBvZiBmcmVlZG9tIHdpdGgg SW50ZXJtZWRpYXJpZXMgLSBFZmZvcnQgYW5kIFBvbGljeQ0KDQpPbiBUdWUsIE1heSAxOSwgMjAx NSBhdCAxMjowMCBQTSwgVGVycnkgWmluayA8dHppbmtAZXhjaGFuZ2UubWljcm9zb2Z0LmNvbTxt YWlsdG86dHppbmtAZXhjaGFuZ2UubWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KSSB0aGluayB3ZeKA mXJlIG1ha2luZyBwcm9ncmVzcyBoZXJlLiBTbywgYSBtZXNzYWdlIHdvdWxkIGxvb2sgbGlrZSB0 aGlzOg0KDQpGcm9tOiBqb2VAYXV0aG9yZG9tYWluLmV4YW1wbGU8bWFpbHRvOmpvZUBhdXRob3Jk b21haW4uZXhhbXBsZT4NCkF1dGhlbnRpY2F0aW9uLVJlc3VsdHM6IHNwZj1wYXNzIChzZW5kZXIg SVAgaXMgeHgueHgueHgueHgpIHNtdHAubWFpbGZyb209bWxtLmV4YW1wbGU7DQogICAgZGtpbT1m YWlsIChpbnZhbGlkIGJvZHkgaGFzaCkgaGVhZGVyLmQ9YXV0aG9yZG9tYWluLmV4YW1wbGUNCiAg ICBka2ltPXBhc3MgKHNpZ25hdHVyZSB3YXMgdmVyaWZpZWQpIGhlYWRlci5kPWF1dGhvcmRvbWFp bi5leGFtcGxlOw0KICAgIGRraW09cGFzcyAoc2lnbmF0dXJlIHdhcyB2ZXJpZmllZCkgaGVhZGVy LmQ9bWxtLmV4YW1wbGU7DQogICAgZG1hcmM9cGFzcyBoZWFkZXIuZnJvbT1hdXRob3Jkb21haW4u ZXhhbXBsZSAoYWN0aW9uPW5vbmUgY2Q9bWxtLmV4YW1wbGUpDQpES0lNLVNpZ25hdHVyZTogdj0x OyBkPWF1dGhvcmRvbWFpbi5leGFtcGxlOyBzPXNlbGVjdG9yOyAuLi4NCkRLSU0tU2lnbmF0dXJl OiB2PTI7IGQ9YXV0aG9yZG9tYWluLmV4YW1wbGU7IHM9c2VsZWN0b3I7ICFjZD1tbG0uZXhhbXBs ZTsgbD0wOyB0PTxub3crMzAgc2Vjb25kcz4NCkRLSU0tU2lnbmF0dXJlOiB2PTE7IGQ9bWxtLmV4 YW1wbGU7IHM9Zm9vYmFyOyAuLi4NClNvbWUgcXVlc3Rpb25zOg0KDQoNCjEuICAgICAgIFRoaXMg c2hvdWxkIGJlIHJlc2lzdGFudCB0byBhIHJlcGxheSBhdHRhY2sgMTIgaG91cnMgaW4gdGhlIGZ1 dHVyZSBiZWNhdXNlIHRoZSDigJx0PTxub3crMzAgc2Vjb25kcz7igJ0gaXMgcGFydCBvZiB0aGUg REtJTSBzaWduYXR1cmUgZm9yIHY9MiwgYW5kIGlmIGEgcGhpc2hlciBjb3B5L3Bhc3RlcyBpdCBh bmQgY2hhbmdlcyDigJx2PTLigJ0gdG8g4oCcdj0x4oCdLCB0aGUg4oCcdD0g4oCcIHBhcnQgd2ls bCBiZSBsb25nIHBhc3QuIFJpZ2h0Pw0KDQoidD0iIGlzIHRoZSB0aW1lc3RhbXAgYXQgd2hpY2gg dGhlIHNpZ25hdHVyZSBpcyBnZW5lcmF0ZWQsIHdoaWxlICJ4PSIgaXMgdGhlIGV4cGlyYXRpb24g dGltZXN0YW1wLiBTbywgeW91J2QgZG8gIng9PHQrbGlmZXRpbWU+IiB3aGVyZSAibGlmZXRpbWUi IGlzIHRoZSBudW1iZXIgb2Ygc2Vjb25kcyB5b3Ugd2FudCB0aGUgc2lnbmF0dXJlIHRvIGJlIHZh bGlkLg0KSWYgYSBwaGlzaGVyIGNoYW5nZXMgdGhlICJ2PTIiIHRvICJ2PTEiLCB0aGUgc2lnbmF0 dXJlIGlzIHJlbmRlcmVkIGludmFsaWQgYmVjYXVzZSB0aGF0IGNoYW5nZXMgdGhlIHBhcnQgdGhh dCdzIGhhc2hlZC4gVGhhdCBhdHRhY2sgd29uJ3Qgd29yay4NCg0KMi4gICAgICAgVGhpcyB3aWxs IGJlIHN1c2NlcHRpYmxlIHRvIGEgcmVwbGF5IGF0dGFjayBmb3IgMzAgc2Vjb25kcyBhZnRlciBp bml0aWFsbHkgc2VuZGluZyBpdCBvdXQsIGJ1dCBvbmx5IHRvIHRoZSBtYWlsaW5nIGxpc3QuIFJp Z2h0Pw0KDQpJdCB3aWxsIGJlIHJlcGxheWFibGUgZm9yIHdoYXRldmVyIHRoZSBkaWZmZXJlbmNl IGlzIGJldHdlZW4gInQ9IiBhbmQgIng9IiwgYnkgYW55b25lIHRoYXQgY2FuIGdlbmVyYXRlIGEg dmFsaWQgc2lnbmF0dXJlIGZvciB0aGUgIiFjZCIgZG9tYWluLg0KDQoNCjMuICAgICAgIFZlcmlm aWVycyBuZWVkIHRvIGtub3cgKGVuZm9yY2U/KSB0aGF0IGEgREtJTSBzaWduYXR1cmUgb2Yg4oCc dj0yICFjZD08YmxhaD7igJ0gaXMgbm90IGVub3VnaCB0byB2ZXJpZnkgYSByZWFsIHNpZ25hdHVy ZSB3aXRob3V0IHRoZSBjb3JyZXNwb25kaW5nIOKAnHY9MSBkPTxibGFoPuKAnSBhZGRpdGlvbmFs IERLSU0gc2lnbmF0dXJlLiBJbiBvdGhlciB3b3JkcyDigJx2PTIgIWNkPTxibGFoPuKAnSBpcyB1 c2VsZXNzIHVubGVzcyBwYWlyZWQgd2l0aCBzb21ldGhpbmcgZWxzZS4gUmlnaHQ/DQoNClRoZSBp ZGVhIGJlaGluZCBjaGFuZ2luZyAidj0iIGlzIHRvIGNhdXNlIHZlcmlmaWVycyB0aGF0IGtub3cg YWJvdXQgInY9MiIgdG8gYmUgdGhlIG9ubHkgb25lcyB0aGF0IHVuZGVyc3RhbmQgd2hhdCAiIWNk IiBtZWFucywgbmFtZWx5IHRoYXQgdGhlIHNpZ25hdHVyZSBpcyBub3QgdmFsaWQgdW5sZXNzIGFj Y29tcGFuaWVkIGJ5IGEgdmFsaWQgc2lnbmF0dXJlIGZyb20gdGhlICIhY2QiIGRvbWFpbi4gIEEg dmVyaWZpZXIgdGhhdCBkb2Vzbid0IGtub3cgYWJvdXQgInY9MiIgd2lsbCBzaW1wbHkgaWdub3Jl IHRoYXQgc2lnbmF0dXJlIGVudGlyZWx5LCBzbyB0aGUgY29uZGl0aW9uIGNhbm5vdCBwb3NzaWJs eSBiZSBzYXRpc2ZpZWQuDQoNCjQuICAgICAgIEhvdyBzaG91bGQgcmVwdXRhdGlvbiBlbmdpbmVz IGFjY3J1ZSB0aGlzIG1lc3NhZ2U/IFRvIGF1dGhvcmRvbWFpbi5leGFtcGxlICh0aGUgb25lIGlu IHRoZSBoZWFkZXIuZnJvbSk/IE9yIHRvIG1sbS5leGFtcGxlLCB0aGUgb25lIGluIHRoZSBzbXRw Lm1haWxmcm9tIGFuZCBES0lNIGQ9IGRvbWFpbiB0aGF0IGNvbnRhaW5lZCB0aGUgc3Ryb25nIHNp Z25hdHVyZT8NCg0KVGhhdCdzIGEgZ29vZCBxdWVzdGlvbiwgYnV0IG9uZSBvdXRzaWRlIG9mIEpv aG4ncyBwcm9wb3NhbC4gIEkgc3VwcG9zZSB5b3UgY291bGQgYWNjcnVlIHJlcHV0YXRpb24gb24g dGhlbSBzZXZlcmFsbHksIG9yIGpvaW50bHksIG9yIHBlcmhhcHMgaW4gc29tZSBjb21iaW5hdGlv bnMuICBJIGRvbid0IGtub3cgb2ZmIHRoZSB0b3Agb2YgbXkgaGVhZCB3aGljaCB3b3VsZCBiZSBi ZXN0Lg0KDQoNCjUuICAgICAgIFZlcmlmaWVycyB3aWxsIG5lZWQgdG8gY2hlY2sgYXQgbGVhc3Qg MyBES0lNIHNpZ25hdHVyZXMuIElzIHRoZXJlIGEgbGltaXQgb24gdGhlIGFtb3VudCBvZiBzaWdu YXR1cmVzIHRoZXkgc2hvdWxkIGNoZWNrPyBQcmVzdW1hYmx5IHdlIHdvdWxkbuKAmXQgd2FudCBh IHZlcmlmaWVyIHRvIGNoZWNrIDMwIHNpZ25hdHVyZXMuDQoNCkl0IHdvdWxkIGJlIHVudXN1YWwg dG8gY2hlY2sgbW9yZSB0aGFuIHRocmVlIG9yIHBlcmhhcHMgZml2ZSwgSSB3b3VsZCB0aGluay4g IEl0IG1pZ2h0IGJlIHVzZWZ1bCB0byBjb2xsZWN0IGluZm9ybWF0aW9uIG9uIGhvdyBtYW55IHdl J3JlIHNlZWluZyBpbiB0aGUgd2lsZC4gIENlcnRhaW5seSBhIG1lc3NhZ2UgYmVhcmluZyAyMCBv ciAzMCBtaWdodCByZWFzb25hYmx5IGJlIHJlZ2FyZGVkIGFzIGEgcG9zc2libGUgYXR0YWNrIGJl Y2F1c2UgYSBsb3Qgb2YgRE5TIGFuZCBjcnlwdG8gaGFzIHRvIGJlIGRvbmUuDQoNCjYuICAgICAg IFdoYXQgaXMgdGhlIHByb3Bvc2VkIHQ9IHRpbWUgbGltaXQ/IElzIDMwIHNlY29uZHMgZW5vdWdo PyBUb28gbG9uZz8gVG9vIGxpdHRsZT8NCkkgd291bGQgZ3Vlc3MgdG9vIGxpdHRsZSwgYnV0IGF0 IHRoaXMgcG9pbnQgdGhhdCdzIHN0cmljdGx5IGEgZ3Vlc3MuICBZb3UgbmVlZCB0byBsZWF2ZSBl bm91Z2ggdGltZSBmb3IgcG9zc2libGUgbmV0d29yayBvciBvdGhlciB0cmFuc21pc3Npb24gcHJv YmxlbXMgYmV0d2VlbiB0aGUgc2lnbmVyIGFuZCB0aGUgaW50ZXJtZWRpYXJ5IHlvdSdyZSB0cnlp bmcgdG8gYWNjb21tb2RhdGUuDQotTVNLDQo= --_000_BLUSR01MB601EC45AB3320FA0F46564B96C30BLUSR01MB601namsdf_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+WWVhaCwgc29ycnksIEkgY29uZnVzZWQgdGhl IHQ9IHdpdGggeD0gaW4gdGhlIERLSU0gc2lnbmF0dXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvYT48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+LS0gVGVycnk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE11cnJheSBTLiBLdWNoZXJh d3kgW21haWx0bzpzdXBlcnVzZXJAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNk YXksIE1heSAxOSwgMjAxNSAxOjAyIFBNPGJyPg0KPGI+VG86PC9iPiBUZXJyeSBaaW5rPGJyPg0K PGI+Q2M6PC9iPiBTY290dCBLaXR0ZXJtYW47IGRtYXJjQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbZG1hcmMtaWV0Zl0gTG9va2luZyBmb3IgZGVncmVlcyBvZiBmcmVlZG9tIHdp dGggSW50ZXJtZWRpYXJpZXMgLSBFZmZvcnQgYW5kIFBvbGljeTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgTWF5IDE5LCAyMDE1IGF0IDEyOjAwIFBNLCBUZXJy eSBaaW5rICZsdDs8YSBocmVmPSJtYWlsdG86dHppbmtAZXhjaGFuZ2UubWljcm9zb2Z0LmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnR6aW5rQGV4Y2hhbmdlLm1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBuYW1lPSIxNGQ2ZDhjZGZiYTg2OWZjX19NYWls RW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JIHRo aW5rIHdl4oCZcmUgbWFraW5nIHByb2dyZXNzIGhlcmUuIFNvLCBhIG1lc3NhZ2Ugd291bGQNCiBs b29rIGxpa2UgdGhpczo8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxicj4NCkZy b206IDxhIGhyZWY9Im1haWx0bzpqb2VAYXV0aG9yZG9tYWluLmV4YW1wbGUiPmpvZUBhdXRob3Jk b21haW4uZXhhbXBsZTwvYT48YnI+DQpBdXRoZW50aWNhdGlvbi1SZXN1bHRzOiBzcGY9cGFzcyAo c2VuZGVyIElQIGlzIHh4Lnh4Lnh4Lnh4KSBzbXRwLm1haWxmcm9tPW1sbS5leGFtcGxlOzxicj4N CiZuYnNwOyZuYnNwOyZuYnNwOyBka2ltPWZhaWwgKGludmFsaWQgYm9keSBoYXNoKSBoZWFkZXIu ZD1hdXRob3Jkb21haW4uZXhhbXBsZTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBka2ltPXBhc3Mg KHNpZ25hdHVyZSB3YXMgdmVyaWZpZWQpIGhlYWRlci5kPWF1dGhvcmRvbWFpbi5leGFtcGxlOyA8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZGtp bT1wYXNzIChzaWduYXR1cmUgd2FzIHZlcmlmaWVkKSBoZWFkZXIuZD1tbG0uZXhhbXBsZTs8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDsgZG1hcmM9cGFzcyBoZWFkZXIuZnJvbT1hdXRob3Jkb21haW4u ZXhhbXBsZSAoYWN0aW9uPW5vbmUgY2Q9bWxtLmV4YW1wbGUpPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRL SU0tU2lnbmF0dXJlOiB2PTE7IGQ9YXV0aG9yZG9tYWluLmV4YW1wbGU7IHM9c2VsZWN0b3I7IC4u Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5ES0lNLVNpZ25hdHVyZTogdj0yOyBkPWF1dGhvcmRvbWFpbi5l eGFtcGxlOyBzPXNlbGVjdG9yOyAhY2Q9bWxtLmV4YW1wbGU7IGw9MDsgdD0mbHQ7bm93JiM0Mzsz MCBzZWNvbmRzJmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5ES0lNLVNpZ25hdHVyZTogdj0xOyBkPW1sbS5leGFt cGxlOyBzPWZvb2JhcjsgLi4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlNvbWUgcXVl c3Rpb25zOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjEu PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+VGhpcyBzaG91bGQgYmUgcmVzaXN0YW50IHRvIGEgcmVwbGF5 IGF0dGFjayAxMiBob3VycyBpbiB0aGUgZnV0dXJlIGJlY2F1c2UgdGhlIOKAnHQ9Jmx0O25vdyYj NDM7MzAgc2Vjb25kcyZndDvigJ0gaXMgcGFydCBvZiB0aGUgREtJTSBzaWduYXR1cmUgZm9yIHY9 MiwgYW5kIGlmIGEgcGhpc2hlciBjb3B5L3Bhc3RlcyBpdCBhbmQNCiBjaGFuZ2VzIOKAnHY9MuKA nSB0byDigJx2PTHigJ0sIHRoZSDigJx0PSDigJwgcGFydCB3aWxsIGJlIGxvbmcgcGFzdC4gUmln aHQ/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+JnF1b3Q7dD0mcXVvdDsgaXMgdGhlIHRpbWVzdGFtcCBhdCB3aGljaCB0aGUgc2lnbmF0dXJl IGlzIGdlbmVyYXRlZCwgd2hpbGUgJnF1b3Q7eD0mcXVvdDsgaXMgdGhlIGV4cGlyYXRpb24gdGlt ZXN0YW1wLiBTbywgeW91J2QgZG8gJnF1b3Q7eD0mbHQ7dCYjNDM7bGlmZXRpbWUmZ3Q7JnF1b3Q7 IHdoZXJlICZxdW90O2xpZmV0aW1lJnF1b3Q7IGlzIHRoZSBudW1iZXIgb2Ygc2Vjb25kcyB5b3Ug d2FudCB0aGUgc2lnbmF0dXJlIHRvIGJlIHZhbGlkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgYSBwaGlzaGVyIGNoYW5nZXMgdGhlICZxdW90 O3Y9MiZxdW90OyB0byAmcXVvdDt2PTEmcXVvdDssIHRoZSBzaWduYXR1cmUgaXMgcmVuZGVyZWQg aW52YWxpZCBiZWNhdXNlIHRoYXQgY2hhbmdlcyB0aGUgcGFydCB0aGF0J3MgaGFzaGVkLiBUaGF0 IGF0dGFjayB3b24ndCB3b3JrLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PGRpdj4NCjxkaXY+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PjIuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhpcyB3aWxsIGJlIHN1c2NlcHRpYmxlIHRvIGEgcmVw bGF5IGF0dGFjayBmb3IgMzAgc2Vjb25kcyBhZnRlciBpbml0aWFsbHkgc2VuZGluZyBpdCBvdXQs IGJ1dCBvbmx5IHRvIHRoZSBtYWlsaW5nIGxpc3QuIFJpZ2h0Pzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JdCB3aWxsIGJlIHJlcGxheWFibGUgZm9yIHdoYXRldmVyIHRoZSBkaWZmZXJlbmNl IGlzIGJldHdlZW4gJnF1b3Q7dD0mcXVvdDsgYW5kICZxdW90O3g9JnF1b3Q7LCBieSBhbnlvbmUg dGhhdCBjYW4gZ2VuZXJhdGUgYSB2YWxpZCBzaWduYXR1cmUgZm9yIHRoZSAmcXVvdDshY2QmcXVv dDsgZG9tYWluLjxicj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxkaXY+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjMuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPlZlcmlmaWVycyBuZWVk IHRvIGtub3cgKGVuZm9yY2U/KSB0aGF0IGEgREtJTSBzaWduYXR1cmUgb2Yg4oCcdj0yICFjZD0m bHQ7YmxhaCZndDvigJ0gaXMgbm90IGVub3VnaCB0byB2ZXJpZnkgYSByZWFsIHNpZ25hdHVyZSB3 aXRob3V0IHRoZSBjb3JyZXNwb25kaW5nIOKAnHY9MSBkPSZsdDtibGFoJmd0O+KAnSBhZGRpdGlv bmFsIERLSU0gc2lnbmF0dXJlLiBJbiBvdGhlciB3b3JkcyDigJx2PTIgIWNkPSZsdDtibGFoJmd0 O+KAnSBpcyB1c2VsZXNzIHVubGVzcyBwYWlyZWQgd2l0aCBzb21ldGhpbmcNCiBlbHNlLiBSaWdo dD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoZSBp ZGVhIGJlaGluZCBjaGFuZ2luZyAmcXVvdDt2PSZxdW90OyBpcyB0byBjYXVzZSB2ZXJpZmllcnMg dGhhdCBrbm93IGFib3V0ICZxdW90O3Y9MiZxdW90OyB0byBiZSB0aGUgb25seSBvbmVzIHRoYXQg dW5kZXJzdGFuZCB3aGF0ICZxdW90OyFjZCZxdW90OyBtZWFucywgbmFtZWx5IHRoYXQgdGhlIHNp Z25hdHVyZSBpcyBub3QgdmFsaWQgdW5sZXNzIGFjY29tcGFuaWVkIGJ5IGEgdmFsaWQgc2lnbmF0 dXJlDQogZnJvbSB0aGUgJnF1b3Q7IWNkJnF1b3Q7IGRvbWFpbi4mbmJzcDsgQSB2ZXJpZmllciB0 aGF0IGRvZXNuJ3Qga25vdyBhYm91dCAmcXVvdDt2PTImcXVvdDsgd2lsbCBzaW1wbHkgaWdub3Jl IHRoYXQgc2lnbmF0dXJlIGVudGlyZWx5LCBzbyB0aGUgY29uZGl0aW9uIGNhbm5vdCBwb3NzaWJs eSBiZSBzYXRpc2ZpZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2 Pg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+NC48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+SG93IHNob3VsZCByZXB1dGF0aW9u IGVuZ2luZXMgYWNjcnVlIHRoaXMgbWVzc2FnZT8gVG8gYXV0aG9yZG9tYWluLmV4YW1wbGUgKHRo ZSBvbmUgaW4gdGhlIGhlYWRlci5mcm9tKT8gT3IgdG8gbWxtLmV4YW1wbGUsIHRoZSBvbmUgaW4g dGhlIHNtdHAubWFpbGZyb20gYW5kIERLSU0gZD0gZG9tYWluIHRoYXQgY29udGFpbmVkIHRoZSBz dHJvbmcgc2lnbmF0dXJlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQncyBhIGdvb2QgcXVlc3Rp b24sIGJ1dCBvbmUgb3V0c2lkZSBvZiBKb2huJ3MgcHJvcG9zYWwuJm5ic3A7IEkgc3VwcG9zZSB5 b3UgY291bGQgYWNjcnVlIHJlcHV0YXRpb24gb24gdGhlbSBzZXZlcmFsbHksIG9yIGpvaW50bHks IG9yIHBlcmhhcHMgaW4gc29tZSBjb21iaW5hdGlvbnMuJm5ic3A7IEkgZG9uJ3Qga25vdyBvZmYg dGhlIHRvcCBvZiBteSBoZWFkIHdoaWNoIHdvdWxkIGJlIGJlc3QuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj41Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcu MHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj5WZXJpZmllcnMgd2lsbCBuZWVkIHRvIGNoZWNrIGF0IGxlYXN0IDMgREtJTSBzaWduYXR1 cmVzLiBJcyB0aGVyZSBhIGxpbWl0IG9uIHRoZSBhbW91bnQgb2Ygc2lnbmF0dXJlcyB0aGV5IHNo b3VsZCBjaGVjaz8gUHJlc3VtYWJseSB3ZSB3b3VsZG7igJl0IHdhbnQgYSB2ZXJpZmllciB0byBj aGVjayAzMCBzaWduYXR1cmVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHdvdWxkIGJlIHVudXN1 YWwgdG8gY2hlY2sgbW9yZSB0aGFuIHRocmVlIG9yIHBlcmhhcHMgZml2ZSwgSSB3b3VsZCB0aGlu ay4mbmJzcDsgSXQgbWlnaHQgYmUgdXNlZnVsIHRvIGNvbGxlY3QgaW5mb3JtYXRpb24gb24gaG93 IG1hbnkgd2UncmUgc2VlaW5nIGluIHRoZSB3aWxkLiZuYnNwOyBDZXJ0YWlubHkgYSBtZXNzYWdl IGJlYXJpbmcgMjAgb3IgMzAgbWlnaHQgcmVhc29uYWJseSBiZSByZWdhcmRlZCBhcyBhIHBvc3Np YmxlDQogYXR0YWNrIGJlY2F1c2UgYSBsb3Qgb2YgRE5TIGFuZCBjcnlwdG8gaGFzIHRvIGJlIGRv bmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxw PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Ni48L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5XaGF0IGlzIHRoZSBwcm9wb3NlZCB0PSB0aW1lIGxpbWl0PyBJcyAzMCBzZWNvbmRz IGVub3VnaD8gVG9vIGxvbmc/IFRvbyBsaXR0bGU/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkkgd291bGQgZ3Vlc3MgdG9vIGxpdHRsZSwgYnV0 IGF0IHRoaXMgcG9pbnQgdGhhdCdzIHN0cmljdGx5IGEgZ3Vlc3MuJm5ic3A7IFlvdSBuZWVkIHRv IGxlYXZlIGVub3VnaCB0aW1lIGZvciBwb3NzaWJsZSBuZXR3b3JrIG9yIG90aGVyIHRyYW5zbWlz c2lvbiBwcm9ibGVtcyBiZXR3ZWVuIHRoZSBzaWduZXIgYW5kIHRoZSBpbnRlcm1lZGlhcnkgeW91 J3JlIHRyeWluZyB0bw0KIGFjY29tbW9kYXRlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LU1TSzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BLUSR01MB601EC45AB3320FA0F46564B96C30BLUSR01MB601namsdf_-- From nobody Tue May 19 13:52:46 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395CD1B3264 for ; Tue, 19 May 2015 13:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.999 X-Spam-Level: X-Spam-Status: No, score=0.999 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awqQCEKG60LA for ; Tue, 19 May 2015 13:52:42 -0700 (PDT) Received: from mx10.mailtransaction.com (mx10.mailtransaction.com [88.198.59.241]) by ietfa.amsl.com (Postfix) with ESMTP id 49D9F1B3262 for ; Tue, 19 May 2015 13:52:32 -0700 (PDT) Received: from mx24.mailtransaction.com (mx21.mailtransaction.com [78.46.16.236]) by mx10.mailtransaction.com (Postfix) with ESMTP id 3lrqCf5q5Kz5Mgfk; Tue, 19 May 2015 22:52:30 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx24.mailtransaction.com (Postfix) with ESMTP id 3lrqCf1jmBz1L8nh; Tue, 19 May 2015 22:52:30 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 063F3123514; Tue, 19 May 2015 22:52:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ZKUgkjiiJZg2; Tue, 19 May 2015 22:52:27 +0200 (CEST) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 128CE123398; Tue, 19 May 2015 22:52:27 +0200 (CEST) Message-ID: <555BA28A.5040208@sonnection.nl> Date: Tue, 19 May 2015 22:52:26 +0200 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Terry Zink References: <555656FC.5010609@dcrocker.net> <1432015208815.92898@exchange.microsoft.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060706070101010107080005" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1432068750; bh=r5ARrRCi7eKVrgxJDn2201HjylesTiWtHQKzJiTfYz8=; h=Message-ID:Date:From:To:Subject:From; b=lh3iR7QKMx6cI74X7eU3uEaTo3W2EW6mTrmoaZ5A7hWR1wtWZExaTCDCNvCYhJk8H Spdr9LgDzKFmlKIkfmdPTRyXrr2E/OGlNtQEDnKYTfVS842mQpfTZZ5h2QKJ9t670h jL4IYhIYtzYcDsEKJ1Cg/SgqvtdbEZfkv3ZjjkVg= DKIM-Filter: OpenDKIM Filter v2.8.2 mx10.mailtransaction.com 3lrqCf5q5Kz5Mgfk Archived-At: Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 20:52:45 -0000 This is a multi-part message in MIME format. --------------060706070101010107080005 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 05/19/2015 10:01 PM, Murray S. Kucherawy wrote: > On Tue, May 19, 2015 at 12:00 PM, Terry Zink=20 > >=20 > wrote: > > I think we=92re making progress here. So, a message would look like > this: > > > From: joe@authordomain.example > Authentication-Results: spf=3Dpass (sender IP is xx.xx.xx.xx) > smtp.mailfrom=3Dmlm.example; > dkim=3Dfail (invalid body hash) header.d=3Dauthordomain.example > dkim=3Dpass (signature was verified) header.d=3Dauthordomain.ex= ample; > > dkim=3Dpass (signature was verified) header.d=3Dmlm.example; > dmarc=3Dpass header.from=3Dauthordomain.example (action=3Dnone > cd=3Dmlm.example) > > DKIM-Signature: v=3D1; d=3Dauthordomain.example; s=3Dselector; ... > > DKIM-Signature: v=3D2; d=3Dauthordomain.example; s=3Dselector; > !cd=3Dmlm.example; l=3D0; t=3D > > DKIM-Signature: v=3D1; d=3Dmlm.example; s=3Dfoobar; ... > > Some questions: > > 1.This should be resistant to a replay attack 12 hours in the > future because the =93t=3D=94 is part of the DKIM > signature for v=3D2, and if a phisher copy/pastes it and changes > =93v=3D2=94 to =93v=3D1=94, the =93t=3D =93 part will be long past.= Right? > > > "t=3D" is the timestamp at which the signature is generated, while "x=3D= "=20 > is the expiration timestamp. So, you'd do "x=3D" where=20 > "lifetime" is the number of seconds you want the signature to be valid. Do we have information about the percentage of implementations (c.q. of=20 the installed base of implementations) that honour the t=3D and x=3D tags= ?=20 Is that near 100%, 50%, less? /rolf --------------060706070101010107080005 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On 05/19/2015 10:01 PM, Murray S. Kucherawy wrote:
On Tue, May 19, 2015 at 12:00 PM, Terry Zink <tzink@exchange.microsoft.com> wrote:

I think we=92re making progress here. So, a message would look like this:


From: joe@authordomain.example
Authentication-Results: spf=3Dpass (sender IP is xx.xx.xx.xx) smtp.mailfrom=3Dmlm.example;
=A0=A0=A0 dkim=3Dfail (invalid body hash) header.d=3Dauthordomain.example
=A0=A0=A0 dkim=3Dpass (signature was verified) header.d=3Dauthordomain.example;

=A0=A0=A0=A0dkim=3Dpass (signature was verified) header.d=3Dmlm.example; =A0=A0=A0 dmarc=3Dpass header.from=3Dauthordomain.e= xample (action=3Dnone cd=3Dmlm.example)

DKIM-Signature: v=3D1; d=3Dauthordomain.example; s=3Dselector; ..= .

DKIM-Signature: v=3D2; d=3Dauthordomain.example; s=3Dselector; !cd=3Dmlm.example; l=3D0; t=3D<now+30 seconds>= ;

DKIM-Signature: v=3D1; d=3Dmlm.example; s=3Dfoobar; ...

Some questions:

=A0

1.This should be resistant to a replay attack 12 hours in the future because the =93t=3D<now+30 seconds>= ;=94 is part of the DKIM signature for v=3D2, and if a phisher copy/pastes it and changes =93v=3D2=94 to =93= v=3D1=94, the =93t=3D =93 part will be long past. Right?


"t=3D" is the timestamp at which the signature is generated, while "x=3D" is the expiration timestamp. So, you'd do "x=3D<t+lifetime>" where "lifetime" is the number of seconds you want the signature to be valid.

Do we have information about the percentage of implementations (c.q. of the installed base of implementations) that honour the t=3D and x=3D= =A0 tags? Is that near 100%, 50%, less?

/rolf

--------------060706070101010107080005-- From nobody Tue May 19 13:58:29 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CD31B2A99 for ; Tue, 19 May 2015 13:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.689 X-Spam-Level: X-Spam-Status: No, score=0.689 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXmBTRKjMdTr for ; Tue, 19 May 2015 13:58:26 -0700 (PDT) Received: from segv.crash.com (segv.crash.com [IPv6:2001:470:1:1e9::4415]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF67A1B2A80 for ; Tue, 19 May 2015 13:58:26 -0700 (PDT) Received: from abort.crash.com (70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26]) (authenticated bits=0) by segv.crash.com (8.14.5/8.14.5/cci-colo-1.6) with ESMTP id t4JKwICJ035550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 19 May 2015 13:58:23 -0700 (PDT) (envelope-from smj@crash.com) X-DKIM: OpenDKIM Filter v2.4.3 segv.crash.com t4JKwICJ035550 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crash.com; s=20130426; t=1432069104; bh=VO0oMx+FKwxDzdk4L5nLAT6YbY7Q/BXhy+XMd84i2NI=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type; b=M1/R+eET0Cr1/QLHg7F2pfQrncC3YcEGpTOrkAu4ooQVEvpuRifCRNuR00STRR0Zp XusH3SC4Aevjl8ikl22Khv66CluVHxTWELZeOqhh/1xiz30b/JEdi1AGh4kEd9yx5J 6mZApcSbJHw2g4pvAo1JQyIvTMMopd7nrfWnUdds= X-Authentication-Warning: segv.crash.com: Host 70-36-157-26.dsl.static.fusionbroadband.com [70.36.157.26] claimed to be abort.crash.com Message-ID: <555BA3EC.2060000@crash.com> Date: Tue, 19 May 2015 13:58:20 -0700 From: Steven M Jones Organization: Crash Computing, Inc. User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <555656FC.5010609@dcrocker.net> <1432015208815.92898@exchange.microsoft.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080002050803030409020200" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (segv.crash.com [72.52.75.15]); Tue, 19 May 2015 13:58:24 -0700 (PDT) Archived-At: Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 20:58:28 -0000 This is a multi-part message in MIME format. --------------080002050803030409020200 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 05/19/2015 13:01, Murray S. Kucherawy wrote: > On Tue, May 19, 2015 at 12:00 PM, Terry Zink > > > wrote: > > 6.What is the proposed t= time limit? Is 30 seconds enough? Too > long? Too little? > > I would guess too little, but at this point that's strictly a guess. > You need to leave enough time for possible network or other > transmission problems between the signer and the intermediary you're > trying to accommodate. I expect you'll ultimately have to leave that up to the signer, no? Traditional practice would set it sometime between hours and days. But when somebody gets around to trying to exploit this window, sites with quick (re-)delivery to most of their recipients will probably want to cut the length of that exposure down... --S. --------------080002050803030409020200 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 05/19/2015 13:01, Murray S. Kucherawy wrote:
On Tue, May 19, 2015 at 12:00 PM, Terry Zink <tzink@exchange.microsoft.com> wrote:

6.       What is the proposed t= time limit? Is 30 seconds enough? Too long? Too little?

I would guess too little, but at this point that's strictly a guess.  You need to leave enough time for possible network or other transmission problems between the signer and the intermediary you're trying to accommodate.

I expect you'll ultimately have to leave that up to the signer, no? Traditional practice would set it sometime between hours and days. But when somebody gets around to trying to exploit this window, sites with quick (re-)delivery to most of their recipients will probably want to cut the length of that exposure down...

--S.

--------------080002050803030409020200-- From nobody Tue May 19 14:51:42 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3265D1B33DD for ; Tue, 19 May 2015 14:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVwxWvJ26Dwj for ; Tue, 19 May 2015 14:51:40 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id A28841ACCF5 for ; Tue, 19 May 2015 14:51:39 -0700 (PDT) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3lrrWs4gVTz1L8nh; Tue, 19 May 2015 23:51:37 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3lrrWs3H1Rz5Mgfk; Tue, 19 May 2015 23:51:37 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 8B196123518; Tue, 19 May 2015 23:42:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YaVIrHWmfgfP; Tue, 19 May 2015 23:42:47 +0200 (CEST) Received: from [192.168.1.49] (unknown [192.168.1.49]) by jaguar.sonnection.nl (Postfix) with ESMTPSA id 0A447123514; Tue, 19 May 2015 23:42:47 +0200 (CEST) Message-ID: <555BAE56.1090003@sonnection.nl> Date: Tue, 19 May 2015 23:42:46 +0200 From: "Rolf E. Sonneveld" Organization: Sonnection B.V. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Steven M Jones , dmarc@ietf.org References: <555656FC.5010609@dcrocker.net> <1432015208815.92898@exchange.microsoft.com> <555BA3EC.2060000@crash.com> In-Reply-To: <555BA3EC.2060000@crash.com> Content-Type: multipart/alternative; boundary="------------060401090701060807060800" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1432072297; bh=kzQ6dYVRZY0Ja17UEpkJyjQJzSem334juHwHn+PKLP8=; h=Message-ID:Date:From:To:Subject:From; b=VLZSdNfnriXYCymZwodC8WlENkUlQ/azuPHQGF0nX8otkwG5Ln2FgUYfsMXI8Qwe+ eKjWy59hWbV5IVfnb2IlI4TGu39HYh58XIKlpipM3t4qIyh55hzmeCi5Vs5Cvf51+C rI/jfuqkERsf3YpT0MHkyzw/U0CdsG3GIANP7yls= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3lrrWs4gVTz1L8nh Archived-At: Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: R.E.Sonneveld@sonnection.nl List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 21:51:42 -0000 This is a multi-part message in MIME format. --------------060401090701060807060800 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 05/19/2015 10:58 PM, Steven M Jones wrote: > On 05/19/2015 13:01, Murray S. Kucherawy wrote: >> On Tue, May 19, 2015 at 12:00 PM, Terry Zink >> > >> wrote: >> >> 6.What is the proposed t= time limit? Is 30 seconds enough? Too >> long? Too little? >> >> I would guess too little, but at this point that's strictly a guess. >> You need to leave enough time for possible network or other >> transmission problems between the signer and the intermediary you're >> trying to accommodate. > > I expect you'll ultimately have to leave that up to the signer, no? Yep. And with the 'receiver' deciding whether to honour the requested expiration. > Traditional practice would set it sometime between hours and days. Agreed. > But when somebody gets around to trying to exploit this window, sites > with quick (re-)delivery to most of their recipients will probably > want to cut the length of that exposure down... which effectively kills the SMTP retry strategy concept [1] and hence the store-and-forward character of Internet mail, as we know it since the late 70's. Please note that SMTP itself has per command timeouts [2] which make short t= limits in the order of sub-minutes or some minutes unrealistic for some parts of the Internet and for delivery to some organizations which now and then have outages of more than a few minutes (no monitoring, no staff etc.). Also, note that large mailing lists may take some time to expand the address list and deliver the mail to all recipients... So when an expiration time is chosen it has to match the real world of mail delivery, which is far better than 20 years ago, but still isn't perfect... /rolf [1] https://tools.ietf.org/html/rfc5321#section-4.5.4.1 [2] https://tools.ietf.org/html/rfc5321#section-4.5.3.2 --------------060401090701060807060800 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On 05/19/2015 10:58 PM, Steven M Jones wrote:
On 05/19/2015 13:01, Murray S. Kucherawy wrote:
On Tue, May 19, 2015 at 12:00 PM, Terry Zink <tzink@exchange.microsoft.com> wrote:

6.=A0=A0=A0=A0=A0=A0 What is the proposed t=3D time limit? Is 30 seconds enough? Too long? Too little?

I would guess too little, but at this point that's strictly a guess.=A0 You need to leave enough time for possible network or other transmission problems between the signer and the intermediary you're trying to accommodate.

I expect you'll ultimately have to leave that up to the signer, no?

Yep. And with the 'receiver' deciding whether to honour the requested expiration.
=A0
Tra= ditional practice would set it sometime between hours and days.
Agreed.

But when somebody gets around to trying to exploit this window, sites with quick (re-)delivery to most of their recipients will probably want to cut the length of that exposure down...

which effectively kills the SMTP retry strategy concept [1] and hence the store-and-forward character of Internet mail, as we know it since the late 70's. Please note that SMTP itself has per command timeouts [2] which make short t=3D limits in the order of sub-minutes or some minutes unrealistic for some parts of the Internet and for delivery to some organizations which now and then have outages of more than a few minutes (no monitoring, no staff etc.). Also, note that large mailing lists may take some time to expand the address list and deliver the mail to all recipients... So when an expiration time is chosen it has to match the real world of mail delivery, which is far better than 20 years ago, but still isn't perfect...

/rolf

[1] https://tools.ietf.org/html/rfc5321#sectio= n-4.5.4.1
[2] https://tools.ietf.org/html/rfc5321#sectio= n-4.5.3.2

--------------060401090701060807060800-- From nobody Tue May 19 15:15:28 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D3A1B3461 for ; Tue, 19 May 2015 15:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.263 X-Spam-Level: ** X-Spam-Status: No, score=2.263 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYJ4woJNA-eU for ; Tue, 19 May 2015 15:15:20 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DEE81B345C for ; Tue, 19 May 2015 15:15:20 -0700 (PDT) Received: (qmail 43061 invoked from network); 19 May 2015 22:15:24 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 19 May 2015 22:15:24 -0000 Date: 19 May 2015 22:14:56 -0000 Message-ID: <20150519221456.62340.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] A-R header, was Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 22:15:21 -0000 >> What would the Authentication-Results header look like? Presumably 3 >> results for DKIM (dkim=fail, dkim=pass, dkim=pass)? And what about DMARC? >> Show one result or two? Or maybe something like dmarc=conditionalpass? ... >Is there any use in making a distinction to your acceptance/routing of >messages to know it was based on a conditional signature versus an original >author signature? I don't see how this would work. A bad guy can sign a fake A-R header as easily as a good guy can sign a real one. How is the recipient supposed to tell the difference? If you say you only use the A-R if you trust the intermediary, who needs the A-R? You already trust them to send something reasonable. R's, John From nobody Tue May 19 15:16:07 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6F41B345E for ; Tue, 19 May 2015 15:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFmPqhhHkHzT for ; Tue, 19 May 2015 15:16:05 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E6461B3319 for ; Tue, 19 May 2015 15:16:04 -0700 (PDT) Received: by wgjc11 with SMTP id c11so33413511wgj.0 for ; Tue, 19 May 2015 15:16:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PrBFGDGqEN6g5rrG4jIQDJBpZQQWNWxzAGjKAc0UZuk=; b=MkCL2DxTDAZHjwGqyeejxqCqZKLkREoUgAvXmYhJ8vaaMpUf9hYPSlTtDQz4loTwmq m2QBaec8+eccayB1ODlHC0x9rMd3SRxmtGLUIZkbpe5aE4MCK7/MWZIyr9uMkocHrZvv 8Ng8UkvHHabkridclr5RH/tL7sKkIOIw+5t8lFVZnN9eIOotfJcE1Q/XnUS4d74dPy8c /XUXE1Uzn8L+UwqB+0kXsqTei/C3AO7wUW8oL6AnGdWM6nxh/UfZfE/sti5NSEc6BzSE xUajIOECB6VXxj+4RmKf3Rth1DBlpOhwATxhyfXpVnS+ErJDS2Acc0jxnyLtQKx1X4D5 8FRw== MIME-Version: 1.0 X-Received: by 10.194.174.68 with SMTP id bq4mr42538149wjc.4.1432073762990; Tue, 19 May 2015 15:16:02 -0700 (PDT) Received: by 10.27.170.134 with HTTP; Tue, 19 May 2015 15:16:02 -0700 (PDT) In-Reply-To: <555BA3EC.2060000@crash.com> References: <555656FC.5010609@dcrocker.net> <1432015208815.92898@exchange.microsoft.com> <555BA3EC.2060000@crash.com> Date: Tue, 19 May 2015 15:16:02 -0700 Message-ID: From: "Murray S. Kucherawy" To: Steven M Jones Content-Type: multipart/alternative; boundary=089e01493680ef714e051676a789 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 22:16:06 -0000 --089e01493680ef714e051676a789 Content-Type: text/plain; charset=UTF-8 On Tue, May 19, 2015 at 1:58 PM, Steven M Jones wrote: > 6. What is the proposed t= time limit? Is 30 seconds enough? Too > long? Too little? > > I would guess too little, but at this point that's strictly a guess. > You need to leave enough time for possible network or other transmission > problems between the signer and the intermediary you're trying to > accommodate. > > > I expect you'll ultimately have to leave that up to the signer, no? > Traditional practice would set it sometime between hours and days. But when > somebody gets around to trying to exploit this window, sites with quick > (re-)delivery to most of their recipients will probably want to cut the > length of that exposure down... > Yes, absolutely this is at the discretion of the signer and not something to be fixed in a protocol document except perhaps to enumerate the tradeoffs between a short expiration and a long one. -MSK --089e01493680ef714e051676a789 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 19, 2015 at 1:58 PM, Steven M Jones <smj@crash.c= om> wrote:
=20 =20 =20
6.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 What is the proposed t=3D time limit? Is 30 seconds enough? Too long? Too little?
I would guess too little, but at this point that's strictly a guess.=C2=A0 You need to leave enough time for possible network or other transmission problems between the signer and the intermediary you're trying to accommodate.

I expect you'll ultimately have to leave that up to the signer, no? Traditional practice would set it sometime between hours and days. But when somebody gets around to trying to exploit this window, sites with quick (re-)delivery to most of their recipients will probably want to cut the length of that exposure down...

<= /div>
Yes, absolutely this is at the discretion of the signer and not s= omething to be fixed in a protocol document except perhaps to enumerate the= tradeoffs between a short expiration and a long one.

-MS= K
--089e01493680ef714e051676a789-- From nobody Tue May 19 15:28:45 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A2E1B3461 for ; Tue, 19 May 2015 15:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBsNSy5pcHdT for ; Tue, 19 May 2015 15:28:41 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA251B3479 for ; Tue, 19 May 2015 15:28:40 -0700 (PDT) Received: by wibt6 with SMTP id t6so39442360wib.0 for ; Tue, 19 May 2015 15:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HugT7kL++8zDh7X2UCjWg7qiotebFvujW35APQLDnSA=; b=dZTUD4V7ykPqMApv6SJsnQr4A23QaG2Y30peNgZbQGCICKxjx7JuoNIdylQlj7qy+N pe5CCiWzQ/l9HE58zk0pX5M2527AevBgV+dIe8MgsFTpT8v/6YVMGhWd748S6DUBOu4E RRBKGXD+Gvi5xe5VmygJ5fdCggneSF4C981UbR78deH9wZPAt0ywXqKDCiKmEYl8rtRm ar5VXZzE4Mk2WF0KoBAjdh5QWnVhF+YoCyuDiEw+ZUdD45lGpeir400+AsjRYEZx+6Y4 1noY8NPtc6PntcjGGlAaGcTg8hvcUCJRBcckQisFIMpuMPG9SseojyT7JKxH+V3SeOa7 +Rwg== MIME-Version: 1.0 X-Received: by 10.180.221.9 with SMTP id qa9mr13520594wic.52.1432074519492; Tue, 19 May 2015 15:28:39 -0700 (PDT) Received: by 10.27.170.134 with HTTP; Tue, 19 May 2015 15:28:39 -0700 (PDT) In-Reply-To: <555BAE56.1090003@sonnection.nl> References: <555656FC.5010609@dcrocker.net> <1432015208815.92898@exchange.microsoft.com> <555BA3EC.2060000@crash.com> <555BAE56.1090003@sonnection.nl> Date: Tue, 19 May 2015 15:28:39 -0700 Message-ID: From: "Murray S. Kucherawy" To: "" Content-Type: multipart/alternative; boundary=001a1134ccc006bf06051676d51b Archived-At: Cc: "dmarc@ietf.org" , Steven M Jones Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 22:28:43 -0000 --001a1134ccc006bf06051676d51b Content-Type: text/plain; charset=UTF-8 On Tue, May 19, 2015 at 2:42 PM, Rolf E. Sonneveld < R.E.Sonneveld@sonnection.nl> wrote: > > But when somebody gets around to trying to exploit this window, sites with > quick (re-)delivery to most of their recipients will probably want to cut > the length of that exposure down... > > > which effectively kills the SMTP retry strategy concept [1] and hence the > store-and-forward character of Internet mail, as we know it since the late > 70's. Please note that SMTP itself has per command timeouts [2] which make > short t= limits in the order of sub-minutes or some minutes unrealistic for > some parts of the Internet and for delivery to some organizations which now > and then have outages of more than a few minutes (no monitoring, no staff > etc.). Also, note that large mailing lists may take some time to expand the > address list and deliver the mail to all recipients... So when an > expiration time is chosen it has to match the real world of mail delivery, > which is far better than 20 years ago, but still isn't perfect... > To your first point: SMTP itself isn't being altered by these proposals in any way that I can see. We're not changing the parts of SMTP you referenced. For one thing, if a DMARC rejection is undertaken by a receiver, that action is final; there's no retry going to happen. For another, we're not influencing which host is being selected or what the retry interval might be, or how long a queued message should be held before ultimately being returned as undeliverable. If DMARC recommended 4yz SMTP replies when failures happen, that might be different, but that's not the case here. All of this can be thought of as happening in a layer above SMTP, not as part of it. To your second point: Those timeouts recommended by SMTP should at least be referenced by any advice a conditional signatures draft might provide in terms of selecting an expiration time. Such a section would also be wise to talk about header field selection and the like. More generally, any advice we can provide about what to consider when selecting the construction of the conditional signature would be wise to include. -MSK --001a1134ccc006bf06051676d51b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 19, 2015 at 2:42 PM, Rolf E. Sonneveld <R.E.Sonneveld@sonnection.nl> wrote:
=20 =20 =20

But when somebody gets around to trying to exploit this window, sites with quick (re-)delivery to most of their recipients will probably want to cut the length of that exposure down...

 which effectively kills the SMTP retry strategy concept [1] and hence the store-and-forward character of Internet mail, as we know it since the late 70's. Please note that SMTP itself has per comman= d timeouts [2] which make short t=3D limits in the order of sub-minutes or some minutes unrealistic for some parts of the Internet and for delivery to some organizations which now and then have outages of more than a few minutes (no monitoring, no staff etc.). Also, note that large mailing lists may take some time to expand the address list and deliver the mail to all recipients... So when an expiration time is chosen it has to match the real world of mail delivery, which is far better than 20 years ago, but still isn't perfect...

To your first point: SMTP itself i= sn't being altered by these proposals in any way that I can see.=C2=A0 = We're not changing the parts of SMTP you referenced.=C2=A0 For one thin= g, if a DMARC rejection is undertaken by a receiver, that action is final; = there's no retry going to happen.=C2=A0 For another, we're not infl= uencing which host is being selected or what the retry interval might be, o= r how long a queued message should be held before ultimately being returned= as undeliverable.=C2=A0 If DMARC recommended 4yz SMTP replies when failure= s happen, that might be different, but that's not the case here.=C2=A0 = All of this can be thought of as happening in a layer above SMTP, not as pa= rt of it.

To your second point: Those timeouts recommende= d by SMTP should at least be referenced by any advice a conditional signatu= res draft might provide in terms of selecting an expiration time.=C2=A0 Suc= h a section would also be wise to talk about header field selection and the= like.=C2=A0 More generally, any advice we can provide about what to consid= er when selecting the construction of the conditional signature would be wi= se to include.

-MSK


--001a1134ccc006bf06051676d51b-- From nobody Tue May 19 15:56:49 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461BC1B34CB for ; Tue, 19 May 2015 15:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wA02ZMqatLt for ; Tue, 19 May 2015 15:56:34 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2CCA1B34C5 for ; Tue, 19 May 2015 15:56:32 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so132502260wic.0 for ; Tue, 19 May 2015 15:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UBV2A1DMR3dMp0GxBknGwIYensi4WSfCIB2e9kPeSAQ=; b=vOe1jCegrxpRSK6qmShSHCvdFEygw9TFfItg8+YjqaEXH7Z0rDyuZEeQxBsH5HgwtV TZCPr03gPNRKADY4hlvyOD6n3G2SesI9JP5RjO0iCwT7G1k1l4hcrKXDDPAZPrAvh/eZ gH3rcVlAbAzue91umEbf+u9/C8VwKEZeniLLqIKvIMu9AIVJX8wUM7+fzOuGRCHA91I5 kQ3uXXDVyOLesFbl1/NxGx5lk7gOzXQv2BIefgYQu97Rr9DXulNE6hXOmHAqN/AQPNQT myLVPbXTY+45Su2wpfzfLI4YvYpMYG2eujL2l72jH6Htkr5+NbeKViF/cuK1/o/XzfBa YR1Q== MIME-Version: 1.0 X-Received: by 10.180.210.162 with SMTP id mv2mr36136279wic.59.1432076191502; Tue, 19 May 2015 15:56:31 -0700 (PDT) Received: by 10.27.170.134 with HTTP; Tue, 19 May 2015 15:56:31 -0700 (PDT) In-Reply-To: References: <555656FC.5010609@dcrocker.net> <1432015208815.92898@exchange.microsoft.com> <555BA3EC.2060000@crash.com> <555BAE56.1090003@sonnection.nl> Date: Tue, 19 May 2015 15:56:31 -0700 Message-ID: From: "Murray S. Kucherawy" To: "" Content-Type: multipart/alternative; boundary=001a11c37daeaf9931051677380d Archived-At: Cc: "dmarc@ietf.org" , Steven M Jones Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 22:56:36 -0000 --001a11c37daeaf9931051677380d Content-Type: text/plain; charset=UTF-8 On Tue, May 19, 2015 at 3:28 PM, Murray S. Kucherawy wrote: > On Tue, May 19, 2015 at 2:42 PM, Rolf E. Sonneveld < > R.E.Sonneveld@sonnection.nl> wrote: > > >> But when somebody gets around to trying to exploit this window, sites >> with quick (re-)delivery to most of their recipients will probably want to >> cut the length of that exposure down... >> >> >> which effectively kills the SMTP retry strategy concept [1] and hence the >> store-and-forward character of Internet mail, as we know it since the late >> 70's. Please note that SMTP itself has per command timeouts [2] which make >> short t= limits in the order of sub-minutes or some minutes unrealistic for >> some parts of the Internet and for delivery to some organizations which now >> and then have outages of more than a few minutes (no monitoring, no staff >> etc.). Also, note that large mailing lists may take some time to expand the >> address list and deliver the mail to all recipients... So when an >> expiration time is chosen it has to match the real world of mail delivery, >> which is far better than 20 years ago, but still isn't perfect... >> > > To your first point: SMTP itself isn't being altered by these proposals in > any way that I can see. We're not changing the parts of SMTP you > referenced. For one thing, if a DMARC rejection is undertaken by a > receiver, that action is final; there's no retry going to happen. For > another, we're not influencing which host is being selected or what the > retry interval might be, or how long a queued message should be held before > ultimately being returned as undeliverable. If DMARC recommended 4yz SMTP > replies when failures happen, that might be different, but that's not the > case here. All of this can be thought of as happening in a layer above > SMTP, not as part of it. > > To your second point: Those timeouts recommended by SMTP should at least > be referenced by any advice a conditional signatures draft might provide in > terms of selecting an expiration time. Such a section would also be wise > to talk about header field selection and the like. More generally, any > advice we can provide about what to consider when selecting the > construction of the conditional signature would be wise to include. > We also appear to be OK with imposing delivery timeouts that extend beyond the basic timeout set described in RFC5321, given what it says in RFC2852 (from 2000). -MSK --001a11c37daeaf9931051677380d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 19, 2015 at 3:28 PM, Murray S. Kucherawy <s= uperuser@gmail.com> wrote:
On Tue, May 19, 2015 at 2:42 PM, Rolf E. Sonneveld <R.E.Sonneveld@sonnection.nl> wrote:

=20 =20 =20

But when somebody gets around to trying to exploit this window, sites with quick (re-)delivery to most of their recipients will probably want to cut the length of that exposure down...

 which effectively kills the SMTP retry strategy concept [1] and hence the store-and-forward character of Internet mail, as we know it since the late 70's. Please note that SMTP itself has per comman= d timeouts [2] which make short t=3D limits in the order of sub-minutes or some minutes unrealistic for some parts of the Internet and for delivery to some organizations which now and then have outages of more than a few minutes (no monitoring, no staff etc.). Also, note that large mailing lists may take some time to expand the address list and deliver the mail to all recipients... So when an expiration time is chosen it has to match the real world of mail delivery, which is far better than 20 years ago, but still isn't perfect...

To your first point: SMTP i= tself isn't being altered by these proposals in any way that I can see.= =C2=A0 We're not changing the parts of SMTP you referenced.=C2=A0 For o= ne thing, if a DMARC rejection is undertaken by a receiver, that action is = final; there's no retry going to happen.=C2=A0 For another, we're n= ot influencing which host is being selected or what the retry interval migh= t be, or how long a queued message should be held before ultimately being r= eturned as undeliverable.=C2=A0 If DMARC recommended 4yz SMTP replies when = failures happen, that might be different, but that's not the case here.= =C2=A0 All of this can be thought of as happening in a layer above SMTP, no= t as part of it.

To your second point: Those timeouts rec= ommended by SMTP should at least be referenced by any advice a conditional = signatures draft might provide in terms of selecting an expiration time.=C2= =A0 Such a section would also be wise to talk about header field selection = and the like.=C2=A0 More generally, any advice we can provide about what to= consider when selecting the construction of the conditional signature woul= d be wise to include.
=

We also appear to be OK with imposing deli= very timeouts that extend beyond the basic timeout set described in RFC5321= , given what it says in RFC2852 (from 2000).

-MSK
--001a11c37daeaf9931051677380d-- From nobody Tue May 19 16:40:48 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B3A1A19F8 for ; Tue, 19 May 2015 16:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxGR8T3_AEh2 for ; Tue, 19 May 2015 16:40:46 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF5F01A19E5 for ; Tue, 19 May 2015 16:40:44 -0700 (PDT) Received: (qmail 53843 invoked from network); 19 May 2015 23:40:49 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 19 May 2015 23:40:49 -0000 Date: 19 May 2015 23:40:21 -0000 Message-ID: <20150519234021.62540.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: sklist@kitterman.com Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 23:40:47 -0000 >I would think you'd have to. There's a replay risk that's unique to this type of >signature, so I think treating them the same would be a naive approach. Remember that DMARC doesn't tell you that a message is good. The most it can say is "not so awful that you should automatically reject it." A sensible implementation will still run the mail through spam filters like any other mail. The risk is that the second signer might be malicious, but that's nothing new, any signer can be malicious. So do the usual filtering, use the second signer's reputation. R's, John From nobody Tue May 19 17:14:31 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3CB1ACD5B for ; Tue, 19 May 2015 17:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mxqc5bUHqxbS for ; Tue, 19 May 2015 17:14:29 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 025C21ACD55 for ; Tue, 19 May 2015 17:14:29 -0700 (PDT) Received: by pacwv17 with SMTP id wv17so44993393pac.2 for ; Tue, 19 May 2015 17:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=qV/sVut14pB5dEZBBAsHaDxOXA33t9a8hHclISPFvnM=; b=ogbn9L9513D5euRhmCydMMOT/wbgqvAElBLHZPmMbmJw5WTtXko55+/eTe9NhOFS7/ x2wNqnw65qrj50OhUrvHzc3TbGA0tYXoIWqDs3kwJbt/8yQIq+j+cfFdw2ZwuvNf1fhh RO+MD63jr23E5tecul5q1d6JU65q6qCabdRZmKtqq/k9QqgrPNtboXu53QuV9Q/1FeRd Q0SDR5EQidsK1//fPU2+/cLyzB/iZQ6wMx182J/UZOGkLiygX7xhGJHHpcud1/yF2ZAz 3ddlEZQb+OScTE0Nkfzy4RZzkFALdEvTjZmOKDA2/3WBSWe7agseydSACCXh5x0sUdqB ZolQ== X-Received: by 10.70.90.100 with SMTP id bv4mr58616885pdb.53.1432080868732; Tue, 19 May 2015 17:14:28 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id cd10sm14224598pac.7.2015.05.19.17.14.25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 May 2015 17:14:27 -0700 (PDT) Message-ID: <555BD1DF.7080502@gmail.com> Date: Tue, 19 May 2015 17:14:23 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <555656FC.5010609@dcrocker.net> <1432015208815.92898@exchange.microsoft.com> <555BA3EC.2060000@crash.com> <555BAE56.1090003@sonnection.nl> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 00:14:31 -0000 On 5/19/15 3:56 PM, Murray S. Kucherawy wrote: > On Tue, May 19, 2015 at 3:28 PM, Murray S. Kucherawy > wrote: >> On Tue, May 19, 2015 at 2:42 PM, Rolf E. Sonneveld < >> R.E.Sonneveld@sonnection.nl> wrote: >> >>> But when somebody gets around to trying to exploit this window, >>> sites with quick (re-)delivery to most of their recipients will >>> probably want to cut the length of that exposure down... >>> >>> which effectively kills the SMTP retry strategy concept [1] and >>> hence the store-and-forward character of Internet mail, as we >>> know it since the late 70's. Please note that SMTP itself has per >>> command timeouts [2] which make short t= limits in the order of >>> sub-minutes or some minutes unrealistic for some parts of the >>> Internet and for delivery to some organizations which now and >>> then have outages of more than a few minutes (no monitoring, no >>> staff etc.). Also, note that large mailing lists may take some >>> time to expand the address list and deliver the mail to all >>> recipients... So when an expiration time is chosen it has to >>> match the real world of mail delivery, which is far better than >>> 20 years ago, but still isn't perfect... >>> >> On Tue, May 19, 2015 at 3:28 PM, Murray S. Kucherawy >> wrote: >> >> To your first point: SMTP itself isn't being altered by these >> proposals in any way that I can see. We're not changing the parts >> of SMTP you referenced. For one thing, if a DMARC rejection is >> undertaken by a receiver, that action is final; there's no retry >> going to happen. For another, we're not influencing which host is >> being selected or what the retry interval might be, or how long a >> queued message should be held before ultimately being returned as >> undeliverable. If DMARC recommended 4yz SMTP replies when failures >> happen, that might be different, but that's not the case here. All >> of this can be thought of as happening in a layer above SMTP, not >> as part of it. >> >> To your second point: Those timeouts recommended by SMTP should at >> least be referenced by any advice a conditional signatures draft >> might provide in terms of selecting an expiration time. Such a >> section would also be wise to talk about header field selection and >> the like. More generally, any advice we can provide about what to >> consider when selecting the construction of the conditional >> signature would be wise to include. > > We also appear to be OK with imposing delivery timeouts that extend > beyond the basic timeout set described in RFC5321, given what it says > in RFC2852 (from 2000). Murray, Rolf has a valid point. You are advocating email is to radically change into an instant messaging scheme. Are you now suggesting any properly functioning mediator must process ALL its messages as they arrive rather than permitting moderator approvals or any realistic post processing overhead? Such issues often confronts small servers to produce somewhat erratic handling delays. "Conditional" authorization expiry is wholly unrelated to protocol timeouts. A message being queued does not normally obtain a fresh set of signatures. If you are going to justify short expiry using RFC5321, why ignore Section 4.5.4.1 and Section 7.1? It is fairly common for a system to shutdown while being patched whenever an active exploit is noticed. Undelivered messages are then queued and retried later. Unreasonably short expiry will once again make DMARC a primary cause for message disruption whenever DMARC asserts inappropriate handling requests. How can delivery integrity be re-established? What can extend a delivery window? What can mitigate an exploited DKIM "conditional" authorization? Is it reasonable to impose ever shorter "conditional" authorization windows while holding mailing-lists increasingly responsible for messages they distribute? How will a mailing-list be affected by a malicious message originating from a DMARC domain? Since a DMARC domain will need to regiment inclusion of "conditional" DKIM signatures, what prevents forthright publication of this information to fully supplant use of "conditional" DKIM signatures? Isn't this a case of when a hammer is your only tool, everything looks like a nail? A stand-alone regimentation DNS server should prove more effective and less disruptive than the proposed use of conditional DKIM siglets. After all, an attempt to use DKIM to signal a regimentation scheme is likely the primary cause for a lack of adoption. Why allow a few disruptive domains to prevent others from adopting a workable solution? Regards, Douglas Otis From nobody Tue May 19 19:13:23 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E2F1B2B65 for ; Tue, 19 May 2015 19:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1YK8UyDpvrh for ; Tue, 19 May 2015 19:13:20 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C24B91B2B62 for ; Tue, 19 May 2015 19:13:20 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 630E5C400DB for ; Tue, 19 May 2015 21:13:19 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1432087999; bh=Zq7BIbHGHJ7j2bNuY75xAfithj/zVvyh3Sg1lfkfxg8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=B/2qlVs3mkohn4wD5HqwJgzr/qxLRDf8Tw/IAaE/rNsh6hiLbiQgEhn/91bDQ+7Lr ikfzBUq29vtfGYP9ek255trIbe1jR6cM8LsKA2gNHDu/82ce7XrrmrxI+wILT+02YL FJmnxOj3Or1+DmMBu9cIJN2kj4Prl3ah08HfluCk= From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 19 May 2015 22:13:22 -0400 Message-ID: <1931404.xCzP8N6imS@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-51-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20150519234021.62540.qmail@ary.lan> References: <20150519234021.62540.qmail@ary.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 02:13:22 -0000 On Tuesday, May 19, 2015 11:40:21 PM John Levine wrote: > >I would think you'd have to. There's a replay risk that's unique to this > >type of signature, so I think treating them the same would be a naive > >approach. > Remember that DMARC doesn't tell you that a message is good. The most > it can say is "not so awful that you should automatically reject it." > A sensible implementation will still run the mail through spam > filters like any other mail. > > The risk is that the second signer might be malicious, but that's nothing > new, any signer can be malicious. So do the usual filtering, use the > second signer's reputation. The challenge here is that the second signer may not have anything to do with the message. Since, except for From, only invisible parts of the message are signed, the signature could be applied to almost any email. Using the reputation of the second signer's domain is not substantially different than using the reputation of an unauthenticated identity. I don't see how that helps. If this is the path we go down, there's got to be something in the second signature that says it's means enough to override the DMARC fail/p=reject determination. Scott K From nobody Tue May 19 20:25:53 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4713B1A0196 for ; Tue, 19 May 2015 20:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aj2z34cWgwE7 for ; Tue, 19 May 2015 20:25:51 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 532D51B2C61 for ; Tue, 19 May 2015 20:25:51 -0700 (PDT) Received: (qmail 55046 invoked from network); 20 May 2015 03:25:56 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 20 May 2015 03:25:56 -0000 Date: 20 May 2015 03:25:28 -0000 Message-ID: <20150520032528.63043.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <1931404.xCzP8N6imS@kitterma-e6430> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: sklist@kitterman.com Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 03:25:52 -0000 >The challenge here is that the second signer may not have anything to do with >the message. Since, except for From, only invisible parts of the message are >signed, the signature could be applied to almost any email. Using the >reputation of the second signer's domain is not substantially different than >using the reputation of an unauthenticated identity. I don't see how that >helps. The second signer has at least enough to do with the message that it has a real message in hand with permission to re-sign. Remember the problem that got us here in the first place: AOL and Yahoo had security failures that let crooks steal zillions of address books, who then used botnets to send spam to AOL and Yahoo users that appeared to be from other AOL and Yahoo users that they knew. The actual source of the mail had nothing to do with AOL or Yahoo, or any system that had ever gotten mail from AOL or Yahoo. The double signing hack limits the opportunity for trouble to mail systems that have a recent real message in hand. While I can certainly imagine spammy scenarios, it's hard to imagine ones that wouldn't be fairly easy to detect and shut down. If nothing else, if the original sender gets spam reports about double signed mail (there are FBLs that key on DKIM signature) it can tell who's screwing around and stop putting conditional signatures on mail to them. R's, John From nobody Tue May 19 20:34:09 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4E41B2D70 for ; Tue, 19 May 2015 20:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.298 X-Spam-Level: * X-Spam-Status: No, score=1.298 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ta8z8-GCYXmH for ; Tue, 19 May 2015 20:34:07 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A0761B2CB1 for ; Tue, 19 May 2015 20:34:07 -0700 (PDT) Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id A05CCC40029 for ; Tue, 19 May 2015 22:34:04 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1432092844; bh=bFkROzBsQvpAuSzVVYBpMKwb+dGWGkZAvQLsVoDJOXI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=o2sSEvsDIMjwDrhlVTiVBJxXroO4q6LvsQabVUSh7g+QfdDsy1pZzafKD6aNFJvfY PRlBurPKjEtGKdQQDutwT+UZPrmirDOCrMA2Cz6+z2LZ6Dbtiap+RIcu8+ptVidHWd 6U/l6DVeIMOlNElTCRdiibxuV24X90yywnn++HqY= From: Scott Kitterman To: dmarc@ietf.org Date: Tue, 19 May 2015 23:34:07 -0400 Message-ID: <102314300.h94a8hZgnb@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-51-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20150520032528.63043.qmail@ary.lan> References: <20150520032528.63043.qmail@ary.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 03:34:08 -0000 On Wednesday, May 20, 2015 03:25:28 AM John Levine wrote: > >The challenge here is that the second signer may not have anything to do > >with the message. Since, except for From, only invisible parts of the > >message are signed, the signature could be applied to almost any email. > >Using the reputation of the second signer's domain is not substantially > >different than using the reputation of an unauthenticated identity. I > >don't see how that helps. > > The second signer has at least enough to do with the message that it > has a real message in hand with permission to re-sign. > > Remember the problem that got us here in the first place: AOL and > Yahoo had security failures that let crooks steal zillions of address > books, who then used botnets to send spam to AOL and Yahoo users that > appeared to be from other AOL and Yahoo users that they knew. The > actual source of the mail had nothing to do with AOL or Yahoo, or any > system that had ever gotten mail from AOL or Yahoo. > > The double signing hack limits the opportunity for trouble to mail > systems that have a recent real message in hand. While I can > certainly imagine spammy scenarios, it's hard to imagine ones that > wouldn't be fairly easy to detect and shut down. If nothing else, if > the original sender gets spam reports about double signed mail (there > are FBLs that key on DKIM signature) it can tell who's screwing > around and stop putting conditional signatures on mail to them. Right. We need to be very careful about the security considerations with this so that operators don't inadvertently re-enable the scenario that Yahoo! and AOL set p=reject to mitigate. It occurs to me that such FBL checks could be even be done prospectively, i.e. do a bad domain check and only add the domain as an fs= domain if it's not "bad". That would allow the damage to be preempted for future mails once a domain makes the list. This would get easier if DMARC feedback included some kind of spam verdict, but I doubt receivers would be willing to expose that. Scott K From nobody Tue May 19 22:18:01 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66EE41B357F for ; Tue, 19 May 2015 22:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzkNWsdQEjH8 for ; Tue, 19 May 2015 22:17:58 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 948A21B2DC4 for ; Tue, 19 May 2015 22:17:58 -0700 (PDT) Received: by qkgx75 with SMTP id x75so24996541qkg.1 for ; Tue, 19 May 2015 22:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=GqS355J/Nrh7xVeW4Jg4JVZ3qw5nUvUpIdQ6lrihCTg=; b=YJy/3c3Tq4KSdTw44cQnw7RwDmCYnofx8sNTYbQzaMTE9DbewYLC+bU8hoZlUK/MW3 dX8ZQY1GhXiX+x5zUT/RP7YilOpJKdSVaorxuuhEUdO4EeQleiv6W2bExw8tnRzxlFlz ATqsyIanFcxhfiNauv851zv/vZ14+IRh9FKUOnIoQNo0SE9ChXUGonffT9N0svWDDGpV +BeqaGqlm+S1isGXxJHlm1AW2bA/sR3RCCVZv6in/KKfd//uaGO0mMewvedRzVVtouTe ThhuNj6XUin34utAM71RNVS2u9RaT8CXR/gFTrHAP9VNHyFWpmv1QFuwyPi4Ot4pgOt+ lgtA== X-Received: by 10.55.20.215 with SMTP id 84mr66979635qku.51.1432099077884; Tue, 19 May 2015 22:17:57 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id g184sm10490244qhc.6.2015.05.19.22.17.56 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 May 2015 22:17:56 -0700 (PDT) Message-ID: <555C1903.2050403@gmail.com> Date: Tue, 19 May 2015 22:17:55 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150520032528.63043.qmail@ary.lan> In-Reply-To: <20150520032528.63043.qmail@ary.lan> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 05:18:00 -0000 On 5/19/15 8:25 PM, John Levine wrote: >> The challenge here is that the second signer may not have anything to do with >> the message. Since, except for From, only invisible parts of the message are >> signed, the signature could be applied to almost any email. Using the >> reputation of the second signer's domain is not substantially different than >> using the reputation of an unauthenticated identity. I don't see how that >> helps. > The second signer has at least enough to do with the message that it > has a real message in hand with permission to re-sign. > > Remember the problem that got us here in the first place: AOL and > Yahoo had security failures that let crooks steal zillions of address > books, who then used botnets to send spam to AOL and Yahoo users that > appeared to be from other AOL and Yahoo users that they knew. The > actual source of the mail had nothing to do with AOL or Yahoo, or any > system that had ever gotten mail from AOL or Yahoo. > > The double signing hack limits the opportunity for trouble to mail > systems that have a recent real message in hand. While I can > certainly imagine spammy scenarios, it's hard to imagine ones that > wouldn't be fairly easy to detect and shut down. If nothing else, if > the original sender gets spam reports about double signed mail (there > are FBLs that key on DKIM signature) it can tell who's screwing > around and stop putting conditional signatures on mail to them. Dear John, I receive similar levels of spoofed friends who once had accounts with Yahoo and AOL. The phishing now tends to depend on the look and feel of the Display name rather than having an exact domain. In these cases DMARC offers little to no value. Mediators could apply a policy suitable for blocking input failing an initial hop from the DMARC domain. Any subsequent policy would then need to carve out exceptions for mediator domains that their DMARC feedback should clearly identify. Once a two stage policy scheme is facilitated that only the DMARC domain can monitor via their feedback, then only the DMARC domain would be able to spoof one of their own users. If someone cheated, the exceptions to permit these mediators could be immediately retracted. The daisy-chain alternative you proposed provides a DMARC domain less ability to stop bad actors and causes far greater change to email infrastructure for little benefit. A similar regimentation scheme will be needed. I still think this should be published as Sha-1 hash labels, but that optimization seems to make people think it is too complex. People need to think of it like a box of chocolates, you never know what you are going to get. Whatever the answer, it is authoritatively delicious. :^) Regards, Douglas Otis From nobody Wed May 20 02:59:26 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E5B1A1BAF for ; Wed, 20 May 2015 02:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.299 X-Spam-Level: *** X-Spam-Status: No, score=3.299 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPu3leqDS_gs for ; Wed, 20 May 2015 02:59:22 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF581A1B4E for ; Wed, 20 May 2015 02:59:22 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id F21351C3857; Wed, 20 May 2015 18:59:20 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id D6BE51A3398; Wed, 20 May 2015 18:59:20 +0900 (JST) From: "Stephen J. Turnbull" To: Douglas Otis In-Reply-To: <555A3433.6070109@gmail.com> References: <555656FC.5010609@dcrocker.net> <10034618.CIMjht0PXi@kitterma-e6430> <87wq07yr8l.fsf@uwakimon.sk.tsukuba.ac.jp> <87twvazk1w.fsf@uwakimon.sk.tsukuba.ac.jp> <555A3433.6070109@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 20 May 2015 18:59:20 +0900 Message-ID: <87egmbzi13.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 09:59:25 -0000 Douglas Otis writes: > Wiki is fine, but traditionally anything somewhat involved > should be published in the form of an Internet Draft. Understood. But this was Dave's idea, and he pretty clearly intends to take care of coordination of collection and editing. From nobody Wed May 20 03:01:46 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0DB71B35BD for ; Wed, 20 May 2015 03:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.299 X-Spam-Level: *** X-Spam-Status: No, score=3.299 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUFXYKwj1oRX for ; Wed, 20 May 2015 03:01:43 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id AC1041A1BDB for ; Wed, 20 May 2015 03:01:43 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 2C5EC1C3931; Wed, 20 May 2015 19:01:43 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 12B1A1A3398; Wed, 20 May 2015 19:01:43 +0900 (JST) From: "Stephen J. Turnbull" To: dcrocker@bbiw.net In-Reply-To: <555AD3AF.7060204@dcrocker.net> References: <555656FC.5010609@dcrocker.net> <555A282B.6050906@sonnection.nl> <555AD3AF.7060204@dcrocker.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 20 May 2015 19:01:42 +0900 Message-ID: <87d21vzhx5.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: R.E.Sonneveld@sonnection.nl, "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 10:01:45 -0000 Dave Crocker writes: > However getting them all to use exactly the same wonderful MLM > software that mailbox providers consider the very best for > anti-spam, is probably in the realm of impossible. Especially since 3 of the biggest mailbox providers are surely going to promote their own in-house services. (At least, I would if I were them, at least to my own mailbox users.) > (And given the weaknesses of monocultures, it's also a terrible > idea...) +1 to that! From nobody Wed May 20 03:14:41 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251E11B35D9 for ; Wed, 20 May 2015 03:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.299 X-Spam-Level: *** X-Spam-Status: No, score=3.299 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOrkgKe0Pl-O for ; Wed, 20 May 2015 03:14:38 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id C31821B35D7 for ; Wed, 20 May 2015 03:14:37 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 411DB1C383B; Wed, 20 May 2015 19:14:37 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 26C131A3398; Wed, 20 May 2015 19:14:37 +0900 (JST) From: "Stephen J. Turnbull" To: Douglas Otis In-Reply-To: <555AB134.4080503@gmail.com> References: <555656FC.5010609@dcrocker.net> <555AB134.4080503@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 20 May 2015 19:14:37 +0900 Message-ID: <87bnhfzhbm.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 10:14:39 -0000 Douglas Otis writes: > Termnology: > DKIM Siglet is a highly constrained DKIM signature omitting > elements likely altered by a mediator. Please, no. I agree that "weak signature" is inaccurate, but really we have a "full-coverage" signature (whatever terminology you like) signing pretty all originator header fields plus authentication fields plus the whole body, versus anything less than that (especially but not restricted to allowing additions to the body). I suspect that that is the "security-relevant" distinction, but that some originators will be willing to take more risks than others (eg, using or avoiding an l= spec). "Siglet" is way too constrained in your definition; if we push for that, I think we'll have real trouble convincing some of the managements. Let's not embed that in the terminology, but rather let the originators decide what's "strong" or "full" enough for them. It's possible that with Murray's signature-per-MIME-part technique we could get finer distinctions, but that really requires support from MUAs that I expect Emacs/Gnus will have a Day 0 implementation for, while GMail and Outlook may never implement. Ie, don't hold your breath. From nobody Wed May 20 03:35:56 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236821B3627 for ; Wed, 20 May 2015 03:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.899 X-Spam-Level: *** X-Spam-Status: No, score=3.899 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUqYX7zoJ9Am for ; Wed, 20 May 2015 03:35:52 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7953D1A700C for ; Wed, 20 May 2015 03:35:52 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id C1C671C3949; Wed, 20 May 2015 19:35:51 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 990401A3398; Wed, 20 May 2015 19:35:51 +0900 (JST) From: "Stephen J. Turnbull" To: Douglas Otis In-Reply-To: <555BD1DF.7080502@gmail.com> References: <555656FC.5010609@dcrocker.net> <1432015208815.92898@exchange.microsoft.com> <555BA3EC.2060000@crash.com> <555BAE56.1090003@sonnection.nl> <555BD1DF.7080502@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 20 May 2015 19:35:51 +0900 Message-ID: <87a8wzzgc8.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 10:35:55 -0000 Douglas Otis writes: > Rolf has a valid point. You are advocating email is to > radically change into an instant messaging scheme. No, this change is only necessary if the Author Domain is *already* advocating that email has to radically change into a direct-mail-only scheme. I consider "direct mail only" to be by far the more radical restriction in today's environment. Heck, even in the late 80s it was possible to have a lover's quarrel (not to forget certain post- quarrel activities) in realtime over BitNET. > Are you now suggesting any properly functioning mediator > must process ALL its messages as they arrive rather than > permitting moderator approvals or any realistic post > processing overhead? No, they can still reject or munge or omit changes that invalidate signatures, etc, if they detect that the message is unlikely (or impossible) to deliver within the window. This protocol gives *more* choice to the Mediator than DMARC currently allows. Remember, we've *already* backpedaled (temporarily) from "all 3rd party mail" to "actively mediated mail". If we can get half of that list traffic past DMARC p=reject, a large share of my constituency will be a lot happier. > It is fairly common for a system to shutdown while being > patched whenever an active exploit is noticed. Undelivered > messages are then queued and retried later. Unreasonably > short expiry will once again make DMARC a primary cause for > message disruption whenever DMARC asserts inappropriate > handling requests. Yup. HMS DMARC Disruption has sailed. The only real option is to torpedo her, but I think that target is out of range now. > Why allow a few disruptive domains to prevent others from > adopting a workable solution? Because they not only brought the bat and ball, but their Daddy owns the sandlot? Specifically, at least for the Mom & Pop MLs you've mentioned as being a concern, a lot of their posters are from those domains, and they don't want to upset them any more than they already are. From nobody Wed May 20 04:53:31 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8071B1A1A0B for ; Wed, 20 May 2015 04:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.301 X-Spam-Level: X-Spam-Status: No, score=-99.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQJ4-2VV-OLS for ; Wed, 20 May 2015 04:53:26 -0700 (PDT) Received: from dkim.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD4F1A1A07 for ; Wed, 20 May 2015 04:53:25 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3335; t=1432122797; atps=isdg.net; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=WhqsM6yT9n08cXSzIXCH0CxLftk=; b=gT5ufU2+QAkbPsqN6IKH/mSQHFutJYr02mdiD9E33NshxDfu0mIJNNbCYtNvlm wPWgGYtzEa0IhYzi/wy2OPc1Pip3AI6vPiNM00vztSufYEek0c73K60nL1Ymfo9a 8h8kxS01rFsWiZDVJEx/0sFo+9vFGDad3vBCqlZR1QQwA= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 20 May 2015 07:53:17 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1537809756.21933.3104; Wed, 20 May 2015 07:53:16 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3335; t=1432122504; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=brOxzQF 7YrWGEUcLXmqHS2qO5XYn5BdJUlXj2Rbzg0o=; b=tcA6iyGj2HiCf9n3HLVHVhx wO8CxykpKEk7gd4qVza3QFScNFwcWrBb/xPEJyNhUe8cejtICXS7zCXuwtMbZduf ErJQKKl0Bgs7S22ODji8Y4GQvOxWZ0LgoiFsPu+GS9s7KqxqWZPgCUQsnXmpwxX0 p0lU8xCyoCWjtYfLs7tM= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 20 May 2015 07:48:24 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 130072489.9.20180; Wed, 20 May 2015 07:48:23 -0400 Message-ID: <555C75AC.3060502@isdg.net> Date: Wed, 20 May 2015 07:53:16 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150520032528.63043.qmail@ary.lan> In-Reply-To: <20150520032528.63043.qmail@ary.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [dmarc-ietf] Weaker single author signature X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 11:53:30 -0000 With two sigs, all I can see is that the first leg of the transport is stronger PATH: MTA ----> MLM strong 1st party v1 signature PATH: MLM o---> MTA weak 1st party v2 signature If this hack essentially weakens a DKIM signed message so that it can survive the transport, the MLM changes and the final destination. then why not just do create this weakness with just one original v1 signature using the i= (AUID) to pass the resigner information? From: user@author.example DKIM-Signature: v=1 d=author.example s=signer.selector i=resigner.example@author.example l= <-- weak sizing h= <-- weak header binding list Just as you expect the v2 signature to survive, and also not get stripped, why can't that happen with the weak v1 author domain signature? The resigner domain can be passed via the AUID i= tag. The final receiver will now see weak first party signature and the OPTIONAL stronger resigner signature. Since this is a DMARC extension, the trigger tag can be used such as "dualsig=y" on the DMARC record to enable the logic. But that wouldn't be needed as long as the first party sig is survivable which is all we are doing with the v2 sig. Unless I missing something, using this simpler method offer compatibility with the non-signing MLM as well. The only benefit using 2 sigs I see is the stronger first leg transport to the MLM and as long as the MLM domain is known, it doesn't matter at the point why you send this guy as long as its survivable for the distribution. The final receiver can use the i= tag of the original weak signature to get the permission to "authorize" the potential resigner. -- HLS On 5/19/2015 11:25 PM, John Levine wrote: >> The challenge here is that the second signer may not have anything to do with >> the message. Since, except for From, only invisible parts of the message are >> signed, the signature could be applied to almost any email. Using the >> reputation of the second signer's domain is not substantially different than >> using the reputation of an unauthenticated identity. I don't see how that >> helps. > > The second signer has at least enough to do with the message that it > has a real message in hand with permission to re-sign. > > Remember the problem that got us here in the first place: AOL and > Yahoo had security failures that let crooks steal zillions of address > books, who then used botnets to send spam to AOL and Yahoo users that > appeared to be from other AOL and Yahoo users that they knew. The > actual source of the mail had nothing to do with AOL or Yahoo, or any > system that had ever gotten mail from AOL or Yahoo. > > The double signing hack limits the opportunity for trouble to mail > systems that have a recent real message in hand. While I can > certainly imagine spammy scenarios, it's hard to imagine ones that > wouldn't be fairly easy to detect and shut down. If nothing else, if > the original sender gets spam reports about double signed mail (there > are FBLs that key on DKIM signature) it can tell who's screwing > around and stop putting conditional signatures on mail to them. > > R's, > John > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > From nobody Wed May 20 05:56:25 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C071A017D for ; Wed, 20 May 2015 05:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNSvdKrfJjGJ for ; Wed, 20 May 2015 05:56:21 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id A451F1A0199 for ; Wed, 20 May 2015 05:56:19 -0700 (PDT) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3lsDbj3hXCz1L8rt; Wed, 20 May 2015 14:56:17 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3lsDbj2RHtz5Mgfk; Wed, 20 May 2015 14:56:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 1B1EE123514; Wed, 20 May 2015 14:56:16 +0200 (CEST) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fEcRTHPTw8f1; Wed, 20 May 2015 14:56:11 +0200 (CEST) Received: from jaguar.sonnection.nl (jaguar.sonnection.nl [192.168.1.21]) by jaguar.sonnection.nl (Postfix) with ESMTP id 753811234B7; Wed, 20 May 2015 14:56:11 +0200 (CEST) Date: Wed, 20 May 2015 14:56:10 +0200 (CEST) From: "Rolf E. Sonneveld" To: "Murray S. Kucherawy" Message-ID: <1706610070.17130.1432126570472.JavaMail.root@sonnection.nl> In-Reply-To: References: <555656FC.5010609@dcrocker.net> <555BA3EC.2060000@crash.com> <555BAE56.1090003@sonnection.nl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_17129_1317954004.1432126570471" X-Originating-IP: [193.173.78.167] X-Mailer: Zimbra 8.0.0_GA_5434 (ZimbraWebClient - FF38 (Linux)/8.0.0_GA_5434) Thread-Topic: Looking for degrees of freedom with Intermediaries - Effort and Policy Thread-Index: Fi3Us9yrvHIplLUzHeV30d6mDCg3Iw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1432126577; bh=sQzGByjAF5dB9SdU+trB74cCqPxkgE6GmQDoP05OAa4=; h=Date:From:To:Message-ID:Subject:From; b=JcCAhqVA4+hYAxBNSRlq3Jwj8fm1ZgFt/M1T7qrM044pWL+kxV6lfnWXL/AYd5McA UvjjBzDaRxQtrEShMUdR6qBob8+jkGzob7pkePR5IFWAgaZCtX0wyo/oYi68+T6Cmb dQpUp8401KxPIZbVZ1C9tY4mN5qFuC/Nj0BtE2uY= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3lsDbj3hXCz1L8rt Archived-At: Cc: "R.E.Sonneveld" , dmarc@ietf.org, Steven M Jones Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 12:56:24 -0000 ------=_Part_17129_1317954004.1432126570471 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Murray S. Kucherawy" > To: "" > Cc: "Steven M Jones" , dmarc@ietf.org > Sent: Wednesday, May 20, 2015 12:56:31 AM > Subject: Re: [dmarc-ietf] Looking for degrees of freedom with > Intermediaries - Effort and Policy > On Tue, May 19, 2015 at 3:28 PM, Murray S. Kucherawy < > superuser@gmail.com > wrote: > > On Tue, May 19, 2015 at 2:42 PM, Rolf E. Sonneveld < > > R.E.Sonneveld@sonnection.nl > wrote: > > > > > But when somebody gets around to trying to exploit this window, > > > > sites > > > > with quick (re-)delivery to most of their recipients will > > > > probably > > > > want to cut the length of that exposure down... > > > > > > > > > which effectively kills the SMTP retry strategy concept [1] and > > > hence > > > the store-and-forward character of Internet mail, as we know it > > > since the late 70's. Please note that SMTP itself has per command > > > timeouts [2] which make short t= limits in the order of > > > sub-minutes > > > or some minutes unrealistic for some parts of the Internet and > > > for > > > delivery to some organizations which now and then have outages of > > > more than a few minutes (no monitoring, no staff etc.). Also, > > > note > > > that large mailing lists may take some time to expand the address > > > list and deliver the mail to all recipients... So when an > > > expiration > > > time is chosen it has to match the real world of mail delivery, > > > which is far better than 20 years ago, but still isn't perfect... > > > > > To your first point: SMTP itself isn't being altered by these > > proposals in any way that I can see. We're not changing the parts > > of > > SMTP you referenced. > No, I understand and that's not what I said. > > For one thing, if a DMARC rejection is undertaken by a receiver, > > that > > action is final; there's no retry going to happen. > Correct. But DMARC rejection is only the final part of the chain (at least, when we talk about the transfer of messages from one ADMD boundary, via an intermediary ADMD or directly, to a receiver ADMD). If you write out all the actions that are required to get a mail from A to B, then you'll get an impressive list of situations where something can go wrong and which in turn can delay the delivery of the message to the receiving ADMD. > > For another, we're not influencing which host is being selected or > > what the retry interval might be, or how long a queued message > > should be held before ultimately being returned as undeliverable. > Correct, but we must take into account that there are retry intervals being used by MTA's along the line between author domain and receiver domain. > > If DMARC recommended 4yz SMTP replies when failures happen, that > > might be different, but that's not the case here. All of this can > > be > > thought of as happening in a layer above SMTP, not as part of it. > > > To your second point: Those timeouts recommended by SMTP should at > > least be referenced by any advice a conditional signatures draft > > might provide in terms of selecting an expiration time. Such a > > section would also be wise to talk about header field selection and > > the like. More generally, any advice we can provide about what to > > consider when selecting the construction of the conditional > > signature would be wise to include. > > We also appear to be OK with imposing delivery timeouts that extend > beyond the basic timeout set described in RFC5321, given what it > says in RFC2852 (from 2000). I'm afraid you missed my point (or better said: obviously I didn't make myself clear :-)). What I want to say is: we have an existing Internet mail infrastructure where delivery times can range from seconds to many hours. With 'delivery time' I mean the time between the author domain DKIM signs the message and the time that the verifier domain checks the DKIM signature (not just between author domain and intermediary domain nor just between intermediary domain and verifier domain). Maybe we should call this 'message transfer time', not delivery time. If we try to solve the 'Mediator problem' by assuming that we can set very short expiration times on the signatures (to prevent replay) we seem to forget that this may lead to the rejection of a non-negligible amount of legitimate mail due to the nature of the Internet mail ecosystem as it is today. /rolf ------=_Part_17129_1317954004.1432126570471 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

From: "Murray S.= Kucherawy" <superuser@gmail.com>
To: "<R.E.Sonneveld@so= nnection.nl>" <R.E.Sonneveld@sonnection.nl>
Cc: "Steven = M Jones" <smj@crash.com>, dmarc@ietf.org
Sent: Wednesday, M= ay 20, 2015 12:56:31 AM
Subject: Re: [dmarc-ietf] Looking for deg= rees of freedom with Intermediaries - Effort and Policy

<= div dir=3D"ltr">On Tue, May 19, 2015 at 3:28 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
On Tue= , May 19, 2015 at 2:42 PM, Rolf E. Sonneveld <R.E.Sonneveld@sonnection.nl> wrote:


=
But when somebody gets around to trying to exploit this = window, sites with quick (re-)delivery to most of their recipients will pro= bably want to cut the length of that exposure down...
whic= h effectively kills the SMTP retry strategy concept [1] and hence the store= -and-forward character of Internet mail, as we know it since the late 70's.= Please note that SMTP itself has per command timeouts [2] which make short= t=3D limits in the order of sub-minutes or some minutes unrealistic for so= me parts of the Internet and for delivery to some organizations which now a= nd then have outages of more than a few minutes (no monitoring, no staff et= c.). Also, note that large mailing lists may take some time to expand the a= ddress list and deliver the mail to all recipients... So when an expiration= time is chosen it has to match the real world of mail delivery, which is f= ar better than 20 years ago, but still isn't perfect...

To your first point: SMTP itself isn't being altered= by these proposals in any way that I can see.  We're not changing the= parts of SMTP you referenced. 
<= /div>

No, I understand and that= 's not what I said.

For one= thing, if a DMARC rejection is undertaken by a receiver, that action is fi= nal; there's no retry going to happen. 

Correct. But DMAR= C rejection is only the final part of the chain (at least, when we talk abo= ut the transfer of messages from one ADMD boundary, via an intermediary ADM= D or directly, to a receiver ADMD).  If you write out all the actions = that are required to get a mail from A to B, then you'll get an impressive = list of situations where something can go wrong and which in turn can delay= the delivery of the message to the receiving ADMD.

For another, we're not influencing which host is be= ing selected or what the retry interval might be, or how long a queued mess= age should be held before ultimately being returned as undeliverable.

Correct, but we must take into account that there are retry interva= ls being used by MTA's along the line between author domain and receiver do= main.

If DMARC recommended 4y= z SMTP replies when failures happen, that might be different, but that's no= t the case here.  All of this can be thought of as happening in a laye= r above SMTP, not as part of it.

To your secon= d point: Those timeouts recommended by SMTP should at least be referenced b= y any advice a conditional signatures draft might provide in terms of selec= ting an expiration time.  Such a section would also be wise to talk ab= out header field selection and the like.  More generally, any advice w= e can provide about what to consider when selecting the construction of the= conditional signature would be wise to include.

We also appear to be OK with imposing deliver= y timeouts that extend beyond the basic timeout set described in RFC5321, g= iven what it says in RFC2852 (from 2000).

I'm afraid you missed my point (or better said: obvi= ously I didn't make myself clear :-)). What I want to say is: we have an ex= isting Internet mail infrastructure where delivery times can range from sec= onds to many hours. With 'delivery time' I mean the time  between the = author domain DKIM signs the message and the time that the verifier domain = checks the DKIM signature (not just between author domain and intermediary = domain nor just between intermediary domain and verifier domain). Maybe we = should call this 'message transfer time', not delivery time. If we try to s= olve the 'Mediator problem' by assuming that we can set very short expirati= on times on the signatures (to prevent replay) we seem to forget that this = may lead to the rejection of a non-negligible amount of legitimate mail due= to the nature of the Internet mail ecosystem as it is today.

/rolf

------=_Part_17129_1317954004.1432126570471-- From nobody Wed May 20 06:20:53 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1391A1A10 for ; Wed, 20 May 2015 06:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrniOKY6nfyH for ; Wed, 20 May 2015 06:20:50 -0700 (PDT) Received: from mx20.mailtransaction.com (mx20.mailtransaction.com [78.46.16.213]) by ietfa.amsl.com (Postfix) with ESMTP id 99BFB1A1A0B for ; Wed, 20 May 2015 06:20:50 -0700 (PDT) Received: from mx14.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by mx20.mailtransaction.com (Postfix) with ESMTP id 3lsF816QCwz1L8rt; Wed, 20 May 2015 15:20:49 +0200 (CEST) Received: from jaguar.sonnection.nl (D57E1702.static.ziggozakelijk.nl [213.126.23.2]) by mx14.mailtransaction.com (Postfix) with ESMTP id 3lsF8155HTz5Mgfk; Wed, 20 May 2015 15:20:49 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by jaguar.sonnection.nl (Postfix) with ESMTP id 78E10123514; Wed, 20 May 2015 15:20:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at sonnection.nl Received: from jaguar.sonnection.nl ([127.0.0.1]) by localhost (jaguar.sonnection.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id pD_xgMy_03lk; Wed, 20 May 2015 15:20:44 +0200 (CEST) Received: from jaguar.sonnection.nl (jaguar.sonnection.nl [192.168.1.21]) by jaguar.sonnection.nl (Postfix) with ESMTP id EF6E91234B7; Wed, 20 May 2015 15:20:43 +0200 (CEST) Date: Wed, 20 May 2015 15:20:43 +0200 (CEST) From: "Rolf E. Sonneveld" To: Douglas Otis Message-ID: <1831158042.17186.1432128043315.JavaMail.root@sonnection.nl> In-Reply-To: <555BD1DF.7080502@gmail.com> References: <555656FC.5010609@dcrocker.net> <555BA3EC.2060000@crash.com> <555BAE56.1090003@sonnection.nl> <555BD1DF.7080502@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [193.173.78.167] X-Mailer: Zimbra 8.0.0_GA_5434 (ZimbraWebClient - FF38 (Linux)/8.0.0_GA_5434) Thread-Topic: Looking for degrees of freedom with Intermediaries - Effort and Policy Thread-Index: gFLjoax7v118rbPmVaF0RezBv+vp+Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1432128049; bh=4Z57rQ3wDIyzn76gOLrGhYwC1X+0pYNox+PstKVWYMY=; h=Date:From:To:Message-ID:Subject:From; b=TKb01b3SJyULamBKvZv56y2uLATBmg58jgJEHraZ7NfP48cBCMOcH6Shc1uU7i+3i hNCLeuojjc9lH6VDDcgfbJyhN73q16YaBSS2+Uxo0P/WFOAylfyXgxhqtnAwr6s2MO qSkHilaJsqQ1ma+T1Qq/XaX/ZP7/GCqCJ6h8mYg8= DKIM-Filter: OpenDKIM Filter v2.8.2 mx20.mailtransaction.com 3lsF816QCwz1L8rt Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 13:20:52 -0000 [...] > > > > We also appear to be OK with imposing delivery timeouts > that extend > > beyond the basic timeout set described in RFC5321, given > what it says > > in RFC2852 (from 2000). > > Murray, > > Rolf has a valid point. You are advocating email is to > radically change into an instant messaging scheme. > > Are you now suggesting any properly functioning mediator > must process ALL its messages as they arrive rather than > permitting moderator approvals or any realistic post > processing overhead? > > Such issues often confronts small servers to produce > somewhat erratic handling delays. > > "Conditional" authorization expiry is wholly unrelated to > protocol timeouts. A message being queued does not normally > obtain a fresh set of signatures. If you are going to > justify short expiry using RFC5321, why ignore Section > 4.5.4.1 and Section 7.1? > > It is fairly common for a system to shutdown while being > patched whenever an active exploit is noticed. Undelivered > messages are then queued and retried later. Unreasonably > short expiry will once again make DMARC a primary cause for > message disruption whenever DMARC asserts inappropriate > handling requests. Doug rephrased my concern about short expiry times quite well. Of course author domains are free to choose what expiry they want, but the question is: is it OK to design a(n extension to a) protocol which don't take the existing status quo of Internet mail into account? /rolf From nobody Wed May 20 07:10:42 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838801A6FF9 for ; Wed, 20 May 2015 07:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3f_pmYCHn-q for ; Wed, 20 May 2015 07:10:40 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4CF71A6FF7 for ; Wed, 20 May 2015 07:10:35 -0700 (PDT) Received: from [IPv6:2600:1003:b10b:bdc4:68a8:90a5:e6bd:dbbd] (unknown [IPv6:2600:1003:b10b:bdc4:68a8:90a5:e6bd:dbbd]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id AA58EC40028; Wed, 20 May 2015 09:10:32 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1432131033; bh=bupq+zMnO7LDou9d2vrAnXQmlIuH6rtBXhXwbqp/jus=; h=In-Reply-To:References:Subject:From:Date:To:From; b=Pqxw9GtPsIcUtMey7L+TzdLOryWHzeLvVSc5gGTXiHZFrgapik7G5wA6hGHnxwhM5 X3lqQp8akhRFd2TmYwRadz2tAaseLipPg09Lu+Dm2cQUfJcon4Xk5gHyV6ldwz2KyR CXV78vhTCrRMK+PO4oGwsFM304DPrlukXvwSqif8= User-Agent: K-9 Mail for Android In-Reply-To: <1831158042.17186.1432128043315.JavaMail.root@sonnection.nl> References: <555656FC.5010609@dcrocker.net> <555BA3EC.2060000@crash.com> <555BAE56.1090003@sonnection.nl> <555BD1DF.7080502@gmail.com> <1831158042.17186.1432128043315.JavaMail.root@sonnection.nl> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Wed, 20 May 2015 10:10:25 -0400 To: dmarc@ietf.org Message-ID: <094C3F52-54A6-4D62-A28C-1A6D48FB4DD6@kitterman.com> Archived-At: Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 14:10:41 -0000 On May 20, 2015 9:20:43 AM EDT, "Rolf E. Sonneveld" wrote: >[...] > >> > >> > We also appear to be OK with imposing delivery timeouts >> that extend >> > beyond the basic timeout set described in RFC5321, given >> what it says >> > in RFC2852 (from 2000). >> >> Murray, >> >> Rolf has a valid point. You are advocating email is to >> radically change into an instant messaging scheme. >> >> Are you now suggesting any properly functioning mediator >> must process ALL its messages as they arrive rather than >> permitting moderator approvals or any realistic post >> processing overhead? >> >> Such issues often confronts small servers to produce >> somewhat erratic handling delays. >> >> "Conditional" authorization expiry is wholly unrelated to >> protocol timeouts. A message being queued does not normally >> obtain a fresh set of signatures. If you are going to >> justify short expiry using RFC5321, why ignore Section >> 4.5.4.1 and Section 7.1? >> >> It is fairly common for a system to shutdown while being >> patched whenever an active exploit is noticed. Undelivered >> messages are then queued and retried later. Unreasonably >> short expiry will once again make DMARC a primary cause for >> message disruption whenever DMARC asserts inappropriate >> handling requests. > >Doug rephrased my concern about short expiry times quite well. Of >course author domains are free to choose what expiry they want, but the >question is: is it OK to design a(n extension to a) protocol which >don't take the existing status quo of Internet mail into account? If it weren't, DMARC wouldn't exist. We probably won't repair all the breakage. The question is how much is enough. Scott K From nobody Wed May 20 08:25:56 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C12F1A8856 for ; Wed, 20 May 2015 08:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.5 X-Spam-Level: X-Spam-Status: No, score=-99.5 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33lCYpbeAa6V for ; Wed, 20 May 2015 08:25:51 -0700 (PDT) Received: from secure.winserver.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3F02B1A886C for ; Wed, 20 May 2015 08:25:33 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=7337; t=1432135523; atps=isdg.net; atpsh=sha1; h=Received:Received:Message-Id:From:Subject:Date:To:Organization: List-ID; bh=MZeDiyXtQU2EuUwGqVQS0Yr9Po0=; b=N1x+tNTXbgUKn6ANjZ08 FYl+8n/FR786Bcqi8kzjVITeiLdfmiV6pR/1XeKbc5uvlPn8RhX9IvXI5ZdWXV2E xO2KzSPiNGB703SsIQsT86Pi4nPoVt2VM+6woOlGmwxUO+hMOjveXbz89VUNYigr 15Hc6FaDyP9UHgu/1AJXfs0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 20 May 2015 11:25:23 -0400 Received: from [192.168.1.67] (99-3-146-30.lightspeed.miamfl.sbcglobal.net [99.3.146.30]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1550535444.21933.4260; Wed, 20 May 2015 11:25:22 -0400 References: <555656FC.5010609@dcrocker.net> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-22E88CDC-7E99-440F-9B92-37D87014B30E Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (12B435) From: Hector Santos Date: Wed, 20 May 2015 11:25:23 -0400 To: "Murray S. Kucherawy" Archived-At: Cc: "dmarc@ietf.org" , Dave Crocker Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 15:25:54 -0000 --Apple-Mail-22E88CDC-7E99-440F-9B92-37D87014B30E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable How can you see lower cost for hotmail.com, aol.com and yahoo.com and such d= omains to begin to weaken their signed mail streams with v2 signature resign= er authorization signatures? That pesky registration problem again. What= if the resigner domain decides to change its resigner domain? How that's= the feedback get back to the originating domain?=20 I believe the dual sig idea is good to be part of a more comprehensive solut= ion, not total and nor exclusive, but more. It is less secure not matter h= ow we look at it, so it is prudent, the more secured, more baseline, DNS qu= ery solution be also part of the IE* recommendations. This is especially the= case when proposed as a Standard Track protocol. Let's remember there are two parts of this; verification by two receivers we= are mostly concern about, and the original signer and its exposed public po= licy intentions and expectations. We got working code and a practical solution for those with DNS management. = I have ATPS running code both the rev4 and RFC version in a wide network of= operators. I have enterprise beta testers what also use openDKIM/openDMARC= in an integrated SMTP environment where our package serves as an AVS fronte= nd relay for them. So we can do ATPS testing and I plan to recommend and il= lustrate source code change to support ATPSRev4. It's about support option= s. Adding two signatures will take signer engine code change. Once I see p=3Dre= ject domains add support for v2, I will explore changing code again to supp= ort for V2 signatures too. Or at least, explore adding verification code sin= ce that is already in a change flux. -- Hector Santos http://www.santronics.com > On May 18, 2015, at 12:26 AM, Murray S. Kucherawy wr= ote: >=20 >> On Fri, May 15, 2015 at 1:28 PM, Dave Crocker wrote: >> Performing DKIM/SPF validation upon receipt >=20 > There already exist several implementations of each of these, so I would s= ay that they are currently deployed rather widely, making our cost near-zero= . Plus, any DMARC operator already has at least one of them going. >=20 >> DKIM-signing all outbound mail. >=20 > Let's say that's close to zero cost as well. >=20 > One thing absent from your list is conditional signatures, which is John's= idea, and is a special case of both of these. I've implemented it now in l= ibopendkim as a compile-time experimental feature, and it took me about four= hours including testing. I just have to add it to the plugin that uses the= library, and it'll be available for others to play with. >=20 > -MSK > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --Apple-Mail-22E88CDC-7E99-440F-9B92-37D87014B30E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
How can you see lower cost for  <= a href=3D"http://hotmail.com">hotmail.com, ao= l.com and yahoo.com and such domains to= begin to weaken their signed mail streams with v2 signature resigner author= ization signatures?   That pesky registration problem again.   Wha= t if the resigner domain decides to change its resigner domain?    = ;How that's the feedback get back to the originating domain? 

I believe the dual sig idea is good to be part of a more com= prehensive solution, not total and nor exclusive,  but more.  It i= s less secure not matter how we look at it, so it is prudent, the more secur= ed, more baseline,  DNS query solution be also part of the IE* recommen= dations. This is especially the case when  proposed as a Standard Track= protocol.

Let's remember there are two parts of th= is; verification by two receivers we are mostly concern about, and the origi= nal signer and its exposed public policy  intentions and expectations.<= /div>

We got working code and a practical solution for th= ose with DNS management.  I have ATPS running code both the rev4 and RFC= version in a wide network of operators.  I have enterprise beta tester= s what also use openDKIM/openDMARC in an integrated SMTP environment where o= ur package serves as an AVS frontend relay for them.  So we can do ATPS= testing and I plan to recommend and illustrate source code change to suppor= t ATPSRev4.   It's about support options.

Addi= ng two signatures will take signer engine code change. Once I see p=3Dreject= domains add support for v2,  I will explore changing code again to sup= port for V2 signatures too. Or at least, explore adding verification code si= nce that is already in a change flux.

--
Hector Santos

On May 18, 2015, at 12:26 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
On Fri, May 15, 2015 a= t 1:28 PM, Dave Crocker <dhc@dcrocker.net> wrote:
&n= bsp;  Performing DKIM/SPF validation upon receipt
=
There already exist several implementations of each of these,= so I would say that they are currently deployed rather widely, making our c= ost near-zero.  Plus, any DMARC operator already has at least one of th= em going.

   DKIM-signing all outbound mail.

=
Let's say that's close to zero cost as well.

One thin= g absent from your list is conditional signatures, which is John's idea, and= is a special case of both of these.  I've implemented it now in libope= ndkim as a compile-time experimental feature, and it took me about four hour= s including testing.  I just have to add it to the plugin that uses the= library, and it'll be available for others to play with.

= -MSK
____________________= ___________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mai= lman/listinfo/dmarc
= --Apple-Mail-22E88CDC-7E99-440F-9B92-37D87014B30E-- From nobody Wed May 20 09:35:26 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06CAB1A8907 for ; Wed, 20 May 2015 09:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 837xUREFGDHu for ; Wed, 20 May 2015 09:35:23 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (mail-sn2ln0088.outbound.o365filtering.com [IPv6:2a01:111:f400:7c04::88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7975D1A88F6 for ; Wed, 20 May 2015 09:35:23 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB604.namsdf01.sdf.exchangelabs.com (10.255.109.166) with Microsoft SMTP Server (TLS) id 15.1.184.4; Wed, 20 May 2015 16:35:04 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.210]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.210]) with mapi id 15.01.0184.000; Wed, 20 May 2015 16:35:04 +0000 From: Terry Zink To: "Stephen J. Turnbull" , Douglas Otis Thread-Topic: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy Thread-Index: AQHQkSLjmR8NgZwmBEqnwBkgIc5yZJ2CdTYQgAAL4QCAAE1PAYAAAuMAgABflICAAB0JAIAALQsQgAAc9ICAAAbY0IAABTkAgAACBJCAABURgIAAD8EAgAAMagCAAAzSgIAAB8mAgAAVwoCAAK2jgIAAY3wg Date: Wed, 20 May 2015 16:35:03 +0000 Message-ID: References: <555656FC.5010609@dcrocker.net> <1432015208815.92898@exchange.microsoft.com> <555BA3EC.2060000@crash.com> <555BAE56.1090003@sonnection.nl> <555BD1DF.7080502@gmail.com> <87a8wzzgc8.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87a8wzzgc8.fsf@uwakimon.sk.tsukuba.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.40] x-microsoft-exchange-diagnostics: 1; BL2SR01MB604; 3:UadP/fqTWhkFnkY6Q4VOXmw8hrcuXo59Tk1qX6WZy6a7rrtfRHyQ4hfFRK/By5SKarZPUhRYFJ9hl7LXz1kxK4PkdQS9KK7WRGWh3jGAmAMkzIXWWeVV5htmGQpYNwkPOyV6d8N80hjuoAoe+LT4/Q==; 10:tkpxQ9m7GdsvjhohNncvJWEouqtBFlvneNBvd5aM+xTyTcggpPanbH/PvNcp1iU4ewKnMo+nJzZ9L4o7J5u/S52K1TpGCxnmSZOMpOj2wNE=; 6:SXcl1ZNEmK97q9m2zww2VJM2rQy6iz9QL8+h9tCyB0u0urs1XfDs61+gk3cgDUWb x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB604; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(199003)(111735001)(189002)(106356001)(105586002)(50986999)(54356999)(106116001)(2656002)(64706001)(76176999)(66066001)(101416001)(87936001)(19580395003)(93886004)(46102003)(33656002)(2950100001)(2900100001)(92566002)(5001960100002)(102836002)(5001830100001)(5001860100001)(5001920100001)(15975445007)(68736005)(86362001)(189998001)(62966003)(77156002)(4001540100001)(81156007)(5001770100001)(97736004)(48203002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB604; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005002)(5002009)(3002001); SRVR:BL2SR01MB604; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB604; x-forefront-prvs: 0582641F53 received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2015 16:35:03.1874 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB604 Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 16:35:26 -0000 >> Rolf has a valid point. You are advocating email is to >> radically change into an instant messaging scheme. > No, this change is only necessary if the Author Domain is *already* > advocating that email has to radically change into a direct-mail-only > scheme. =20 This is off-topic, but I read yesterday that Microsoft is coming out with a= product called "Flow" that treats email like instant messaging. You contac= t anyone on your list with an email address and send them a message. The ba= ckend is email/SMTP but the front-end is like instant message. So, the dist= inction between instant messaging and email is blurring even now. http://www.cnet.com/news/microsoft-may-be-building-a-lightweight-email-app-= called-flow/ Anyhow, now back to the discussion at hand. -- Terry From nobody Wed May 20 10:09:55 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8902B1A892A for ; Wed, 20 May 2015 10:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWxLk2F3tKqB for ; Wed, 20 May 2015 10:09:53 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7D821A88C2 for ; Wed, 20 May 2015 10:09:52 -0700 (PDT) Received: by wghq2 with SMTP id q2so59760580wgh.1 for ; Wed, 20 May 2015 10:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RG3W8yFRkff5lM3s762ImHdl0iS4ZTbPIQdh86/hXDc=; b=cy20WeSDf76t2q/mrKPTNL3kwMWKp35vAu3lBnX5N1ozNudd5FOUK8SgaV8Vd8E/yL zoe9Jy3jqXim6FbdQ2mpzIQVHqUwTD++1xxPNFYxho+FE3CsxBXFV4GrrTJQkGyLkv6F FGJnV1fF0K7IDrrCPT1bQCW1b/0TlUAiCykvgEdOmIUSSMfFMuNUiWomLAFSku3WSFD2 kutDqeC+BqAPkM2+INdJBPe681NLtPbQgRl/scxoMo2kdY1G7f2EzQp6VmBl1J2ovr1j Bvd+f9zJ1lT+D3BIge9DN9vLErzer6Ufjcuufv+o7gOGcoloNxlhXOhgjkr5U69I4yZr OCPg== MIME-Version: 1.0 X-Received: by 10.194.174.68 with SMTP id bq4mr50090962wjc.4.1432141791615; Wed, 20 May 2015 10:09:51 -0700 (PDT) Received: by 10.27.170.134 with HTTP; Wed, 20 May 2015 10:09:51 -0700 (PDT) In-Reply-To: <1831158042.17186.1432128043315.JavaMail.root@sonnection.nl> References: <555656FC.5010609@dcrocker.net> <555BA3EC.2060000@crash.com> <555BAE56.1090003@sonnection.nl> <555BD1DF.7080502@gmail.com> <1831158042.17186.1432128043315.JavaMail.root@sonnection.nl> Date: Wed, 20 May 2015 10:09:51 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Rolf E. Sonneveld" Content-Type: multipart/alternative; boundary=089e01493680c1df4f0516867e53 Archived-At: Cc: "dmarc@ietf.org" , Douglas Otis Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 17:09:54 -0000 --089e01493680c1df4f0516867e53 Content-Type: text/plain; charset=UTF-8 On Wed, May 20, 2015 at 6:20 AM, Rolf E. Sonneveld < r.e.sonneveld@sonnection.nl> wrote: > > It is fairly common for a system to shutdown while being > > patched whenever an active exploit is noticed. Undelivered > > messages are then queued and retried later. Unreasonably > > short expiry will once again make DMARC a primary cause for > > message disruption whenever DMARC asserts inappropriate > > handling requests. > > Doug rephrased my concern about short expiry times quite well. Of course > author domains are free to choose what expiry they want, but the question > is: is it OK to design a(n extension to a) protocol which don't take the > existing status quo of Internet mail into account? > I don't think it's at all the case that we're not taking the existing status quo into account. In fact I'm explicitly saying the opposite: Operators need to select expiration times that balance the expected flow of email (with its typical and atypical patterns) with the security concerns of a signature that has a risk of abuse, and we would do well to remind them of this, either explicitly or by reference. -MSK --089e01493680c1df4f0516867e53 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, May 20, 2015 at 6:20 AM, Rolf E. Sonneveld <r.e.sonneveld@sonnection.nl> wrote:
> It= is fairly common for a system to shutdown while being
> patched whenever an active exploit is noticed.=C2=A0 Undelivered
> messages are then queued and retried later.=C2=A0 Unreasonably
> short expiry will once again make DMARC a primary cause for
> message disruption whenever DMARC asserts inappropriate
> handling requests.

Doug rephrased my concern about short expiry times quite well. = Of course author domains are free to choose what expiry they want, but the = question is: is it OK to design a(n extension to a) protocol which don'= t take the existing status quo of Internet mail into account?

I don't think it's at all = the case that we're not taking the existing status quo into account.=C2= =A0 In fact I'm explicitly saying the opposite: Operators need to selec= t expiration times that balance the expected flow of email (with its typica= l and atypical patterns) with the security concerns of a signature that has= a risk of abuse, and we would do well to remind them of this, either expli= citly or by reference.

-MSK
--089e01493680c1df4f0516867e53-- From nobody Wed May 20 10:32:13 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFB5C1A8986 for ; Wed, 20 May 2015 10:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWwdU7pcG-Lc for ; Wed, 20 May 2015 10:32:09 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26EDB1A8932 for ; Wed, 20 May 2015 10:32:08 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB606.namsdf01.sdf.exchangelabs.com (10.255.109.168) with Microsoft SMTP Server (TLS) id 15.1.184.4; Wed, 20 May 2015 17:32:07 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.210]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.210]) with mapi id 15.01.0184.000; Wed, 20 May 2015 17:32:07 +0000 From: Terry Zink To: Hector Santos , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Weaker single author signature Thread-Index: AQHQkvObUBCP7SpFb0KNEb+Ij9FjRZ2FHt7Q Date: Wed, 20 May 2015 17:32:06 +0000 Message-ID: References: <20150520032528.63043.qmail@ary.lan> <555C75AC.3060502@isdg.net> In-Reply-To: <555C75AC.3060502@isdg.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.40] x-microsoft-exchange-diagnostics: 1; BL2SR01MB606; 3:/VLrxpNh7Jmtkj2tH2oAqn3vw+R2h5vCQmun2lEjWfW4esxwTCfgrMCdreMRMk0fva4ptMWQXVqkbBmhjqAy0ue57U3YYEg4giodGcC055hkmO7duaqjd48DnvUtzP6hWn+QcyyTRi/7Gcs+Jch0Pw==; 10:FLVwjU0C12TwWCxoCwV5+LWJ3DodI+rGzIGFP/ifJ2ePTRzO6Ocj61edbP6tsvWWT6u0n46+jw215Ruvotd75PYdoqQMlAV3ga54yaynJIs=; 6:tCoCXPZnuM8LljneaWPG2UVN6jUgOmoH37aPRwiZco+DwamJUKD2hypFEwai/9Oq x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB606; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(189002)(479174004)(51704005)(199003)(13464003)(377454003)(24454002)(46102003)(68736005)(15975445007)(102836002)(66066001)(19580405001)(19580395003)(33656002)(2950100001)(87936001)(106356001)(2900100001)(92566002)(64706001)(76176999)(105586002)(50986999)(54356999)(106116001)(77156002)(62966003)(2656002)(189998001)(97736004)(5001770100001)(81156007)(4001540100001)(5001860100001)(5001830100001)(107886002)(101416001)(2501003)(5001960100002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB606; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005002)(5002009)(3002001); SRVR:BL2SR01MB606; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB606; x-forefront-prvs: 0582641F53 received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2015 17:32:06.6707 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB606 Archived-At: Subject: Re: [dmarc-ietf] Weaker single author signature X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 17:32:11 -0000 > If this hack essentially weakens a DKIM signed message so that it can=20 > survive the transport, the MLM changes and the final destination. then=20 > why not just do create this weakness with just one original v1=20 > signature using the i=3D (AUID) to pass the resigner information? >=20 > Just as you expect the v2 signature to survive, and also not get=20 > stripped, why can't that happen with the weak v1 author domain signature? A weak single signature makes it more vulnerable to a replay attack. With t= wo signatures, the MTA --> MLM is protected (which is important) and the ML= M --> MTA is also protected although there is a time window of vulnerabilit= y. However, if the first leg is protected then it's smaller risk if the sec= ond leg is less protected. Thus, it's easier for the MLM (MTA --> MLM) to filter it properly the first= time. -- Terry -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Hector Santos Sent: Wednesday, May 20, 2015 4:53 AM To: dmarc@ietf.org Subject: [dmarc-ietf] Weaker single author signature With two sigs, all I can see is that the first leg of the transport is=20 stronger PATH: MTA ----> MLM strong 1st party v1 signature PATH: MLM o---> MTA weak 1st party v2 signature If this hack essentially weakens a DKIM signed message so that it can=20 survive the transport, the MLM changes and the final destination. then=20 why not just do create this weakness with just one original v1=20 signature using the i=3D (AUID) to pass the resigner information? From: user@author.example DKIM-Signature: v=3D1 d=3Dauthor.example s=3Dsigner.selector i=3Dresigner.example@author.example l=3D <-- weak sizing h=3D <-- weak header binding list Just as you expect the v2 signature to survive, and also not get=20 stripped, why can't that happen with the weak v1 author domain signature? The resigner domain can be passed via the AUID i=3D tag. The final receiver will now see weak first party signature and the=20 OPTIONAL stronger resigner signature. Since this is a DMARC extension, the trigger tag can be used such as=20 "dualsig=3Dy" on the DMARC record to enable the logic. But that wouldn't=20 be needed as long as the first party sig is survivable which is all we=20 are doing with the v2 sig. Unless I missing something, using this simpler method offer=20 compatibility with the non-signing MLM as well. The only benefit using 2 sigs I see is the stronger first leg=20 transport to the MLM and as long as the MLM domain is known, it=20 doesn't matter at the point why you send this guy as long as its=20 survivable for the distribution. The final receiver can use the i=3D=20 tag of the original weak signature to get the permission to=20 "authorize" the potential resigner. --=20 HLS On 5/19/2015 11:25 PM, John Levine wrote: >> The challenge here is that the second signer may not have anything to do= with >> the message. Since, except for From, only invisible parts of the messag= e are >> signed, the signature could be applied to almost any email. Using the >> reputation of the second signer's domain is not substantially different = than >> using the reputation of an unauthenticated identity. I don't see how th= at >> helps. > > The second signer has at least enough to do with the message that it > has a real message in hand with permission to re-sign. > > Remember the problem that got us here in the first place: AOL and > Yahoo had security failures that let crooks steal zillions of address > books, who then used botnets to send spam to AOL and Yahoo users that > appeared to be from other AOL and Yahoo users that they knew. The > actual source of the mail had nothing to do with AOL or Yahoo, or any > system that had ever gotten mail from AOL or Yahoo. > > The double signing hack limits the opportunity for trouble to mail > systems that have a recent real message in hand. While I can > certainly imagine spammy scenarios, it's hard to imagine ones that > wouldn't be fairly easy to detect and shut down. If nothing else, if > the original sender gets spam reports about double signed mail (there > are FBLs that key on DKIM signature) it can tell who's screwing > around and stop putting conditional signatures on mail to them. > > R's, > John > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Wed May 20 12:15:31 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2644E1A8AD1 for ; Wed, 20 May 2015 12:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSQqKfeaydMM for ; Wed, 20 May 2015 12:15:28 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 419641A8AC9 for ; Wed, 20 May 2015 12:15:28 -0700 (PDT) Received: by padbw4 with SMTP id bw4so77270807pad.0 for ; Wed, 20 May 2015 12:15:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=yRJcJil4iu2CvVDYMTRzqALVm+ii9exgjH5GLIj4qA0=; b=hVNW0ie8hIe6cNh0jAjolLNX4Y4u3c9yPvu8tZOx28oq24f9WKdxkDNd8bS2GdUpnZ 7aNVzgM1cK+tYQVRpi5o3yRwTeJUMEHJvYrjCY35voJx1MXhJzOfQ0KjVE8PiqKbQ2em weEre7k9HtPJ7+P4QGdXFOYW2+QnsbTBwzD3+iZFehyaE0JZBimq7tvqcDzH+SaDMuAr 2NLMH7RhnYCPmnXVEPa3OTX7dDpY7XZbvCGYOVo9Iux1MRHFf823Dc3yVcfI6wfwG44X T8GNv7so4BI+NOSuv1aHvjWQw1V6dEX4C2qAhsb7Bx6hj0cebGgOErsp7zQhLBteWBPQ GUPA== X-Received: by 10.68.57.209 with SMTP id k17mr46912582pbq.118.1432149327893; Wed, 20 May 2015 12:15:27 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id cd10sm16976484pac.7.2015.05.20.12.15.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 May 2015 12:15:26 -0700 (PDT) Message-ID: <555CDD4A.6060000@gmail.com> Date: Wed, 20 May 2015 12:15:22 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150520032528.63043.qmail@ary.lan> <555C75AC.3060502@isdg.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Weaker single author signature X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 19:15:30 -0000 On 5/20/15 10:32 AM, Terry Zink wrote: >> If this hack essentially weakens a DKIM signed message so that it can >> survive the transport, the MLM changes and the final destination. then >> why not just do create this weakness with just one original v1 >> signature using the i= (AUID) to pass the resigner information? >> >> Just as you expect the v2 signature to survive, and also not get >> stripped, why can't that happen with the weak v1 author domain signature? > A weak single signature makes it more vulnerable to a replay attack. With two signatures, the MTA --> MLM is protected (which is important) and the MLM --> MTA is also protected although there is a time window of vulnerability. However, if the first leg is protected then it's smaller risk if the second leg is less protected. > > Thus, it's easier for the MLM (MTA --> MLM) to filter it properly the first time. > > -- Terry Dear Terry, Various conditional DKIM signatures signal a time limited trust with some indicated third-party domains where delivery failure results in either Quarantine or Reject!!! What has changed to suggest a new found willingness to regiment issuance of short-term unreliable and vulnerable messaging? Who would really want to handle support after deploying this type of scheme? What level of psychic capability will be required of the support staff? This situation is caused by DMARC's refusal to allow proper request profiles for domains that handle NORMAL email. Email compatibility demands recognition of Sender header field's role! Whether or not AOL or Yahoo decides to implement a "public" profile as described in section 4 of https://tools.ietf.org/html/draft-otis-dmarc-escape , a fairly practical override could be implemented to allow other domains a sane way to deal with resulting delivery disruptions. The short-term delivery scheme you are suggesting only makes the situation worse. A sane and compatible method to handle email will actually improve email security without expecting disruptive domains to reform their behavior. This could ensure any source where the From contains an address within a DMARC domain can be verified. These domains can base acceptance on feedback to curb spoofing attempts. Of course, they should find a way to share this feedback with various reputation services (which is the norm). They should at least share this information with themselves. By having the Sender header field present, MUAs are able to make this apparent to recipients and reduce someone's need to search for often legitimate messages in spam folders. Poking around in the spam folder is always perilous. Without a defined "public" profile, the typical override is to change "reject" to "quarantine" where users are then told where they might find their missing messages. Any domain not happy with a "public" profile could also override this with "quarantine" as well. A properly implemented "public" profile better enables improved and non-disruptive inbox defenses. Regards, Douglas Otis From nobody Wed May 20 12:56:44 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2891A9063 for ; Wed, 20 May 2015 12:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4XhpigKcurO for ; Wed, 20 May 2015 12:56:34 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (mail-sn2ln0087.outbound.o365filtering.com [IPv6:2a01:111:f400:7c04::87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9BB81A905F for ; Wed, 20 May 2015 12:56:33 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB604.namsdf01.sdf.exchangelabs.com (10.255.109.166) with Microsoft SMTP Server (TLS) id 15.1.184.4; Wed, 20 May 2015 19:56:15 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.210]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.210]) with mapi id 15.01.0184.000; Wed, 20 May 2015 19:56:15 +0000 From: Terry Zink To: Scott Kitterman , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy Thread-Index: AQHQkSLjmR8NgZwmBEqnwBkgIc5yZJ2CdTYQgAAL4QCAAE1PAYAAAuMAgABflICAAMc0gIAAKsAAgAEn+LA= Date: Wed, 20 May 2015 19:56:15 +0000 Message-ID: References: <20150519234021.62540.qmail@ary.lan> <1931404.xCzP8N6imS@kitterma-e6430> In-Reply-To: <1931404.xCzP8N6imS@kitterma-e6430> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.40] x-microsoft-exchange-diagnostics: 1; BL2SR01MB604; 3:MisO8YRxo1newB1He14cCzX2c5BudRmCPgnOHAT0ABsmSMSEr24KQ6NS/CUzTiazXJ/ZNzOsj3YFGwD7hunKjYU3aH32s/Ny7xvtc1DS2SY+vzFY11dOOKk9qsO7NA1KgouRuTq1qJjuzYfr1wTE/Q==; 10:mptdMHbHcep0or6sENs4LpEIMn/SFBp0ZEBWn3Jr5TdWKjsmXWrRP1KNbcL5OjzaAiLcZX1ThXZwu/mau2R6qb5csBcp4J74yWIXqJkLLqA=; 6:6/PLyTekjXNamW3CogVvmww4ynfzhcjlUKjOr0jsvfzi+npb5MnB9vP8W/H2FRhl x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB604; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(189002)(51704005)(13464003)(24454002)(199003)(377454003)(2501003)(2900100001)(2950100001)(92566002)(77156002)(62966003)(4001540100001)(189998001)(81156007)(97736004)(5001770100001)(5001830100001)(102836002)(5001960100002)(15975445007)(68736005)(86362001)(107886002)(5001860100001)(106116001)(105586002)(50986999)(54356999)(64706001)(76176999)(106356001)(19580405001)(19580395003)(2656002)(33656002)(46102003)(101416001)(66066001)(87936001)(48203002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB604; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005002)(5002009)(3002001); SRVR:BL2SR01MB604; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB604; x-forefront-prvs: 0582641F53 received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2015 19:56:15.3769 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB604 Archived-At: Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediaries - Effort and Policy X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 19:56:41 -0000 > The challenge here is that the second signer may not have anything to do = with=20 > the message. =20 Not sure I follow this comment. The first signer says that there will be a = second signer, and the second signer must be the one the first signer said. Sounds like the second signer has (almost) everything to do with the messag= e? > It occurs to me that such FBL checks could be even be done prospectively,= i.e.=20 > do a bad domain check and only add the domain as an fs=3D domain if it's = not=20 > "bad". =20 Yes, a first-signer could choose to only add an fs=3D (or !cd=3D ) if they = trust the second signer and know it's a mailing list. A receiver could choo= se not to honor the fs=3D (or !cd=3D ) if it thinks the second signer doesn= 't do a good job of filtering mail at its entry point, or sends a lot of ba= d mail in general. -- Terry -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Scott Kitterman Sent: Tuesday, May 19, 2015 7:13 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Looking for degrees of freedom with Intermediarie= s - Effort and Policy On Tuesday, May 19, 2015 11:40:21 PM John Levine wrote: > >I would think you'd have to. There's a replay risk that's unique to this > >type of signature, so I think treating them the same would be a naive > >approach. > Remember that DMARC doesn't tell you that a message is good. The most > it can say is "not so awful that you should automatically reject it." > A sensible implementation will still run the mail through spam > filters like any other mail. >=20 > The risk is that the second signer might be malicious, but that's nothing > new, any signer can be malicious. So do the usual filtering, use the > second signer's reputation. The challenge here is that the second signer may not have anything to do wi= th=20 the message. Since, except for From, only invisible parts of the message a= re=20 signed, the signature could be applied to almost any email. Using the=20 reputation of the second signer's domain is not substantially different tha= n=20 using the reputation of an unauthenticated identity. I don't see how that= =20 helps. If this is the path we go down, there's got to be something in the second=20 signature that says it's means enough to override the DMARC fail/p=3Dreject= =20 determination. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Wed May 20 13:12:36 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284EA1A9008 for ; Wed, 20 May 2015 13:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id votc0ftyjvcl for ; Wed, 20 May 2015 13:12:32 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (mail-sn2ln0089.outbound.o365filtering.com [IPv6:2a01:111:f400:7c04::89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 358671A8BB6 for ; Wed, 20 May 2015 13:12:32 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB606.namsdf01.sdf.exchangelabs.com (10.255.109.168) with Microsoft SMTP Server (TLS) id 15.1.184.4; Wed, 20 May 2015 20:12:14 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.210]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.210]) with mapi id 15.01.0184.000; Wed, 20 May 2015 20:12:14 +0000 From: Terry Zink To: Douglas Otis , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Weaker single author signature Thread-Index: AQHQkvObUBCP7SpFb0KNEb+Ij9FjRZ2FHt7QgAAd3QCAAA4xIA== Date: Wed, 20 May 2015 20:12:13 +0000 Message-ID: References: <20150520032528.63043.qmail@ary.lan> <555C75AC.3060502@isdg.net> <555CDD4A.6060000@gmail.com> In-Reply-To: <555CDD4A.6060000@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.40] x-microsoft-exchange-diagnostics: 1; BL2SR01MB606; 3:QyK6YoyDdc7Qa/Lo5XuVTw+lS3SG1Um9maBnJyl1uW+S4x9t+x2PRZvTAogkZrk3C0a+mX91km8NHKqCYgW/zY/7e/h4eulc6WuXo4nEMRZYSwVXVGrX01FLwT2o0UFzVBteSjF/+PmXTd4g7OV34g==; 10:8hF00yG0e3xzyhIrNnTm5paFLF/wDp0P3zfIzt06dAskr0dAxyC9VZ/KHJ5viRMrwRP0Gvkovox8+50BpwTx6pSSDHagHMHzU0MsLVS00iU=; 6:YDSZJ5byJAy3DCg+28zHUHuaLPtGJh5qzo5r5vMnuPIe9x6dD+0iqqxUQNmy7NAJ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB606; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(189002)(479174004)(51704005)(199003)(13464003)(377454003)(24454002)(46102003)(68736005)(66066001)(102836002)(15975445007)(19580395003)(33656002)(106356001)(2950100001)(87936001)(2900100001)(93886004)(92566002)(19580405001)(64706001)(105586002)(50986999)(54356999)(106116001)(77156002)(62966003)(2656002)(189998001)(76176999)(97736004)(5001770100001)(81156007)(4001540100001)(5001860100001)(5001830100001)(107886002)(101416001)(2501003)(5001960100002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB606; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005002)(5002009)(3002001); SRVR:BL2SR01MB606; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB606; x-forefront-prvs: 0582641F53 received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2015 20:12:13.9453 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB606 Archived-At: Subject: Re: [dmarc-ietf] Weaker single author signature X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2015 20:12:35 -0000 Hi, Doug, > By having the Sender header field present, MUAs are able to > make this apparent to recipients and reduce someone's need > to search for often legitimate messages in spam folders. I'm not sure why you keep bringing up the Sender: field in the MUA as a sui= table example. As has been pointed out elsewhere, most mail clients (Hotmai= l, Gmail, iOS, Android, even Windows Phone!) don't show it. It's not that t= hey are unaware of its existence, but rather that its presence confuses rec= ipients. There's no magic wand to wave where users will understand it, nor = MUA's will bother to expose it, and that's why many people on this list - m= yself included - don't think it will work. The only mail client off the top of my head that shows it is Outlook, and I= see it used a lot when an administrator sends it on behalf of an executive= 's email inbox. That is, " on behalf of ." Here it makes sense.= But I think outside of a corporate environment, it's confusing. -- Terry -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Douglas Otis Sent: Wednesday, May 20, 2015 12:15 PM To: dmarc@ietf.org Subject: Re: [dmarc-ietf] Weaker single author signature On 5/20/15 10:32 AM, Terry Zink wrote: >> If this hack essentially weakens a DKIM signed message so that it can=20 >> survive the transport, the MLM changes and the final destination. then=20 >> why not just do create this weakness with just one original v1=20 >> signature using the i=3D (AUID) to pass the resigner information? >> >> Just as you expect the v2 signature to survive, and also not get=20 >> stripped, why can't that happen with the weak v1 author domain signature= ? > A weak single signature makes it more vulnerable to a replay attack. With= two signatures, the MTA --> MLM is protected (which is important) and the = MLM --> MTA is also protected although there is a time window of vulnerabil= ity. However, if the first leg is protected then it's smaller risk if the s= econd leg is less protected. > > Thus, it's easier for the MLM (MTA --> MLM) to filter it properly the fir= st time. > > -- Terry Dear Terry, Various conditional DKIM signatures signal a time limited trust with some indicated third-party domains where delivery failure results in either Quarantine or Reject!!! What has changed to suggest a new found willingness to regiment issuance of short-term unreliable and vulnerable messaging? Who would really want to handle support after deploying this type of scheme? What level of psychic capability will be required of the support staff? This situation is caused by DMARC's refusal to allow proper request profiles for domains that handle NORMAL email. =20 Email compatibility demands recognition of Sender header field's role! Whether or not AOL or Yahoo decides to implement a "public" profile as described in section 4 of https://tools.ietf.org/html/draft-otis-dmarc-escape , a fairly practical override could be implemented to allow other domains a sane way to deal with resulting delivery disruptions. The short-term delivery scheme you are suggesting only makes the situation worse. A sane and compatible method to handle email will actually improve email security without expecting disruptive domains to reform their behavior. This could ensure any source where the From contains an address within a DMARC domain can be verified. These domains can base acceptance on feedback to curb spoofing attempts. Of course, they should find a way to share this feedback with various reputation services (which is the norm). They should at least share this information with themselves. By having the Sender header field present, MUAs are able to make this apparent to recipients and reduce someone's need to search for often legitimate messages in spam folders.=20 Poking around in the spam folder is always perilous.=20 Without a defined "public" profile, the typical override is to change "reject" to "quarantine" where users are then told where they might find their missing messages. Any domain not happy with a "public" profile could also override this with "quarantine" as well. A properly implemented "public" profile better enables improved and non-disruptive inbox defenses. Regards, Douglas Otis _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Wed May 20 19:23:13 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD6A1ACE6D for ; Wed, 20 May 2015 19:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqrHCRn4Ufd5 for ; Wed, 20 May 2015 19:23:10 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E73981ACE71 for ; Wed, 20 May 2015 19:23:09 -0700 (PDT) Received: by pacwv17 with SMTP id wv17so88151572pac.2 for ; Wed, 20 May 2015 19:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=lu2Nvx9HPuABgCdwCYNJgFQvMXVevcgwEKorexBzJkc=; b=ho8J41HMM74Id1+MjXEBL2IzxmA5KynXkXblfzdNyzFRnWDhRCiZo9VhR8mi0EGURI FG+U1Kt7pLYl0ROSA6izNooe38PHx7wUbHn54TkbgQU0s54q0UyPuFuLyESyGT0pMe2n MxpM3wIGrJfw516JOtJq869giKiRLfMCPl21hm3JGDksF5IJef3Oh/5ZuLaYWac8AsNY /SvwSMc/XEyGAkG6XRZph9Vo9tWHC5iwKwelA5EHn+4HF22qZiATLM8gt4NoXomrqif5 xe2n6GgFbcTBwgztHznZz+kVUor7Oo8tyN3+HaDiPj39HZeTizIq5/sDURqGNgd1VVik Wd5g== X-Received: by 10.70.37.167 with SMTP id z7mr816266pdj.55.1432174989536; Wed, 20 May 2015 19:23:09 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id fm3sm17447049pdb.28.2015.05.20.19.23.03 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 May 2015 19:23:08 -0700 (PDT) Message-ID: <555D4185.9090809@gmail.com> Date: Wed, 20 May 2015 19:23:01 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Terry Zink , "dmarc@ietf.org" References: <20150520032528.63043.qmail@ary.lan> <555C75AC.3060502@isdg.net> <555CDD4A.6060000@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] Weaker single author signature X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 02:23:11 -0000 On 5/20/15 1:12 PM, Terry Zink wrote: > Hi, Doug, > >> > By having the Sender header field present, MUAs are able to >> > make this apparent to recipients and reduce someone's need >> > to search for often legitimate messages in spam folders. > I'm not sure why you keep bringing up the Sender: field in the MUA as a suitable example. As has been pointed out elsewhere, most mail clients (Hotmail, Gmail, iOS, Android, even Windows Phone!) don't show it. It's not that they are unaware of its existence, but rather that its presence confuses recipients. There's no magic wand to wave where users will understand it, nor MUA's will bother to expose it, and that's why many people on this list - myself included - don't think it will work. > > The only mail client off the top of my head that shows it is Outlook, and I see it used a lot when an administrator sends it on behalf of an executive's email inbox. That is, " on behalf of ." Here it makes sense. But I think outside of a corporate environment, it's confusing. Dear Terry, As re-enforced by Section 7.1 of RFC5321, unless S/MIME or OPEN PGP is used, mobile and desktop environments offer poor visibility of a message's originating domain. The level of security should quickly improve as DANE becomes more prevalent. With increased resolutions, mobile devices also offer capable web interfaces. Don't deprecate currently defined identifiers clearly declaring source agents. Assume a solution will be found within a very competitive MUA environment. Avoid solutions that attempt to make poorly considered alterations to email's fundamental transport. Any message from a DMARC domain asserting a "public" policy request permits a non-disruptive verification of source identifiers as defined by Section 4 of draft-otis-dmarc-escape . Only when verification is not obtained should a message be placed into a spam folder. This should limit spam folder placements to unverified domains, or domains having either bad or unknown reputations. This is far better than treating recipients as being unable to obtain an effective MUA or to use a browser. Accurately ascertaining the source to exclude malicious actors is important since just the Display name can easily deceive recipients in cases where user accounts have been compromised. A Display name exploit offers an effective means to side-step DMARC's efforts, especially when man-in-the-middle schemes make true source recognition impossible. Depending on weird DKIM hacks will only serve to ossify security improvements. Use of short-lived "conditional" DKIM authorization signatures that must also coincide with a stronger third-party domain has a likelihood of showing recipients "conditional" authorization signatures where an entire message body may change. When DKIM is used in this fashion, it can not ensure against messages being carried by botnets to any number of recipients containing any type of content. Botnets will not have any trouble making full use of any reasonable expiry established at the first hop. While the source header display is not normally the default except for Outlook, the following MUAs offer informed recipients information necessary to detect likely fraud. They can also provide safer services that make use of a mobile devices' support of S/MIME or depend on the mobile browser or depend on proper vetting of "public" DMARC handling. MUAs offering informed recipients information necessary to detect likely fraud-- Mozilla Thunderbird Outlook 2007 Outlook 2007 Web Access Outlook 2000/XP/2003 Outlook Express 6 OS X Mail.app v2 and v3 Entourage 2008 Eudora (Based on Thunderbird) Eudora (Original) Evolution The Bat! KDE Kmail Pine Pegasus Mail XtraMail Claris Emailer Juno Novell Groupwise Webmail Gmail Yahoo! Mail Classic Yahoo! Mail (New) Windows Live Hotmail (in "Full Version" mode) AOL Yandex Regards, Douglas Otis From nobody Thu May 21 05:23:59 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA3E1AD26E for ; Thu, 21 May 2015 05:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.102 X-Spam-Level: X-Spam-Status: No, score=-100.102 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L88ho0pRC4Bb for ; Thu, 21 May 2015 05:23:55 -0700 (PDT) Received: from secure.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6C61AD26B for ; Thu, 21 May 2015 05:23:55 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3237; t=1432211024; atps=isdg.net; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=QrOefb1BBSGAFMqd48xWU12fco0=; b=ORrwrKpV+qXI7Oe2848IugXpIK7qyARTO3gT3nncqosJ5avrfInnGBEgrYjC5v 10gsj3tUrNiZpGnoy5VFDycR6omaIhm37pxzpFC3iFta+fVA156PEWkBsH+PcVeo +TMLogHn/a4QhFPdsUH0QshwAA6edUtRhTQPDy/mcVPSA= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 21 May 2015 08:23:44 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1626035685.1.4204; Thu, 21 May 2015 08:23:43 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3237; t=1432210728; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=LslB8S2 A2VfXNpK5KtQgdjaB0b53bRp7xSjfFwfdIN0=; b=D40l/47RjIcXFnwPMb04rDQ VAjtzxlOdifsbdlXPYqqGsQIOMAP1WmDCFZgvNX1NdGpy/5Sbl/yockIVTrVjtkc 6pfffCYrtogEBLiy91bGaqDQiKUJ8Bz5THIfZ5xQrF3g8vA9PoWz1MJFwDUY8gdA I0GMfVdmpg6nAAubYcpc= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 21 May 2015 08:18:48 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 218296692.9.23824; Thu, 21 May 2015 08:18:47 -0400 Message-ID: <555DCE4F.40602@isdg.net> Date: Thu, 21 May 2015 08:23:43 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Terry Zink References: <20150520032528.63043.qmail@ary.lan> <555C75AC.3060502@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Weaker single author signature X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 12:23:58 -0000 On 5/20/2015 1:32 PM, Terry Zink wrote: >> If this hack essentially weakens a DKIM signed message so that it can >> survive the transport, the MLM changes and the final destination. then >> why not just do create this weakness with just one original v1 >> signature using the i= (AUID) to pass the resigner information? >> >> Just as you expect the v2 signature to survive, and also not get >> stripped, why can't that happen with the weak v1 author domain signature? > > A weak single signature makes it more vulnerable to a replay attack. With two signatures, the MTA --> MLM is protected (which is important) and the MLM --> MTA is also protected although there is a time window of vulnerability. However, if the first leg is protected then it's smaller risk if the second leg is less protected. > > Thus, it's easier for the MLM (MTA --> MLM) to filter it properly the first time. Several points. First, you are assuming the MLM will do CSP (Check Signing Practices). A good bit of the long time conflict and dilemma has to do with the fact there are legacy MLM operations that can not adapt and/or will militantly refuse to adapt. So one question might be; will this weak v2 idea encourage them or "mandate" them to do the CSP? The MLM MUST|SHOULD|MAY do the CSP prior to resigning. The MLM MUST|SHOULD|MAY deny restrictive submissions. The MLM MUST|SHOULD|MAY resign a V2 message. You have to consider all scenarios when the domain, i.e. Hotmail.com, is going to begin to double v1/v2 sign all its outgoing messages to avoid registration design requirements. Overall, you will have a population of different types of MLMs. To address the extra time window exploit on the first leg, you can always send out a Double V1/V1 pair, first leg strong, second leg weak. The main point is that its possible to do same thing with no signer engine code change using a weak v1 signature. You can pass the resigner domain via the i= tag (AUID) which was one of its intended ideas, among many. This would have a lower cost of adoption and adaptation because its compatible with V1 STD operations and configurations that may be already exist using a "i=signer@author" syntax or allow for it as our system does: ###################################################################### # Wildcat! DKIM (wcDKIM) # (c) copyright 2011 Santronics Software, Inc. # version: 3.10 # ... # .... # IDENTITY (i=) # # The optional i= tag allows you to add any valid formatted "email address" # (but it doesn't have to exist). It must be the same domain as the signer # or a sub-domain of the signer. Some macros are available: # # {AUTHOR} replace the Author (From:) address # {AUTHOR.DOMAIN} replace the Author (From:) address domain # {SIGNER} replace the signer domain # # example: i= {AUTHOR}.{SIGNER} That wasn't just my idea. That was a WG consideration and I believe it may be documented somewhere. No code change. I believe the AUID is already a registered tag for A-R. At some point we need to leverage what we already have done and stop reinventing stuff, with more patch work and hacks that at some point the benefits of incremental adaptation diminishes. -- HLS From nobody Thu May 21 08:24:39 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5301A1A9C for ; Thu, 21 May 2015 08:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-eHt_Qn1_It for ; Thu, 21 May 2015 08:24:36 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 800911A7017 for ; Thu, 21 May 2015 08:24:33 -0700 (PDT) Received: by wicmc15 with SMTP id mc15so16459528wic.1 for ; Thu, 21 May 2015 08:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w7dzvEb8piH0e5NfdPWhd6zgxdVm0aeN0qoV2+V3yHk=; b=TjTD7Bi8yfOQ/Z26t/N9dkMmvgcK6XOvXonTxCPP2iGpBhRFBNrPQ3QFzKav2+vv/q KEmQLtfWlaQ2dxsTRS71UVyuCoMH3n4KidB4K1Wh+Tsunpt8PvlopJknQcbjcCyubZ5J BjeF2fXKdB2jxoxQF07de/tDe7016IyHII1Qt8X9sbOjrzPIosn27jPvRUR7F17AKzl5 SIDytoj6RDuu66UotsGuBUCnfpXFn3mFKUIOSuDcXOL3mhuHluo1NAiz2XBkyVvDY7fG QsgYDxUez8Gx/+wIpll6/2zQcooNd84a+gU7iUChrPQQn6TphAcqVe7JYLoYUxplr5xP 0RwQ== MIME-Version: 1.0 X-Received: by 10.194.189.4 with SMTP id ge4mr6088404wjc.111.1432221872273; Thu, 21 May 2015 08:24:32 -0700 (PDT) Received: by 10.27.170.134 with HTTP; Thu, 21 May 2015 08:24:32 -0700 (PDT) In-Reply-To: References: <20150520032528.63043.qmail@ary.lan> <555C75AC.3060502@isdg.net> Date: Thu, 21 May 2015 08:24:32 -0700 Message-ID: From: "Murray S. Kucherawy" To: Terry Zink Content-Type: multipart/alternative; boundary=047d7bf0c0a0efc0df0516992314 Archived-At: Cc: "dmarc@ietf.org" , Hector Santos Subject: Re: [dmarc-ietf] Weaker single author signature X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 15:24:38 -0000 --047d7bf0c0a0efc0df0516992314 Content-Type: text/plain; charset=UTF-8 On Wed, May 20, 2015 at 10:32 AM, Terry Zink wrote: > A weak single signature makes it more vulnerable to a replay attack. With > two signatures, the MTA --> MLM is protected (which is important) and the > MLM --> MTA is also protected although there is a time window of > vulnerability. However, if the first leg is protected then it's smaller > risk if the second leg is less protected. > > Thus, it's easier for the MLM (MTA --> MLM) to filter it properly the > first time. > Right. The trick is deciding under what circumstances to add both a v1 and v2 signature. You could do it always, which smaller operators would probably do. It's terribly simple, and that covers your bases for interacting with MLMs a priori, but exposes you to a temporary risk when any of your users sends a message to any domain containing a bad actor. You could do it only if some local secret sauce determines that the intended recipient is an MLM. But that amounts to either use of heuristics (which can be gamed or come up with the wrong answer) or some kind of local registration process (which doesn't scale). The temporary risk is still there, but the threat surface is reduced because you inherently know a little something about the recipient domain. You could do it only for domains your users have declared contain MLMs with which they want to interact, but there again is the registration problem. There's also again the smaller threat surface, but this time you're also inherently trusting your users to make true declarations, and also to declare when the MLM is no longer of interest. That seems rather a burden. You could do it for all domains until they misbehave and then stop adding v2 signatures for them, but that can be gamed ad infinitum (domains can be trivially created and discarded). All of those options for any at-scale operator seem uncomfortable to me. The most obvious advantages to me of this method over ATPS, TPA, and that family of proposals are that (1) there's no additional DNS check required because the third party endorsement is contained within the message; and (2) it's quite a bit easier to implement than the others, at least for my project. Then again, if the at-scale operators that are home to most of the problem (we meet again, Mr. Pareto) are comfortable with using whatever homegrown heuristics they use now with the commensurate risks of v2 signatures, then this approach appears to me to be quite viable. Note that in fact the MLM doesn't have to check anything, or know any of this is even going on. Neither does its MTA even need to know what a v2 signature is; it simply re-signs the message and sends it along to the list subscribers. The whole point here is to make sure the MLMs know as little as possible so that all of them can be silently accommodated. > > The double signing hack limits the opportunity for trouble to mail > > systems that have a recent real message in hand. While I can > > certainly imagine spammy scenarios, it's hard to imagine ones that > > wouldn't be fairly easy to detect and shut down. If nothing else, if > > the original sender gets spam reports about double signed mail (there > > are FBLs that key on DKIM signature) it can tell who's screwing > > around and stop putting conditional signatures on mail to them. > True, the damage is limited to the lifetime of the last v2 signature the author domain added. I'm being cautious above because I'm sure author domains would prefer to be proactive about such threats rather than reactive to them. -MSK --047d7bf0c0a0efc0df0516992314 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, May 20, 2015 at 10:32 AM, Terry Zink <= tzink@exchange.microsoft.com> wrote:
A weak single signature makes it more vulnerable to a replay a= ttack. With two signatures, the MTA --> MLM is protected (which is impor= tant) and the MLM --> MTA is also protected although there is a time win= dow of vulnerability. However, if the first leg is protected then it's = smaller risk if the second leg is less protected.

Thus, it's easier for the MLM (MTA --> MLM) to filter it properly th= e first time.

Right.=C2=A0 The trick is deciding unde= r what circumstances to add both a v1 and v2 signature.

Y= ou could do it always, which smaller operators would probably do.=C2=A0 It&= #39;s terribly simple, and that covers your bases for interacting with MLMs= a priori, but exposes you to a temporary risk when any of your users sends= a message to any domain containing a bad actor.

You coul= d do it only if some local secret sauce determines that the intended recipi= ent is an MLM.=C2=A0 But that amounts to either use of heuristics (which ca= n be gamed or come up with the wrong answer) or some kind of local registra= tion process (which doesn't scale).=C2=A0 The temporary risk is still t= here, but the threat surface is reduced because you inherently know a littl= e something about the recipient domain.

You could do it o= nly for domains your users have declared contain MLMs with which they want = to interact, but there again is the registration problem.=C2=A0 There's= also again the smaller threat surface, but this time you're also inher= ently trusting your users to make true declarations, and also to declare wh= en the MLM is no longer of interest.=C2=A0 That seems rather a burden.
<= br>
You could do it for all domains until they misbehave and then= stop adding v2 signatures for them, but that can be gamed ad infinitum (do= mains can be trivially created and discarded).

All of tho= se options for any at-scale operator seem uncomfortable to me.=C2=A0 The mo= st obvious advantages to me of this method over ATPS, TPA, and that family = of proposals are that (1) there's no additional DNS check required beca= use the third party endorsement is contained within the message; and (2) it= 's quite a bit easier to implement than the others, at least for my pro= ject.

Then again, if the at-scale operators th= at are home to most of the problem (we meet again, Mr. Pareto) are comforta= ble with using whatever homegrown heuristics they use now with the commensu= rate risks of v2 signatures, then this approach appears to me to be quite v= iable.

Note that in fact the MLM doesn't have to chec= k anything, or know any of this is even going on.=C2=A0 Neither does its MT= A even need to know what a v2 signature is; it simply re-signs the message = and sends it along to the list subscribers.=C2=A0 The whole point here is t= o make sure the MLMs know as little as possible so that all of them can be = silently accommodated.
=C2=A0
> The double signing hack limits = the opportunity for trouble to mail
> systems that have a recent real message in hand.=C2=A0 While I can
> certainly imagine spammy scenarios, it's hard to imagine ones that=
> wouldn't be fairly easy to detect and shut down.=C2=A0 If nothing = else, if
> the original sender gets spam reports about double signed mail (there<= br> > are FBLs that key on DKIM signature) it can tell who's screwing > around and stop putting conditional signatures on mail to them.

True, the damage is limited to th= e lifetime of the last v2 signature the author domain added.=C2=A0 I'm = being cautious above because I'm sure author domains would prefer to be= proactive about such threats rather than reactive to them.

-MSK
--047d7bf0c0a0efc0df0516992314-- From nobody Thu May 21 10:13:25 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2061A00C8 for ; Thu, 21 May 2015 10:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRDTOWO8aLuY for ; Thu, 21 May 2015 10:13:22 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1CAB1A0021 for ; Thu, 21 May 2015 10:11:05 -0700 (PDT) Received: (qmail 81667 invoked from network); 21 May 2015 17:11:11 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 21 May 2015 17:11:11 -0000 Date: 21 May 2015 17:10:42 -0000 Message-ID: <20150521171042.70867.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] Weaker single author signature X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 17:13:22 -0000 >> The double signing hack limits the opportunity for trouble to mail >> systems that have a recent real message in hand. While I can >> certainly imagine spammy scenarios, it's hard to imagine ones that >> wouldn't be fairly easy to detect and shut down. ... >True, the damage is limited to the lifetime of the last v2 signature the >author domain added. I'm being cautious above because I'm sure author >domains would prefer to be proactive about such threats rather than >reactive to them. These days the big mail systems' spam filtering is so fluid that the difference is pretty blurry. I gather that gmail has per-user filter rules and can update them after each message. It is my impression that the problem that persuaded Yahoo to do the DMARC thing was crooks mailing into Yahoo with fake Yahoo return addresses so their own users were complaining. Should crooks use double signing to do that, I'd think it'd be pretty easy to detect and to mitigate. If they're seeing a lot of spam button reports about a particular re-signer, stop putting conditional signatures on mail sent to them. It sure would be nice to get some feedback from large mail systems and hear whether our guesses about them are correct. R's, John From nobody Thu May 21 10:24:50 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 076D91A00CC for ; Thu, 21 May 2015 10:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.399 X-Spam-Level: * X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLa6GDYOr_vD for ; Thu, 21 May 2015 10:24:46 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.31]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 661D11A0086 for ; Thu, 21 May 2015 10:24:45 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES533.agna.amgreetings.com ([::1]) with mapi id 14.03.0210.002; Thu, 21 May 2015 13:24:44 -0400 From: "MH Michael Hammer (5304)" To: John Levine , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Weaker single author signature Thread-Index: AQHQkvOZLJMRgd5gL0GBOKYXeWgwoZ2FYu8AgAFusACAAB2qAP//wE6A Date: Thu, 21 May 2015 17:24:44 +0000 Message-ID: References: <20150521171042.70867.qmail@ary.lan> In-Reply-To: <20150521171042.70867.qmail@ary.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.200] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "superuser@gmail.com" Subject: Re: [dmarc-ietf] Weaker single author signature X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 17:24:49 -0000 > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of John Levine > Sent: Thursday, May 21, 2015 1:11 PM > To: dmarc@ietf.org > Cc: superuser@gmail.com > Subject: Re: [dmarc-ietf] Weaker single author signature >=20 > >> The double signing hack limits the opportunity for trouble to mail > >> systems that have a recent real message in hand. While I can > >> certainly imagine spammy scenarios, it's hard to imagine ones that > >> wouldn't be fairly easy to detect and shut down. ... >=20 > >True, the damage is limited to the lifetime of the last v2 signature > >the author domain added. I'm being cautious above because I'm sure > >author domains would prefer to be proactive about such threats rather > >than reactive to them. >=20 > These days the big mail systems' spam filtering is so fluid that the diff= erence > is pretty blurry. I gather that gmail has per-user filter rules and can = update > them after each message. >=20 > It is my impression that the problem that persuaded Yahoo to do the DMARC > thing was crooks mailing into Yahoo with fake Yahoo return addresses so > their own users were complaining. Should crooks use double signing to do > that, I'd think it'd be pretty easy to detect and to mitigate. If they'r= e seeing a > lot of spam button reports about a particular re-signer, stop putting > conditional signatures on mail sent to them. >=20 My understanding is that the bad guys were stealing Yahoo address book info= rmation and then mailing from OUTSIDE Yahoo to the recipients (not Yahoo) c= laiming to be from the Yahoo user that they stole the address book info fro= m - thus the p=3Dreject shutting the problem down almost immediately for ma= ny recipients. > It sure would be nice to get some feedback from large mail systems and he= ar > whether our guesses about them are correct. >=20 > R's, > John >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Thu May 21 10:27:12 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB761A0100 for ; Thu, 21 May 2015 10:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKXQyoFqnVIY for ; Thu, 21 May 2015 10:27:08 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7F21A00BE for ; Thu, 21 May 2015 10:27:07 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB606.namsdf01.sdf.exchangelabs.com (10.255.109.168) with Microsoft SMTP Server (TLS) id 15.1.184.4; Thu, 21 May 2015 17:27:05 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.210]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.210]) with mapi id 15.01.0184.000; Thu, 21 May 2015 17:27:05 +0000 From: Terry Zink To: "Murray S. Kucherawy" Thread-Topic: [dmarc-ietf] Weaker single author signature Thread-Index: AQHQkvObUBCP7SpFb0KNEb+Ij9FjRZ2FHt7QgAFvswCAAB/pIA== Date: Thu, 21 May 2015 17:27:04 +0000 Message-ID: References: <20150520032528.63043.qmail@ary.lan> <555C75AC.3060502@isdg.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [167.220.2.248] x-microsoft-exchange-diagnostics: 1; BL2SR01MB606; 3:5h55GNn0DRGkiDDJ/JEBSbs2v8RQ/YSbd8kFUH5s+aWj0Km1mA9p7Z2IopCwpsKbYXr00poCX+JqOzhmG5psSAFiEtxuPy8od3eNneXiKfq4SIo4/DR8T73ppC4HnFEYLp5wGWN3JUbWGvVWeFqbcg==; 10:bH01Bp4Qr4OUg4sOP3RPkQ7UdqB7q1+El/u66OnOKmIikDFrzh/R0VC6Z8KN4/6BBEoHwOjG1jP8qND+skjqabIL5b+Bmp+y1Se2PLEF0f8=; 6:UL4s1TE8iM1SzYNSKObH9cMIjw3H65Axlj2e6L6XE+YmVKkUTzZucDULLnDJLSB7 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2SR01MB606; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(16236675004)(2656002)(19625215002)(76176999)(54356999)(62966003)(77156002)(81156007)(110136002)(101416001)(86362001)(4001540100001)(5001860100001)(5001830100001)(5001960100002)(106116001)(1411001)(189998001)(66066001)(97736004)(15975445007)(102836002)(92566002)(68736005)(2900100001)(64706001)(105586002)(46102003)(50986999)(19580395003)(33656002)(93886004)(106356001)(87936001)(2950100001)(19300405004); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2SR01MB606; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(5005002)(5002009)(520001)(3002001); SRVR:BL2SR01MB606; BCL:0; PCL:0; RULEID:; SRVR:BL2SR01MB606; x-forefront-prvs: 0583A86C08 received-spf: None (protection.outlook.com: exchange.microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=tzink@exchange.microsoft.com; Content-Type: multipart/alternative; boundary="_000_BL2SR01MB605D2A70F12791658D2B8E696C10BL2SR01MB605namsdf_" MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2015 17:27:04.9919 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f686d426-8d16-42db-81b7-ab578e110ccd X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2SR01MB606 Archived-At: Cc: "dmarc@ietf.org" , Hector Santos Subject: Re: [dmarc-ietf] Weaker single author signature X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 17:27:11 -0000 --_000_BL2SR01MB605D2A70F12791658D2B8E696C10BL2SR01MB605namsdf_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBZb3UgY291bGQgZG8gaXQgb25seSBpZiBzb21lIGxvY2FsIHNlY3JldCBzYXVjZSBkZXRlcm1p bmVzIHRoYXQgdGhlIGludGVuZGVkDQo+IHJlY2lwaWVudCBpcyBhbiBNTE0uLi4gVGhlbiBhZ2Fp biwgaWYgdGhlIGF0LXNjYWxlIG9wZXJhdG9ycyB0aGF0IGFyZSBob21lIHRvDQo+IG1vc3Qgb2Yg dGhlIHByb2JsZW0gKHdlIG1lZXQgYWdhaW4sIE1yLiBQYXJldG8pIGFyZSBjb21mb3J0YWJsZSB3 aXRoIHVzaW5nDQo+IHdoYXRldmVyIGhvbWVncm93biBoZXVyaXN0aWNzIHRoZXkgdXNlIG5vdyB3 aXRoIHRoZSBjb21tZW5zdXJhdGUgcmlza3MNCj4gb2YgdjIgc2lnbmF0dXJlcywgdGhlbiB0aGlz IGFwcHJvYWNoIGFwcGVhcnMgdG8gbWUgdG8gYmUgcXVpdGUgdmlhYmxlLg0KDQo+IFRoZXNlIGRh eXMgdGhlIGJpZyBtYWlsIHN5c3RlbXMnIHNwYW0gZmlsdGVyaW5nIGlzIHNvIGZsdWlkIHRoYXQg dGhlIGRpZmZlcmVuY2UgaXMgcHJldHR5DQo+IGJsdXJyeS4gIEl0IHN1cmUgd291bGQgYmUgbmlj ZSB0byBnZXQgc29tZSBmZWVkYmFjayBmcm9tIGxhcmdlIG1haWwgc3lzdGVtcyBhbmQNCg0KPiBo ZWFyIHdoZXRoZXIgb3VyIGd1ZXNzZXMgYWJvdXQgdGhlbSBhcmUgY29ycmVjdC4NCg0KVGhlIHdh eSBJIGVudmlzaW9uIHRoaXMgd29ya2luZyBhdCBhIGxhcmdlIG1haWwgcHJvdmlkZXIg4oCTIG9m IHdoaWNoIEkgaGFwcGVuIHRvIGhhdmUgc29tZSBpbnNpZ2h0IGludG8sIHRoYXQgb2YgSG90bWFp bCAoYW5kIGFzc29jaWF0ZWQgY29uc3VtZXIgYnJhbmRzKSBhbmQgT2ZmaWNlIDM2NSB3aGljaCBo b3N0cyBzbWFsbCwgbWVkaXVtLCBhbmQgbGFyZ2UgYnVzaW5lc3NlcyDigJMgd2hhdCB3ZSB3b3Vs ZCBkbyBpcyBjb21lIHVwIHdpdGggYSBsaXN0IG9mIE1MTSBkb21haW5zIGFuZCBmaWd1cmUgb3V0 IGl0cyByZXB1dGF0aW9uIOKAkyBkb2VzIGl0IHNlbmQgbW9zdGx5IGdvb2QgZW1haWwgb3IgbW9z dGx5IGJhZCBlbWFpbD8gSWYgbW9zdGx5IGdvb2QsIHRoZW4gaWYgYSBzZW5kZXIgc2VuZHMgYSBt ZXNzYWdlIHRvIHRoZW0sIHdl4oCZZCBhZmZpeCBhIERLSU0gdjIgc2lnbmF0dXJlLg0KDQpPbiB0 aGUgaW5ib3VuZCwgSeKAmW0gbm90IHN1cmUgd2hldGhlciBvciBub3Qgd2XigJlkIHZlcmlmeSB0 aGUgREtJTSB2MiAqb3IqIHNpbXBseSBzdXBwcmVzcyB0aGUgRE1BUkMgY2hlY2sgYW5kIGFwcGx5 IGFsbCBvZiBvdXIgb3RoZXIgYW50aXNwYW0gZmlsdGVyaW5nLCBhbmQgdXBkYXRlIHRoZSBNTE3i gJlzIHJlcHV0YXRpb24gYWNjb3JkaW5nbHkuIFRoZSBhZmZpeGluZyBvZiB0aGUgREtJTSB2MiBp cyBtb3JlIGZvciBpbnRlcm9wZXJhYmlsaXR5IGZvciB3aGVuIG91ciB1c2VycyBzZW5kIHRvIE1M TXMgd2hpY2ggaW4gdHVybiBhcmUgcmVsYXllZCB0byBvdGhlciBwcm92aWRlcnMuIElmIGEgTUxN IHN0YXJ0cyBnZW5lcmF0aW5nIHRvbyBtYW55IHNwYW0gY29tcGxhaW50cyB0aGVuIHdl4oCZZCBz dG9wIGFwcGx5aW5nIERLSU0gdjIgc2lnbmF0dXJlcyBhbmQgbWF5YmUgc3RhcnQgcmVhcHBseWlu ZyBETUFSQyB0byBpdC4NCg0KTm90IHN1cmUgaG93IG90aGVyIGJpZyBtYWlsZXJzIHdvdWxkIGRv IGl0LCBidXQgSSB3b3VsZCB0aGluayBpdCB3b3VsZCBiZSBzaW1pbGFyIChlc3BlY2lhbGx5IEdt YWlsKS4NCg0KLS0gVGVycnkNCg== --_000_BL2SR01MB605D2A70F12791658D2B8E696C10BL2SR01MB605namsdf_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5N c29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwg bGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXBy aW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2lu LWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy aWYiO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWls U3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uUGxhaW5UZXh0Q2hh cg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj4mZ3Q7IFlvdSBj b3VsZCBkbyBpdCBvbmx5IGlmIHNvbWUgbG9jYWwgc2VjcmV0IHNhdWNlIGRldGVybWluZXMgdGhh dCB0aGUgaW50ZW5kZWQ8YnI+DQomZ3Q7IHJlY2lwaWVudCBpcyBhbiBNTE0uLi4mbmJzcDtUaGVu IGFnYWluLCBpZiB0aGUgYXQtc2NhbGUgb3BlcmF0b3JzIHRoYXQgYXJlIGhvbWUgdG8gPGJyPg0K Jmd0OyBtb3N0IG9mIHRoZSBwcm9ibGVtICh3ZSBtZWV0IGFnYWluLCBNci4gUGFyZXRvKSBhcmUg Y29tZm9ydGFibGUgd2l0aCB1c2luZyA8YnI+DQomZ3Q7IHdoYXRldmVyIGhvbWVncm93biBoZXVy aXN0aWNzIHRoZXkgdXNlIG5vdyB3aXRoIHRoZSBjb21tZW5zdXJhdGUgcmlza3MgPGJyPg0KJmd0 OyBvZiB2MiBzaWduYXR1cmVzLCB0aGVuIHRoaXMgYXBwcm9hY2ggYXBwZWFycyB0byBtZSB0byBi ZSBxdWl0ZSB2aWFibGUuPG86cD48L286cD48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBUaGVzZSBkYXlzIHRoZSBiaWcgbWFpbCBzeXN0ZW1zJyBzcGFtIGZpbHRlcmluZyBp cyBzbyBmbHVpZCB0aGF0IHRoZSBkaWZmZXJlbmNlIGlzIHByZXR0eQ0KPGJyPg0KJmd0OyBibHVy cnkuJm5ic3A7IEl0IHN1cmUgd291bGQgYmUgbmljZSB0byBnZXQgc29tZSBmZWVkYmFjayBmcm9t IGxhcmdlIG1haWwgc3lzdGVtcyBhbmQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgaGVhciB3aGV0aGVyIG91ciBndWVzc2VzIGFib3V0IHRoZW0gYXJlIGNvcnJl Y3QuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+VGhlIHdheSBJIGVudmlzaW9uIHRoaXMgd29ya2luZyBhdCBhIGxhcmdlIG1haWwgcHJvdmlk ZXIg4oCTIG9mIHdoaWNoIEkgaGFwcGVuIHRvIGhhdmUgc29tZSBpbnNpZ2h0IGludG8sIHRoYXQg b2YgSG90bWFpbCAoYW5kIGFzc29jaWF0ZWQgY29uc3VtZXIgYnJhbmRzKSBhbmQgT2ZmaWNlDQog MzY1IHdoaWNoIGhvc3RzIHNtYWxsLCBtZWRpdW0sIGFuZCBsYXJnZSBidXNpbmVzc2VzIOKAkyB3 aGF0IHdlIHdvdWxkIGRvIGlzIGNvbWUgdXAgd2l0aCBhIGxpc3Qgb2YgTUxNIGRvbWFpbnMgYW5k IGZpZ3VyZSBvdXQgaXRzIHJlcHV0YXRpb24g4oCTIGRvZXMgaXQgc2VuZCBtb3N0bHkgZ29vZCBl bWFpbCBvciBtb3N0bHkgYmFkIGVtYWlsPyBJZiBtb3N0bHkgZ29vZCwgdGhlbiBpZiBhIHNlbmRl ciBzZW5kcyBhIG1lc3NhZ2UgdG8gdGhlbSwgd2XigJlkDQogYWZmaXggYSBES0lNIHYyIHNpZ25h dHVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+T24gdGhlIGluYm91bmQsIEnigJltIG5vdCBzdXJlIHdoZXRoZXIgb3Igbm90 IHdl4oCZZCB2ZXJpZnkgdGhlIERLSU0gdjIgKjxiPm9yPC9iPiogc2ltcGx5IHN1cHByZXNzIHRo ZSBETUFSQyBjaGVjayBhbmQgYXBwbHkgYWxsIG9mIG91ciBvdGhlciBhbnRpc3BhbSBmaWx0ZXJp bmcsDQogYW5kIHVwZGF0ZSB0aGUgTUxN4oCZcyByZXB1dGF0aW9uIGFjY29yZGluZ2x5LiBUaGUg YWZmaXhpbmcgb2YgdGhlIERLSU0gdjIgaXMgbW9yZSBmb3IgaW50ZXJvcGVyYWJpbGl0eSBmb3Ig d2hlbiBvdXIgdXNlcnMgc2VuZCB0byBNTE1zIHdoaWNoIGluIHR1cm4gYXJlIHJlbGF5ZWQgdG8g b3RoZXIgcHJvdmlkZXJzLiBJZiBhIE1MTSBzdGFydHMgZ2VuZXJhdGluZyB0b28gbWFueSBzcGFt IGNvbXBsYWludHMgdGhlbiB3ZeKAmWQgc3RvcCBhcHBseWluZw0KIERLSU0gdjIgc2lnbmF0dXJl cyBhbmQgbWF5YmUgc3RhcnQgcmVhcHBseWluZyBETUFSQyB0byBpdC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Tm90IHN1cmUg aG93IG90aGVyIGJpZyBtYWlsZXJzIHdvdWxkIGRvIGl0LCBidXQgSSB3b3VsZCB0aGluayBpdCB3 b3VsZCBiZSBzaW1pbGFyIChlc3BlY2lhbGx5IEdtYWlsKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+LS0gVGVycnk8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BL2SR01MB605D2A70F12791658D2B8E696C10BL2SR01MB605namsdf_-- From nobody Thu May 21 10:38:07 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0E91A0046 for ; Thu, 21 May 2015 10:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.163 X-Spam-Level: ** X-Spam-Status: No, score=2.163 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3Q2VU6XNSCY for ; Thu, 21 May 2015 10:38:04 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF9D91A0089 for ; Thu, 21 May 2015 10:37:59 -0700 (PDT) Received: (qmail 85842 invoked from network); 21 May 2015 17:38:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=14f51.555e17fd.k1505; bh=QerHaROD0Jrt0KVIeoJhSAgy2R1z6ztyQ8X1rMfy3+I=; b=wvJRJgjIsVov4wXKrpZEmaGepsY/ZKqlJzFOy6I4xSUpEY4tFR5s9QW9fwzfgBHrpJXf7NO68s5JmGMiOVo0H6x6aNqTZNNiom4NB98tGwX4+vkp8fmizS9QVmLZZuuB0H6f1mE8I72erKAEEfXcs0ikCKcbnX1Y3w16CsRIWREg+XBBeWtHhZVGALFEoszclcpD3PXyzuNa8N6XKRuQbZShyE+IbqQhR49MAY9FWCNuosQNuMrReYxD5v81RTxL DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=14f51.555e17fd.k1505; bh=QerHaROD0Jrt0KVIeoJhSAgy2R1z6ztyQ8X1rMfy3+I=; b=MVQeqhdbKHbwiNZ4Z+SGfnQkOIvQ2vEKMQEyKPP9GU17vhvDAQxbj6ur2ZSXNshfG2fnl7wgg3JxQlt8/YpIQ5hn/JVFun/vea49nBVL/O7cFa1D8QMojUHOEhptRiz+nN93kYy8P0vgCdUctG51JmcQXoYo38xHvWHt8DAGIJqFRiwwzu4ziPkMjSlMaTGERWhBPPanHXxG/d+PpWz8Fz+SKIc55SizRzSlH/cfDSGWrHRRHUlVq+qxgumLG7WO Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 21 May 2015 17:38:05 -0000 Date: 21 May 2015 13:37:57 -0400 Message-ID: From: "John R Levine" To: "MH Michael Hammer (5304)" In-Reply-To: References: <20150521171042.70867.qmail@ary.lan> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dmarc@ietf.org" , "superuser@gmail.com" Subject: Re: [dmarc-ietf] Weaker single author signature X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 17:38:07 -0000 > My understanding is that the bad guys were stealing Yahoo address book > information and then mailing from OUTSIDE Yahoo to the recipients (not > Yahoo) claiming to be from the Yahoo user that they stole the address > book info from - thus the p=reject shutting the problem down almost > immediately for many recipients. The bad guys used stolen address books to mail to lots of places including into Yahoo, with fake Yahoo return addresses of people the recipients knew. The complaints that mattered were from Yahoo users about mail sent to their Yahoo addresses. (If get spam with a fake Yahoo return address sent to my Hotmail address, I'll hit the spam button, Hotmail will decrease the reputation of the sending IP, and that's about it.) We can leave for the advanced seminar the question of why if that were the problem, Yahoo didn't do something less disruptive. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Thu May 21 10:57:13 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D0D1A007F for ; Thu, 21 May 2015 10:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPK2sBwtV9Qr for ; Thu, 21 May 2015 10:57:09 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93B881A0191 for ; Thu, 21 May 2015 10:56:28 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so23306282wic.0 for ; Thu, 21 May 2015 10:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2sFF4Ut4VmDr5lYww+DO2S1IiT7IgT4rNbX9n7kTtrI=; b=ve8dtUlWuRavvQcdkjk8vQzA5O0agSJxcmumHeDh3ex+sgltMhTwJ+wItzi/yjHTbB 7zhMcJztOmzu1+a0OY0tQQTWp9y0DPXpYQDWXzM8mReBjW6IpY0/swZ1vHmlsg9wjqvQ BpkNaa0ibW5aNlg4ZG+dILM2NhdbgX+zBq4Dble39qiTTc1UP1MHyLNF5WT865oakLzG ESLqHbkTFKwyYZRFuHwOMu4AJeGrngCSoErEAGzn0YOTEm1wjLPCIxy+I5ERjz+TYqlc UpUuc6TzuOJvtwf1mrdbi+NR1cOwR7J+JZ40FlqTXBgfMK8Nk5w2If121lxV7EGuinZI tqmQ== MIME-Version: 1.0 X-Received: by 10.194.61.208 with SMTP id s16mr7503547wjr.135.1432230986572; Thu, 21 May 2015 10:56:26 -0700 (PDT) Received: by 10.27.170.134 with HTTP; Thu, 21 May 2015 10:56:26 -0700 (PDT) In-Reply-To: References: <20150520032528.63043.qmail@ary.lan> <555C75AC.3060502@isdg.net> Date: Thu, 21 May 2015 10:56:26 -0700 Message-ID: From: "Murray S. Kucherawy" To: Terry Zink Content-Type: multipart/alternative; boundary=047d7b86d3e630e97c05169b43ea Archived-At: Cc: "dmarc@ietf.org" , Hector Santos Subject: Re: [dmarc-ietf] Weaker single author signature X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 17:57:11 -0000 --047d7b86d3e630e97c05169b43ea Content-Type: text/plain; charset=UTF-8 On Thu, May 21, 2015 at 10:27 AM, Terry Zink wrote: > > Not sure how other big mailers would do it, but I would think it would be > similar (especially Gmail). > > > At Facebook there are no longer any email-enabled mailbox services, so it's not among the more interesting of the big cases except for the scale it handles. In terms of email it's just a forwarding service now. So inbound, it would check v=1 and v=2 and DMARC, and then hand the whole package off to internal analysis machinery for a verdict. If the message survives, it's relayed; then, outbound, it would sign with v=1 and be done because it's unlikely anything past that is an MLM. Gmail, AOL, and Yahoo would be interesting to hear about. -MSK --047d7b86d3e630e97c05169b43ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, May 21, 2015 at 10:27 AM, Terry Zink <= tzink@exchange.microsoft.com> wrote:

Not sure how other big= mailers would do it, but I would think it would be similar (especially Gma= il).



At Facebook there are no lon= ger any email-enabled mailbox services, so it's not among the more inte= resting of the big cases except for the scale it handles.=C2=A0 In terms of= email it's just a forwarding service now.=C2=A0 So inbound, it would c= heck v=3D1 and v=3D2 and DMARC, and then hand the whole package off to inte= rnal analysis machinery for a verdict.=C2=A0 If the message survives, it= 9;s relayed; then, outbound, it would sign with v=3D1 and be done because i= t's unlikely anything past that is an MLM.

Gmail, AOL= , and Yahoo would be interesting to hear about.

-MSK
--047d7b86d3e630e97c05169b43ea-- From nobody Thu May 21 11:13:17 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCC21A1A1C for ; Thu, 21 May 2015 11:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KibgmL8orPHO for ; Thu, 21 May 2015 11:13:13 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C4E91A0389 for ; Thu, 21 May 2015 11:13:13 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so23767906wic.0 for ; Thu, 21 May 2015 11:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5LyMnDMhU/dRlews+aVEHmLgmgDCnwEu364AJQUVzWw=; b=bXtye2dNtbo2DS/sh6LC/tOxDXSZz9H7BNZq6esEy6r8L+9n/QGDX8/nXQHV7NTeYQ JKffyp/yzbsb1BL/Lys/YasRQAZ4HSI6ZsHUnB+5lNJDsV7UTh7iWtEh9PJDRBNWdIIk i1qwtbrUE5MmA4EcJs7Gls596N8v6zlq4nmHmWDoxEsakXqag9MHIFa9PHdonHvbLTsS SWaECAcTnKcbjYAZJQDS6kFC2LFK97tSapnqzy6KQB4leUoVytylG21kjYr1IxOm3v9I OW5rLbsh1C2Z5Mz8FHohZk6UBrZBGmrdyHw1Uyi6wxNofqudtYPwWyedP3AbZ4oqM7nW T2aw== MIME-Version: 1.0 X-Received: by 10.194.189.4 with SMTP id ge4mr7325000wjc.111.1432231992374; Thu, 21 May 2015 11:13:12 -0700 (PDT) Received: by 10.27.170.134 with HTTP; Thu, 21 May 2015 11:13:12 -0700 (PDT) In-Reply-To: References: <20150520032528.63043.qmail@ary.lan> <555C75AC.3060502@isdg.net> Date: Thu, 21 May 2015 11:13:12 -0700 Message-ID: From: "Murray S. Kucherawy" To: Terry Zink Content-Type: multipart/alternative; boundary=047d7bf0c0a0243a3d05169b7f61 Archived-At: Cc: "dmarc@ietf.org" , Hector Santos Subject: Re: [dmarc-ietf] Weaker single author signature X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 18:13:15 -0000 --047d7bf0c0a0243a3d05169b7f61 Content-Type: text/plain; charset=UTF-8 On Thu, May 21, 2015 at 10:56 AM, Murray S. Kucherawy wrote: > > At Facebook there are no longer any email-enabled mailbox services, so > it's not among the more interesting of the big cases except for the scale > it handles. In terms of email it's just a forwarding service now. So > inbound, it would check v=1 and v=2 and DMARC, and then hand the whole > package off to internal analysis machinery for a verdict. If the message > survives, it's relayed; then, outbound, it would sign with v=1 and be done > because it's unlikely anything past that is an MLM. > > Gmail, AOL, and Yahoo would be interesting to hear about. > Also, the vast majority of FB's outbound traffic is notifications, not stuff that's user-generated, so v=1 outbound there is again all that's probably needed. -MSK --047d7bf0c0a0243a3d05169b7f61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, May 21, 2015 at 10:56 AM, Murray S. Kucherawy <= superuser@gmail.com> wrote:

At Facebook there are no longer any email-enabled mailbox services, s= o it's not among the more interesting of the big cases except for the s= cale it handles.=C2=A0 In terms of email it's just a forwarding service= now.=C2=A0 So inbound, it would check v=3D1 and v=3D2 and DMARC, and then = hand the whole package off to internal analysis machinery for a verdict.=C2= =A0 If the message survives, it's relayed; then, outbound, it would sig= n with v=3D1 and be done because it's unlikely anything past that is an= MLM.

Gmail, AOL, and Yahoo would be interesting to hear = about.

Also, the vast majo= rity of FB's outbound traffic is notifications, not stuff that's us= er-generated, so v=3D1 outbound there is again all that's probably need= ed.

-MSK
--047d7bf0c0a0243a3d05169b7f61-- From nobody Thu May 21 13:27:40 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6368B1A8A8A for ; Thu, 21 May 2015 13:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6_cYUWV8fqAR for ; Thu, 21 May 2015 13:27:34 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B60251A8992 for ; Thu, 21 May 2015 13:27:34 -0700 (PDT) Received: by iesa3 with SMTP id a3so17173623ies.2 for ; Thu, 21 May 2015 13:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=1IBhQ8FzhNFYqr2/6VM7UEVSCP0ba62wtDHSw/ms/Nw=; b=W/VzT9vHICsGkO/OOtr11RbV8FMdtQA1Af8qx41sOZVXVylB2twn69mzpszbJqZntU 10zwOL9nNj8PXF/Fwqjvok1d4v+K9PRz9VctIelo14qXQTBfD+cOLw3Cxz4gvBW2Ap4c VihaYL6ONEfjQANnQDtzIVHysAemuljyg37P3zucNvaTXsMTcBrDZU3UMwQSFUL+Tufv 21A0WJay1XBg59WzTrKLggfMI+WGvbS9ECgkZR4X25sGblQ7NxVZXAkCP1FtR5XIUEiX 7yPYu/9UsMHN4hf88pFuWQaHimXMdTZ8gdUWAm4eErbjqxVqg6GsBj8wSXfuwhj64quj Rjag== X-Received: by 10.50.4.67 with SMTP id i3mr637625igi.47.1432240054211; Thu, 21 May 2015 13:27:34 -0700 (PDT) Received: from justsomecomcastuser.selfip.org (c-24-6-60-244.hsd1.ca.comcast.net. [24.6.60.244]) by mx.google.com with ESMTPSA id l128sm15702249iol.1.2015.05.21.13.27.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 May 2015 13:27:33 -0700 (PDT) Message-ID: <555E3FB3.5090803@gmail.com> Date: Thu, 21 May 2015 13:27:31 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150520032528.63043.qmail@ary.lan> <555C75AC.3060502@isdg.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030106010804080406000205" Archived-At: Subject: Re: [dmarc-ietf] Weaker single author signature X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 20:27:38 -0000 This is a multi-part message in MIME format. --------------030106010804080406000205 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Dear Murray, See comments inline: On 5/21/15 8:24 AM, Murray S. Kucherawy wrote: > On Wed, May 20, 2015 at 10:32 AM, Terry Zink > > wrote: > > A weak single signature makes it more > vulnerable to a replay attack. With two > signatures, the MTA --> MLM is protected > (which is important) and the MLM --> MTA is > also protected although there is a time > window of vulnerability. However, if the > first leg is protected then it's smaller > risk if the second leg is less protected. > > Thus, it's easier for the MLM (MTA --> MLM) > to filter it properly the first time. > > > Right. The trick is deciding under what > circumstances to add both a v1 and v2 signature. DKIM v1 v2 is not suitable for use with DMARC because it fails to offer those handling these messages protection. Any v1 + v2 seen by any number of recipients can lead to any number of subsequent authorized messages for any large number of recipients from any large number of sources. This DKIM scheme remains ineffective at offering protection with respect to MiTM threats. This issue is significant for the likely use case of mailing-lists! A major premise of this effort is that recipients ONLY pay attention to the From which this scheme preserves unchanged. As Hector mentioned, this scheme is unable to authorize any service not using DKIM, however the TPA-Label scheme overcomes this significant limitation with respect to NORMAL email. In fact, it can avoid reliance on DKIM altogether when necessary. > You could do it always, which smaller operators > would probably do. It's terribly simple, and > that covers your bases for interacting with MLMs > a priori, but exposes you to a temporary risk > when any of your users sends a message to any > domain containing a bad actor. Unlike the TPA-Label scheme, v1 v2 DKIM signatures offer operators of any size NO help at identifying bad actors exploiting the DKIM v1 v2 scheme. In addition, risks are not limited to just where a message has been sent as it offers NO MiTM protection, nor can it. This is one of the reasons TPA-Label was not limited to just using DKIM. Any expectation that this scheme works will certainly lead to unfair justifications for blocking mailing-lists. > You could do it only if some local secret sauce > determines that the intended recipient is an > MLM. But that amounts to either use of > heuristics (which can be gamed or come up with > the wrong answer) or some kind of local > registration process (which doesn't scale). The > temporary risk is still there, but the threat > surface is reduced because you inherently know a > little something about the recipient domain. Any large ESP should be fully capable of characterizing the entirety of their own outbound email traffic. Especially when DMARC offers them feedback clearly indicating any undesired results. The larger the scale, the more accurate characterization becomes. It is infinitely more problematic for their recipients however, but DKIM v1 v2 fails to share essential information. > You could do it only for domains your users have > declared contain MLMs with which they want to > interact, but there again is the registration > problem. There's also again the smaller threat > surface, but this time you're also inherently > trusting your users to make true declarations, > and also to declare when the MLM is no longer of > interest. That seems rather a burden. If too much of a burden for the DMARC domains, then consider how much greater this is for recipients who lack necessary feedback and sender relationships to ascertain the provenance of a third-party message. That said, we did alright protecting MLMs at a very large scale in an era before there was SPF or DKIM. > You could do it for all domains until they > misbehave and then stop adding v2 signatures for > them, but that can be gamed ad infinitum > (domains can be trivially created and discarded). When a DKIM v1 v2 message is abused, how would you determine who is actually responsible? (Hint. DKIM v1 v2 can't make this determination.) > All of those options for any at-scale operator > seem uncomfortable to me. At scale may mean regimenting hundreds of outbound servers. At these levels SQL won't work well. > The most obvious advantages to me of this method > over ATPS, TPA, and that family of proposals are > that (1) there's no additional DNS check > required because the third party endorsement is > contained within the message; and (2) it's quite > a bit easier to implement than the others, at > least for my project. No additional DNS checks??? DKIM depends heavily upon accessing DNS. Requiring recipients to process three rather than just one DKIM represents a significant increased DNS overhead. Imagine the mess when some domains then attempt to retract their DKIM keys. > Then again, if the at-scale operators that are > home to most of the problem (we meet again, Mr. > Pareto) are comfortable with using whatever > homegrown heuristics they use now with the > commensurate risks of v2 signatures, then this > approach appears to me to be quite viable. Hardly. Pareto's was attempting to model a small percentage of actors controlling a large proportion of commerce. Of course v1, v2 DKIM reinforces such efforts by breaking the backs of smaller operators. > Note that in fact the MLM doesn't have to check > anything, or know any of this is even going on. > Neither does its MTA even need to know what a v2 > signature is; it simply re-signs the message and > sends it along to the list subscribers. The > whole point here is to make sure the MLMs know > as little as possible so that all of them can be > silently accommodated. Not impacting third-party service providers is a great goal, but not protecting them from likely backlash is diabolical. > > > The double signing hack limits the > opportunity for trouble to mail > > systems that have a recent real message in > hand. While I can > > certainly imagine spammy scenarios, it's > hard to imagine ones that > > wouldn't be fairly easy to detect and shut > down. If nothing else, if > > the original sender gets spam reports > about double signed mail (there > > are FBLs that key on DKIM signature) it > can tell who's screwing > > around and stop putting conditional > signatures on mail to them. > > > True, the damage is limited to the lifetime of > the last v2 signature the author domain added. > I'm being cautious above because I'm sure author > domains would prefer to be proactive about such > threats rather than reactive to them. Large ESPs are openly belligerent when imposing restrictive DMARC policy against normal users. Perhaps they see mailing-list as competitors for their precious user's eyeballs. Deal with abuse by identifying and blocking its source. DKIM can't reliably do this when dealing with mailing lists. A "public" DMARC profile can easily dissipate harm by providing a safe less disruptive override by simply requiring source verification when carrying a message that contains their domain. If needed, a DMARC domain can become proactive at helping recipients identify good/bad actors by offering TPA-Label. The problem involved with multiple parties passing messages around does not end with just mailing-lists. Equally problematic are issues related to link distributors (ad servers). Again, abuse is best prevented in the most direct manner possible by blocking sources that originate malicious content. Often, risks are hidden by being combined with various active components within the infrastructure like browser plugins or web based services. TPA-Label can help establish a type of informal federation scheme to better manage abuse abatement. Regards, Douglas Otis --------------030106010804080406000205 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Dear Murray,
See comments inline:

On 5/21/15 8:24 AM, Murray S. Kucherawy wrote:
On Wed, May 20, 2015 at 10:32 AM, Terry Zink <tzink@exchange.microsoft.com> wrote:
A weak single signature makes it more vulnerable to a replay attack. With two signatures, the MTA --> MLM is protected (which is important) and the MLM --> MTA is also protected although there is a time window of vulnerability. However, if the first leg is protected then it's smaller risk if the second leg is less protected.

Thus, it's easier for the MLM (MTA --> MLM) to filter it properly the first time.

Right.  The trick is deciding under what circumstances to add both a v1 and v2 signature.
DKIM v1 v2 is not suitable for use with DMARC because it fails to offer those handling these messages protection.  Any v1 + v2 seen by any number of recipients can lead to any number of subsequent authorized messages for any large number of recipients from any large number of sources.  This DKIM scheme remains ineffective at offering protection with respect to MiTM threats.  This issue is significant for the likely use case of mailing-lists!  A major premise of this effort is that recipients ONLY pay attention to the From which this scheme preserves unchanged.  As Hector mentioned, this scheme is unable to authorize any service not using DKIM, however the TPA-Label scheme overcomes this significant limitation with respect to NORMAL email. In fact, it can avoid reliance on DKIM altogether when necessary.
You could do it always, which smaller operators would probably do.  It's terribly simple, and that covers your bases for interacting with MLMs a priori, but exposes you to a temporary risk when any of your users sends a message to any domain containing a bad actor.
Unlike the TPA-Label scheme, v1 v2 DKIM signatures offer operators of any size NO help at identifying bad actors exploiting the DKIM v1 v2 scheme.  In addition, risks are not limited to just where a message has been sent as it offers NO MiTM protection, nor can it.  This is one of the reasons TPA-Label was not limited to just using DKIM.  Any expectation that this scheme works will certainly lead to unfair justifications for blocking mailing-lists.
You could do it only if some local secret sauce determines that the intended recipient is an MLM.  But that amounts to either use of heuristics (which can be gamed or come up with the wrong answer) or some kind of local registration process (which doesn't scale).  The temporary risk is still there, but the threat surface is reduced because you inherently know a little something about the recipient domain.
Any large ESP should be fully capable of characterizing the entirety of their own outbound email traffic.  Especially when DMARC offers them feedback clearly indicating any undesired results.  The larger the scale, the more accurate characterization becomes. It is infinitely more problematic for their recipients however, but DKIM v1 v2 fails to share essential information.
You could do it only for domains your users have declared contain MLMs with which they want to interact, but there again is the registration problem.  There's also again the smaller threat surface, but this time you're also inherently trusting your users to make true declarations, and also to declare when the MLM is no longer of interest.  That seems rather a burden.
If too much of a burden for the DMARC domains, then consider how much greater this is for recipients who lack necessary feedback and sender relationships to ascertain the provenance of a third-party message.  That said, we did alright protecting MLMs at a very large scale in an era before there was SPF or DKIM. 
You could do it for all domains until they misbehave and then stop adding v2 signatures for them, but that can be gamed ad infinitum (domains can be trivially created and discarded).
When a DKIM v1 v2 message is abused, how would you determine who is actually responsible? (Hint.  DKIM v1 v2 can't make this determination.)
All of those options for any at-scale operator seem uncomfortable to me. 
At scale may mean regimenting hundreds of outbound servers.  At these levels SQL won't work well. 
The most obvious advantages to me of this method over ATPS, TPA, and that family of proposals are that (1) there's no additional DNS check required because the third party endorsement is contained within the message; and (2) it's quite a bit easier to implement than the others, at least for my project.
No additional DNS checks???  DKIM depends heavily upon accessing DNS.  Requiring recipients to process three rather than just one DKIM represents a significant increased DNS overhead.  Imagine the mess when some domains then attempt to retract their DKIM keys.
Then again, if the at-scale operators that are home to most of the problem (we meet again, Mr. Pareto) are comfortable with using whatever homegrown heuristics they use now with the commensurate risks of v2 signatures, then this approach appears to me to be quite viable.
Hardly.  Pareto's was attempting to model a small percentage of actors controlling a large proportion of commerce.

Of course v1, v2 DKIM reinforces such efforts by breaking the backs of smaller operators.
Note that in fact the MLM doesn't have to check anything, or know any of this is even going on.  Neither does its MTA even need to know what a v2 signature is; it simply re-signs the message and sends it along to the list subscribers.  The whole point here is to make sure the MLMs know as little as possible so that all of them can be silently accommodated.
Not impacting third-party service providers is a great goal, but not protecting them from likely backlash is diabolical.
> The double signing hack limits the opportunity for trouble to mail
> systems that have a recent real message in hand.  While I can
> certainly imagine spammy scenarios, it's hard to imagine ones that
> wouldn't be fairly easy to detect and shut down.  If nothing else, if
> the original sender gets spam reports about double signed mail (there
> are FBLs that key on DKIM signature) it can tell who's screwing
> around and stop putting conditional signatures on mail to them.

True, the damage is limited to the lifetime of the last v2 signature the author domain added.  I'm being cautious above because I'm sure author domains would prefer to be proactive about such threats rather than reactive to them.
Large ESPs are openly belligerent when imposing restrictive DMARC policy against normal users. Perhaps they see mailing-list as competitors for their precious user's eyeballs.

Deal with abuse by identifying and blocking its source.  DKIM can't reliably do this when dealing with mailing lists.  A "public" DMARC profile can easily dissipate harm by providing a safe less disruptive override by simply requiring source verification when carrying a message that contains their domain.  If needed, a DMARC domain can become proactive at helping recipients identify good/bad actors by offering TPA-Label.

The problem involved with multiple parties passing messages around does not end with just mailing-lists.  Equally problematic are issues related to link distributors (ad servers).  Again, abuse is best prevented in the most direct manner possible by blocking sources that originate malicious content.  Often, risks are hidden by being combined with various active components within the infrastructure like browser plugins or web based services. TPA-Label can help establish a type of informal federation scheme to better manage abuse abatement.

Regards,
Douglas Otis

--------------030106010804080406000205-- From nobody Thu May 21 14:01:04 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320441A9030 for ; Thu, 21 May 2015 14:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fpblt7PBFk7O for ; Thu, 21 May 2015 14:01:02 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ED351A902C for ; Thu, 21 May 2015 14:01:01 -0700 (PDT) Received: (qmail 19585 invoked from network); 21 May 2015 21:01:07 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 21 May 2015 21:01:07 -0000 Date: 21 May 2015 21:00:38 -0000 Message-ID: <20150521210038.71402.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: tzink@exchange.microsoft.com Subject: Re: [dmarc-ietf] Weaker single author signature X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 21:01:03 -0000 >On the inbound, I’m not sure whether or not we’d verify the DKIM v2 *or* >simply suppress the DMARC check and apply all of our other antispam filtering, >and update the MLM’s reputation accordingly. Well, gee, you can do that now. We hope you do, since that will also enable list mail from people with addresses at Yahoo and AOL. With double signing, you have the ability to distinguish between plain old spammers, and spammers who are screwing around with forwarded mail. I think that's a useful difference, since it is my impression that the set of malicious mutating forwarders is pretty small because it's a lot of hassle and not a lot of reward. R's, John From nobody Thu May 21 19:50:56 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD291A8FD2 for ; Thu, 21 May 2015 19:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.299 X-Spam-Level: *** X-Spam-Status: No, score=3.299 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTc0wm7sVstE for ; Thu, 21 May 2015 19:50:53 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id D341A1A8F51 for ; Thu, 21 May 2015 19:50:52 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 4DE1D1C397F; Fri, 22 May 2015 11:50:51 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 36B581A3398; Fri, 22 May 2015 11:50:51 +0900 (JST) From: "Stephen J. Turnbull" To: "John Levine" In-Reply-To: <20150521210038.71402.qmail@ary.lan> References: <20150521210038.71402.qmail@ary.lan> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 22 May 2015 11:50:51 +0900 Message-ID: <87mw0xxr3o.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org, tzink@exchange.microsoft.com Subject: Re: [dmarc-ietf] Weaker single author signature X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 02:50:55 -0000 John Levine writes: > With double signing, you have the ability to distinguish between plain > old spammers, and spammers who are screwing around with forwarded > mail. I think that's a useful difference, since it is my impression > that the set of malicious mutating forwarders is pretty small because > it's a lot of hassle and not a lot of reward. Unless you have the user's address book to hand, and can thus target your shot with a significantly higher percentage of "successes" than random spamming. That's a significant marketing advantage if you're a contract spammer (rather than spamming for your own account), I would suppose. From nobody Thu May 21 20:08:17 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066251A903B for ; Thu, 21 May 2015 20:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.899 X-Spam-Level: *** X-Spam-Status: No, score=3.899 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buKtpRW3ECFV for ; Thu, 21 May 2015 20:08:13 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id AC7B91A8FD2 for ; Thu, 21 May 2015 20:08:13 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 86DB21C397F; Fri, 22 May 2015 12:08:12 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 6DB641A3398; Fri, 22 May 2015 12:08:12 +0900 (JST) From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: <20150520032528.63043.qmail@ary.lan> <555C75AC.3060502@isdg.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 22 May 2015 12:08:12 +0900 Message-ID: <87lhghxqar.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: "dmarc@ietf.org" , Hector Santos , Terry Zink Subject: Re: [dmarc-ietf] Weaker single author signature X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 03:08:15 -0000 Murray S. Kucherawy writes: > All of those options for any at-scale operator seem uncomfortable to me. > The most obvious advantages to me of this method over ATPS, TPA, and that > family of proposals are that (1) there's no additional DNS check required > because the third party endorsement is contained within the message; and > (2) it's quite a bit easier to implement than the others, at least for my > project. It allows per-message, per-remailer authorization, which cannot scale for a DNS based protocol; they have to restrict themselves to authorizing remailing by whole domains for a period of time. This means that to successfully phish a recipient, attackers have to first phish the apparent sender. This is a *huge* reduction in attack surface compared to that available to the address book spammers pre-p=reject. Or, of course, they can suborn a popular Mediator (or try to instigate one themselves). This is still a significant reduction in attack surface, and can be responded to surgically by denying that Mediator v2 signatures. If that turns into whack-a-mole as you fear (and I admit that's a legitimate worry), *then* they have the option of turning off all v2 signatures, or cranking the relibility threshold way up. This possibility of flexible response seems to me to be an important advantage of the resigning method a priori. Of course it can only be proven in use. > True, the damage is limited to the lifetime of the last v2 signature the > author domain added. I'm being cautious above because I'm sure author > domains would prefer to be proactive about such threats rather than > reactive to them. I'm sure they'd also like to be proactive about providing reliable delivery from their users to whomever the user wants to send to, which they currently have no way to do (except to reverse course on p=reject, which apparently isn't going to happen). That is, AFAICS, these signatures currently are only useful to p=reject ADMDs. From nobody Fri May 22 05:54:20 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B243D1AD160 for ; Fri, 22 May 2015 05:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.702 X-Spam-Level: X-Spam-Status: No, score=-98.702 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_37=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8xHUjWGWGtd for ; Fri, 22 May 2015 05:54:16 -0700 (PDT) Received: from listserv.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6946B1AD0D2 for ; Fri, 22 May 2015 05:54:15 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1986; t=1432299246; atps=isdg.net; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=ZhFdrBHnOczR51hgJlYwGICC/QY=; b=URBsvOC/mbNuyfNEy0a/FbMGRj7IA8OkfkcottpLxrxCpfUgaO6q0KLX8ErH3w 3eQkeREZ2fw4DvaojEc1p1bNp3zOjVIfk82YCwh5IcpxkBv6ZZTT+zY5eQ61W0U7 X2GzJ+V+wbiXX5jNaVt5Nh1/ng9cbA180mbEeMm8i5Vdg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 22 May 2015 08:54:06 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1714256730.2431.3940; Fri, 22 May 2015 08:54:05 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1986; t=1432298946; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=J8DF6rR 2NpeI4ReHllXPcMAcBmocb8Y2bKqZYBIaPUA=; b=uvqSVsbeQVBr6gK/sEVxiOd z/cjFTW+lBqnWOafrORcVLTHuH1hxi8X2kPv3I5UiFxycs+mgE9i2wZXZBCozBNP 2ZaaGOywZ/0/aghlAQToNxZER6T4Nhvs33HfZWr326/OMiETS59hFnFT9Fy3WW72 AKuwRHieuXASrTTlHB5M= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 22 May 2015 08:49:06 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 306514958.9.23328; Fri, 22 May 2015 08:49:05 -0400 Message-ID: <555F26EC.7000406@isdg.net> Date: Fri, 22 May 2015 08:54:04 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dmarc@ietf.org References: <20150521210038.71402.qmail@ary.lan> In-Reply-To: <20150521210038.71402.qmail@ary.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: tzink@exchange.microsoft.com Subject: Re: [dmarc-ietf] Weaker single author signature X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 12:54:18 -0000 On 5/21/2015 5:00 PM, John Levine wrote: > > With double signing, you have the ability to distinguish between plain > old spammers, and spammers who are screwing around with forwarded > mail. That doesn't stop it from happening and targeting users that don't have the ability, capability installed, hasn't updated, etc, to do the "intelligence" you expect. At the end of the day, this is a weaker DKIM derivative which promotes the usage of weak V1 for those who can't change yet and now even weaker new DKIM V2 messages. You can be justify/rationalize it anyway you like, inevitably, DKIM could now be leveraged and exploited. Its weaker. It certainly put more work on verifiers for what you believe is a narrow problem. That said, overall, I am satisfy that we finally got traction on a DKIM Policy framework for a 3rd party Resigner Authorization Protocol or RAP. This is another RAP song, not as secured using DNS query method with strong signatures, but nonetheless, a method to finally get this long time project completed. The registration issue is still required if any entity wishes to minimize the potential exploits. I don't plan to abandon the ATPSrev4 more secured method. What I plan do to is use the ATPS DNS records as a way to signal a double sign. If the there a ATPS record for domain mlm.example at the domain author.example zone, and the mail is targeted to mlm.example then I will create a v2 signature preparing for the mlm.example signature. One registration for ATPS and V2 methods. Learning how to add "registration" automatically is still in progress. I doubt a manual process will be skipped, but that can be done via SMTP reply codes or by bounces returned back to the list bounce manager. It can be done via an existing "too many bounces" notification logic preparing to unsubscribe if the user doesn't respond in time where it can do a restrictive domain check and report this to the user. Thanks -- HLS From nobody Fri May 22 08:14:51 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A851A000D for ; Fri, 22 May 2015 08:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sidL5V77jaMj for ; Fri, 22 May 2015 08:14:48 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F7081A0040 for ; Fri, 22 May 2015 08:14:41 -0700 (PDT) Received: (qmail 65231 invoked from network); 22 May 2015 15:14:46 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 22 May 2015 15:14:46 -0000 Date: 22 May 2015 15:14:17 -0000 Message-ID: <20150522151417.74918.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <87mw0xxr3o.fsf@uwakimon.sk.tsukuba.ac.jp> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: stephen@xemacs.org Subject: Re: [dmarc-ietf] Weaker single author signature X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 15:14:49 -0000 > > With double signing, you have the ability to distinguish between plain > > old spammers, and spammers who are screwing around with forwarded > > mail. I think that's a useful difference, since it is my impression > > that the set of malicious mutating forwarders is pretty small because > > it's a lot of hassle and not a lot of reward. > >Unless you have the user's address book to hand, and can thus target >your shot with a significantly higher percentage of "successes" than >random spamming. That's a significant marketing advantage if you're a >contract spammer (rather than spamming for your own account), I would >suppose. For this to work, you somehow need to persuade the real system to send you a signed message from the address you're planning to abuse. That seems like an implausible amount of work. If you can get the real system to send you a message to re-sign, why not just have it send the spam? R's, John From nobody Fri May 22 10:04:30 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A461A1BA3 for ; Fri, 22 May 2015 10:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.299 X-Spam-Level: *** X-Spam-Status: No, score=3.299 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmmvGxs9Wa9n for ; Fri, 22 May 2015 10:04:26 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 698FB1A7035 for ; Fri, 22 May 2015 10:04:03 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 9BDF01C3995; Sat, 23 May 2015 02:04:02 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 364021A3398; Sat, 23 May 2015 02:04:02 +0900 (JST) From: "Stephen J. Turnbull" To: "John Levine" In-Reply-To: <20150522151417.74918.qmail@ary.lan> References: <87mw0xxr3o.fsf@uwakimon.sk.tsukuba.ac.jp> <20150522151417.74918.qmail@ary.lan> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 23 May 2015 02:04:01 +0900 Message-ID: <87pp5sh7cu.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Weaker single author signature X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 17:04:29 -0000 John Levine writes: > For this to work, you somehow need to persuade the real system to send > you a signed message from the address you're planning to abuse. That > seems like an implausible amount of work. I agree it sounds like a lot of work. But I don't see why you would bother attacking the resigning system at all, if you're not trying to exploit acquaintanceship relations. Just send apparently from a sibling domain. > If you can get the real system to send you a message to re-sign, > why not just have it send the spam? Because you can't get the real system to send spam, but you can get a user with a mailbox on that system to get it to send you a message to resign. From nobody Fri May 22 10:17:03 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4580F1A870F for ; Fri, 22 May 2015 10:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.563 X-Spam-Level: * X-Spam-Status: No, score=1.563 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z_fXZmQrSwqC for ; Fri, 22 May 2015 10:17:01 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6DF31A870D for ; Fri, 22 May 2015 10:17:00 -0700 (PDT) Received: (qmail 88804 invoked from network); 22 May 2015 17:17:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=15ae3.555f6492.k1505; bh=injmwteIiNR3P9xgkwozxAiUOWW5T/LtMtn7xQMVtFs=; b=C8Rusq2GhmTJFNIXOH2Os/T7NFFtmLy03YuFkqYbfO79J1SwPDQ/WPvzxw8KHG2vhPshM5hPJTxAjdJuYbj8qTutso452EeNNqjHpySmR75ml0rZnWUgTOE4Cje3LGCH46MA6iIhTnAFQOD1gl1xjejakp9mrQq2WrM5OWobNRQronoYvTnMhqVodrgNPpGA3QvxVPBv6mhuHUa1X64sN3jtpKFZ99s/05Pu6q3bJ8W1st1/cEln+VDsjbs00mQW DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=15ae3.555f6492.k1505; bh=injmwteIiNR3P9xgkwozxAiUOWW5T/LtMtn7xQMVtFs=; b=ydHPWUL89HM3V22EHfN0XsA28V3xCa6PhLMRoUKvFIFdRvIztZxHOmYfUvNH7adrUK1WfvulgAd8/7KjPR1aRGpNmXWaGBeUnjKmFhrO/HADSxvuWyzgiirWHd3W0tjUS7AshzaYbuIft2JbrDAvWDU1IPrWOl4dhbBvfnUUGG8cuopb3W4vr6UD/pEBi4JGusmQingzt2JlGl9s29qa0nOB/ftMSkVRLDYShLz7Tdj3z101cRvPaPeVCbjIAqEn Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 22 May 2015 17:17:06 -0000 Date: 22 May 2015 13:16:59 -0400 Message-ID: From: "John R Levine" To: "Stephen J. Turnbull" In-Reply-To: <87pp5sh7cu.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87mw0xxr3o.fsf@uwakimon.sk.tsukuba.ac.jp> <20150522151417.74918.qmail@ary.lan> <87pp5sh7cu.fsf@uwakimon.sk.tsukuba.ac.jp> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Weaker single author signature X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 17:17:02 -0000 > > For this to work, you somehow need to persuade the real system to send > > you a signed message from the address you're planning to abuse. That > > seems like an implausible amount of work. > > I agree it sounds like a lot of work. But I don't see why you would > bother attacking the resigning system at all, if you're not trying to > exploit acquaintanceship relations. Just send apparently from a > sibling domain. That's just what they do, or they send from random addresses, expecting (usually correctly) that the recipient will only see the From: comment and not the bogus address. A couple of the people on my church's mailing list got their AOL or Yahoo address book stolen, and the list software catches spam like that all the time, since if course it looks at the address. > > If you can get the real system to send you a message to re-sign, > > why not just have it send the spam? > > Because you can't get the real system to send spam, but you can get a > user with a mailbox on that system to get it to send you a message to > resign. Right, and now you can do one teensy spam run until the weak signature expires, or the re-sending system's reputation drops to the point where nobody accepts its mail, or adaptive systems like Google's recognize the person's address as a reliable spam sign. If you can't use a spamming system to send a million messages a day and expect a fair number of them to be delivered, it's not interesting. Like I keep saying, while you can imagine hypothetical spam scenarios, it's hard to think of one that would be effective enough to be worth the effort, particularly compared to just using a fake address with the person's name as the From comment. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Fri May 22 15:44:44 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D731A894F for ; Fri, 22 May 2015 15:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFjxzaCj-65e for ; Fri, 22 May 2015 15:44:42 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id 5944F1A1AB2 for ; Fri, 22 May 2015 15:44:42 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id E7FCE563DD4; Fri, 22 May 2015 17:44:41 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id D1322A0437; Fri, 22 May 2015 17:44:41 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rqfXvkXhQR1; Fri, 22 May 2015 17:44:41 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 6E7F4A0439; Fri, 22 May 2015 17:44:41 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 6E7F4A0439 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1432334681; bh=qXnCrsmkbZaNOcrXyCMtU7Ru8F2K8XGLSS8Mu/UcZms=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=UTHAbzFTZS/XAu28rKhEwV52sYqGgjxTfn5+9dODN2xCiNgZcINULJtRpMBYhg9vB e1hxrJg1Xp7U52goC59emEpaeCuFYjDfnYLXnfAVwjbw4n2iIvHkoHhrGRHk4QYnMV yccQmYVCsw7vdikQTp7bDdBzR4ktGmg2YA7kqBdo= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 2E4F5A0438; Fri, 22 May 2015 17:44:41 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Z6PibYY1V6WK; Fri, 22 May 2015 17:44:41 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id EB918A0437; Fri, 22 May 2015 17:44:40 -0500 (CDT) Date: Fri, 22 May 2015 17:44:40 -0500 (CDT) From: Franck Martin To: John Levine Message-ID: <65726159.97984.1432334680529.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20150509023355.56318.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF38 (Mac)/8.0.5_GA_5839) Thread-Topic: draft-ietf-dmarc-interoperability-02.txt Thread-Index: vPzN5oGMp93vhOmk4ywgrooxzJaNCw== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] draft-ietf-dmarc-interoperability-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 22:44:44 -0000 ----- Original Message ----- > From: "John Levine" > To: dmarc@ietf.org > Cc: franck@peachymango.org > Sent: Friday, May 8, 2015 7:33:55 PM > Subject: Re: [dmarc-ietf] draft-ietf-dmarc-interoperability-02.txt > > In article <1552316227.113529.1431130088299.JavaMail.zimbra@peachymango.org> > you write: > >I went over the emails of this week, did not find any new comment/update for > >the above document. > > Do you know when you'll be posting a new draft? There's a fair amount of > stuff to fix. > Please submit "stuff" that needs to be fixed From nobody Fri May 22 16:00:27 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA8A1A8988 for ; Fri, 22 May 2015 16:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sv8BQdItRsD9 for ; Fri, 22 May 2015 16:00:24 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id AD8FA1A8983 for ; Fri, 22 May 2015 16:00:24 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 892C4563DFB; Fri, 22 May 2015 18:00:23 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 6E738A029E; Fri, 22 May 2015 18:00:23 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8taAQ2pojAt; Fri, 22 May 2015 18:00:23 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 291DFA0437; Fri, 22 May 2015 18:00:23 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 291DFA0437 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1432335623; bh=XJ9yOzS0eIJ4p9DTulw5pOLpKqkDI7j211CoSQisI9I=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=D3fusA34f6ZQ5/dxIXLYxLxrXtGE7m9HKwoACzEnaHR804aKcZdV/zBD53+eaMkWH VJ/snLiTytVvzn0NvTTxjOosXNr2maSefS4z7hE1XmKJ+x0L9Eubzeb/EwAcynocma pmuhfV8ZrYYfJFb9cW/x0QnACCBb5GyFoRYc31Po= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id F3E4AA0411; Fri, 22 May 2015 18:00:22 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id T3DLqo0tnmvf; Fri, 22 May 2015 18:00:22 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id C42D5A029E; Fri, 22 May 2015 18:00:22 -0500 (CDT) Date: Fri, 22 May 2015 18:00:22 -0500 (CDT) From: Franck Martin To: "Stephen J. Turnbull" Message-ID: <165424531.98201.1432335622656.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <554BC30F.1020107@isdg.net> <55529DFB.3010704@gmail.com> <87a8x92q7g.fsf@uwakimon.sk.tsukuba.ac.jp> <5553C44C.7040307@gmail.com> <87vbfv2480.fsf@uwakimon.sk.tsukuba.ac.jp> <87mw171trj.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF38 (Mac)/8.0.5_GA_5839) Thread-Topic: DMARC ATPS Interop Note Thread-Index: y/23hofYEelvdRFhdLik2CFj5JYG7w== Archived-At: Cc: dmarc@ietf.org, "Murray S. Kucherawy" , Douglas Otis Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 23:00:26 -0000 ----- Original Message ----- > From: "Stephen J. Turnbull" > To: "Murray S. Kucherawy" > Cc: dmarc@ietf.org, "Douglas Otis" > Sent: Thursday, May 14, 2015 12:51:44 AM > Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note > > Murray S. Kucherawy writes: > ). > > (3) I would really like to see some provision for reporting to mailbox > users when their mail is being discarded due to publication of > p=reject by their mailbox providers, especially in cases where a > Mediator is willing to put its reputation on the line by signing > the forwarded message. > > Note that this would only be a burden to abusers of p=reject, as > in the case of transactional mail the responsible author is the > corporate entity, not the employee. So no further report would be > appropriate in that case, as the organization is already receiving > the DMARC reports. > The email is bounced, not discarded. The mailbox user knows about it. Unfortunately, bounces are so ugly that few people can successfully read them. From nobody Fri May 22 16:16:52 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753E51A0058 for ; Fri, 22 May 2015 16:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9Z2dtD-WxYS for ; Fri, 22 May 2015 16:16:50 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FB7C1A0047 for ; Fri, 22 May 2015 16:16:50 -0700 (PDT) Received: (qmail 30201 invoked from network); 22 May 2015 23:16:55 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 22 May 2015 23:16:55 -0000 Date: 22 May 2015 23:16:26 -0000 Message-ID: <20150522231626.76111.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <65726159.97984.1432334680529.JavaMail.zimbra@peachymango.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: franck@peachymango.org Subject: Re: [dmarc-ietf] draft-ietf-dmarc-interoperability-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 23:16:51 -0000 >Please submit "stuff" that needs to be fixed The worst problem is still section 3.1.2.3 which needs to be deleted, since most of what it says is wrong, and what little isn't wrong is irrelevant. RFC 6854 is not about EAI, since an ASCII MUA can create mail with an empty group From: as easily as an EAI MUA. The assertion that RFC 6854 allows empty groups "during the transition period to SMTPUTF8" is false. Empty group syntax has nothing to do with DMARC since there is no domain on the From: line to check. From a DMARC point of view, there is no difference between a From: with an empty group and one with an address in a domain that publishes no DMARC record. This sentence is completely false. EAI MTAs never downgrade mail in transit: If an EAI/SMTPUTF8-aware MTA needs to transmit a message to a non- aware MTA, the EAI/SMTPUTF8-aware system may transform the RFC5322.From header field of the message to include group syntax to allow the non-aware MTA to receive the email. Section 4.1.2.3 is equally wrong for the same reasons and also needs to go. Section 4.1.3.1 doesn't mention rewriting the From: address to a valid forwarding address in a domain for which the list can sign. It's not just me doing it, LISTSERV can do that, it's widely implemented. Take out .invalid, nobody does that because (as I discovered and you mention) many spam filters dislike From: addresses with domains that don't resolve. R's, John From nobody Fri May 22 16:17:58 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2871A0122 for ; Fri, 22 May 2015 16:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.863 X-Spam-Level: ** X-Spam-Status: No, score=2.863 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRWG8-rDD5rv for ; Fri, 22 May 2015 16:17:56 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DD851A0047 for ; Fri, 22 May 2015 16:17:56 -0700 (PDT) Received: (qmail 30383 invoked from network); 22 May 2015 23:18:02 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 22 May 2015 23:18:02 -0000 Date: 22 May 2015 23:17:33 -0000 Message-ID: <20150522231733.76132.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <165424531.98201.1432335622656.JavaMail.zimbra@peachymango.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: franck@peachymango.org Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 23:17:57 -0000 >> (3) I would really like to see some provision for reporting to mailbox >> users when their mail is being discarded due to publication of >> p=reject by their mailbox providers, especially in cases where a >> Mediator is willing to put its reputation on the line by signing >> the forwarded message. ... >The email is bounced, not discarded. The mailbox user knows about it. >Unfortunately, bounces are so ugly that few people can successfully read them. Good point. I would like to see some provision for reporting to mailbox users when their mail is effectively discarded due to p=quarantine. R's, John From nobody Fri May 22 16:37:49 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91D21A8880; Fri, 22 May 2015 16:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98np8aC-PdhM; Fri, 22 May 2015 16:35:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DDDB41A87C9; Fri, 22 May 2015 16:35:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150522233550.6375.68792.idtracker@ietfa.amsl.com> Date: Fri, 22 May 2015 16:35:50 -0700 Archived-At: X-Mailman-Approved-At: Fri, 22 May 2015 16:37:48 -0700 Cc: dmarc@ietf.org Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-interoperability-03.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 23:35:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance Working Group of the IETF. Title : Interoperability Issues Between DMARC and Indirect Email Flows Authors : Franck Martin Eliot Lear Tim Draegen Elizabeth Zwicky Filename : draft-ietf-dmarc-interoperability-03.txt Pages : 21 Date : 2015-05-22 Abstract: DMARC introduces a mechanism for expressing domain-level policies and preferences for email message validation, disposition, and reporting. The DMARC mechanism can encounter interoperability issues when messages do not flow directly from the author's administrative domain to the final recipients. Collectively these email flows are referred to as indirect email flows. This document describes interoperability issues between DMARC and indirect email flows. Possible methods for addressing interoperability issues are presented. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-interoperability-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 22 16:40:28 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4FF61A8984 for ; Fri, 22 May 2015 16:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xv7bc_okjOa9 for ; Fri, 22 May 2015 16:40:25 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id C22C41A8945 for ; Fri, 22 May 2015 16:40:25 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 6CAA3563E15; Fri, 22 May 2015 18:40:25 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 65D8960288; Fri, 22 May 2015 18:40:25 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsEnZPifwV-Z; Fri, 22 May 2015 18:40:25 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 3A3256028F; Fri, 22 May 2015 18:40:25 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 3A3256028F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1432338025; bh=6dVNhpQaTHOBq3uR3nSGowGSV14z/cltJWKpL4iFmXs=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=gHL40/fZ0nUeCjv0os4BkrGH8n9u+vBdJSb5gQtVMsbdpo9rUqqyeIlIgINxtcZRS pym+FO8Vj9JEElxEzABGNrrxAgWksDQXImEDTRWqRHqt9rNI9DibD1anuEtrayPunc QCzmLgjMDTHtFdDf09YgidTHnxcXnrCM73CeKbGE= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 2B5C16028E; Fri, 22 May 2015 18:40:25 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 77aBU5iArR6B; Fri, 22 May 2015 18:40:25 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 1284460288; Fri, 22 May 2015 18:40:25 -0500 (CDT) Date: Fri, 22 May 2015 18:40:24 -0500 (CDT) From: Franck Martin To: John Levine Message-ID: <2089482611.98369.1432338024897.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20150522231626.76111.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF38 (Mac)/8.0.5_GA_5839) Thread-Topic: draft-ietf-dmarc-interoperability-02.txt Thread-Index: kJMnRypFWtkFEckpy/wvx+/YyjpiTw== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] draft-ietf-dmarc-interoperability-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 23:40:27 -0000 ----- Original Message ----- > From: "John Levine" > To: dmarc@ietf.org > Cc: franck@peachymango.org > Sent: Friday, May 22, 2015 4:16:26 PM > Subject: Re: [dmarc-ietf] draft-ietf-dmarc-interoperability-02.txt > > >Please submit "stuff" that needs to be fixed > > The worst problem is still section 3.1.2.3 which needs to be deleted, > since most of what it says is wrong, and what little isn't wrong is > irrelevant. > I rewrote some of it, see next email... I'm mulling indeed about deleting the whole EAI stuff, because it is about tangent policies around DMARC and not an interoperability issue per se. But I'm stubborn, so I leave it for one last round, if only to get someone(you) to comment on the draft :P Pass that, I don't see much more comments, so WG Chair should move the document close to last call? I see the mailing list is focused on finding future solutions, not in explaining current operational solutions. From nobody Fri May 22 16:47:06 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B491A8848 for ; Fri, 22 May 2015 16:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_110=0.6, J_CHICKENPOX_16=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJSNqdvceDcG for ; Fri, 22 May 2015 16:47:03 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id CAF161A87C8 for ; Fri, 22 May 2015 16:47:03 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 79464563D03; Fri, 22 May 2015 18:47:03 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 5E9D9A043D; Fri, 22 May 2015 18:47:03 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ar-PeFGPFOir; Fri, 22 May 2015 18:47:03 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 16523A043C; Fri, 22 May 2015 18:47:03 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-1.01.com 16523A043C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1432338423; bh=WYRU2qMesgogDx15EP/YiJidrh5mgzNFdt/XrAsFIlo=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=BSysz3SqNOiZn2kuMPkPhFiaQOgB68FXnjPlPSrFo5wOioXr2cR6Bz/FN8ItSmyD7 MOY7K2N1aSxodYuI3cuhgX1863Ao+lfXbDj+IcSrRuNhxaQHK5EKcSqlq1rKtGldZS QT78k9ez9f0M0+4T4we72xz8NXhs3CP7i1GuDPS0= Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 3D259A043D; Fri, 22 May 2015 18:47:01 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vflGBbXe8Xtd; Fri, 22 May 2015 18:47:01 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-1.01.com (Postfix) with ESMTP id 19243A043C; Fri, 22 May 2015 18:47:01 -0500 (CDT) Date: Fri, 22 May 2015 18:47:00 -0500 (CDT) From: Franck Martin To: John Levine Message-ID: <482703147.98402.1432338420968.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20150522231733.76132.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF38 (Mac)/8.0.5_GA_5839) Thread-Topic: DMARC ATPS Interop Note Thread-Index: +EOHA3eaGVswNT2I3ZPTwbEp3+f/fA== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 23:47:04 -0000 ----- Original Message ----- > From: "John Levine" > To: dmarc@ietf.org > Cc: franck@peachymango.org > Sent: Friday, May 22, 2015 4:17:33 PM > Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note > > >> (3) I would really like to see some provision for reporting to mailbox > >> users when their mail is being discarded due to publication of > >> p=reject by their mailbox providers, especially in cases where a > >> Mediator is willing to put its reputation on the line by signing > >> the forwarded message. ... > > >The email is bounced, not discarded. The mailbox user knows about it. > >Unfortunately, bounces are so ugly that few people can successfully read > >them. > > Good point. I would like to see some provision for reporting to mailbox > users when their mail is effectively discarded due to p=quarantine. > With p=quarantine commonly either the message is marked as [SPAM] in the subject or is delivered to the spam folder. The message is not discarded either, so the mailbox users knows about it because people tend to write back: "why your message was marked as spam?" This is of course if the message is not spammy or contain a virus, or nasty stuff like that, where the anti-spam filter may discard the message. At no point in the spec DMARC tells to "discard the message". From nobody Fri May 22 17:07:01 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626661A89B8 for ; Fri, 22 May 2015 17:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwnDYImpO5B2 for ; Fri, 22 May 2015 17:06:59 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 778AE1A89AF for ; Fri, 22 May 2015 17:06:59 -0700 (PDT) Received: (qmail 36226 invoked from network); 23 May 2015 00:07:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=8d81.555fc4a9.k1505; bh=xFcp/RwxcYLfRcq7bg900Sh3cQmmxVnpnH+5zcDDnVI=; b=je2GHug7UrNmSdN1CDf5WNDVT5NvRX53/8FibEr1Dhsc48ubkpeQPH5VWfHBHqueEb+LsFmr1zhTJieqdHyqEUc1nP1d4Ua7YIl4gJramKgYqY2FZfDW572tMMyaWQP52dP/KBgl1lhc1J1s6ovaJd1b2/fbWHLl19csxTIowsbZ8k6pU+Vs5aUCrBW1xcsTdXC4wng3IKJqEkVNKBy7kat58QJ6wKIr6g3OrNMcpMfh5T+tZXvAfQo445HgWkBO DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=8d81.555fc4a9.k1505; bh=xFcp/RwxcYLfRcq7bg900Sh3cQmmxVnpnH+5zcDDnVI=; b=lF9QJIXZKFf0bkhHWpJ2/ykFVrBWDH+sUl7BAciAx8sSm6VHIlw8ioX93ffGuZ09pR2WUmxyY5Afq5EUf93G/zKbRlSQLHTdU0v8YB3fM1PXuMAwMwOANqeN4LpCadeZUYIhxHWI/+WBwqezGdCxp7OjkbKXivRXzrv6TkGc7xSHfxlEw9Tl0MGS/2kReYfMsC6D9TFSEpZr9PiMuoCJYII20iW104wGuB8AIwRNiBKnPuNwegNlt/Y+tsx1EonZ Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 23 May 2015 00:07:05 -0000 Date: 22 May 2015 20:06:57 -0400 Message-ID: From: "John R Levine" To: "Franck Martin" In-Reply-To: <2089482611.98369.1432338024897.JavaMail.zimbra@peachymango.org> References: <20150522231626.76111.qmail@ary.lan> <2089482611.98369.1432338024897.JavaMail.zimbra@peachymango.org> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] draft-ietf-dmarc-interoperability-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 00:07:00 -0000 > I'm mulling indeed about deleting the whole EAI stuff, because it is about tangent policies around DMARC and not an interoperability issue per se. Really, it's just wrong. Delete it, please. > I see the mailing list is focused on finding future solutions, not in > explaining current operational solutions. OK, then how about taking out all of section 4? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Fri May 22 17:08:06 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B20391A1A12 for ; Fri, 22 May 2015 17:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDEV76748FS8 for ; Fri, 22 May 2015 17:08:05 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC0C61A0095 for ; Fri, 22 May 2015 17:08:04 -0700 (PDT) Received: (qmail 36356 invoked from network); 23 May 2015 00:08:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=8e02.555fc4ea.k1505; bh=iFl98ZbmWnhh+lUieXRaMsrfK/qnCMvNO5rxKzYm8i8=; b=M1/WejL/is22rXq9981kJjAU0wi4jc00obE95ZNqz1oid8iDKLigaiKp0Apj4QPhhc0yWmahRO5a0QANzzATazmM48jeWQZ8X7o/JJDv/lLkJfgaoHdpm8/ug/EnHX4kHMLuYwpyMxwUBUTXNr3wJrv/54co2w8OdJjg+qz0RBOT24eOhphv76iZbixWg9lebdVgkkbvQUvQZHerAijHt1Ghw5lcyulL7G7TmXvO+qltuKEYj4EqisfwAEM9FmXr DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=8e02.555fc4ea.k1505; bh=iFl98ZbmWnhh+lUieXRaMsrfK/qnCMvNO5rxKzYm8i8=; b=xhFj0t56xbPK0ats0CcYNJ9JkAPfjbZI05ghQvGaoUExDGcP4U3B0dUOs2JT8YEHg/8mMmrWNf3tDMOZe9mdbS3ClQ+tbgf6v6Vsw+il9DXybOiCNzph/7JcXIdXTnDQbrELGyl7mPYxRKqQN9IndZKd6Bt+uxMmHcZVWZ2ChOdhjzL72vUfJ+4jX0zsEg46/YhgVq0+9qjVbF9BcDgsyv0tHsOIDbGBD0Lw4M9Oxx1VTCQiwXkh13PB+bkKgLny Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 23 May 2015 00:08:10 -0000 Date: 22 May 2015 20:08:03 -0400 Message-ID: From: "John R Levine" To: "Franck Martin" In-Reply-To: <482703147.98402.1432338420968.JavaMail.zimbra@peachymango.org> References: <20150522231733.76132.qmail@ary.lan> <482703147.98402.1432338420968.JavaMail.zimbra@peachymango.org> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 00:08:05 -0000 > This is of course if the message is not spammy or contain a virus, or nasty stuff like that, where the anti-spam filter may discard the message. Except of course for all of the people who don't look at all the crud in their spam folder. They're not likely to write about messages they don't see. If it's in the spam folder, for a whole lot of people it might as well be discarded. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Fri May 22 17:26:29 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D591F1A70E1 for ; Fri, 22 May 2015 17:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ac4WfZUV5PPa for ; Fri, 22 May 2015 17:26:26 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id AED981A015F for ; Fri, 22 May 2015 17:26:26 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 4D101563DF6; Fri, 22 May 2015 19:26:26 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 465F66028E; Fri, 22 May 2015 19:26:26 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgj8SIh90AHw; Fri, 22 May 2015 19:26:26 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 144AB60290; Fri, 22 May 2015 19:26:26 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com 144AB60290 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1432340786; bh=ryr18hN76Mif3+HKDm+wQH50BNEABmJGbVD9V531o9Y=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=hOeZDxtBeu3kpWxt4bHphydskgTwzKVo3+Jp5XLqgVuru3HD4ziD/vFaXBgPLmEw3 i+Rv3qJ+4uZqOIfM3H77eD6W8KiJ1tPNWnmuR5+FGjwXEeBOULYaJDEkGgyDV3G3e/ b98fAMtlXBrNr9eRf4HuHn5zCiKQu10a8Xg4deaI= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 066986028F; Fri, 22 May 2015 19:26:26 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XUl_bS3kOkbR; Fri, 22 May 2015 19:26:25 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id E2F4C6028E; Fri, 22 May 2015 19:26:25 -0500 (CDT) Date: Fri, 22 May 2015 19:26:25 -0500 (CDT) From: Franck Martin To: John R Levine Message-ID: <24588841.98571.1432340785763.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20150522231626.76111.qmail@ary.lan> <2089482611.98369.1432338024897.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF38 (Mac)/8.0.5_GA_5839) Thread-Topic: draft-ietf-dmarc-interoperability-02.txt Thread-Index: 0O48P9Yw6Z0mZPJwIXkdf2LavJe3xA== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] draft-ietf-dmarc-interoperability-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 00:26:28 -0000 ----- Original Message ----- > From: "John R Levine" > To: "Franck Martin" > Cc: dmarc@ietf.org > Sent: Friday, May 22, 2015 5:06:57 PM > Subject: Re: [dmarc-ietf] draft-ietf-dmarc-interoperability-02.txt > > > I'm mulling indeed about deleting the whole EAI stuff, because it is about > > tangent policies around DMARC and not an interoperability issue per se. > > Really, it's just wrong. Delete it, please. It is not wrong, I think you have no practical experience with EAI. The point is that it is just not relevant to the scope of the document. > > > I see the mailing list is focused on finding future solutions, not in > > explaining current operational solutions. > > OK, then how about taking out all of section 4? LOL! I'm more thinking about taking out entirely section 4.2 seeing the traffic on this list. From nobody Fri May 22 17:28:41 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6448B1A82E2 for ; Fri, 22 May 2015 17:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7sIx6oOXxUm for ; Fri, 22 May 2015 17:28:39 -0700 (PDT) Received: from mx-out-1.zmailcloud.com (01.zmailcloud.com [192.198.85.104]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBC31A70E1 for ; Fri, 22 May 2015 17:28:39 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id E14F6563E2A; Fri, 22 May 2015 19:28:38 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id DA89A60286; Fri, 22 May 2015 19:28:38 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YA3BrrOaQTfu; Fri, 22 May 2015 19:28:38 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id A508C6028E; Fri, 22 May 2015 19:28:38 -0500 (CDT) DKIM-Filter: OpenDKIM Filter v2.8.4 smtp-out-2.01.com A508C6028E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=peachymango.org; s=61F775A4-4A7F-11E4-A6BB-61E3068E35F6; t=1432340918; bh=UCIB22eJ8GB0Yuk9B2MqDSLXJnm+Z71gStectDkCpQE=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=kG7nAqfZO7areklV8JRvwTkzxdLGOCG/EmIsRITTg6a8w9AiMrJj1I7znhLNEnCbX TydYk487TPUAGx69HkUGcoa5YU0zIGUN+vm6Iq+OYt/UZaDjfej0ZOCDwMhDN10iin b2hw973hb908k88knokBdG1GPK/KNm8bCNQ6icsc= Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 871E46028C; Fri, 22 May 2015 19:28:38 -0500 (CDT) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xIr6A33kVaLq; Fri, 22 May 2015 19:28:38 -0500 (CDT) Received: from mail-2.01.com (mail.01.com [10.10.0.41]) by smtp-out-2.01.com (Postfix) with ESMTP id 040A660286; Fri, 22 May 2015 19:20:41 -0500 (CDT) Date: Fri, 22 May 2015 19:20:40 -0500 (CDT) From: Franck Martin To: John R Levine Message-ID: <1252902033.98555.1432340440839.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20150522231733.76132.qmail@ary.lan> <482703147.98402.1432338420968.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF38 (Mac)/8.0.5_GA_5839) Thread-Topic: DMARC ATPS Interop Note Thread-Index: 800AFkLF7qwKKOuuKfDVQA/hIc/vZQ== Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 00:28:40 -0000 ----- Original Message ----- > From: "John R Levine" > To: "Franck Martin" > Cc: dmarc@ietf.org > Sent: Friday, May 22, 2015 5:08:03 PM > Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note > > > This is of course if the message is not spammy or contain a virus, or nasty > > stuff like that, where the anti-spam filter may discard the message. > > Except of course for all of the people who don't look at all the crud in > their spam folder. They're not likely to write about messages they don't > see. If it's in the spam folder, for a whole lot of people it might as > well be discarded. > If a tree falls in the forest and your don't hear it, does it matter? From nobody Fri May 22 18:14:23 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB871A0119 for ; Fri, 22 May 2015 18:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.263 X-Spam-Level: X-Spam-Status: No, score=0.263 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WX20X9-Gifgd for ; Fri, 22 May 2015 18:14:20 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6AE41A009E for ; Fri, 22 May 2015 18:14:19 -0700 (PDT) Received: (qmail 43678 invoked from network); 23 May 2015 01:14:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=aa9d.555fd471.k1505; bh=zbvQ3lMwN30av7RLhMkiI1e4bHKdpP9+A28XGplEZhg=; b=lE7DtsEWy07PKmzkbvo0BUEsPQ/0TQI/jUh6QAMnGczNbb1gijiLfKPz22yjT6niLdlm3QAUIL9+cIYEjB5hP3SdYZbznS3WXOo70HormUkaKMTwgRZsRXz1DpN5Q9OIIb7HDOcRY/CbfOMQDQTzX/A1+tTVeZWMT7DeBzOV5reXhulpTR1rnC+lDrNjZWKgGdmtxz3v1qZahvCPGFN9o78ZiiVGZewZwGip8fNUY66e39o/20XECPJpvLXVsE/W DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=aa9d.555fd471.k1505; bh=zbvQ3lMwN30av7RLhMkiI1e4bHKdpP9+A28XGplEZhg=; b=V8i0VZ5u4XW37Pj6lZdi2E+yNKTNv4J2b0v7/kEMBEvx1E5q0YU2JWifftYAyofJcauOMRS90jWQMM7k6zaTOPBvmrdPlrMfsT0ZGaaGLtds3+iSbWY/iOYTBOEEkHAU6W+NlnX3ZHWcqwropK/CdfKx4OYXkzq5OAu0u+h5SWtni+dLx9xu1U1O60U0HFngn393YoDYVzm2lLiZRZIiRnMmvvbvwo/yyv0bQghprs9zlkANvNCwhTRpaXHSFnPt Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 23 May 2015 01:14:25 -0000 Date: 22 May 2015 21:14:17 -0400 Message-ID: From: "John R Levine" To: "Franck Martin" In-Reply-To: <1252902033.98555.1432340440839.JavaMail.zimbra@peachymango.org> References: <20150522231733.76132.qmail@ary.lan> <482703147.98402.1432338420968.JavaMail.zimbra@peachymango.org> <1252902033.98555.1432340440839.JavaMail.zimbra@peachymango.org> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 01:14:21 -0000 >> Except of course for all of the people who don't look at all the crud in >> their spam folder. They're not likely to write about messages they don't >> see. If it's in the spam folder, for a whole lot of people it might as >> well be discarded. >> > If a tree falls in the forest and your don't hear it, does it matter? Um, what? The topic at hand is a desire for senders to know when their mail isn't going where they want it to. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Fri May 22 20:25:28 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A985C1A8ADE for ; Fri, 22 May 2015 20:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.299 X-Spam-Level: *** X-Spam-Status: No, score=3.299 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6UVNZ4wS8KQ for ; Fri, 22 May 2015 20:25:22 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7E81A8ADB for ; Fri, 22 May 2015 20:25:21 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id E01A71C38EC; Sat, 23 May 2015 12:25:19 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id B4BA41A3398; Sat, 23 May 2015 12:25:19 +0900 (JST) From: "Stephen J. Turnbull" To: "John R Levine" In-Reply-To: References: <87mw0xxr3o.fsf@uwakimon.sk.tsukuba.ac.jp> <20150522151417.74918.qmail@ary.lan> <87pp5sh7cu.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 23 May 2015 12:25:19 +0900 Message-ID: <87lhgggelc.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Weaker single author signature X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 03:25:26 -0000 John R Levine writes: > If you can't use a spamming system to send a million messages a day > and expect a fair number of them to be delivered, it's not > interesting. Like I keep saying, while you can imagine > hypothetical spam scenarios, it's hard to think of one that would > be effective enough to be worth the effort, particularly compared > to just using a fake address with the person's name as the From > comment. I hope you don't mind if I say, "Hey! that's *my* line ... too." We can share it. :-) But others don't agree, apparently. I think in that context it's worth spelling things out. Since the detractors have made no move whatsoever to explain their threat models[1], I guess it's on us to do so and debunk them. Steve Footnotes: [1] Except for "what if the spammers suborn an existing mailing list?", but it seems to me that the possibility of resigning doesn't really make that much more attractive than it would be in the first place. From nobody Fri May 22 20:40:33 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5C21A8F4D for ; Fri, 22 May 2015 20:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.899 X-Spam-Level: *** X-Spam-Status: No, score=3.899 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHBsmHWxODCn for ; Fri, 22 May 2015 20:40:28 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id A80A11A8F4A for ; Fri, 22 May 2015 20:40:28 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id DC2161C3995; Sat, 23 May 2015 12:40:27 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id BD7A01A3398; Sat, 23 May 2015 12:40:27 +0900 (JST) From: "Stephen J. Turnbull" To: "John Levine" In-Reply-To: <20150522231626.76111.qmail@ary.lan> References: <65726159.97984.1432334680529.JavaMail.zimbra@peachymango.org> <20150522231626.76111.qmail@ary.lan> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 23 May 2015 12:40:27 +0900 Message-ID: <87iobkgdw4.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org, franck@peachymango.org Subject: Re: [dmarc-ietf] draft-ietf-dmarc-interoperability-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 03:40:33 -0000 John Levine writes: > Take out .invalid, nobody does that because (as I discovered and > you mention) many spam filters dislike From: addresses with domains > that don't resolve. s/take out/deprecate/, please. I know of at least one MLM with many thousands of subscribers (python.org's locally modified version of Mailman) that does use .invalid. I know of exactly one recent poster using a p=reject address, and nobody has complained about not seeing his posts despite the practice. (That's the dev lists, I'm not subscribed to the user list which has a couple score thousand subscribers I suppose, and probably a much higher proportion of users posting from p=reject domains and receiving at "strict" treatment domains.) From nobody Fri May 22 20:44:47 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C9D1A9005 for ; Fri, 22 May 2015 20:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.498 X-Spam-Level: ** X-Spam-Status: No, score=2.498 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qR-GD_IMndUc for ; Fri, 22 May 2015 20:44:42 -0700 (PDT) Received: from shako.sk.tsukuba.ac.jp (shako.sk.tsukuba.ac.jp [130.158.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 383021A8FD7 for ; Fri, 22 May 2015 20:44:42 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id ACFBC1C3892; Sat, 23 May 2015 12:44:41 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 888091A3398; Sat, 23 May 2015 12:44:41 +0900 (JST) From: "Stephen J. Turnbull" To: Franck Martin In-Reply-To: <165424531.98201.1432335622656.JavaMail.zimbra@peachymango.org> References: <554BC30F.1020107@isdg.net> <55529DFB.3010704@gmail.com> <87a8x92q7g.fsf@uwakimon.sk.tsukuba.ac.jp> <5553C44C.7040307@gmail.com> <87vbfv2480.fsf@uwakimon.sk.tsukuba.ac.jp> <87mw171trj.fsf@uwakimon.sk.tsukuba.ac.jp> <165424531.98201.1432335622656.JavaMail.zimbra@peachymango.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" 83e5c3cd6be6 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 23 May 2015 12:44:41 +0900 Message-ID: <87h9r4gdp2.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: Cc: dmarc@ietf.org, "Murray S. Kucherawy" , Douglas Otis Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 03:44:46 -0000 Franck Martin writes: > > From: "Stephen J. Turnbull" > > (3) I would really like to see some provision for reporting to mailbox > > users when their mail is being discarded > The email is bounced, not discarded. Not necessarily. Discard is one of the standard interpretations of "reject" in RFC 7489, per section 10.3. That is the case I'm referring to. From nobody Sat May 23 07:39:54 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACB81A1A92 for ; Sat, 23 May 2015 07:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.663 X-Spam-Level: * X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYgaImLjuoYJ for ; Sat, 23 May 2015 07:39:51 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14FEE1A1A7B for ; Sat, 23 May 2015 07:39:50 -0700 (PDT) Received: (qmail 49545 invoked from network); 23 May 2015 14:39:57 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 23 May 2015 14:39:57 -0000 Date: 23 May 2015 14:39:28 -0000 Message-ID: <20150523143928.6503.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <24588841.98571.1432340785763.JavaMail.zimbra@peachymango.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: franck@peachymango.org Subject: Re: [dmarc-ietf] draft-ietf-dmarc-interoperability-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 14:39:52 -0000 >It is not wrong, I think you have no practical experience with EAI. You might want to review these, as well as RFC 6783. http://www.circleid.com/posts/email_in_the_worlds_languages_part_i/ http://www.circleid.com/posts/email_in_the_worlds_languages_part_ii/ http://www.circleid.com/posts/email_in_the_worlds_languages_part_iii/ From nobody Sat May 23 07:43:27 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB931A1B6B for ; Sat, 23 May 2015 07:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.38 X-Spam-Level: X-Spam-Status: No, score=-98.38 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWis_AzYP3CC for ; Sat, 23 May 2015 07:43:22 -0700 (PDT) Received: from catinthebox.net (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id BFE6F1A001A for ; Sat, 23 May 2015 07:43:21 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1001; t=1432392198; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=2TZMh5/fAn4KXsG26P4+d2lwiCg=; b=ZQGh3QLw//l/I94UrRru5MzjZoQF7unZy0uR9+hfJ2gQFXyT3y9OjAXzKYx/NO PEFomYxr/ZpCenec0HI9cl+lp8+TUgiSRGEGeMxzqV5mVM1TGsEzk+Ftcsupv0F0 dUlLAxFEFQZq1Vl4CgnKeUIa9/alxhZonnbxIxBrHOoSE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 23 May 2015 10:43:18 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1807207758.6474.256; Sat, 23 May 2015 10:43:17 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1001; t=1432391897; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=4iwpGcg JSYOaGP4iB+WCpsjsqZt4g0mnek6WogRZlYs=; b=IPgzfZ9KIl3i+oO3X1xX7lD toKDFgewEZZ+xNQltCVBhKQ/oBdTPllX2fJ/oFGYX4w65tjSakAqfDmY2WqqZvxW MAFxJX90D/joMVhgTDMcfyH34oCruUEiMa70qAvb63G8BmOGFmAaubUF4VpEO4A5 qxiLrRFJWllZT/Tx1e/s= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 23 May 2015 10:38:17 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 399465442.9.24720; Sat, 23 May 2015 10:38:16 -0400 Message-ID: <55609206.5060708@isdg.net> Date: Sat, 23 May 2015 10:43:18 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dmarc@ietf.org References: <554BC30F.1020107@isdg.net> <55529DFB.3010704@gmail.com> <87a8x92q7g.fsf@uwakimon.sk.tsukuba.ac.jp> <5553C44C.7040307@gmail.com> <87vbfv2480.fsf@uwakimon.sk.tsukuba.ac.jp> <87mw171trj.fsf@uwakimon.sk.tsukuba.ac.jp> <165424531.98201.1432335622656.JavaMail.zimbra@peachymango.org> <87h9r4gdp2.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87h9r4gdp2.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] DMARC ATPS Interop Note X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 14:43:25 -0000 On 5/22/2015 11:44 PM, Stephen J. Turnbull wrote: > Franck Martin writes: > > > From: "Stephen J. Turnbull" > > > > (3) I would really like to see some provision for reporting to mailbox > > > users when their mail is being discarded > > > The email is bounced, not discarded. > > Not necessarily. Discard is one of the standard interpretations of > "reject" in RFC 7489, per section 10.3. That is the case I'm > referring to. Feedback can already be done with an EOD (End of DATA) 250 server mail acceptance response: 250 [2.5.7] Mail was accepted but will be discarded due to policy That could be written in the spec as: The DMARC processor MAY issue a 250 reply code with an extended textual response indicating an accept/discard action is going to take place. Keep in mind, that one of the key points of the [silent] accept/discard action is to not provide any feedback, notifications, bounces, backscattering mail noise, etc. -- HLS From nobody Sat May 23 08:34:08 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376D21A011B for ; Sat, 23 May 2015 08:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.688 X-Spam-Level: X-Spam-Status: No, score=0.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaLFpOpqimXa for ; Sat, 23 May 2015 08:34:02 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id ABAB81A010C for ; Sat, 23 May 2015 08:34:02 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PMB2QGW4HC00PYRL@mauve.mrochek.com> for dmarc@ietf.org; Sat, 23 May 2015 08:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1432394941; bh=7VsWzHH9vF2/mLFTD4+cq+5DCGCBbmCq/T7j/UVWtag=; h=From:Cc:Date:Subject:In-reply-to:References:To; b=M3kAuUtU/dzJq2pTjvblHjB3hsGX6ZxuP1wGjF9h9QjrQ8vwfmQwx1C6I1MdfV8yD 4SIqVNdknf7atbfR/5uPi1amZyytBtTK8jYcXtL95OG4hDdwyZh7V+gsLKvyySFclD 30wKPhXvTtmXPAojmKZ8gAIz4dhtNf3UoX+iqoH4= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PMAA9D0GIO0000AQ@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Sat, 23 May 2015 08:28:58 -0700 (PDT) From: ned+dmarc@mrochek.com Message-id: <01PMB2QF7BNI0000AQ@mauve.mrochek.com> Date: Sat, 23 May 2015 07:59:07 -0700 (PDT) In-reply-to: "Your message dated Fri, 22 May 2015 23:16:26 +0000" <20150522231626.76111.qmail@ary.lan> References: <65726159.97984.1432334680529.JavaMail.zimbra@peachymango.org> <20150522231626.76111.qmail@ary.lan> To: John Levine Archived-At: Cc: dmarc@ietf.org, franck@peachymango.org Subject: Re: [dmarc-ietf] draft-ietf-dmarc-interoperability-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 15:34:07 -0000 (chair hat off) > >Please submit "stuff" that needs to be fixed > The worst problem is still section 3.1.2.3 which needs to be deleted, > since most of what it says is wrong, and what little isn't wrong is > irrelevant. > RFC 6854 is not about EAI, since an ASCII MUA can create mail with an > empty group From: as easily as an EAI MUA. The assertion that RFC > 6854 allows empty groups "during the transition period to SMTPUTF8" is > false. RFC 6854 does mention EAI, but only as one of its possible uses. The primary stated use is for "utomated systems that wish to send email but cannot handle replies". > Empty group syntax has nothing to do with DMARC since there is no > domain on the From: line to check. From a DMARC point of view, there > is no difference between a From: with an empty group and one with an > address in a domain that publishes no DMARC record. Agreed. > This sentence is completely false. EAI MTAs never downgrade mail in transit: > If an EAI/SMTPUTF8-aware MTA needs to transmit a message to a non- > aware MTA, the EAI/SMTPUTF8-aware system may transform the > RFC5322.From header field of the message to include group syntax to > allow the non-aware MTA to receive the email. Specifically, this sort of downgrading is only defined in the context of an EAI-aware POP or IMAP server returning a message to a non-EAI-aware client. While it's true that such a message can be resubmitted to the transport infrastructure, at that point its a new message, with all that implies. An MTA performing such a downgrade in the context of handling EAI mail is engaging in an egregious standards violation. Talking about such standards violations is an interoperability document is fine, but (1) The standards violation aspect needs to be made clear and (2) There needs to at least some evidence that such things are happening on a wide enough scale to care about. As such, I agree with John: This section needs to be deleted. > Section 4.1.2.3 is equally wrong for the same reasons and also needs to go. Agreed. > Section 4.1.3.1 doesn't mention rewriting the From: address to a valid > forwarding address in a domain for which the list can sign. It's not > just me doing it, LISTSERV can do that, it's widely implemented. Our list server supports it as well, and it is being used this way. So: Agreed. > Take > out .invalid, nobody does that because (as I discovered and you > mention) many spam filters dislike From: addresses with domains that > don't resolve. I don't mind mentioning .invalid as long as the problematic nature of using this mechanism is made clear. Ned From nobody Tue May 26 08:06:55 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D581A8961 for ; Tue, 26 May 2015 08:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.301 X-Spam-Level: X-Spam-Status: No, score=-99.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1v6D7CKPFrnG for ; Tue, 26 May 2015 08:06:45 -0700 (PDT) Received: from ntbbs.santronics.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D70081A893E for ; Tue, 26 May 2015 08:06:40 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2114; t=1432652794; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=w/DP1YGkjNsMetEP/ZLjBsEOwXY=; b=Ntluylg9T2RSnL3fpvLGjrStJqSCORMyBe5HrYvTQ3npczAH/vKU66iZUYPurE /zhwIjr5elQ4TCDcAzpttkW2U+oJoP9UbZOP5p3aneOijVoseVZr7nohvAmvjAH2 ++HLatcpo6JfhQIYmu4xra5BV5EwUnrHF+fz7PoW6exyU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 26 May 2015 11:06:34 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass policy=none author.d=isdg.net signer.d=beta.winserver.com (atps signer); Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2067801250.14481.3488; Tue, 26 May 2015 11:06:34 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2114; t=1432652489; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=hp9Cq7u wbnr4eLt0jucNF7nFbvCQpiNmPcqSzg5pKhk=; b=zAoUTCNZXIarH1M4uZf5VPn 6mbyk31YxnZWIzzy7FXNUpU9NR5SRVPaY3yQHnvBBnqTwXyik+r69B6wDJjRtBT3 px5ZSWZlFy19g7BxFQgysl5hTg5HBaP+6LcZmUFitcGcgQZ3FTM2bFG3CyTyg4/N qvUEax/vg7X0qBt74NSs= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 26 May 2015 11:01:29 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 660057536.9.28368; Tue, 26 May 2015 11:01:28 -0400 Message-ID: <55648BF8.6080205@isdg.net> Date: Tue, 26 May 2015 11:06:32 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dmarc@ietf.org References: <65726159.97984.1432334680529.JavaMail.zimbra@peachymango.org> <20150522231626.76111.qmail@ary.lan> <01PMB2QF7BNI0000AQ@mauve.mrochek.com> In-Reply-To: <01PMB2QF7BNI0000AQ@mauve.mrochek.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dmarc-ietf] draft-ietf-dmarc-interoperability-02.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 15:06:52 -0000 On 5/23/2015 10:59 AM, ned+dmarc@mrochek.com wrote: > (chair hat off) > >> This sentence is completely false. EAI MTAs never downgrade mail in transit: > >> If an EAI/SMTPUTF8-aware MTA needs to transmit a message to a non- >> aware MTA, the EAI/SMTPUTF8-aware system may transform the >> RFC5322.From header field of the message to include group syntax to >> allow the non-aware MTA to receive the email. > > Specifically, this sort of downgrading is only defined in the context of an > EAI-aware POP or IMAP server returning a message to a non-EAI-aware client. > While it's true that such a message can be resubmitted to the transport > infrastructure, at that point its a new message, with all that implies. > > An MTA performing such a downgrade in the context of handling EAI mail is > engaging in an egregious standards violation. Talking about such standards > violations is an interoperability document is fine, but (1) The standards > violation aspect needs to be made clear and +1 > (2) There needs to at least some > evidence that such things are happening on a wide enough scale to care about. Side note, I think there is too much of this going on that it have been causing too many compatibility problems in the long run/term. > As such, I agree with John: This section needs to be deleted. If there is an DMARC interop issue related to SMTP vs ESMTP compatibility/support issues, then that should be pointed out. But this section talks about a mitigating method, the new group syntax support that I never supported anyway. As long as it was a transparent syntax, there was no need to get worry about it, that I could see. For DMARC, I don't support any form of rewriting the header from. I don't think the interop report should encourage rewriting or downgrading. But I am not sure if removal/deleting the section does that. I think it should say that downgrading or rewriting can cause more unrelated to DMARC conflicts. The reports should outline all the related issues that a current and future MARC implementation may run into. -- HLS From nobody Thu May 28 16:08:28 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5BF01ACE18 for ; Thu, 28 May 2015 16:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.312 X-Spam-Level: * X-Spam-Status: No, score=1.312 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZ2SD0zc1BcP for ; Thu, 28 May 2015 16:08:20 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9E2E1ACDFD for ; Thu, 28 May 2015 16:08:19 -0700 (PDT) Received: by oifu123 with SMTP id u123so44309677oif.1 for ; Thu, 28 May 2015 16:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=wIDXoKriR61sRTh1D/tRgBQGQIFlcGMJbDksomaOClk=; b=ai8h6ys42p1m5A7CFWMaHUg/4u38TmHcVk+R9TVTHvZ8D3EvADaII16iG8HkzPE+UD PvsIdKFem8RAKOwMmO1z6bp8R6gje4Xt/MoExyduj9rpssZIMO8pqWPFOFPGs0eqxugc KeXg7ylsK75ApIWiDrxbaLDlUYpA6NeGsfNH/nTCghKpWzBKZ4E6trPV9NMk5bIhXIkK u5b7V4mEzPJ6w1cTLh915iojyCDnadcJg08R6PX5yG14GeIVWEZJJFOQYJC1oKzMV4T2 NDTRJjvZpYb7HEN2TEzZ5ghKeSyeV6lMZTCoy9fNVC2/BykNnWywfl0GwlXgloNIQKwT P64w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=wIDXoKriR61sRTh1D/tRgBQGQIFlcGMJbDksomaOClk=; b=M+orU6Fm6DNTQqTPdCTYJYKDvZ22q0OGfB9T6w/GqsVdQRPmvr6mIp+48HC0CCKfve V1q/IbiPbCy/7Qm/+tYJbyZzwo9RdkYk32xuShWl5vu6j0v5fXLg/lcqLPCcPkO2uLgi YxLqeTPQCmlDA+bK4shchy1BacPOvM0i4yNLp8eQwoLbQJzbw8KfWIR6g6XWgozxvQP9 LJ/RVzNvHGL+qXH7HavPSG92KQnonGY1SMSBoiy1mN6AvaGl0CJzQ2cgC9y9MPk6YxE+ x06XerTAnTH2eU5SJBpkUqUDwK1vzS1pS5Wd2be3a0HZ7ALV50862RwSxE146OKkuY0K IN0g== X-Gm-Message-State: ALoCoQmO1xcqdI1jIbGTPZCd6xLowwevZg4hnIPKZenHwzpIJbvVA8hUQTw4YcXLVAt0uJJhQrSc MIME-Version: 1.0 X-Received: by 10.60.50.168 with SMTP id d8mr4650547oeo.41.1432854499185; Thu, 28 May 2015 16:08:19 -0700 (PDT) Received: by 10.182.108.7 with HTTP; Thu, 28 May 2015 16:08:19 -0700 (PDT) Date: Thu, 28 May 2015 16:08:19 -0700 Message-ID: From: Brandon Long To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a11c30bf0708a6805172c6f4e Archived-At: Subject: [dmarc-ietf] weak dkim canonicalization X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 23:08:22 -0000 --001a11c30bf0708a6805172c6f4e Content-Type: text/plain; charset=UTF-8 We've been looking at weak dkim from the angle of reducing what's covered by the signature... but unfortunately, that takes out the major parts of the message that we care about. I'm wondering if there is a different alternative. This starts from the concept of the clean subject, similar to the reply_regexp setting in mutt ( http://www.mutt.org/doc/devel/manual.html#reply-regexp). In Gmail, this same cleaning involves more, where we also strip Fwd type prefixes, as well as list-prefixes [] and whitespace changes. One could imagine a canonicalization of the subject which did something similar, allowing for most list subject mangling to not affect the signature for that header. We'd probably also need to de-2047 the header as well, so the processing was done on the user visible header, not the raw header. Maybe there's some phishing or weirdness in allowing [whatever I want in brackets] as a prefix, and there is the argument that given a large enough user population, someone will fall for it... but its certainly better than ignoring the subject completely. Moving on to the body is more complicated. I know the proposal for using the l= to limit the size of the body that is signed, which could allow for a footer to be added without breaking the signature. With HTML, it's been argued that the later part of the message could modify the viewability of the signed part and do all sorts of nasty things, and that may be true. We might be able to specify a very specific format for footers, requiring both an l= and that the rest matched that format, and maybe we could encode that formating requirement as a canonicalization play, ie that a footer matching the format would be removed during canonicalization, and one that doesn't, isn't. Obviously, this may require a lot of work on list admins to move their footers to a matching format, though if its pure text, that may be simple enough for the list software to handle. One could also imagine that an MUA could choose to only display the l= part by default, eliding the rest the same way Gmail hides signatures and the like (ignore that I mentioned that we should talk with the MUA folks, of course). One could also sign the body as an independent mime part and force footers into multipart/mixed addendums. I realize both of these body changes require modifications to various intermediate software, where the semi-point of the weak signatures was to hope that it would pass unharmed and limit the scope of changes that would be required. The final hare brained idea I had was more in the scope of "is this possible" without actually knowing that myself. There are various fingerprinting type algorithms, is it possible to construct a fingerprint algorithm which one could then sign, and require the modified body to still match the fingerprint. This may not be possible in cases where the footer is significantly larger than the original message text, and I'm pretty ignorant of the actual algorithms to know if any would work in this case, but it seems to me that this is something we could pose to people knowledgeable about work in that area to see if there is a solution. Now, the fingerprinting solution may end up being just a more generic version of l=, ie it may allow for prefix and footers or rewriting links or something. And it probably wouldn't catch the HTML writing tricks, so maybe all of that is less useful than one would hope. Brandon --001a11c30bf0708a6805172c6f4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We've been looking at weak dkim from the angle of redu= cing what's covered by the signature... but unfortunately, that takes o= ut the major parts of the message that we care about.

I&= #39;m wondering if there is a different alternative.

This starts from the concept of the clean subject, similar to the reply_= regexp setting in mutt (http://www.mutt.org/doc/devel/manual.html#reply-regexp)= .=C2=A0 In Gmail, this same cleaning involves more, where we also strip Fwd= type prefixes, as well as list-prefixes [] and whitespace changes.

One could imagine a canonicalization of the subject which= did something similar, allowing for most list subject mangling to not affe= ct the signature for that header.=C2=A0 We'd probably also need to de-2= 047 the header as well, so the processing was done on the user visible head= er, not the raw header.

Maybe there's some phi= shing =C2=A0or weirdness in allowing [whatever I want in brackets] as a pre= fix, and there is the argument that given a large enough user population, s= omeone will fall for it... but its certainly better than ignoring the subje= ct completely.

Moving on to the body is more compl= icated.=C2=A0 I know the proposal for using the l=3D to limit the size of t= he body that is signed, which could allow for a footer to be added without = breaking the signature.=C2=A0 With HTML, it's been argued that the late= r part of the message could modify the viewability of the signed part and d= o all sorts of nasty things, and that may be true.=C2=A0 We might be able t= o specify a very specific format for footers, requiring both an l=3D and th= at the rest matched that format, and maybe we could encode that formating r= equirement as a canonicalization play, ie that a footer matching the format= would be removed during canonicalization, and one that doesn't, isn= 9;t.=C2=A0 Obviously, this may require a lot of work on list admins to move= their footers to a matching format, though if its pure text, that may be s= imple enough for the list software to handle.=C2=A0 One could also imagine = that an MUA could choose to only display the l=3D part by default, eliding = the rest the same way Gmail hides signatures and the like (ignore that I me= ntioned that we should talk with the MUA folks, of course).

<= /div>
One could also sign the body as an independent mime part and forc= e footers into multipart/mixed addendums.

I realiz= e both of these body changes require modifications to various intermediate = software, where the semi-point of the weak signatures was to hope that it w= ould pass unharmed and limit the scope of changes that would be required.

The final hare brained idea I had was more in the s= cope of "is this possible" without actually knowing that myself.<= /div>

There are various fingerprinting type algorithms, = is it possible to construct a fingerprint algorithm which one could then si= gn, and require the modified body to still match the fingerprint.=C2=A0 Thi= s may not be possible in cases where the footer is significantly larger tha= n the original message text, and I'm pretty ignorant of the actual algo= rithms to know if any would work in this case, but it seems to me that this= is something we could pose to people knowledgeable about work in that area= to see if there is a solution.

Now, the fingerpri= nting solution may end up being just a more generic version of l=3D, ie it = may allow for prefix and footers or rewriting links or something.=C2=A0 And= it probably wouldn't catch the HTML writing tricks, so maybe all of th= at is less useful than one would hope.

Brandon
--001a11c30bf0708a6805172c6f4e-- From nobody Fri May 29 18:30:27 2015 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCF31ACEE4 for ; Fri, 29 May 2015 18:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.263 X-Spam-Level: ** X-Spam-Status: No, score=2.263 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pj2exPsNAdeH for ; Fri, 29 May 2015 18:30:25 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A73B1ACEE3 for ; Fri, 29 May 2015 18:30:25 -0700 (PDT) Received: (qmail 93120 invoked from network); 30 May 2015 01:30:32 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 30 May 2015 01:30:32 -0000 Date: 30 May 2015 01:30:02 -0000 Message-ID: <20150530013002.14768.qmail@ary.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: blong@google.com Subject: Re: [dmarc-ietf] weak dkim canonicalization X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2015 01:30:27 -0000 >We've been looking at weak dkim from the angle of reducing what's covered >by the signature... but unfortunately, that takes out the major parts of >the message that we care about. > >I'm wondering if there is a different alternative. When we were doing DKIM, we went around and around and around trying to figure out what sort of modifications we could allow and still consider messages to be "the same", with negligible success. All we came up with was relaxed canon and l=NN. The point of relaxed was to allow for the sort of message tidying up that sendmail used to do before people understood the distinction between mail submission and mail relay. It is my impression that these days it's rare to have a message that passes relaxed that wouldn't also pass strict. The point of l= was to allow mailing lists to add footers, not so much because we thought that would solve a lot of problems but because it was the only thing we could think of that might solve one problem and it was cheap to specify and implement. Again, I don't get the impression that it's used very much, and messages with l=N would usually pass anyway. Google has some great algorithms people, so maybe they can come up with some essence of message fingerprint that works, but I'd be surprised. Anything that a mailing list might do to add innocuous text to a message, a spammer can do the same but adding spam text. I don't see any way around that. We can probably come up with a hack for subject lines just because subject lines are so short, but I'd be pretty surprised if anything more general were workable. (Proposed subject hack: add a new code to DKIM-Signature that says to use the copied subject from z= when verifying the signature, but only if the contents of that subject is a substring of the current subject. De-MIME-ing is a quality of implementation issue.) For my double signing hack, I'm coming at it from the other direction, what problem are we trying to solve. When AOL and Yahoo made their unfortunate DMARC decisions, they had a very concrete problem to solve. They'd allowed crooks to steal address books, so Yahoo (or AOL) users were getting spam with Yahoo addresses of people they knew, sent from random botnets, not from Yahoo. I believe that double signing still solves 99.9% of that problem while allowing mailing lists to do most of what they ordinarily do. While it is true that a malicious re-signing mediator could still delete the contents of a weakly signed message and replace it with spam, this greatly decreases the attack surface. The malicious party has to have a recent real message in hand from the real author, and the real author's mail system has fine grained control over who they allow to re-sign. Start with a heuristic about what domains are likely to be mailing lists (something I know gmail has from the comments in the aggregate reports), put weak signatures on mail sent to them. If a particular mediator's spamminess spikes, you can stop putting weak signatures on mail to the bad actor without having to break mail to everyone else. For incoming mail, the double signature allows you to tell the difference between direct mail and mediated mail, with the double signature not meaning that the mail is "real", but rather that it came via someone with at least a weak relationship with the author so it's likely non-horrible enough to be worth running through the normal spam filters. This does require heuristics and tuning, but so does any spam filter, and what this does seems similar to what any spam filter does anyway. R's, John