From nobody Sun Jun 1 15:23:05 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA961A00CF for ; Sun, 1 Jun 2014 15:23: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 bNXZwjPjKhkr for ; Sun, 1 Jun 2014 15:23:03 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E48681A00D5 for ; Sun, 1 Jun 2014 15:23:02 -0700 (PDT) Received: by mail-pa0-f47.google.com with SMTP id ld10so3535618pab.20 for ; Sun, 01 Jun 2014 15:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=wj/0j7wSYiSSgj6DFAKd3B7KVO2uiRM+mGmlPG5dkpk=; b=hNl/W8zmRgYvwZ3KR8afzXipFoBe2prjf5PwKeUh4nfGLYVyht8sav+ghS/yVfD83I HYBpHG5SuxQCxISQ/zfbSeoTC7fZ+oZhXosQ3S0+0g2UmHskcHhrC5C6Xk2dLwL2Pl2S Vzgdxqy/SQpGXn8DnEXD78luowS/ZmP4L50YjvhInj4CBTcecRp2yYaVX63mYpNAVeKo RB1h3WekYrPGE+i93dcYGqn2GnP+c9+cXSqSvFzHn4CqQs6hasA6P4XjMj7bgYU6fdvM lbl6cox4iS9vTF8EObRDtS0X97N9l4Ax7g6qoohZbSWiqfHUDZojlOVasWUy8SSjyVIZ kEzg== X-Received: by 10.68.241.68 with SMTP id wg4mr36412366pbc.66.1401661377693; Sun, 01 Jun 2014 15:22:57 -0700 (PDT) Received: from [192.168.2.109] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id jt7sm17053662pbc.46.2014.06.01.15.22.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Jun 2014 15:22:57 -0700 (PDT) From: Douglas Otis Content-Type: multipart/alternative; boundary="Apple-Mail=_A3936B11-FB6B-43E9-84B8-C239E363B90A" Message-Id: Date: Sun, 1 Jun 2014 15:22:55 -0700 To: dmarc@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/S9syRLYTZ93CyJZTdZDN5llKLUY Subject: [dmarc-ietf] Update of the Third-Party Authorization Label 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, 01 Jun 2014 22:23:04 -0000 --Apple-Mail=_A3936B11-FB6B-43E9-84B8-C239E363B90A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear dmarc, The significant change in this version helps facilitate processing of = DMARC feedback. This is to assure automated processing of feedback and = logs will be practical. By conveying this information, it would also = indicate those domains that have been listed in this manner will need to = contact the trusted domain to understand what changes they still need to = make when authorization specifically has not been granted.=20 http://tools.ietf.org/html/draft-otis-tpa-label Thank you for your feedback. Regards, Douglas Otis --Apple-Mail=_A3936B11-FB6B-43E9-84B8-C239E363B90A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Dear dmarc,

The = significant change in this version helps facilitate processing of DMARC = feedback. This is to assure automated processing of feedback and logs = will be practical.  By conveying this information, it would also = indicate those domains that have been listed in this manner will need to = contact the trusted domain to understand what changes they still need to = make when authorization specifically has not been = granted. 


Thank you = for your feedback.

Regards,
Douglas = Otis



= --Apple-Mail=_A3936B11-FB6B-43E9-84B8-C239E363B90A-- From nobody Sun Jun 1 19:56:54 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56EB71A011E for ; Sun, 1 Jun 2014 19:56:53 -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 ynMNK9EAqj5C for ; Sun, 1 Jun 2014 19:56:51 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F9EC1A011B for ; Sun, 1 Jun 2014 19:56:51 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id y13so2907435pdi.25 for ; Sun, 01 Jun 2014 19:56:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=+1KX9+sRcrnGFlk2ZakC+KEtCd63MEVKSlvWnU89k/s=; b=Ln8iyiafsNkrDCG2In8SMB0JLsptho4gWRXRDvp0L5QL/+Cbj6ibs3ABeiC/C0n2c5 Pa5DFDtYB21U5ZBNCJKcnxyxN8TDzPhtAZ4UcahqFAPP7Img/bLiKVdpjRrH5pqlMSIc lO0/k+Jp9875NNBu/LS9JM0YeRowu3DIpjQ0hTqZ00VhXmGQxNqGe7v0rNWzm7Pg3RUK HV8lx0NWduNKsha2ucPRTJDaq1czszHHPHjnKQa/YKHPFYf/oFhWBd6khhrLfC6scmzF iGpGawTjyd2zSEEp82wYG5l2kQmMIWg8eBBn+r1q+60/o6DsFsovk6ZvA2YHfmMhOw3d t6Bg== X-Received: by 10.66.147.99 with SMTP id tj3mr37364240pab.47.1401677805955; Sun, 01 Jun 2014 19:56:45 -0700 (PDT) Received: from [192.168.2.105] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id ko10sm17674967pbd.52.2014.06.01.19.56.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Jun 2014 19:56:44 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_0E9FF4BD-F1C9-4BE6-A685-5217DE1624BD" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: <538917D0.7040604@isdg.net> Date: Sun, 1 Jun 2014 19:56:42 -0700 Message-Id: <08F3556F-2470-424D-8BE2-2DF8B7E27B39@gmail.com> References: <20140528163723.63860.qmail@joyce.lan><728937278.65439.1401312715643.JavaMail.zimbra@peachymango.org><87tx887ry5.fsf@uwakimon.sk.tsukuba.ac.jp> <8761kn7f42.fsf@uwakimon.sk.tsukuba.ac.jp> <538917D0.7040604@isdg.net> To: Hector Santos X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/AehkkchkSdzZQWa6bm0TLRRJm_4 Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection 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, 02 Jun 2014 02:56:53 -0000 --Apple-Mail=_0E9FF4BD-F1C9-4BE6-A685-5217DE1624BD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Hector, See comments inline: On May 30, 2014, at 4:44 PM, Hector Santos wrote: > On 5/30/2014 5:49 PM, J. Gomez wrote: >=20 >>> Ah, but "just like" is a complete misstatement of the situation. >>> There's a big difference. Users on a mailing list think of the >>> poster, not the mailing list, as responsible for the content. So >>> according to RFC 5322, the poster's mailbox belongs in From:. >>> Remailed or not, the author belongs there. >>=20 >> That is debatable. As long as the mailing list program tampers with = the message's content, rendering its DKIM signature invalid, it can be = argued that the mailing list program is rewriting the message's content, = and therefore that the mailing list program now becomes "the system = responsible for the writing of the message" (as per RFC 5322 parlance, = section 3.6.2), and thus the mailing list address would earn its = legitimate place in the Header-=46rom field, making interoperability = with rogue DMARC Senders a solved problem. >=20 > In my book, this is mail tampering. It will be hard to justify adding = support for this radical behavior in our mail list server product which = puts customers at risk. You are putting yourself at product liability = risk but intentionally defying a security protocol against the wishes of = the publishing restrictive domain. Of course, its only becomes a = problem when its used as a loophole to further spread harmful mail and = someone actually gets harmed. Thats all you have to prove in a = courtroom. If you had all the tools before you to tell you = definitively, "This is unauthorized mail" and you intentionally, = deliberately and neglectfully ignore it, do nothing about it but further = distribute to end points, well, who knows what a young punk, tech savvy, = high tech, new age lawyer will think about suing you. If you got deep = pockets, well, don't think it can't happen. >=20 > It is this sort of mentality that completely makes this old game no = more fun to work with. Seriously. >=20 > We can do it right. All we have to do is LOOKUP the policy and follow = it. Give the YAHOOs the tools to authorize the resigners and you and I = won't have these new ethical problems to content with. It seems wrong to describe a mailing-list adding Subject Tags, List = Footers, while retaining the =46rom header field so people have an easer = task of knowing who is talking and at reviewing past conversations as = putting recipients in grave risk. Causing a massive number of people to = find different email providers so they can retain their effectiveness at = using a mailing list is far more likely to create risk simply due to the = resulting confusion. There is also the case of Intuit sending "From" invoices on behalf of = various individuals and using their customer's email address given to = them by their Internet provider, only to find someone now thinks DKIM = can't possibly be considered valid when signing the Sender header field. = That is exactly the intended purpose for this field. This is essentially = the same issue with mailing-lists. In both cases, there is a valid = reason for the =46rom header field to contain that of their client or = the speaker, because that is what the recipient is able to recognize. = There are also MUAs that will create a synthetic =46rom on = behalf of . Most MUAs can also optionally display both headers.=20= The real effort involved in the sequence of these messages is = establishing trust anchors. While there is going to be a massive number = of individuals involved, there are several orders of magnitude fewer = trust anchors. For any domain wanting to assert strict alignment for = their messages, it is only fair for them to work out relationships = between their users messages and the non-aligned third-party services = (trusted domain --> worthy third-party service). Their out-bound logs = and DMARC/User feedback should arrive at a reasonable estimate about = which domains are being trusted. Rogue services will be excluded and = any mistakes can be quickly corrected. Rather than describing this as a permission to sign, think of this as a = type of server federation aimed at protecting the federated identity = much like single-user-sign-on. In this case, it would be which of these = services are normally used and maintain practices that protect the = federated identifiers. The TPA-Label scheme allows this type of = federation to be centralized or handled separately by each trusted = domain (senders) as described in = http://tools.ietf.org/html/draft-otis-tpa-label. Regards, Douglas Otis --Apple-Mail=_0E9FF4BD-F1C9-4BE6-A685-5217DE1624BD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Dear Hector,

See = comments inline:
On May 30, 2014, at 4:44 PM, Hector = Santos <hsantos@isdg.net> = wrote:

On 5/30/2014 5:49 PM, J. Gomez wrote:

Ah, but "just like" is a = complete misstatement of the situation.
There's a big difference. =  Users on a mailing list think of the
poster, not the mailing = list, as responsible for the content.  So
according to RFC 5322, = the poster's mailbox belongs in From:.
Remailed or not, the author = belongs there.

That is debatable. As long as the = mailing list program tampers with the message's content, rendering its = DKIM signature invalid, it can be argued that the mailing list program = is rewriting the message's content, and therefore that the mailing list = program now becomes "the system responsible for the writing of the = message" (as per RFC 5322 parlance, section 3.6.2), and thus the mailing = list address would earn its legitimate place in the Header-=46rom field, = making interoperability with rogue DMARC Senders a solved = problem.

In my book, this is mail tampering. It will = be hard to justify adding support for this radical behavior in our mail = list server product which puts customers at risk.  You are putting = yourself at product liability risk but intentionally defying a security = protocol against the wishes of the publishing restrictive domain. =  Of course, its only becomes a problem when its used as a loophole = to further spread harmful mail and someone actually gets harmed. =  Thats all you have to prove in a courtroom.   If you had = all the tools before you to tell you definitively, "This is unauthorized = mail"  and you intentionally, deliberately and neglectfully ignore = it, do nothing about it but further distribute to end points, well, who = knows what a young punk, tech savvy, high tech, new age lawyer will = think about suing you.  If you got deep pockets, well, don't think = it can't happen.

It is this sort of mentality that completely = makes this old game no more fun to work with. Seriously.

We can = do it right.  All we have to do is LOOKUP the policy and follow it. =  Give the YAHOOs the tools to authorize the resigners and you and I = won't have these new ethical problems to content = with.

It seems wrong to describe a = mailing-list adding Subject Tags, List Footers, while retaining the =46rom= header field so people have an easer task of knowing who is talking and = at reviewing past conversations as putting recipients in grave risk. =  Causing a massive number of people to find different email = providers so they can retain their effectiveness at using a mailing list = is far more likely to create risk simply due to the resulting = confusion.

There is also the case of Intuit = sending "From" invoices on behalf of various individuals and using their = customer's email address given to them by their Internet provider, only = to find someone now thinks DKIM can't possibly be considered valid when = signing the Sender header field. That is exactly the intended purpose = for this field. This is essentially the same issue with mailing-lists. =  In both cases, there is a valid reason for the =46rom header field = to contain that of their client or the speaker, because that is what the = recipient is able to recognize.  There are also MUAs that will = create a synthetic =46rom <sender> on behalf of <from>. =  Most MUAs can also optionally display both = headers. 

The real effort involved in the = sequence of these messages is establishing trust anchors. While there is = going to be a massive number of individuals involved, there are several = orders of magnitude fewer trust anchors.  For any domain wanting to = assert strict alignment for their messages, it is only fair for them to = work out relationships between their users messages and the non-aligned = third-party services (trusted domain --> worthy third-party service). =  Their out-bound logs and DMARC/User feedback should arrive at a = reasonable estimate about which domains are being trusted.  Rogue = services will be excluded and any mistakes can be quickly = corrected.

Rather than describing this as a = permission to sign, think of this as a type of server federation aimed = at protecting the federated identity much like single-user-sign-on. =  In this case, it would be which of these services are normally = used and maintain practices that protect the federated identifiers. =  The TPA-Label scheme allows this type of federation to be = centralized or handled separately by each trusted domain (senders) as = described in http://tools.ietf= .org/html/draft-otis-tpa-label.

Regards,
Douglas Otis

= --Apple-Mail=_0E9FF4BD-F1C9-4BE6-A685-5217DE1624BD-- From nobody Mon Jun 2 10:10:13 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1291A024D for ; Mon, 2 Jun 2014 10:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.321 X-Spam-Level: X-Spam-Status: No, score=-16.321 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] 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 I-xVmzzcEykQ for ; Mon, 2 Jun 2014 10:10:09 -0700 (PDT) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86F9A1A01ED for ; Mon, 2 Jun 2014 10:10:09 -0700 (PDT) Received: from GQ1-EX10-CAHT15.y.corp.yahoo.com (gq1-ex10-caht15.corp.gq1.yahoo.com [10.73.119.196]) by mrout3.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id s52H8tD3069819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Jun 2014 10:08:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1401728936; bh=E0SLcshSgcGsVO76N1n/eSHTrBxYdAQ35s/ER0FJiIg=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=tyVvJgX3MkvBkUQw8AhcR0ezgmiN5IWA94P5kCfYp8Vj5FM/EHgkB2ZTtjIkpgmd4 0b7NhSy4PlB7jM8ChtCyEGUvmiW1DH7KbP5EnrWIVAg0guIJeWHdEN+JU12F4tfFzR mviKcdr2LFpzElaREs2JcahAv//BuAMJ+fdDgWP0= Received: from GQ1-MB01-02.y.corp.yahoo.com ([fe80::a049:b5af:9055:ada6]) by GQ1-EX10-CAHT15.y.corp.yahoo.com ([fe80::a59c:f6d4:6ac1:572e%14]) with mapi id 14.03.0181.006; Mon, 2 Jun 2014 10:08:55 -0700 From: Elizabeth Zwicky To: "Stephen J. Turnbull" Thread-Topic: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) Thread-Index: AQHPe7Tw0rXUTivWFE2qV1g12n37IZtY8MgAgABrEACAAd3rAIAC2XCA Date: Mon, 2 Jun 2014 17:08:54 +0000 Message-ID: References: <5387F6E0.1070903@att.com> <15749590.z7A0vHW603@scott-latitude-e6320> <87ppiu57zt.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87ppiu57zt.fsf@uwakimon.sk.tsukuba.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [216.145.54.7] Content-Type: text/plain; charset="us-ascii" Content-ID: <24F470845424FB448FDF7E0AC96A6EB5@yforest.corp.yahoo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 728936000 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/DMCMhC93VJ_BKLQHV4kcpyst4fU Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 02 Jun 2014 17:10:11 -0000 It is true that when attackers can't use our From: lines, they try other things.=20 Empirically, it's also clear that the attackers do not like From: "Victim Name" as much as they like From: "Victim Name" based on lowered volume when the second form is unavailable. Given that, I see no reason to believe they won't go back to the second form if it becomes available. And, taking into account Murphy's law, previous tactics of these attackers, and the reasonable expectations of the public, what will happen then is that they go very aggressive at 2:00 in the morning my time, followed by a great deal of bad press. At this point, I do not see going to p=3Dquarantine in the hope that attackers won't exploit data they already have exactly the same way they did before, even though nothing is stopping them, as a reasonable approach.=20 Elizabeth zwicky@yahoo-inc.com On 5/31/14, 7:37 AM, "Stephen J. Turnbull" wrote: >Elizabeth Zwicky writes: > > > So changes that maintain effective protection for users who are > > being targeted by attackers with addressbook information, with less > > disruption to email that people want, are of great interest to us. > >How about trying "p=3Dquarantine" with a real short TTL just in case? >After a while you crank it back up to the current level (which is only >1800 in any case). > >The argument is that, seriously, since the attackers have addressbook >information, you're done for anyway. They're already hard at work on >Plan B, using "I'm writing this from my friend's account" with self in >Sender: (should work well on Outlook users despite having on-behalf-of >point the wrong direction), and ... Heck, I've already thought of a >dozen of these dodges and my name isn't even Laurence Canter. > >I think it's worth a check to see if the miscreants will bother to >come back at you with the previous style of spam shot even though they >should expect that the vast majority of their spam will get rejected >anyway (messages apparently from a "p=3Dquarantine" domain should be >given a rough time as encouraged by the DMARC protocol), and the rest >will end up in spam folders. I would think trying to avoid DMARC >entirely would now be the best use of their resources, so maintaining >quarantine should be enough. There may be some directly relevant >recent evidence on this, since GMail is evidently promoting mailing >list traffic from "p=3Dreject" domains to "quarantine". If the spammers >know this, they could continue targeting GMail customers in their >stolen addressbook database. Dunno if GMail will tell Yahoo!, but you >could ask. > >BTW I hope you guys are basing "p=3Dreject" (vs. "p=3Dquarantine") on real >data on how often fraudulent mail that ends up in spam folders >actually succeeds in harming the targeted victim. > From nobody Mon Jun 2 10:48:15 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305A81A02B3 for ; Mon, 2 Jun 2014 00:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.609 X-Spam-Level: ** X-Spam-Status: No, score=2.609 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6] 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 UD5w5-Q7ka2V for ; Mon, 2 Jun 2014 00:28:28 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id 07FF71A02A7 for ; Mon, 2 Jun 2014 00:28:27 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id C6417970B25; Mon, 2 Jun 2014 16:28:21 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id B8B3811F235; Mon, 2 Jun 2014 16:28:21 +0900 (JST) From: "Stephen J. Turnbull" To: Tony Hansen In-Reply-To: <538A76ED.4050609@att.com> References: <5387F6E0.1070903@att.com> <87ha456dlt.fsf@uwakimon.sk.tsukuba.ac.jp> <538A76ED.4050609@att.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Mon, 02 Jun 2014 16:28:21 +0900 Message-ID: <8738fn6a96.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/wLssZCsdjy_gzhx_GzZBRkduISg X-Mailman-Approved-At: Mon, 02 Jun 2014 10:48:13 -0700 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 02 Jun 2014 07:28:30 -0000 Tony Hansen writes: > I would love to see that list of multiple mitigations shared with the > broader community. That would be useful information for people in the > IETF, I've shared it here in various levels of detail more than once, and sooner or later it will be in the Mailman FAQ as I'm sure that the brief descriptions in the admin UI will need amplification. Basically, Mailman provides two orthogonal features: 1. Whether to mitigate, and when to mitigate, that is the question a. Don't. b. Always. c. Only for posters from DMARC "p=reject" domains. 2. How to mitigate: a. Replace poster with list in From:, and diddle Reply-To so that reply-to-poster is as convenient as possible. b. Wrap the message in a MIME message/rfc822 body. Thanks to John Levine, we'll eventually have a 2c option: append .INVALID to the poster's mailbox in From:. > as well as other MLM teams not involved wherever those discussions > occurred. AFAIK there is no particular place where MLM teams meet up; there are very few interoperation considerations. I would think other MLM teams would be here now if they cared (cf John Levine's comment on your post). > Perhaps there is one or more of those solutions that we SHOULD be > recommending. The only solution currently available I can see recommending is banning domains that DoS third parties. However, that isn't going to fly on many, probably the great majority, of Mailman and ListServ lists. (Majordomo, smartlist, and whatever is used with qmail may have a rather different user population, as is suggested by John's observation.) All the others have defects that some people consider severe, so will have to be chosen by the list's administration. > And perhaps broader discussions will provide an AHA moment where we see > a way to solve BOTH MLM's problems AND DMARC's problems with MLMs in the > face of a p=reject policies. My personal belief (as previously mentioned) is that that is a logical impossibility. But we can hope I'm wrong! > Are the current p=reject semantics totally correct? As has been pointed > out by others, even with mail sent out from banks, there are legitimate > uses of mailing lists or things like mailing lists where you want copies > to be received by multiple people. The important thing is that the banks' problems with "p=reject" can be solved (worked around, if you prefer) by the banks, without cooperation of third parties, and without (much) harm to third parties (it's unlikely that there are Mailman lists where 314 bank reps will post to the same list in a week and so knock all subscribers into disabled state). While it would be as nice as getting a pony for the banks' tech staff to be able to post to this list from the well-known domain, I don't think that's very high on their list of tasks for their techies. Just registering a "somebank-inc.com" domain is satisfactory, I suppose. > Or alternatively, perhaps p=reject needs to be redefined slightly to > take advantage of specific recommended practices for mailing lists. Perhaps. I'm a fan of "simple protocols used judiciously" vs. "complex protocols that try to forestall all problems" myself. If complexity would make it possible for Yahoo! to use "p=reject" without DoS'ing mailing list subscribers and their own posters, it would be worth it, I suppose. > > SPF and DKIM are now ancient history, at least as far as Mailman > > development goes. We've already done what's technically > > possible. > > Since I'm not privy yet to what all GNU Mailman has chosen to do in > the face of SPF and DKIM, so I don't know how to evaluate that > statement. Sorry. > > If you're saying that you've thrown out all use of DKIM, I consider that > a sorry state of affairs. No. What we've done is (1) Put up a FAQ encouraging re-signing by MTAs hosting lists. (2) Added an option to strip the (presumably broken, we don't check for it) original DKIM signature. There's no real point in MLMs doing more than that as it requires cooperation from the domain's DNS. OAR (which I don't think is worth it) could be done, but I think this probably is better done by the MTA (local MUAs and admins might wish to refer to it). From nobody Mon Jun 2 11:34:45 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95651A038C for ; Mon, 2 Jun 2014 11:34:44 -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_16=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 OyIHMsE3_HD4 for ; Mon, 2 Jun 2014 11:34:41 -0700 (PDT) Received: from pop3.winserver.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 77C371A026B for ; Mon, 2 Jun 2014 11:34:41 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=6936; t=1401734071; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=aOgLAnMa1sLtoN92i0GlKRzZiIY=; b=XXFlsJLXB68eukF1KFln eA8d/jg9WAiXswNORzF3HRJagPDMTIBr9NcpTGoulZuwh0gJypw3N1y+7/5zDvev D/yYw0u9dLUV/Cxa2bRL0nuDmtwnaSWHpGtGkCht1yZqCYul4NUU4CevdI7dLKil 66GlAEku3lAqIevQyAEmRnw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 02 Jun 2014 14:34:31 -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; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1214201115.8045.1572; Mon, 02 Jun 2014 14:34:29 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=6936; t=1401733919; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=sc1VNba ePABDF/Lc4hheEJe/jnMFB7RD2WNXozZCeXg=; b=UWZe4MLv8s9gTAv7suXusrn oeIDO/TqjwcKMtnRbWGFgXZ23NoD1BVFFj5IOL0cfBEoxhcrjovMdv2J5cFqfat4 bSwcKKT/RQmzm2e+3NAucOkwEzSJW3HfvCuD6SNlEhMMxgYPDTwyDqMlcHPTfTpA osYpJ9LkDKBj0w8fmrk8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 02 Jun 2014 14:31:59 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1230566093.9.5824; Mon, 02 Jun 2014 14:31:58 -0400 Message-ID: <538CC3B4.6050504@isdg.net> Date: Mon, 02 Jun 2014 14:34:28 -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: "Stephen J. Turnbull" , Tony Hansen References: <5387F6E0.1070903@att.com> <87ha456dlt.fsf@uwakimon.sk.tsukuba.ac.jp> <538A76ED.4050609@att.com> <8738fn6a96.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <8738fn6a96.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/LNUNOEYufPArlyHXYD6ylKcv1gE Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 02 Jun 2014 18:34:44 -0000 I'm a list software product developer. I believe our list package was among the first to implement domains controls with restrictive domains. In our case, we used the then IETF Proposed Standard ADSP. It followed the guidelines written in the 2006 DSAP (DKIM Signature Authorization Protocol) I-D 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. The main point is that there should be no advocation or promoting what is effectively violating a security protocol, especially of that being advocated with a 5322.From rewrite. I think its an unethical practice to be bypassing a security protocol, intentionally. Its bound to bite you. And what about the domains that don't want you to do this? Unless there is a permission based concept to do this, it is a terrible mistake to open up this door. You won't be able to trust any domain and From rewrites would cause the lost of any protective value the message originally had. What is to suggest that the receiving domains won't learn to adapt to detect these "rewrite/rewrap" loopholes and begin to give such senders bad reputation blocks? Overall, the hurdle to is to get systems to do a LOOKUP in order to get permission to resign. If you assume this is going to be the case, then we don't to be kludging radical methods simply to bypass a security the originating domain does not want you to do anyway. Thats a pretty risky thing to do. I certainly can't support these ideas to rewrite lacking permission to do considerations and against the wishes of the originating domain. -- HLS [1] http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-01.html#anchor14 On 6/2/2014 3:28 AM, Stephen J. Turnbull wrote: > Tony Hansen writes: > > > I would love to see that list of multiple mitigations shared with the > > broader community. That would be useful information for people in the > > IETF, > > I've shared it here in various levels of detail more than once, and > sooner or later it will be in the Mailman FAQ as I'm sure that the > brief descriptions in the admin UI will need amplification. > Basically, Mailman provides two orthogonal features: > > 1. Whether to mitigate, and when to mitigate, that is the question > > a. Don't. > b. Always. > c. Only for posters from DMARC "p=reject" domains. > > 2. How to mitigate: > > a. Replace poster with list in From:, and diddle Reply-To so that > reply-to-poster is as convenient as possible. > b. Wrap the message in a MIME message/rfc822 body. > > Thanks to John Levine, we'll eventually have a 2c option: append > .INVALID to the poster's mailbox in From:. > > > as well as other MLM teams not involved wherever those discussions > > occurred. > > AFAIK there is no particular place where MLM teams meet up; there are > very few interoperation considerations. I would think other MLM teams > would be here now if they cared (cf John Levine's comment on your post). > > > Perhaps there is one or more of those solutions that we SHOULD be > > recommending. > > The only solution currently available I can see recommending is > banning domains that DoS third parties. However, that isn't going to > fly on many, probably the great majority, of Mailman and ListServ > lists. (Majordomo, smartlist, and whatever is used with qmail may > have a rather different user population, as is suggested by John's > observation.) > > All the others have defects that some people consider severe, so will > have to be chosen by the list's administration. > > > And perhaps broader discussions will provide an AHA moment where we see > > a way to solve BOTH MLM's problems AND DMARC's problems with MLMs in the > > face of a p=reject policies. > > My personal belief (as previously mentioned) is that that is a logical > impossibility. But we can hope I'm wrong! > > > Are the current p=reject semantics totally correct? As has been pointed > > out by others, even with mail sent out from banks, there are legitimate > > uses of mailing lists or things like mailing lists where you want copies > > to be received by multiple people. > > The important thing is that the banks' problems with "p=reject" can be > solved (worked around, if you prefer) by the banks, without > cooperation of third parties, and without (much) harm to third parties > (it's unlikely that there are Mailman lists where 314 bank reps will > post to the same list in a week and so knock all subscribers into > disabled state). > > While it would be as nice as getting a pony for the banks' tech staff > to be able to post to this list from the well-known domain, I don't > think that's very high on their list of tasks for their techies. Just > registering a "somebank-inc.com" domain is satisfactory, I suppose. > > > Or alternatively, perhaps p=reject needs to be redefined slightly to > > take advantage of specific recommended practices for mailing lists. > > Perhaps. I'm a fan of "simple protocols used judiciously" > vs. "complex protocols that try to forestall all problems" myself. > > If complexity would make it possible for Yahoo! to use "p=reject" > without DoS'ing mailing list subscribers and their own posters, it > would be worth it, I suppose. > > > > SPF and DKIM are now ancient history, at least as far as Mailman > > > development goes. We've already done what's technically > > > possible. > > > > Since I'm not privy yet to what all GNU Mailman has chosen to do in > > the face of SPF and DKIM, so I don't know how to evaluate that > > statement. Sorry. > > > > If you're saying that you've thrown out all use of DKIM, I consider that > > a sorry state of affairs. > > No. What we've done is > > (1) Put up a FAQ encouraging re-signing by MTAs hosting lists. > (2) Added an option to strip the (presumably broken, we don't check > for it) original DKIM signature. > > There's no real point in MLMs doing more than that as it requires > cooperation from the domain's DNS. OAR (which I don't think is worth > it) could be done, but I think this probably is better done by the MTA > (local MUAs and admins might wish to refer to it). > From nobody Mon Jun 2 11:48:10 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F5E1A038C for ; Mon, 2 Jun 2014 11:48:09 -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 xt39-66ySRQh for ; Mon, 2 Jun 2014 11:48:07 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [192.254.77.197]) by ietfa.amsl.com (Postfix) with ESMTP id A97A11A025F for ; Mon, 2 Jun 2014 11:48:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 7DA9AA0557; Mon, 2 Jun 2014 13:48: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 10024) with ESMTP id cCfDzixLwP5Y; Mon, 2 Jun 2014 13:48:01 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 5F83DA0569; Mon, 2 Jun 2014 13:48:01 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 4A335A055F; Mon, 2 Jun 2014 13:48: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 SfLLUAzsmA34; Mon, 2 Jun 2014 13:48: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 30522A055A; Mon, 2 Jun 2014 13:48:01 -0500 (CDT) Date: Mon, 2 Jun 2014 13:47:59 -0500 (CDT) From: Franck Martin To: "Stephen J. Turnbull" Message-ID: <466746097.24148.1401734879005.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <5387F6E0.1070903@att.com> <87ha456dlt.fsf@uwakimon.sk.tsukuba.ac.jp> <538A76ED.4050609@att.com> <8738fn6a96.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [216.3.18.37] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF29 (Mac)/8.0.5_GA_5839) Thread-Topic: DKIM through mailing lists (rebutting MLs won't change) Thread-Index: sawCweiu0wmnEuRjWgekAOr7J81n8g== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/_Trh62NqG0fP4RSexYRuWuM037U Cc: dmarc@ietf.org, Tony Hansen Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 02 Jun 2014 18:48:09 -0000 ----- Original Message ----- > From: "Stephen J. Turnbull" > To: "Tony Hansen" > Cc: dmarc@ietf.org > Sent: Monday, June 2, 2014 12:28:21 AM > Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) > > Tony Hansen writes: > > > I would love to see that list of multiple mitigations shared with the > > broader community. That would be useful information for people in the > > IETF, > > I've shared it here in various levels of detail more than once, and > sooner or later it will be in the Mailman FAQ as I'm sure that the > brief descriptions in the admin UI will need amplification. > Basically, Mailman provides two orthogonal features: > > 1. Whether to mitigate, and when to mitigate, that is the question > > a. Don't. > b. Always. > c. Only for posters from DMARC "p=reject" domains. > > 2. How to mitigate: > > a. Replace poster with list in From:, and diddle Reply-To so that > reply-to-poster is as convenient as possible. > b. Wrap the message in a MIME message/rfc822 body. > > Thanks to John Levine, we'll eventually have a 2c option: append > .INVALID to the poster's mailbox in From:. > I'm not sure it is wise to encourage the use of "invalid" domains in any of the email headers. The tendency is to become more strict with malformed emails (for instance: reject if none or more than one From field), not more loose. The use of the .INVALID is likely to create problems in the future, if not already with reputation systems. From nobody Mon Jun 2 11:52:54 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772AC1A03E9 for ; Mon, 2 Jun 2014 11:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.32 X-Spam-Level: X-Spam-Status: No, score=-16.32 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, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] 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 sR5CTmkSO2XE for ; Mon, 2 Jun 2014 11:52:51 -0700 (PDT) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E7521A03DF for ; Mon, 2 Jun 2014 11:52:51 -0700 (PDT) Received: from GQ1-EX10-CAHT12.y.corp.yahoo.com (gq1-ex10-caht12.corp.gq1.yahoo.com [10.73.119.193]) by mrout3.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id s52Ipblk016749 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Jun 2014 11:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1401735098; bh=GesvnH0om0Uf6Nukuo3zz4vCNTBB8DsKrjcC3BOMRZE=; h=From:To:Subject:Date:References:In-Reply-To; b=h3d5c5umAMvd8UQ27PmYYeSMTJ+SVG7GvkxCay9VBwpgqJkasEu7AKX8DzWI7rPmt kntUsxuYvDiCVH+2/ypzuCTfECe8DMioZEcWH6DLhDTh+tPcD/gt76ZHx2ZFwMVwHr pe3PuLcbcE655D3T1ev1gqs6qTk8w1WANd2H5v/s= Received: from GQ1-MB01-02.y.corp.yahoo.com ([fe80::a049:b5af:9055:ada6]) by GQ1-EX10-CAHT12.y.corp.yahoo.com ([fe80::692f:da29:9036:7034%14]) with mapi id 14.03.0181.006; Mon, 2 Jun 2014 11:51:37 -0700 From: Elizabeth Zwicky To: Brandon Long , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Yet another mailing list solution thread Thread-Index: AQHPe98NOk2aQ+nFpE+CpSZljpUs65teL5gA Date: Mon, 2 Jun 2014 18:51:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [216.145.54.7] Content-Type: multipart/alternative; boundary="_000_CFAE10FA18170Fzwickyyahooinccom_" MIME-Version: 1.0 X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 735098001 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/wO4H1R0ypSCfMNCYT3EZDqnSYx0 Subject: Re: [dmarc-ietf] Yet another mailing list solution thread 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, 02 Jun 2014 18:52:52 -0000 --_000_CFAE10FA18170Fzwickyyahooinccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Whitelisting mailing well-behaved mailing lists is a hole, but not in gener= al a horrible one; the problems are receiver consistency, scaling and maint= enance, and they are pretty intractable. One variant of the minimal DKIM signature which has been suggested to me is= to double-sign, with a minimal signature and a protective one using two di= fferent selectors. That is currently pointless (if not actually dangerous, = because it's very implementation-dependent what receivers will do in this s= ituation), but there are some possible forward paths from there. I don't th= ink I'm enthused, but it's a novel concept. A mailing-list and receiver change option that has also been suggested to m= e is to have mailing lists include the original message as a MIME component= -- you can then verify the signature on the original message and do some k= ind of comparison to the new one and decide how you feel about it. Again, i= t's a future-work solution. Elizabeth zwicky@yahoo-inc.com From: Brandon Long > Date: Friday, May 30, 2014 at 1:13 AM To: "dmarc@ietf.org" > Subject: [dmarc-ietf] Yet another mailing list solution thread What can DMARC enforcing domains do right now: 1) Whitelist mailing lists from enforcement. This is obviously a hole in D= MARC which lowers the overall utility. Its basically saying "we don't trus= t your p=3DREJECT, we'll sometimes downgrade it to p=3DQUARANTINE". 2) Put a really simple DKIM signature on messages which doesn't cover the s= ubject/body. Ick, but it could theoretically be done. The Future 1) Support Original-Authentication-Results. This requires the MLM to add t= hem in the first place, and for the DMARC enforcing domains to check them. = Has an open question of how best to "trust" the OAR header on a message. = Options there are explicit whitelists from the sending domains (tpa-labels = or whatever) or to leave it up to the individual receiving domain. 2) A new mailing list specific DKIM canonicalization. Its unlikely to be p= ossible to be 100% authentication, its open for debate whether we could com= e up with one that'll provide some level of auth that may be useful in a mo= re complicated "spam/phishing evaluation". 3) Some sort of "permission to relay" token. This is pretty similar to the= DKIM above. 4) Plain old whitelisting (tpa-labels or whatever). Personally, I think wi= thout AuthRes/OAR, this is too big a hole to be useful. 5) More radical changes to MLMs/clients such as defining new headers with a= ssociated client requirements (ie, the footer / subject prefix is theoretic= ally redundant with the adoptions of List-* headers). Other alternatives i= nclude embedding the original message in a wrapper (a message/digest of one= ). Are there any other clients besides mutt which handle this well? Other ideas? Brandon --_000_CFAE10FA18170Fzwickyyahooinccom_ Content-Type: text/html; charset="us-ascii" Content-ID: <2D914A7CE65CE54584513504ABD10156@yforest.corp.yahoo.com> Content-Transfer-Encoding: quoted-printable

Whitelisting mailing well-behaved mailing lists is a hole, but not in = general a horrible one; the problems are receiver consistency, scaling and = maintenance, and they are pretty intractable.

One variant of the minimal DKIM signature which has been suggested to = me is to double-sign, with a minimal signature and a protective one using t= wo different selectors. That is currently pointless (if not actually danger= ous, because it's very implementation-dependent what receivers will do in this situation), but there are some possible for= ward paths from there. I don't think I'm enthused, but it's a novel concept= .

A mailing-list and receiver change option that has also been suggested= to me is to have mailing lists include the original message as a MIME comp= onent -- you can then verify the signature on the original message and do s= ome kind of comparison to the new one and decide how you feel about it. Again, it's a future-work solution.<= /div>

Elizab= eth
zwicky= @yahoo-inc.com

From: Brandon Long <blong@google.com>
Date: Friday, May 30, 2014 at 1:13 = AM
To: "dmarc@ietf.org" <dma= rc@ietf.org>
Subject: [dmarc-ietf] Yet another m= ailing list solution thread


What can DMARC enforcing domains do right now:
1) Whitelist mailing lists from enforcement.  This is obviously a= hole in DMARC which lowers the overall utility.  Its basically saying= "we don't trust your p=3DREJECT, we'll sometimes downgrade it to p=3D= QUARANTINE".

2) Put a really simple DKIM signature on messages which doesn't cover = the subject/body.  Ick, but it could theoretically be done.

The Future
1) Support Original-Authentication-Results.  This requires the ML= M to add them in the first place, and for the DMARC enforcing domains to ch= eck them.  Has an open question of how best to "trust" the O= AR header on a message.  Options there are explicit whitelists from the sending domains (tpa-labels or whatever) or to leave i= t up to the individual receiving domain.

2) A new mailing list specific DKIM canonicalization.  Its unlike= ly to be possible to be 100% authentication, its open for debate whether we= could come up with one that'll provide some level of auth that may be usef= ul in a more complicated "spam/phishing evaluation".

3) Some sort of "permission to relay" token.  This is p= retty similar to the DKIM above.

4) Plain old whitelisting (tpa-labels or whatever).  Personally, = I think without AuthRes/OAR, this is too big a hole to be useful.

5) More radical changes to MLMs/clients such as defining new headers w= ith associated client requirements (ie, the footer / subject prefix is theo= retically redundant with the adoptions of List-* headers).  Other alte= rnatives include embedding the original message in a wrapper (a message/digest of one).  Are there any other = clients besides mutt which handle this well?

Other ideas?

Brandon
 --_000_CFAE10FA18170Fzwickyyahooinccom_-- From nobody Mon Jun 2 12:44:12 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF2A1A0223 for ; Mon, 2 Jun 2014 12:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 D0-q6wn3C7cw for ; Mon, 2 Jun 2014 12:43:54 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63AA81A0425 for ; Mon, 2 Jun 2014 12:43:54 -0700 (PDT) Received: by mail-ig0-f180.google.com with SMTP id c1so3858695igq.1 for ; Mon, 02 Jun 2014 12:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dTDNB50cWRX8g+VYzZ2h32Kcymr813g3jVHHHCi0esk=; b=Prcb3dbkkzPSSY2aGh297/v6zbkzkYhfEl3U4mEm7wsCTtFYcXuoNycWhocDe9n8Jd xGFX9aa6Ar0hIoiZ9LnFLtuXO8/HgG28O1vE9RDpSZnVmS/0H9Dh+e7bQQxFztRHy0Xy uS084s3SqPl1R9r+Ce/vm6XatRDR9E9kq3cf7jrCZmuhA9QPGM+UCfQKO+jDaPa4A7f7 jqngCcbIkb4hsOVFT00wTExAQzhXOX7zWky/+GaqW8/WmytMDBadRLUuvBwzzKvfBNl4 F4WGjEe4Z8hlmUVdwsTTM0yNKfqIQ1i21xOZM/DA9JMsJl23BqGi4TePhdK7Sm69SmfE B8tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dTDNB50cWRX8g+VYzZ2h32Kcymr813g3jVHHHCi0esk=; b=hOD/tVVOS0KFa+re+qiBRulLX44DGZ4hIa0tSwPfXLCIpRlWYeNlwZPAWwvOdJFyOQ oEMQYFtS3yTfPbSCGulfLSAh/hLIDAxthOLG/SsipyTI/qpNq5n0mLPJRyUA0pDlBSOg YMcwMkjB42pWYSIz5u9LqkYA3hlFXN0EoINthACTSnZzKaEa9x4i0ANNYx/ILH4tgBKc l7mdFNBoP+yqpSnuPWZZMw2cUBmicSBp3dNcUiAioU0dgAks4bApDxG49A9AyU5aOBCs 1ftgChIJI0mSPEldXQhQbFViAV1PPGb9o+mXCaVARwcudtwwReUUcub69VAwxBk9JF1N PM6A== X-Gm-Message-State: ALoCoQmj2gQhYNrYH2Ce5E9WQB+M0XI9ecx+fFWk2L37YHXVcq32SI1Ru9D2xnSuBdaqwbTZnT+R MIME-Version: 1.0 X-Received: by 10.50.129.97 with SMTP id nv1mr22291476igb.32.1401738228804; Mon, 02 Jun 2014 12:43:48 -0700 (PDT) Received: by 10.64.213.73 with HTTP; Mon, 2 Jun 2014 12:43:48 -0700 (PDT) In-Reply-To: <20140531031056.2397.qmail@joyce.lan> References: <20140531031056.2397.qmail@joyce.lan> Date: Mon, 2 Jun 2014 12:43:48 -0700 Message-ID: From: Brandon Long To: John Levine Content-Type: multipart/alternative; boundary=047d7b41431c32572e04fadf9d40 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/bYRDu6FaiJnVMalVA1uS08zrOXw Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Yet another mailing list solution thread 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, 02 Jun 2014 19:44:03 -0000 --047d7b41431c32572e04fadf9d40 Content-Type: text/plain; charset=UTF-8 On Fri, May 30, 2014 at 8:10 PM, John Levine wrote: > >1) Support Original-Authentication-Results. This requires the MLM to add > >them in the first place, and for the DMARC enforcing domains to check > them. > > Has an open question of how best to "trust" the OAR header on a message. > > Options there are explicit whitelists from the sending domains > (tpa-labels > >or whatever) or to leave it up to the individual receiving domain. > > This keeps reducing to the previous case. If you know what senders > you trust, why do you need the OAR header? > OAR and the signed mailing list means that I trust the mailing list to have properly checked the original validation. The mailing list didn't reject the DMARC message because it was valid, but its modifying the message, so no one downstream knows that it was fine. Or, it may not enforce DMARC at all. OAR allows the MLM to tell everyone else what the auth state was prior to munging. The MLM may choose to forward the message regardless of the auth state, but receivers downstream can then enforce. The OAR isn't necessary for a DMARC "compliant" MLM which would know to make sure the message passed DMARC as sent by following one of the mitigation strategies (don't munge the message, munge the from, embed the message as an attachment, etc). It seems necessary for any whitelisting scheme, however, otherwise an "anyone can post" mailing list on a host which doesn't enforce DMARC is a wide-open hole. Brandon --047d7b41431c32572e04fadf9d40 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, May 30, 2014 at 8:10 PM, John Levine <= johnl@taugh.com>= ; wrote:
>1) Support Original-Auth= entication-Results. =C2=A0This requires the MLM to add
>them in the first place, and for the DMARC enforcing domains to check t= hem.
> Has an open question of how best to "trust" the OAR header o= n a message.
> Options there are explicit whitelists from the sending domains (tpa-la= bels
>or whatever) or to leave it up to the individual receiving domain.

This keeps reducing to the previous case. =C2=A0If you know what send= ers
you trust, why do you need the OAR header?

<= div>OAR and the signed mailing list means that I trust the mailing list to = have properly checked the original validation.

The mailing list didn't reject the DMARC message because it was valid, = but its modifying the message, so no one downstream knows that it was fine.= =C2=A0Or, it may not enforce DMARC at all.

OAR al= lows the MLM to tell everyone else what the auth state was prior to munging= . =C2=A0The MLM may choose to forward the message regardless of the auth st= ate, but receivers downstream can then enforce.

The OAR isn't necessary for a DMARC "compliant= " MLM which would know to make sure the message passed DMARC as sent b= y following one of the mitigation strategies (don't munge the message, = munge the from, embed the message as an attachment, etc). =C2=A0It seems ne= cessary for any whitelisting scheme, however, otherwise an "anyone can= post" mailing list on a host which doesn't enforce DMARC is a wid= e-open hole.

Brandon
--047d7b41431c32572e04fadf9d40-- From nobody Mon Jun 2 12:55:49 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC071A041F for ; Mon, 2 Jun 2014 12:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.618 X-Spam-Level: X-Spam-Status: No, score=-4.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 InW9JARDIOSh for ; Mon, 2 Jun 2014 12:55:46 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 781751A0069 for ; Mon, 2 Jun 2014 12:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1401738943; x=1433274943; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zJUOZrl6fbYlhjXIXcZB/s3cVUMyXReqgEX3DAezneE=; b=ybP/FaVcLnS8ZVYYiKVvqIFsVgWy8xG3nLgxmUT4tXgu+wryUqK5qlgX snIMRDOpLCf0mFslK68zoiKtbBIUzWFSgnKbvKjJV2hqEbdloiKNQejJl RPR9zCAqKhinF6zuouXjN25oV0V7lpDrCU8nipfugZBF0vbFjqfrJnURK 0=; X-IronPort-AV: E=Sophos;i="4.98,959,1392192000"; d="scan'208";a="125050471" Received: from ESV4-EXC01.linkedin.biz ([fe80::d7c:dc04:aea1:97d7]) by esv4-cas01.linkedin.biz ([172.18.46.140]) with mapi id 14.03.0174.001; Mon, 2 Jun 2014 12:55:40 -0700 From: Kurt Andersen To: "Stephen J. Turnbull" , Tony Hansen Thread-Topic: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) Thread-Index: AQHPe7TivF4NU9hER0SK7lgXkKhbh5tbb9EAgAByz4CAAgPEgIAAW04A Date: Mon, 2 Jun 2014 19:55:39 +0000 Message-ID: References: <5387F6E0.1070903@att.com> <87ha456dlt.fsf@uwakimon.sk.tsukuba.ac.jp> <538A76ED.4050609@att.com> <8738fn6a96.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <8738fn6a96.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: [172.18.46.252] Content-Type: text/plain; charset="us-ascii" Content-ID: <1A380D63A058704B856C8E1FAC8ED160@linkedin.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/_Z63vjB13o59sO-d3u4DVKzgo5U Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 02 Jun 2014 19:55:48 -0000 On 2014-06-02, 00:28 , "Stephen J. Turnbull" wrote: >Thanks to John Levine, we'll eventually have a 2c option: append >.INVALID to the poster's mailbox in From:. And how long do you think it will be before some clever organization buys the .INVALID TLD? --Kurt Andersen From nobody Mon Jun 2 12:58:57 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307271A0407 for ; Mon, 2 Jun 2014 12:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, MANGLED_FROM=2.3, RP_MATCHES_RCVD=-0.651, 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 X9WhnsuEWO2Z for ; Mon, 2 Jun 2014 12:58:53 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 414BB1A0069 for ; Mon, 2 Jun 2014 12:58:53 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id y20so4940545ier.22 for ; Mon, 02 Jun 2014 12:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=35BNzlzD3rSnd/MhUrCKPUTAeD2qRlovs3aY3eRAE+0=; b=Bh81LzUejgMeAUGYH4U2G6gZQgRAQMgdc7dGq/vAyifHi/Ns5TmIa7lAgJhkYgyQPk 0E8UemX71d+lBGKIQGHar/ktRMAQTR6vF/i+40TIPhFM+e+z3PI/acmal+lz01izLpGP xXVILvPa4GPKWnkfg6RlKjsS5b0Y5hrav7+5mjlsDaXL2zt6wxdwh+PSFMtJ6alu5Nqq m1rCIoGdO1w3oY9+YOcC+HnWyPhSwvD5ULxKclOwr3drldfmBwffaYvFkhZPHopKxHMc E3VPHg//adT9JF+Iej3FYqM1+RW3ssXgNKKwcgRpNtvgJ8xHML1fDR65MDa2M4gG83gr weag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=35BNzlzD3rSnd/MhUrCKPUTAeD2qRlovs3aY3eRAE+0=; b=YRwK9N9YrapGNaKxSKOUuWYDgWTLzR8ZbA639NkyJgBC6qaNFvXgXhr0KCoqZnqeuq kuzJ0iaCPIa81zU59R2dqmjG8IpeNkr8n3Xy8zWgBmK3Cge3RJQHZ457zXafhoUeW+iH 3KZxkTepR3OhyHFFLm7rvE7+jBoD3zolwICz5skIQ+8P0r1gYp0uIKm2kKkuApA0ZOmD T6rjqIzpfDDP/xiIDCDqawlHgR/DXQW/TS6GwgvKSo74iN1Ne0X/RnWOM33KrSfbaV7s igOUt1VoOCxOxaTBvrlGwIa3KZH6EYSFn01t8OTKDGcBzhcj7ybRQfIR4NDF4ggErPAs ML0A== X-Gm-Message-State: ALoCoQlQn/EQxIA/PqThJuv4wkuV7BdPuTPK02SW9GbF4ypZwUuBGNynhHpO4vHp+zOitDIlS6yL MIME-Version: 1.0 X-Received: by 10.50.111.161 with SMTP id ij1mr22423198igb.12.1401739127635; Mon, 02 Jun 2014 12:58:47 -0700 (PDT) Received: by 10.64.213.73 with HTTP; Mon, 2 Jun 2014 12:58:47 -0700 (PDT) In-Reply-To: <87r43a5c79.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87r43a5c79.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Mon, 2 Jun 2014 12:58:47 -0700 Message-ID: From: Brandon Long To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=047d7b3a8a62c592ee04fadfd21b Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/oRmZYOf9ZpQJa7fnWWG_IIN5Wbw Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Yet another mailing list solution thread 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, 02 Jun 2014 19:58:55 -0000 --047d7b3a8a62c592ee04fadfd21b Content-Type: text/plain; charset=UTF-8 On Sat, May 31, 2014 at 6:07 AM, Stephen J. Turnbull wrote: > Brandon Long writes: > > > 1) Reject posting from p=REJECT users > > +1 <0.2 wink> > > > It seems like [ignoring DMARC bounces when checking if the > > recipient is able to receive] should be relatively uncontroversial, > > Mailman is already working on this. Unfortunately, some domains just > use a generic 5.7.x policy bounce, and other don't even give you that > much information. (We are guessing, but backtracking to the sender -- > you don't always even get that information -- and correlating with > other DMARC bounces, we're pretty sure that these are DMARC bounces.) > We use 5.7.1, and in general we don't let 5.7.1 errors set users to bouncing (though, enough bounces will do so eventually). Its tricky, that's for sure, but generally we treat 5.7.1 as "we can't know whether or not these will ever succeed or its something specific to this message") > > > messages would be rejected... Perhaps we should agree on an > > extended smtp status code that such rejections should use in order > > to make this easier to implement. > > This will take years to diffuse into the installed base, and some > sites have this boneheaded idea that giving any information about why > a message was rejected harms their security, so won't implement anyway. > If you're implementing DMARC, aren't you already on the bleeding edge? And, if its going to take a long time, then better to do so as early as possible. And one could certainly hope that the olive branch from Y! would indicate willingness to make that level of change. DMARC also seems like a really weird thing to want to "hide". (we try not to be too obtuse with our rejection reasons because we find that the abusers usually know the reason, its the innocent or semi-innocent that gets caught that needs help...) > > > [Rewriting From:] could potentially use some finessing or > > standardization. For example, several MLMs are moving the original > > From header to X-Original-From, I could also imagine a > > List-Original-From or List-Poster header. Standardizing on that > > would allow clients to do intelligent things about the display of > > the two pieces of information, or handling reply-to better. > > The *last* thing we want is clients doing anything intelligent with > any of those headers. The problem that DMARC addresses has nothing to > do with the letters F-R-O-M. It has to do with identity alignment. > It just happens that RFC5322 (and predecessors) standardized From: for > conveying originatory identity. So as soon as MUAs start displaying > Use-This-Field-To-Bypass-DMARC: to users, DMARC will *need* to be > revised to sign that one, too -- with a signature authorized by the > Author Domain, *not* the ML domain. This of course is impossible > without Doug Otis's TPA-labels or something like that. > Yes and no. I had a similar argument internally recently, and had a really hard time convincing folks that if there was a way to display that information safely, we wouldn't have needed DMARC in the first place. That said, having the information available for searches (from:blong) or to make sure contacts aren't messed with, or maybe in extended pop-ups (ie, if you expand the address field, it could say something like "the original sender was supposedly foo@foo.com, but we can't guarantee that). Or, it could be used for reply-to handling (though, we just add the original address to the reply-to for that now). > > > What can DMARC enforcing domains do right now: > > > 1) Whitelist mailing lists from enforcement. This is obviously a hole > in > > DMARC which lowers the overall utility. Its basically saying "we don't > > trust your p=REJECT, we'll sometimes downgrade it to p=QUARANTINE". > > That horse already left the barn. I don't know what GMail's criterion > is, but our testing demonstrates that some mailing list posts are > passed through to the spam folder rather than rejected. > > I don't understand what you mean by "lowers overall utility". In > fact, it's quite clear from the way Yahoo! is advocating various > mitigation strategies that they really do not mean DMARC reject, they > mean Do-What-I-Mean reject. That's what GMail gives them. > > For the others, I agree with John Levine's comments. In a perfect DMARC world, we wouldn't need the hole. Its also clear that eventually the bad actors will find the hole, and so it will eventually go away or change. Depending on how much mail would be caught, a better hole may be made, or there may be no hole. I know which way our spam/phishy team is leaning on the subject. Brandon --047d7b3a8a62c592ee04fadfd21b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sat, May 31, 2014 at 6:07 AM, Stephen J. Turnbull <stephen@xem= acs.org> wrote:
Brandon Long writes:

=C2=A0> 1) Reject posting from p=3DREJECT users

+1 <0.2 wink>

=C2=A0> It seems like [ignoring DMARC bounces when checking if the
=C2=A0> recipient is able to receive] should be relatively uncontroversi= al,

Mailman is already working on this. =C2=A0Unfortunately, some domains just<= br> use a generic 5.7.x policy bounce, and other don't even give you that much information. =C2=A0(We are guessing, but backtracking to the sender --=
you don't always even get that information -- and correlating with
other DMARC bounces, we're pretty sure that these are DMARC bounces.)

We use 5.7.1, and in general we don'= t let 5.7.1 errors set =C2=A0users to bouncing=C2=A0
(though, eno= ugh bounces will do so eventually). =C2=A0Its tricky, that's for sure, = but generally we
treat 5.7.1 as "we can't know whether or not these will ever = succeed or its=C2=A0
something specific to this message")
=C2=A0

=C2=A0> messages would be rejected... Perhaps we should agree on an
=C2=A0> extended smtp status code that such rejections should use in ord= er
=C2=A0> to make this easier to implement.

This will take years to diffuse into the installed base, and some
sites have this boneheaded idea that giving any information about why
a message was rejected harms their security, so won't implement anyway.=

If you're implementing DMARC, aren= 't you already on the bleeding edge?
And, if its going to tak= e a long time, then better to do so as early as possible.

And one could certainly hope that the olive branch from= Y! would indicate=C2=A0
willingness to make that level of change= .

DMARC also seems like a really weird thing to wa= nt to "hide".

(we try not to be too obtuse with our rejection reasons= because we find that the abusers
usually know the reason, its th= e innocent or semi-innocent that gets caught that needs=C2=A0
hel= p...)
=C2=A0

=C2=A0> [Rewriting From:] could potentially use some finessing or
=C2=A0> standardization. =C2=A0For example, several MLMs= are moving the original
=C2=A0> From header to X-Original-From, I could also imagine a
=C2=A0> List-Original-From or List-Poster header. =C2=A0Standardizing on= that
=C2=A0> would allow clients to do intelligent things about the display o= f
=C2=A0> the two pieces of information, or handling reply-to better.

The *last* thing we want is clients doing anything intelligent with any of those headers. =C2=A0The problem that DMARC addresses has nothing to=
do with the letters F-R-O-M. =C2=A0It has to do with identity alignment. It just happens that RFC5322 (and predecessors) standardized From: for
conveying originatory identity. =C2=A0So as soon as MUAs start displaying Use-This-Field-To-Bypass-DMARC: to users, DMARC will *need* to be
revised to sign that one, too -- with a signature authorized by the
Author Domain, *not* the ML domain. =C2=A0This of course is impossible
without Doug Otis's TPA-labels or something like that.
=

Yes and no. =C2=A0I had a similar argument internally r= ecently, and had a really hard time
convincing folks that if ther= e was a way to display that information safely, we wouldn't
have needed DMARC in the first place.

That sa= id, having the information available for searches (from:blong) or to make s= ure
contacts aren't messed with, or maybe in extended pop-ups= (ie, if you expand the address field,
it could say something like "the original sender was supposedly <= a href=3D"mailto:foo@foo.com">foo@foo.com, but we can't guarantee t= hat).
Or, it could be used for reply-to handling (though, we just= add the original address to the reply-to for that now).
=C2=A0

=C2=A0> What can DMARC enforcing domains do right now:

=C2=A0> 1) Whitelist mailing lists from enforcement. =C2=A0This is obvio= usly a hole in
=C2=A0> DMARC which lowers the overall utility. =C2=A0Its basically sayi= ng "we don't
=C2=A0> trust your p=3DREJECT, we'll sometimes downgrade it to p=3DQ= UARANTINE".

That horse already left the barn. =C2=A0I don't know what GMail&#= 39;s criterion
is, but our testing demonstrates that some mailing list posts are
passed through to the spam folder rather than rejected.

I don't understand what you mean by "lowers overall utility".= =C2=A0In
fact, it's quite clear from the way Yahoo! is advocating various
mitigation strategies that they really do not mean DMARC reject, they
mean Do-What-I-Mean reject. =C2=A0That's what GMail gives them.

For the others, I agree with John Levine's comments.
<= br>
In a perfect DMARC world, we wouldn't need the hole. =C2= =A0Its also clear that eventually the bad actors
will find the ho= le, and so it will eventually go away or change. =C2=A0Depending on how muc= h mail would
be caught, a better hole may be made, or there may be no hole. =C2=A0I= know which way our spam/phishy team is leaning on the subject.
<= br>
Brandon
--047d7b3a8a62c592ee04fadfd21b-- From nobody Mon Jun 2 13:00:44 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D9B1A0432 for ; Mon, 2 Jun 2014 13:00:42 -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 OAAOFXBenxYh for ; Mon, 2 Jun 2014 13:00:40 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABD3D1A042E for ; Mon, 2 Jun 2014 13:00:40 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id D655DD04616; Mon, 2 Jun 2014 16:00:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1401739234; bh=XPHUuHmQK2K1rCywDhUlAXXbIPSUkYnFtPscymh7LVQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Nt4glDS/uaFwAP1R3HOfhxjXVjoWi4mCQWmFAMahUVMygjAnQOwKd4FpynwNk6f5k qD1GLnuIFS7k8RA5OXl+ioXTAT9HboVj9krS2tFMsPDz85W1wuiXPhqx3egufcKIun x91jEY8MrENq/NoQmQxfECBEo8ISlw6C9dB6zEcw= Received: from scott-latitude-e6320.localnet (unknown [209.140.86.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 27EAFD04377; Mon, 2 Jun 2014 16:00:33 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 02 Jun 2014 16:00:25 -0400 Message-ID: <1512020.bERtnPcCHi@scott-latitude-e6320> User-Agent: KMail/4.13 (Linux/3.13.0-27-generic; KDE/4.13.0; x86_64; ; ) In-Reply-To: References: <20140531031056.2397.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ZVPZP7tB1nTtCB0iXcWxvKLylOo Subject: Re: [dmarc-ietf] Yet another mailing list solution thread 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, 02 Jun 2014 20:00:43 -0000 On Monday, June 02, 2014 12:43:48 Brandon Long wrote: > On Fri, May 30, 2014 at 8:10 PM, John Levine wrote: > > >1) Support Original-Authentication-Results. This requires the MLM to add > > >them in the first place, and for the DMARC enforcing domains to check > > > > them. > > > > > Has an open question of how best to "trust" the OAR header on a message. > > > Options there are explicit whitelists from the sending domains > > > > (tpa-labels > > > > >or whatever) or to leave it up to the individual receiving domain. > > > > This keeps reducing to the previous case. If you know what senders > > you trust, why do you need the OAR header? > > OAR and the signed mailing list means that I trust the mailing list to have > properly checked the original validation. > > The mailing list didn't reject the DMARC message because it was valid, but > its modifying the message, so no one downstream knows that it was fine. > Or, it may not enforce DMARC at all. > > OAR allows the MLM to tell everyone else what the auth state was prior to > munging. The MLM may choose to forward the message regardless of the auth > state, but receivers downstream can then enforce. > > The OAR isn't necessary for a DMARC "compliant" MLM which would know to > make sure the message passed DMARC as sent by following one of the > mitigation strategies (don't munge the message, munge the from, embed the > message as an attachment, etc). It seems necessary for any whitelisting > scheme, however, otherwise an "anyone can post" mailing list on a host > which doesn't enforce DMARC is a wide-open hole. If I already know to trust the mailing list, what does OAR cause me to do differently? Scott K From nobody Mon Jun 2 13:10:15 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880B11A0455 for ; Mon, 2 Jun 2014 13:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 jSEpa5U23rZB for ; Mon, 2 Jun 2014 13:10:10 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AA041A0447 for ; Mon, 2 Jun 2014 13:10:10 -0700 (PDT) Received: by mail-ig0-f171.google.com with SMTP id c1so3839196igq.10 for ; Mon, 02 Jun 2014 13:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qhBoUVuIDKGyvmttrLfGg7/tuIX7qvBvMOODwu8mhs4=; b=CnNeI1xRuRtiCNy4g36t/nzysTwzmaS8JTyMb/5zPLSL4+Peva1aIkWK0hzmk1OaM0 f0Goikr7+HdH0ln6nNbz+orNmv9Pt/pv2dPnVwli+/Xm2Wsgj/a0EMi9O6cyuZDdmcTa mPUcsaBIM6v34l3xvhXHAxv8Qw6a/oIkg1VSrMUlEVwqf6R9TW7HGqqeinH/kq87Olre HQqz4qCgJ6E0uuKzJgmfNYJ5IebB8cjbvVxfWxfkqOTLEKo4zmw+Tungz9SZ08BOgh3o NTyU7PeqFmLnw9YWPxm2u3KCm4K7MgvkBiLdptzZRs0Mt4XTXHu4w48/Mb4mjy+yLoPG IlVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qhBoUVuIDKGyvmttrLfGg7/tuIX7qvBvMOODwu8mhs4=; b=LHPJ2H2PhkU4TuszRAKIJcxuzwPcnrovWEApdUoznOd/cgN8c17s3+nhW8AX2g7Awm 90PoDwYOK7PlNZojgYmY4efz41cS00lleYZy0iJCyI40lyppt97uPGuCHhmwGGlmf/Rh vwoLCSsz2wUeW4thNXAvd0lp8s6Y+BysvfIz+GERtGt7Gd2+cGL5liVvmdEGi/dzGi1Y VRp1KWjtvGpagDXG9UcpbmorZC9we8IsFUTtcIR/KbaAP+dwYNs1J+tKrYIIp5mAJH0w ZCmMKMiiDLM2D9nM8MSdwyenK1IpHP1rfTzZSTkLeW15zi1qi8eZaeXl7va9yExrltwY 80dQ== X-Gm-Message-State: ALoCoQl10oUmi9VkZuH4LitBKQ7uuonO9NwwdBpvd+31zKlU0zu2VIJPyGXLga/0VQveEPbfoqFP MIME-Version: 1.0 X-Received: by 10.42.212.18 with SMTP id gq18mr36306413icb.48.1401739804596; Mon, 02 Jun 2014 13:10:04 -0700 (PDT) Received: by 10.64.213.73 with HTTP; Mon, 2 Jun 2014 13:10:04 -0700 (PDT) In-Reply-To: <1512020.bERtnPcCHi@scott-latitude-e6320> References: <20140531031056.2397.qmail@joyce.lan> <1512020.bERtnPcCHi@scott-latitude-e6320> Date: Mon, 2 Jun 2014 13:10:04 -0700 Message-ID: From: Brandon Long To: Scott Kitterman Content-Type: multipart/alternative; boundary=20cf303e9d821f095e04fadffb36 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/KBFdRPM7tDyakzm0Iw2v7afG1fU Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Yet another mailing list solution thread 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, 02 Jun 2014 20:10:13 -0000 --20cf303e9d821f095e04fadffb36 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 2, 2014 at 1:00 PM, Scott Kitterman wrote: > On Monday, June 02, 2014 12:43:48 Brandon Long wrote: > > On Fri, May 30, 2014 at 8:10 PM, John Levine wrote: > > > >1) Support Original-Authentication-Results. This requires the MLM to > add > > > >them in the first place, and for the DMARC enforcing domains to check > > > > > > them. > > > > > > > Has an open question of how best to "trust" the OAR header on a > message. > > > > Options there are explicit whitelists from the sending domains > > > > > > (tpa-labels > > > > > > >or whatever) or to leave it up to the individual receiving domain. > > > > > > This keeps reducing to the previous case. If you know what senders > > > you trust, why do you need the OAR header? > > > > OAR and the signed mailing list means that I trust the mailing list to > have > > properly checked the original validation. > > > > The mailing list didn't reject the DMARC message because it was valid, > but > > its modifying the message, so no one downstream knows that it was fine. > > Or, it may not enforce DMARC at all. > > > > OAR allows the MLM to tell everyone else what the auth state was prior to > > munging. The MLM may choose to forward the message regardless of the > auth > > state, but receivers downstream can then enforce. > > > > The OAR isn't necessary for a DMARC "compliant" MLM which would know to > > make sure the message passed DMARC as sent by following one of the > > mitigation strategies (don't munge the message, munge the from, embed the > > message as an attachment, etc). It seems necessary for any whitelisting > > scheme, however, otherwise an "anyone can post" mailing list on a host > > which doesn't enforce DMARC is a wide-open hole. > > If I already know to trust the mailing list, what does OAR cause me to do > differently? > What does "trust" mean there? Here's an example we ran into. We had an open-posting (anyone can post) mailing list on a "trusted" domain, but there was no way for gmail to know the mailing list was open posting, and it didn't enforce DMARC. The "reputation" of the mailing list was stellar, 99%+.. but a spear phishing attack was made through the mailing list. So, as I said, if "trust" means "enforces DMARC", then yes, OAR is unnecessary. But, that is a level that I don't expect many MLM services to do. If ietf.org doesn't enforce DMARC, then "trusting" its mailing lists for DMARC enforcement makes no sense. OTOH, I can potentially imagine many MLM services at least upgrading to doing spf/dkim auth and signing their messages. I can then see from the receivers end, that this service signs 99+% of its mail and adds an OAR header, then its easy for me to manage a reputation for their service and whitelist that service or mailing list. Even then, we would still be at the mercy if the service was compromised or a hole was found where by a third party was able to send mail through their servers and have it signed, but that issue is less likely or at least, there's only so much that blanket protections can do against that level of motivated attacker. Brandon --20cf303e9d821f095e04fadffb36 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Jun 2, 2014 at 1:00 PM, Scott Kitterman &= lt;sklist@kitterm= an.com> wrote:
On M= onday, June 02, 2014 12:43:48 Brandon Long wrote:
> On Fri, May 30, 2014 at 8:10 PM, John Levine <johnl@taugh.com> wrote:
> > >1) Support Original-Authentication-Results. =C2=A0This requir= es the MLM to add
> > >them in the first place, and for the DMARC enforcing domains = to check
> >
> > them.
> >
> > > Has an open question of how best to "trust" the OA= R header on a message.
> > > Options there are explicit whitelists from the sending domai= ns
> >
> > (tpa-labels
> >
> > >or whatever) or to leave it up to the individual receiving do= main.
> >
> > This keeps reducing to the previous case. =C2=A0If you know what = senders
> > you trust, why do you need the OAR header?
>
> OAR and the signed mailing list means that I trust the mailing list to= have
> properly checked the original validation.
>
> The mailing list didn't reject the DMARC message because it was va= lid, but
> its modifying the message, so no one downstream knows that it was fine= .
> =C2=A0Or, it may not enforce DMARC at all.
>
> OAR allows the MLM to tell everyone else what the auth state was prior= to
> munging. =C2=A0The MLM may choose to forward the message regardless of= the auth
> state, but receivers downstream can then enforce.
>
> The OAR isn't necessary for a DMARC "compliant" MLM whic= h would know to
> make sure the message passed DMARC as sent by following one of the
> mitigation strategies (don't munge the message, munge the from, em= bed the
> message as an attachment, etc). =C2=A0It seems necessary for any white= listing
> scheme, however, otherwise an "anyone can post" mailing list= on a host
> which doesn't enforce DMARC is a wide-open hole.

If I already know to trust the mailing list, what does OAR caus= e me to do
differently?

What does "trust"= ; mean there?

Here's an example we ran into. = =C2=A0We had an open-posting (anyone can post) mailing list on a "trus= ted" domain, but there was no way for gmail to know the mailing list w= as open posting, and it didn't enforce DMARC.

The "reputation" of the mailing list was stel= lar, 99%+.. but a spear phishing attack was made through the mailing list.<= /div>

So, as I said, if "trust" means "en= forces DMARC", then yes, OAR is unnecessary. =C2=A0But, that is a leve= l that I don't expect many MLM services to do. =C2=A0If ietf.org doesn't enforce DMARC, then "trusting&qu= ot; its mailing lists for DMARC enforcement makes no sense. =C2=A0OTOH, I c= an potentially imagine many MLM services at least upgrading to doing spf/dk= im auth and signing their messages. =C2=A0I can then see from the receivers= end, that this service signs 99+% of its mail and adds an OAR header, then= its easy for me to manage a reputation for their service and whitelist tha= t service or mailing list. =C2=A0Even then, we would still be at the mercy = if the service was compromised or a hole was found where by a third party w= as able to send mail through their servers and have it signed, but that iss= ue is less likely or at least, there's only so much that blanket protec= tions can do against that level of motivated attacker.

Brandon
--20cf303e9d821f095e04fadffb36-- From nobody Mon Jun 2 13:18:58 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88BD01A0439 for ; Mon, 2 Jun 2014 13:18:57 -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 n09frXyr4hoH for ; Mon, 2 Jun 2014 13:18:56 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [192.254.77.197]) by ietfa.amsl.com (Postfix) with ESMTP id DBE2E1A0433 for ; Mon, 2 Jun 2014 13:18:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 9D0BB60228; Mon, 2 Jun 2014 15:18:49 -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 ZhuWR6idkC5p; Mon, 2 Jun 2014 15:18:49 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 4B3D86023F; Mon, 2 Jun 2014 15:18:49 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 2947660242; Mon, 2 Jun 2014 15:18:49 -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 Zg1VdSAQXdtj; Mon, 2 Jun 2014 15:18:48 -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 DAE7360215; Mon, 2 Jun 2014 15:18:48 -0500 (CDT) Date: Mon, 2 Jun 2014 15:18:47 -0500 (CDT) From: Franck Martin To: Kurt Andersen Message-ID: <55382129.27361.1401740317786.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <5387F6E0.1070903@att.com> <87ha456dlt.fsf@uwakimon.sk.tsukuba.ac.jp> <538A76ED.4050609@att.com> <8738fn6a96.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [216.3.18.37] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF29 (Mac)/8.0.5_GA_5839) Thread-Topic: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) Thread-Index: AQHPe7TivF4NU9hER0SK7lgXkKhbh5tbb9EAgAByz4CAAgPEgIAAW04AqddvBFs= Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/a8a0geQa-xdncoPTf6pI36uDGmA Cc: dmarc@ietf.org, Tony Hansen , "Stephen J. Turnbull" Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 02 Jun 2014 20:18:57 -0000 ----- Original Message ----- > From: "Kurt Andersen" > To: "Stephen J. Turnbull" , "Tony Hansen" > Cc: dmarc@ietf.org > Sent: Monday, June 2, 2014 12:55:39 PM > Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't= change) >=20 > On 2014-06-02, 00:28 , "Stephen J. Turnbull" > wrote: >=20 > >Thanks to John Levine, we'll eventually have a 2c option: append > >.INVALID to the poster's mailbox in From:. >=20 > And how long do you think it will be before some clever organization buys > the .INVALID TLD? >=20 Invalid is a reserved TLD for =E2=80=9Cinvalid=E2=80=9D domains.=20 http://en.wikipedia.org/wiki/Top-level_domain#Reserved_domains But why would you accept emails from invalid domains in the first instance? From nobody Mon Jun 2 13:35:02 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8C81A0439 for ; Mon, 2 Jun 2014 13:35: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 zLVdXEYBrgNB for ; Mon, 2 Jun 2014 13:34:59 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF90C1A0410 for ; Mon, 2 Jun 2014 13:34:59 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id E3114D045FF; Mon, 2 Jun 2014 16:34:53 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1401741294; bh=nY8Cnn6feMpmf25H29w5v081CjxhEgq1ORfI3LnglYk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=kA1DNFo+rpurKY9ZEGYxN7akRWdmaE5Ab+1ViTREKmNpj+4XAY1n/WkWUmbkJRBXv Olegm0bYzZctWG319xQ2qvbInALOxNm2nbGhK5GZaMt8xm7VD3JtRIsiV1UMGC8FlT 5ZSxmLTpyITM0N+9xZKt/Vr3BOtCV52gtlpN3EtM= Received: from scott-latitude-e6320.localnet (unknown [209.140.86.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id DE840D04344; Mon, 2 Jun 2014 16:34:52 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 02 Jun 2014 16:34:45 -0400 Message-ID: <3625222.PtFCvczctX@scott-latitude-e6320> User-Agent: KMail/4.13 (Linux/3.13.0-27-generic; KDE/4.13.0; x86_64; ; ) In-Reply-To: References: <87r43a5c79.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/3J-pKKwUY8cdC60cUGwH_naoMoc Subject: Re: [dmarc-ietf] Yet another mailing list solution thread 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, 02 Jun 2014 20:35:01 -0000 On Monday, June 02, 2014 12:58:47 Brandon Long wrote: > On Sat, May 31, 2014 at 6:07 AM, Stephen J. Turnbull > > wrote: > > Brandon Long writes: ... > > Mailman is already working on this. Unfortunately, some domains just > > use a generic 5.7.x policy bounce, and other don't even give you that > > much information. (We are guessing, but backtracking to the sender -- > > you don't always even get that information -- and correlating with > > other DMARC bounces, we're pretty sure that these are DMARC bounces.) > > We use 5.7.1, and in general we don't let 5.7.1 errors set users to > bouncing > (though, enough bounces will do so eventually). Its tricky, that's for > sure, but generally we > treat 5.7.1 as "we can't know whether or not these will ever succeed or its > something specific to this message") FYI, There is a discussion about defining new codes for email authentication failures in progress on apps-discuss which may interest people interested in this particular topic. https://datatracker.ietf.org/doc/draft-ietf-appsawg-email-auth-codes/ (comments there not here and I suggest a review of the ML archives prior to posting comments) Scott K From nobody Mon Jun 2 13:37:07 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33871A0439 for ; Mon, 2 Jun 2014 13:37:06 -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 XG8UPj76S0Gv for ; Mon, 2 Jun 2014 13:37:05 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 444FA1A0425 for ; Mon, 2 Jun 2014 13:37:05 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 6CE62D04397; Mon, 2 Jun 2014 16:36:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1401741419; bh=ZbVFGb89rGb480m/nlHbt1My0MoRvT/yS4muqcfLFOQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=I9Uhz3ujJPeN1Fdtyrw1x30+wjrVBZgDqpwa+OT2cSkvYaYziHEZpWuuaXmHZLF3b k7Mv4EIvX7urrv0fLzpJy80JsYP4erof/CcRPYF15UZKCvnwxHI2wGDhxc2dw/WbIy c/BRjl31paOrxfZ49ndCwzCviC9RP9opZN3/R7h0= Received: from scott-latitude-e6320.localnet (unknown [209.140.86.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 4682AD04251; Mon, 2 Jun 2014 16:36:58 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 02 Jun 2014 16:36:50 -0400 Message-ID: <1915486.LDfXbrr8S0@scott-latitude-e6320> User-Agent: KMail/4.13 (Linux/3.13.0-27-generic; KDE/4.13.0; x86_64; ; ) In-Reply-To: References: <1512020.bERtnPcCHi@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/9FIHr9d-Pr0qeM_TVTRI-GU3Fn8 Subject: Re: [dmarc-ietf] Yet another mailing list solution thread 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, 02 Jun 2014 20:37:07 -0000 On Monday, June 02, 2014 13:10:04 Brandon Long wrote: > On Mon, Jun 2, 2014 at 1:00 PM, Scott Kitterman > > wrote: > > On Monday, June 02, 2014 12:43:48 Brandon Long wrote: > > > On Fri, May 30, 2014 at 8:10 PM, John Levine wrote: > > > > >1) Support Original-Authentication-Results. This requires the MLM to > > > > add > > > > > > >them in the first place, and for the DMARC enforcing domains to check > > > > > > > > them. > > > > > > > > > Has an open question of how best to "trust" the OAR header on a > > > > message. > > > > > > > Options there are explicit whitelists from the sending domains > > > > > > > > (tpa-labels > > > > > > > > >or whatever) or to leave it up to the individual receiving domain. > > > > > > > > This keeps reducing to the previous case. If you know what senders > > > > you trust, why do you need the OAR header? > > > > > > OAR and the signed mailing list means that I trust the mailing list to > > > > have > > > > > properly checked the original validation. > > > > > > The mailing list didn't reject the DMARC message because it was valid, > > > > but > > > > > its modifying the message, so no one downstream knows that it was fine. > > > > > > Or, it may not enforce DMARC at all. > > > > > > OAR allows the MLM to tell everyone else what the auth state was prior > > > to > > > munging. The MLM may choose to forward the message regardless of the > > > > auth > > > > > state, but receivers downstream can then enforce. > > > > > > The OAR isn't necessary for a DMARC "compliant" MLM which would know to > > > make sure the message passed DMARC as sent by following one of the > > > mitigation strategies (don't munge the message, munge the from, embed > > > the > > > message as an attachment, etc). It seems necessary for any whitelisting > > > scheme, however, otherwise an "anyone can post" mailing list on a host > > > which doesn't enforce DMARC is a wide-open hole. > > > > If I already know to trust the mailing list, what does OAR cause me to do > > differently? > > What does "trust" mean there? > > Here's an example we ran into. We had an open-posting (anyone can post) > mailing list on a "trusted" domain, but there was no way for gmail to know > the mailing list was open posting, and it didn't enforce DMARC. > > The "reputation" of the mailing list was stellar, 99%+.. but a spear > phishing attack was made through the mailing list. > > So, as I said, if "trust" means "enforces DMARC", then yes, OAR is > unnecessary. But, that is a level that I don't expect many MLM services to > do. If ietf.org doesn't enforce DMARC, then "trusting" its mailing lists > for DMARC enforcement makes no sense. OTOH, I can potentially imagine many > MLM services at least upgrading to doing spf/dkim auth and signing their > messages. I can then see from the receivers end, that this service signs > 99+% of its mail and adds an OAR header, then its easy for me to manage a > reputation for their service and whitelist that service or mailing list. > Even then, we would still be at the mercy if the service was compromised > or a hole was found where by a third party was able to send mail through > their servers and have it signed, but that issue is less likely or at > least, there's only so much that blanket protections can do against that > level of motivated attacker. Trust in this context means "trust not to lie on the OAR". Either you trust them not to lie (and the content can be used) or you don't and it can't be used. If you've evaluated them sufficiently to conclude they won't lie on the OAR, you already know enough to just whitelist them. Scott K From nobody Mon Jun 2 13:56:48 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E851A035A for ; Mon, 2 Jun 2014 13:56:47 -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 xkeO3G3Vpvb5 for ; Mon, 2 Jun 2014 13:56:46 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EF291A0353 for ; Mon, 2 Jun 2014 13:56:45 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id r20so5306625wiv.15 for ; Mon, 02 Jun 2014 13:56: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=s6hrC8LnGqGCGP2OQlCeQVRtIlQin9kplt7VbxGILd8=; b=il2Zg+HJ3/oAbmO90VCLYeBlyNTFeA/vQSCm2c4riVqREXs+6CLxeAf3e6oImiZI3j EcEWmQDUvtWYjeObk3263hEOwrDyHzk7+6TRtBhPZUt6XoHyIk/EBB5sy/winl3TPYyp MsI618PKYNe0vb+Ggy1/KZ/ldIandsJ5b5vYWUjM7RBKRHAI4CfXh1S6Ajg20o3XW39p z8/bF3x5+GLUW17SqlGRj5NdhW+oUxe0tMNcPHkuQ+rIknc7nuhvLE2sxMEKa+SdD0nM qNQ1LX1IGitZwzX7CSziccm0TkSCPbuuAiIlht0N2DpPP1BUfZO5wD2feFlu99zSLM1h NozQ== MIME-Version: 1.0 X-Received: by 10.194.89.168 with SMTP id bp8mr53399947wjb.73.1401742599050; Mon, 02 Jun 2014 13:56:39 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Mon, 2 Jun 2014 13:56:38 -0700 (PDT) In-Reply-To: <3625222.PtFCvczctX@scott-latitude-e6320> References: <87r43a5c79.fsf@uwakimon.sk.tsukuba.ac.jp> <3625222.PtFCvczctX@scott-latitude-e6320> Date: Mon, 2 Jun 2014 13:56:38 -0700 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=047d7bf10a1caf0a3804fae0a1f5 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/3jr1bhv-FHE7T1MFB_vCzEnwdCQ Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Yet another mailing list solution thread 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, 02 Jun 2014 20:56:47 -0000 --047d7bf10a1caf0a3804fae0a1f5 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 2, 2014 at 1:34 PM, Scott Kitterman wrote: > > There is a discussion about defining new codes for email authentication > failures in progress on apps-discuss which may interest people interested > in > this particular topic. > > https://datatracker.ietf.org/doc/draft-ietf-appsawg-email-auth-codes/ > > (comments there not here and I suggest a review of the ML archives prior to > posting comments) > > For a little extra background: The impetus for that work came from the idea that it might be useful to distinguish between DMARC failures and other failures in a way that's useful to agents that will receive them. DMARC could, and probably should, define one or more of its own using that document's model. We decided not to tie that document to the progress of DMARC, which is why there's not a DMARC code in that one. -MSK --047d7bf10a1caf0a3804fae0a1f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 2, 2014 at 1:34 PM, Scott Kitterman <skli= st@kitterman.com> wrote:

There is a discussion about defining new codes for email authentication
failures in progress on apps-discuss which may interest people interested i= n
this particular topic.

https://datatracker.ietf.org/doc/draft-ietf-appsaw= g-email-auth-codes/

(comments there not here and I suggest a review of the ML archives prior to=
posting comments)


For a little extra background: The imp= etus for that work came from the idea that it might be useful to distinguis= h between DMARC failures and other failures in a way that's useful to a= gents that will receive them.=C2=A0 DMARC could, and probably should, defin= e one or more of its own using that document's model.

We decided not to tie that document to the progress of DMARC= , which is why there's not a DMARC code in that one.

= -MSK
--047d7bf10a1caf0a3804fae0a1f5-- From nobody Mon Jun 2 14:10:10 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E261A042C for ; Mon, 2 Jun 2014 14:10:02 -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 dyh6qN2UuspI for ; Mon, 2 Jun 2014 14:09:56 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8A6B1A03DF for ; Mon, 2 Jun 2014 14:09:55 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id f51so11548895qge.26 for ; Mon, 02 Jun 2014 14:09:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=SF7J9koIhbYocbJEIrBRB22wHAH+H4AV8TEa0wW5O4Y=; b=0LQti8pFs4C7w68yBGV6jEnhFvuq3Y0ng5yu2I39l3K5pgB+jl96ck9m0ylQda0ja9 tB28JTjfuXK4if8cQ1nYWWtnz9YzmV/uYEgKMJisjp7zeH/mb2m3LtIIOAPNb3OM8xNm On2i7aj23vInMdnPU5I7604wk7H1/gIb6XLQTBO3STENfdAvtcPl4Yqfnja4TPS6I2gI j3uYwTqvPALDWCifr1oYO2usMIKWEbV00javKy038rG9ABgGMmNL8Ogq+LOXt4qeM8Gs BnRMiKpgRijGiD5dDAamUq2TqSyqTp16AGPoewiwP+4VedwIYEC9eNgQR1d01lUh3qWh 0HhQ== X-Received: by 10.224.67.201 with SMTP id s9mr53789326qai.29.1401743390037; Mon, 02 Jun 2014 14:09:50 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id d8sm23215278qas.24.2014.06.02.14.09.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Jun 2014 14:09:49 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_812EEF17-1ADF-443A-9DD5-821246946834" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: Date: Mon, 2 Jun 2014 14:09:47 -0700 Message-Id: <58F374EF-D270-4AE5-B04D-E6CF9836ED90@gmail.com> References: <20140531031056.2397.qmail@joyce.lan> <1512020.bERtnPcCHi@scott-latitude-e6320> To: Brandon Long X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/qT7lvNB51ZGKFiRgwLjK6dXMOI8 Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] Yet another mailing list solution thread 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, 02 Jun 2014 21:10:02 -0000 --Apple-Mail=_812EEF17-1ADF-443A-9DD5-821246946834 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Brandon, See comments inline: On Jun 2, 2014, at 1:10 PM, Brandon Long wrote: > On Mon, Jun 2, 2014 at 1:00 PM, Scott Kitterman = wrote: > On Monday, June 02, 2014 12:43:48 Brandon Long wrote: > > On Fri, May 30, 2014 at 8:10 PM, John Levine = wrote: > > > >1) Support Original-Authentication-Results. This requires the = MLM to add > > > >them in the first place, and for the DMARC enforcing domains to = check > > > > > > them. > > > > > > > Has an open question of how best to "trust" the OAR header on a = message. > > > > Options there are explicit whitelists from the sending domains > > > > > > (tpa-labels > > > > > > >or whatever) or to leave it up to the individual receiving = domain. > > > > > > This keeps reducing to the previous case. If you know what = senders > > > you trust, why do you need the OAR header? > > > > OAR and the signed mailing list means that I trust the mailing list = to have > > properly checked the original validation. > > > > The mailing list didn't reject the DMARC message because it was = valid, but > > its modifying the message, so no one downstream knows that it was = fine. > > Or, it may not enforce DMARC at all. > > > > OAR allows the MLM to tell everyone else what the auth state was = prior to > > munging. The MLM may choose to forward the message regardless of = the auth > > state, but receivers downstream can then enforce. > > > > The OAR isn't necessary for a DMARC "compliant" MLM which would know = to > > make sure the message passed DMARC as sent by following one of the > > mitigation strategies (don't munge the message, munge the from, = embed the > > message as an attachment, etc). It seems necessary for any = whitelisting > > scheme, however, otherwise an "anyone can post" mailing list on a = host > > which doesn't enforce DMARC is a wide-open hole. >=20 > If I already know to trust the mailing list, what does OAR cause me to = do > differently? >=20 > What does "trust" mean there? >=20 > Here's an example we ran into. We had an open-posting (anyone can = post) mailing list on a "trusted" domain, but there was no way for gmail = to know the mailing list was open posting, and it didn't enforce DMARC. >=20 > The "reputation" of the mailing list was stellar, 99%+.. but a spear = phishing attack was made through the mailing list. >=20 > So, as I said, if "trust" means "enforces DMARC", then yes, OAR is = unnecessary. But, that is a level that I don't expect many MLM services = to do. If ietf.org doesn't enforce DMARC, then "trusting" its mailing = lists for DMARC enforcement makes no sense. OTOH, I can potentially = imagine many MLM services at least upgrading to doing spf/dkim auth and = signing their messages. I can then see from the receivers end, that = this service signs 99+% of its mail and adds an OAR header, then its = easy for me to manage a reputation for their service and whitelist that = service or mailing list. Even then, we would still be at the mercy if = the service was compromised or a hole was found where by a third party = was able to send mail through their servers and have it signed, but that = issue is less likely or at least, there's only so much that blanket = protections can do against that level of motivated attacker. More than a decade ago, we managed a zone dedicated to mailing-list = subscription policy compliance to confirm the mailing-list's practices. = Back then, the test was to ensure confirmed subscriptions. Of course, = doing so remains important. Authorizing only validated domains still = leaves a few things to still check regarding posts. 1) enforcing DMARC policy alignment request (not a problem when = mailing-list friendly i.e. TPA-Label) 2) protect use of List-ID or Sender header and stipulate inclusion in = authorization 3) use X-original-authentication-results and stipulate inclusion in = authorization (missing but can be added) It would be easy to add any number of these stipulations for receivers = to check before applying the authorization. Also consider the TPA-Label method can disable a domain in minutes = following any detected or reported abuse. No one wants to see their = services disrupted which helps ensure compliance. Allow others to use = your lists, and this hammer gets much bigger.=20 Unless email is only permitted to be exchanged peer-to-peer, there will = always be some intermediate steps to be trusted. Take the Intuit = example, where they make use of the Sender header. Regards, Douglas Otis --Apple-Mail=_812EEF17-1ADF-443A-9DD5-821246946834 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = Brandon,

See comments inline:
On Jun 2, = 2014, at 1:10 PM, Brandon Long <blong@google.com> = wrote:

On Mon, Jun 2, 2014 at = 1:00 PM, Scott Kitterman <sklist@kitterman.com> wrote:
On Monday, June 02, 2014 = 12:43:48 Brandon Long wrote:
> On Fri, May 30, 2014 at 8:10 PM, John Levine <johnl@taugh.com> wrote:
> > >1) Support Original-Authentication-Results.  This = requires the MLM to add
> > >them in the first place, and for the DMARC enforcing = domains to check
> >
> > them.
> >
> > > Has an open question of how best to "trust" the OAR = header on a message.
> > > Options there are explicit whitelists from the sending = domains
> >
> > (tpa-labels
> >
> > >or whatever) or to leave it up to the individual receiving = domain.
> >
> > This keeps reducing to the previous case.  If you know = what senders
> > you trust, why do you need the OAR header?
>
> OAR and the signed mailing list means that I trust the mailing list = to have
> properly checked the original validation.
>
> The mailing list didn't reject the DMARC message because it was = valid, but
> its modifying the message, so no one downstream knows that it was = fine.
>  Or, it may not enforce DMARC at all.
>
> OAR allows the MLM to tell everyone else what the auth state was = prior to
> munging.  The MLM may choose to forward the message regardless = of the auth
> state, but receivers downstream can then enforce.
>
> The OAR isn't necessary for a DMARC "compliant" MLM which would = know to
> make sure the message passed DMARC as sent by following one of = the
> mitigation strategies (don't munge the message, munge the from, = embed the
> message as an attachment, etc).  It seems necessary for any = whitelisting
> scheme, however, otherwise an "anyone can post" mailing list on a = host
> which doesn't enforce DMARC is a wide-open hole.

If I already know to trust the mailing list, what does OAR = cause me to do
differently?

What does "trust" mean = there?

Here's an example we ran into.  We = had an open-posting (anyone can post) mailing list on a "trusted" = domain, but there was no way for gmail to know the mailing list was open = posting, and it didn't enforce DMARC.

The "reputation" of the mailing list was stellar, = 99%+.. but a spear phishing attack was made through the mailing = list.

So, as I said, if "trust" means "enforces = DMARC", then yes, OAR is unnecessary.  But, that is a level that I = don't expect many MLM services to do.  If ietf.org doesn't enforce DMARC, then = "trusting" its mailing lists for DMARC enforcement makes no sense. =  OTOH, I can potentially imagine many MLM services at least = upgrading to doing spf/dkim auth and signing their messages.  I can = then see from the receivers end, that this service signs 99+% of its = mail and adds an OAR header, then its easy for me to manage a reputation = for their service and whitelist that service or mailing list.  Even = then, we would still be at the mercy if the service was compromised or a = hole was found where by a third party was able to send mail through = their servers and have it signed, but that issue is less likely or at = least, there's only so much that blanket protections can do against that = level of motivated = attacker.

More than a = decade ago, we managed a zone dedicated to mailing-list subscription = policy compliance to confirm the mailing-list's practices.  Back = then, the test was to ensure confirmed subscriptions. Of course, doing = so remains important.  Authorizing only validated domains still = leaves a few things to still check regarding = posts.

1) enforcing DMARC policy alignment = request (not a problem when mailing-list friendly i.e. = TPA-Label)
2) protect use of List-ID or Sender header and = stipulate inclusion in authorization
3) use = X-original-authentication-results and stipulate inclusion in = authorization (missing but can be = added)

It would be easy to add any number = of these stipulations for receivers to check before applying the = authorization.

Also consider the TPA-Label = method can disable a domain in minutes following any detected or = reported abuse.  No one wants to see their services disrupted which = helps ensure compliance.  Allow others to use your lists, and this = hammer gets much bigger. 

Unless email is = only permitted to be exchanged peer-to-peer, there will always be some = intermediate steps to be trusted.  Take the Intuit example, where = they make use of the Sender = header.

Regards,
Douglas = Otis

= --Apple-Mail=_812EEF17-1ADF-443A-9DD5-821246946834-- From nobody Mon Jun 2 14:22:50 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90A81A040A for ; Mon, 2 Jun 2014 14:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.171 X-Spam-Level: ** X-Spam-Status: No, score=2.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FM_IS_IT_OUR_ACCOUNT=4.2, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 j_2-pzNEWoe6 for ; Mon, 2 Jun 2014 14:22:47 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA6B81A043D for ; Mon, 2 Jun 2014 14:22:46 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id x19so5080869ier.41 for ; Mon, 02 Jun 2014 14:22:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gYRSbvDkLspPlFTNz/MZ4vIawpP18+6Yk5Ocgx0QzIQ=; b=gjCwZRsM7OOt0Flk3XQZw/VArZf4YaShdrKEcGdydB8W8AdcEe4hTTTVjSyGEwHz1F 4epVlagZtS3dnbaxgR1AJaSXRunOakeWNX9BUWKc1LxJAIB+UP3tVePdwl1JSrRNqeDs 1IEDYHHY88OZ/HyW2NPD1thbop/PCRrhVzOSzBMWhvFhmpcFYiQDOd3+GmnPxsuiIgAo TQGlQq1c522zzwtXXfF5qapZ9ckRwTDQaCDSBYFAxBtQLxELogfJRfr9j0auVXxAVjcC OlWJs7Efr8oGDZnF4F+fCCnkiqrSKMAOwxWC59jtPwX3cRZrpvg5/WocdGDCuPxEg2NV TDOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gYRSbvDkLspPlFTNz/MZ4vIawpP18+6Yk5Ocgx0QzIQ=; b=faiKMo6yj6ND9NIdU9s3DRRzJc3a4MDZSTRkoAapWvQ8+1zLXz4aLiyHg/oph9+pDp FXkZ4Sav5AMKEyL0z4AtcIVR5IfoAOZtHeVtlqqsfHF5WCMXojqito/OkSDNmhdEuHHJ X7mX76NeX3jyKWd3vmL61eTAgccB8wyyTV2h6T2IrUsfhUOJerf1ThkafSYD36fi6ziB wQ14kt3gax0oiE8rZCjbK8r+PFVkUT8ll8KG9nXZiv1ukfaTVxRGBlMx8LPD2JEeKMr5 Nx+9JsaXEku9CFvz9zPehUcF10j2EgViGQJEJaPjORY/+d6ufQCciTKLIyt1LZ548dwu 99iA== X-Gm-Message-State: ALoCoQnPi48NOKTiSye1r9V9thqBqruP1RoG9G1bRKQhc6ApYrxBjUque4EnFzhroBVWJTgiBNlS MIME-Version: 1.0 X-Received: by 10.50.143.100 with SMTP id sd4mr22703406igb.23.1401744161054; Mon, 02 Jun 2014 14:22:41 -0700 (PDT) Received: by 10.64.213.73 with HTTP; Mon, 2 Jun 2014 14:22:40 -0700 (PDT) In-Reply-To: <08F3556F-2470-424D-8BE2-2DF8B7E27B39@gmail.com> References: <20140528163723.63860.qmail@joyce.lan> <728937278.65439.1401312715643.JavaMail.zimbra@peachymango.org> <87tx887ry5.fsf@uwakimon.sk.tsukuba.ac.jp> <8761kn7f42.fsf@uwakimon.sk.tsukuba.ac.jp> <538917D0.7040604@isdg.net> <08F3556F-2470-424D-8BE2-2DF8B7E27B39@gmail.com> Date: Mon, 2 Jun 2014 14:22:40 -0700 Message-ID: From: Brandon Long To: Douglas Otis Content-Type: multipart/alternative; boundary=001a1134b4cac9515304fae0fe4a Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/QWVSGgdYIOly2DCktb89GN2ylas Cc: "dmarc@ietf.org" , Hector Santos Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection 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, 02 Jun 2014 21:22:49 -0000 --001a1134b4cac9515304fae0fe4a Content-Type: text/plain; charset=UTF-8 On Sun, Jun 1, 2014 at 7:56 PM, Douglas Otis wrote: > Dear Hector, > > See comments inline: > On May 30, 2014, at 4:44 PM, Hector Santos wrote: > > On 5/30/2014 5:49 PM, J. Gomez wrote: > > Ah, but "just like" is a complete misstatement of the situation. > There's a big difference. Users on a mailing list think of the > poster, not the mailing list, as responsible for the content. So > according to RFC 5322, the poster's mailbox belongs in From:. > Remailed or not, the author belongs there. > > > That is debatable. As long as the mailing list program tampers with the > message's content, rendering its DKIM signature invalid, it can be argued > that the mailing list program is rewriting the message's content, and > therefore that the mailing list program now becomes "the system responsible > for the writing of the message" (as per RFC 5322 parlance, section 3.6.2), > and thus the mailing list address would earn its legitimate place in the > Header-From field, making interoperability with rogue DMARC Senders a > solved problem. > > > In my book, this is mail tampering. It will be hard to justify adding > support for this radical behavior in our mail list server product which > puts customers at risk. You are putting yourself at product liability risk > but intentionally defying a security protocol against the wishes of the > publishing restrictive domain. Of course, its only becomes a problem when > its used as a loophole to further spread harmful mail and someone actually > gets harmed. Thats all you have to prove in a courtroom. If you had all > the tools before you to tell you definitively, "This is unauthorized mail" > and you intentionally, deliberately and neglectfully ignore it, do nothing > about it but further distribute to end points, well, who knows what a young > punk, tech savvy, high tech, new age lawyer will think about suing you. If > you got deep pockets, well, don't think it can't happen. > > > It is this sort of mentality that completely makes this old game no more > fun to work with. Seriously. > > We can do it right. All we have to do is LOOKUP the policy and follow it. > Give the YAHOOs the tools to authorize the resigners and you and I won't > have these new ethical problems to content with. > > > It seems wrong to describe a mailing-list adding Subject Tags, List > Footers, while retaining the From header field so people have an easer task > of knowing who is talking and at reviewing past conversations as putting > recipients in grave risk. Causing a massive number of people to find > different email providers so they can retain their effectiveness at using a > mailing list is far more likely to create risk simply due to the resulting > confusion. > > There is also the case of Intuit sending "From" invoices on behalf of > various individuals and using their customer's email address given to them > by their Internet provider, only to find someone now thinks DKIM can't > possibly be considered valid when signing the Sender header field. That is > exactly the intended purpose for this field. This is essentially the same > issue with mailing-lists. In both cases, there is a valid reason for the > From header field to contain that of their client or the speaker, because > that is what the recipient is able to recognize. There are also MUAs that > will create a synthetic From on behalf of . Most MUAs can > also optionally display both headers. > > The real effort involved in the sequence of these messages is establishing > trust anchors. While there is going to be a massive number of individuals > involved, there are several orders of magnitude fewer trust anchors. For > any domain wanting to assert strict alignment for their messages, it is > only fair for them to work out relationships between their users messages > and the non-aligned third-party services (trusted domain --> worthy > third-party service). Their out-bound logs and DMARC/User feedback should > arrive at a reasonable estimate about which domains are being trusted. > Rogue services will be excluded and any mistakes can be quickly corrected. > > Rather than describing this as a permission to sign, think of this as a > type of server federation aimed at protecting the federated identity much > like single-user-sign-on. In this case, it would be which of these > services are normally used and maintain practices that protect the > federated identifiers. The TPA-Label scheme allows this type of federation > to be centralized or handled separately by each trusted domain (senders) as > described in http://tools.ietf.org/html/draft-otis-tpa-label. > Why should I, or my users, trust Intuit? Perhaps I do because I have friends who have worked there and I use their software. What about the next payments start-up? Or the Russian or Chinese equivalent of Intuit that I know nothing about and at best rely on the google translate version of their home page? Do you expect that we would pass 30k domains through some sort of human vetting process, and that even if we were willing to do that, we would be capable of actually vetting them all? Third parties that Google uses in this manner need to go through a vendor security audit. I can certainly say that we don't have the resources for doing that for 30k services. Even if we did, I'm betting a good portion of them wouldn't pass. There's nothing preventing the Intuit case from having the mail sent From: "Intuit Billing Services" or even "My Company Billing Services" < foo@intuit.com>. Or, if you really want to send from your gmail.com account, give Intuit permission to send using your account with OAUTH2. That seems pretty acceptable for a billing arrangement. Brandon --001a1134b4cac9515304fae0fe4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sun, Jun 1, 2014 at 7:56 PM, Douglas Otis <= doug.mtview@gmai= l.com> wrote:
Dea= r Hector,

See comments inline:
On May 30, 2014, at 4:44 PM, Hector Santos <hsantos@isdg.net> wrote:

On 5/30/2014 5:49 PM, J. Gomez= wrote:

Ah, but "just like" is a complete misstatement of the situatio= n.
There's a big difference. =C2=A0Users on a mailing list think of = the
poster, not the mailing list, as responsible for the content. =C2=A0So
a= ccording to RFC 5322, the poster's mailbox belongs in From:.
Remaile= d or not, the author belongs there.

That is debatable. = As long as the mailing list program tampers with the message's content,= rendering its DKIM signature invalid, it can be argued that the mailing li= st program is rewriting the message's content, and therefore that the m= ailing list program now becomes "the system responsible for the writin= g of the message" (as per RFC 5322 parlance, section 3.6.2), and thus = the mailing list address would earn its legitimate place in the Header-From= field, making interoperability with rogue DMARC Senders a solved problem.<= br>

In my book, this is mail tampering. It will be hard = to justify adding support for this radical behavior in our mail list server= product which puts customers at risk. =C2=A0You are putting yourself at pr= oduct liability risk but intentionally defying a security protocol against = the wishes of the publishing restrictive domain. =C2=A0Of course, its only = becomes a problem when its used as a loophole to further spread harmful mai= l and someone actually gets harmed. =C2=A0Thats all you have to prove in a = courtroom. =C2=A0=C2=A0If you had all the tools before you to tell you defi= nitively, "This is unauthorized mail" =C2=A0and you intentionally= , deliberately and neglectfully ignore it, do nothing about it but further = distribute to end points, well, who knows what a young punk, tech savvy, hi= gh tech, new age lawyer will think about suing you. =C2=A0If you got deep p= ockets, well, don't think it can't happen.


It is this sort of mentality that completely makes this old game no= more fun to work with. Seriously.

We can do it right. =C2=A0A= ll we have to do is LOOKUP the policy and follow it. =C2=A0Give the YAHOOs = the tools to authorize the resigners and you and I won't have these new= ethical problems to content with.

It seems wrong to describe a mailing-list = adding Subject Tags, List Footers, while retaining the From header field so= people have an easer task of knowing who is talking and at reviewing past = conversations as putting recipients in grave risk. =C2=A0Causing a massive = number of people to find different email providers so they can retain their= effectiveness at using a mailing list is far more likely to create risk si= mply due to the resulting confusion.

There is also the case of Intuit sending "From&quo= t; invoices on behalf of various individuals and using their customer's= email address given to them by their Internet provider, only to find someo= ne now thinks DKIM can't possibly be considered valid when signing the = Sender header field. That is exactly the intended purpose for this field. T= his is essentially the same issue with mailing-lists. =C2=A0In both cases, = there is a valid reason for the From header field to contain that of their = client or the speaker, because that is what the recipient is able to recogn= ize. =C2=A0There are also MUAs that will create a synthetic From <sender= > on behalf of <from>. =C2=A0Most MUAs can also optionally display= both headers.=C2=A0

The real effort involved in the sequence of these messa= ges is establishing trust anchors. While there is going to be a massive num= ber of individuals involved, there are several orders of magnitude fewer tr= ust anchors. =C2=A0For any domain wanting to assert strict alignment for th= eir messages, it is only fair for them to work out relationships between th= eir users messages and the non-aligned third-party services (trusted domain= --> worthy third-party service). =C2=A0Their out-bound logs and DMARC/U= ser feedback should arrive at a reasonable estimate about which domains are= being trusted. =C2=A0Rogue services will be excluded and any mistakes can = be quickly corrected.

Rather than describing this as a permission to sign, th= ink of this as a type of server federation aimed at protecting the federate= d identity much like single-user-sign-on. =C2=A0In this case, it would be w= hich of these services are normally used and maintain practices that protec= t the federated identifiers. =C2=A0The TPA-Label scheme allows this type of= federation to be centralized or handled separately by each trusted domain = (senders) as described in=C2=A0http://tools.ietf.org/html/draft-otis-tpa= -label.

Why should I, or my users, tru= st Intuit?

Perhaps I do because I have friends who= have worked there and I use their software. =C2=A0What about the next paym= ents start-up? =C2=A0Or the Russian or Chinese equivalent of Intuit that I = know nothing about and at best rely on the google translate version of thei= r home page?

Do you expect that we would pass 30k domains through so= me sort of human vetting process, and that even if we were willing to do th= at, we would be capable of actually vetting them all?

Third parties that Google uses in this manner need to go through a ven= dor security audit. =C2=A0I can certainly say that we don't have the re= sources for doing that for 30k services. =C2=A0Even if we did, I'm bett= ing a good portion of them wouldn't pass.

There's nothing preventing the Intuit case from hav= ing the mail sent From: "Intuit Billing Services" or even "M= y Company Billing Services" <foo@= intuit.com>. =C2=A0Or, if you really want to send from your gmail.com account, give Intuit permission to send= using your account with OAUTH2. =C2=A0That seems pretty acceptable for a b= illing arrangement.

Brandon
--001a1134b4cac9515304fae0fe4a-- From nobody Mon Jun 2 14:25:12 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9297F1A043D for ; Mon, 2 Jun 2014 14:25:10 -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 lqAmcvApB_xi for ; Mon, 2 Jun 2014 14:25: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 79FE61A040A for ; Mon, 2 Jun 2014 14:25:09 -0700 (PDT) Received: (qmail 65611 invoked from network); 2 Jun 2014 21:25:02 -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:cleverness; s=1004a.538cebae.k1406; bh=tAdvUaIXEbp+DnX1Qcx/b+neEQovsm5fuZv04oY65Ts=; b=omIlHQ33k3CiIeZSOIGqvIzl5zC1GxZojMkyJzwV8X+lA0Cju4G1JxlbMqpMIJp427t1BUnSM7hmsddzLaMOr+lNkc7QwNkWIfCzkknfwVbuXntJgT8XXtoiCxhJovCmFZ14YfCMeeW1UZYL0gQicbauWdulEINNt2W/KtZYw1HbL7FcRBznlw1ChXWmEJ9ODdw28diLMOUqyO1NX2vz+eU6IyvVhT08mypFzchfan0ytQguwTVEUbDSoaf2ItYH 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:cleverness; s=1004a.538cebae.k1406; bh=tAdvUaIXEbp+DnX1Qcx/b+neEQovsm5fuZv04oY65Ts=; b=XmpBEkVWAEKBae1p4lN534lXKSdA/1X5dBGn311a/G7a5t2ypQwQMFZWmE6waD3+H2LGl3WpiKo4rqfRHjj4LJCa0QxJAIHyYtOae5qRGt5+NMAy4aUJEXhofX19aqLQnWXKtcxdJQtuuM269X6iAnYWI00vV3a5wcaes+rGQoLxHVSp7nLWwqg+H1/jF9YXCTe6Xmta+EsNSRF2eWJSv8wZ8x7+3lLTX+bALxJSwpq58awRDZh6duuu9pf0ZotM 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; 02 Jun 2014 21:25:02 -0000 Date: 2 Jun 2014 17:25:01 -0400 Message-ID: From: "John R Levine" To: "Brandon Long" In-Reply-To: References: <20140531031056.2397.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/3fdGLUsmoXOj3rfMORPZaIjeDzA Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Yet another mailing list solution thread 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, 02 Jun 2014 21:25:10 -0000 >> This keeps reducing to the previous case. If you know what senders >> you trust, why do you need the OAR header? > > OAR and the signed mailing list means that I trust the mailing list to have > properly checked the original validation. True, but if you trust the mailing list that far, how likely is it that the OAR will tell you anything bad? Here's a thought experiment: let's say you have a nice trustworthy list, they're sending you OAR, you deliver all their mail and the complaint rate rounds to zero. I expect there will be a fair number of lists like that. Now you find out that the OAR headers are fake. (They're not sending spam, they're just not reporting the real inbound DKIM or SPF.) Other than that nothing's changed, they're sending the same mail and the complaint rate still rounds to zero. Should you handle their mail differently? If so, why? R's, John PS: Are there in fact any ISPs that pay attention to OAR? I could easily add it if it made them happy. From nobody Mon Jun 2 15:22:01 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB45F1A03FB for ; Mon, 2 Jun 2014 15:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 v3b-3dJwbyah for ; Mon, 2 Jun 2014 15:21:56 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DBF71A03C9 for ; Mon, 2 Jun 2014 15:21:56 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id vb8so5227180obc.14 for ; Mon, 02 Jun 2014 15:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/RyheT7Xwz9M5axushCkwyIIDKgDRmEawgTatXgixoA=; b=gfwjDfgw1e0GBlGQPHU8vnNwyMI2kmBypQXvShbipYvC2nRSMp2v8YibvGpRUe39g5 UvLVHTjI5+tPqsUh0Z9tXJCbjaW3tCF/4Ks/J1RNF1D49q3bbqN2X7UoYqWMI0+ddLrF 8Ykjm/HBJ8ElbzjpmtIPPo2Gn4d4YTnZHgoxcCKd8np3BIP5yXwHTklTQGDMFA5qnQSB zRLfjGMOuee4MMdZ8x0PeVuh1UIMdRKa3MhyZ6SAPWkdaKFdHwClaRDl+ckpy/9rBAO4 jC+k5DhWTgv43mOMei+ccHVX+YqT0QmSaT3G3OMqWA3hZNSdg3132Prp6PCtJ8Z/2dbB 3WwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/RyheT7Xwz9M5axushCkwyIIDKgDRmEawgTatXgixoA=; b=GMrDEKBjgj18YCEDS6W8E2uWrKtpkKMqQpunjOmUMxUyKpW5Kuf0gzZ974RMZWHe30 PxtGaQLjyynSnY/Zq0Vux8rrUS+BmWjUz0F+SkdiLulQ7cpfwztFKGBNVY4hVk6YYnLb X6PNvt5tKTEM2Hl9LjDtZgQWpx2/A5vshi9D45C6rXcqJytUdbIDaO674TtKqfW6cPSz JIeoB+Tl6+TKsO2LwTfcIeDroDsHCAntPUc8UepT2IHHQn5rWqkxTwnvV3+sEK9BDgBU 3Msb0C5OldjC1OvU5KlhvTdj40kexQAveMwFZc7XvjWmIV6tl4ZUZ34j48J8+tbOYW8f Ppww== X-Gm-Message-State: ALoCoQnq+oSV294gmhhV8XmedE3HlEE2MMDCg8euBjUCY58QvB3MtQBZcSPL2nSZnkEnHxoFvwhZ MIME-Version: 1.0 X-Received: by 10.182.22.111 with SMTP id c15mr42331402obf.32.1401747710911; Mon, 02 Jun 2014 15:21:50 -0700 (PDT) Received: by 10.182.224.166 with HTTP; Mon, 2 Jun 2014 15:21:50 -0700 (PDT) In-Reply-To: References: <20140531031056.2397.qmail@joyce.lan> Date: Mon, 2 Jun 2014 15:21:50 -0700 Message-ID: From: Brandon Long To: John R Levine Content-Type: multipart/alternative; boundary=001a1133278a5ff49a04fae1d2ce Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/uyd_gilLyWGMlU3f9XTosT7YIIo Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Yet another mailing list solution thread 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, 02 Jun 2014 22:21:58 -0000 --001a1133278a5ff49a04fae1d2ce Content-Type: text/plain; charset=UTF-8 On Mon, Jun 2, 2014 at 2:25 PM, John R Levine wrote: > This keeps reducing to the previous case. If you know what senders >>> you trust, why do you need the OAR header? >>> >> >> OAR and the signed mailing list means that I trust the mailing list to >> have >> properly checked the original validation. >> > > True, but if you trust the mailing list that far, how likely is it > that the OAR will tell you anything bad? > > Here's a thought experiment: let's say you have a nice trustworthy > list, they're sending you OAR, you deliver all their mail and the > complaint rate rounds to zero. I expect there will be a fair number > of lists like that. > > Now you find out that the OAR headers are fake. (They're not sending > spam, they're just not reporting the real inbound DKIM or SPF.) Other than > that nothing's changed, they're sending the same mail and the complaint > rate still rounds to zero. Should you handle their mail differently? If > so, why? > I proposed internally a scheme where we would compute a reputation for mailing lists, and ones which are sufficiently high will be whitelisted for DMARC. The issue that was presented to me is spear phishing attacks through mailing lists (which we've seen) and the amount of damage that can be done in a single phishing campaign through such a list until the reputation drops sufficiently to stop it. A spear phishing attack, by definition, is usually in the noise for any sufficiently large list or service. Its not clear to me that we can solve that completely, if the target is high value enough, a great deal of effort into finding a hole would be made. The other part is that we've seen entire spam campaigns that run to the millions in <30s, or coordinated attacks across datacenters, all trying to beat latencies in some of our systems. And what happens when the reputation does fall due to one of these attacks? Is that mailing list dead for ever to DMARC domains? Or just for a week? Anyways, yes, the "they could be faking it" would be the hole in the OAR scheme. It may be possible to do some level of testing on the OAR, like trying to do implied SPF verification, but perhaps the whole thing is toast. > R's, > John > > PS: Are there in fact any ISPs that pay attention to OAR? I could easily > add it if it made them happy. > The problem with OAR is knowing when to trust it, so although we accept OAR, we only do so for domains we trust, which last I checked was basically only us. Helps us and anyone who trusts us, but isn't generally useful yet. Brandon --001a1133278a5ff49a04fae1d2ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Mon, Jun 2, 2014 at 2:25 PM, John R Levine <= ;johnl@taugh.com&g= t; wrote:
This keeps reducing to the previous case. =C2=A0If you know what senders you trust, why do you need the OAR header?

OAR and the signed mailing list means that I trust the mailing list to have=
properly checked the original validation.

True, but if you trust the mailing list that far, how likely is it
that the OAR will tell you anything bad?

Here's a thought experiment: let's say you have a nice trustworthy<= br> list, they're sending you OAR, you deliver all their mail and the
complaint rate rounds to zero. =C2=A0I expect there will be a fair number of lists like that.

Now you find out that the OAR headers are fake. =C2=A0(They're not send= ing spam, they're just not reporting the real inbound DKIM or SPF.) =C2= =A0Other than that nothing's changed, they're sending the same mail= and the complaint rate still rounds to zero. =C2=A0Should you handle their= mail differently? If so, why?

I proposed internally a scheme where we wo= uld compute a reputation for mailing lists, and ones which are sufficiently= high will be whitelisted for DMARC. =C2=A0The issue that was presented to = me is spear phishing attacks through mailing lists (which we've seen) a= nd the amount of damage that can be done in a single phishing campaign thro= ugh such a list until the reputation drops sufficiently to stop it.

A spear phishing attack, by definition, is usually in t= he noise for any sufficiently large list or service. =C2=A0Its not clear to= me that we can solve that completely, if the target is high value enough, = a great deal of effort into finding a hole would be made.

The other part is that we've seen entire spam campa= igns that run to the millions in <30s, or coordinated attacks across dat= acenters, all trying to beat latencies in some of our systems.

And what happens when the reputation does fall due to one of= these attacks? =C2=A0Is that mailing list dead for ever to DMARC domains? = =C2=A0Or just for a week?

Anyways, yes, the "= they could be faking it" would be the hole in the OAR scheme. =C2=A0It= may be possible to do some level of testing on the OAR, like trying to do = implied SPF verification, but perhaps the whole thing is toast.
=C2=A0
R's,
John

PS: Are there in fact any ISPs that pay attention to OAR? =C2=A0I could eas= ily add it if it made them happy.

The p= roblem with OAR is knowing when to trust it, so although we accept OAR, we = only do so for domains we trust, which last I checked was basically only us= . =C2=A0Helps us and anyone who trusts us, but isn't generally useful y= et.

Brandon
--001a1133278a5ff49a04fae1d2ce-- From nobody Mon Jun 2 15:31:46 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0E01A03DB for ; Mon, 2 Jun 2014 15:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 3-nJb2-xQmuc for ; Mon, 2 Jun 2014 15:31:42 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF0911A02BA for ; Mon, 2 Jun 2014 15:31:42 -0700 (PDT) Received: by mail-ig0-f169.google.com with SMTP id hl10so3797843igb.0 for ; Mon, 02 Jun 2014 15:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7v6X0W3BBnwkknuQBI0YKVqbrWvfj9kk+IVio388+nM=; b=MpP/scBoBcHiiWikW+IV7/nJcWvZrIyd5J/g9Oncs879aK2/PaqP58jxJGNj3Je426 MZpbDPhqwRk88J6zTta4XlnZdYtJibxQBT9af1HPv96VBK4TX2sohbL5snY+3evQ2/fd jIfB76dHruLPLq7TumlwwdmZbb3V6qdqtUXzomiaTQVy16kWITX1v+RwwtInZiTEN6jP izTdEOKDEmaRIbK1aN4tVMDkUDoxEhJKTPyjf3vdIYruC5g/aK3qMzL1May2bWERuiHd YcVb5EYuhi31kjgts1f1dO5ZDT15wOsyYNyJFKTWhSFGuXGNYIUA94bzqIjN90K9H4nl hwrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7v6X0W3BBnwkknuQBI0YKVqbrWvfj9kk+IVio388+nM=; b=Q/YSRkyIqjSHTm9kEhKiExZ9g38JHKu9Ot4+TN/XMRlwT10tZR4q/NyV4ye6UFdjeu lBmukE5O2mC01aflFb4/fh4bv0B5zUZiLycSJMloelOTLZmqqCdU0m2Sawexb7NWZPYa i0cj+W1bUA0CSN0iLvZEEzqhYhAGEluy3/jpWi1YK0aDv6kYU//Kh1/f6MOKMHzlZlqy G0h4Dyleti0UImUpAQTbuw6W5hudmItTmK3AYUwUaojaHc0uggct78E3Bz4yVQTl5Dlj jsdXHKY+a8CM+nS2314A6MGx+Vr01cMZRdGIcLndSqBqVaS97wiMV6+GGFHc8j2yTP+l Tawg== X-Gm-Message-State: ALoCoQm+wzsbQli94lkm4RAD4UJOXC+fYTBeBw7KY1zB3UC5XfKB0dEMGfWItNWAxrGpR1ekt/he MIME-Version: 1.0 X-Received: by 10.50.129.97 with SMTP id nv1mr23233605igb.32.1401748297092; Mon, 02 Jun 2014 15:31:37 -0700 (PDT) Received: by 10.64.213.73 with HTTP; Mon, 2 Jun 2014 15:31:36 -0700 (PDT) In-Reply-To: <1915486.LDfXbrr8S0@scott-latitude-e6320> References: <1512020.bERtnPcCHi@scott-latitude-e6320> <1915486.LDfXbrr8S0@scott-latitude-e6320> Date: Mon, 2 Jun 2014 15:31:36 -0700 Message-ID: From: Brandon Long To: Scott Kitterman Content-Type: multipart/alternative; boundary=047d7b41431c503e8504fae1f504 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/3PbqPopesyeeA5-Lf8wViIJc0eE Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Yet another mailing list solution thread 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, 02 Jun 2014 22:31:44 -0000 --047d7b41431c503e8504fae1f504 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 2, 2014 at 1:36 PM, Scott Kitterman wrote: > > Trust in this context means "trust not to lie on the OAR". Either you > trust > them not to lie (and the content can be used) or you don't and it can't be > used. If you've evaluated them sufficiently to conclude they won't lie on > the > OAR, you already know enough to just whitelist them. I would argue they aren't the same. Trusting that they aren't lying on the OAR just means that I can implement policy about the value of the OAR. That doesn't mean that we agree on what policy we should implement in regards to authentication-results. An MLM could implement OAR but not enforce DMARC, for example. In that case, a DMARC enforcing receiver could reject the message for DMARC if it fails, but not reject messages that passed auth for the mailing list. One could imagine using it for other things as well, the spam filtering for a mailing list may not be particularly strong, but with OAR, we could apply different rules based on authentication. One could imagine trusting "authenticated sender in address book" more than "unauthenticated sender in address book", for example. Brandon --047d7b41431c503e8504fae1f504 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Jun 2, 2014 at 1:36 PM, Scott Kitterman <sklist@kitterman.com> wrote:

Trust in this context means "trust not to lie on the OAR&q= uot;. =C2=A0Either you trust
them not to lie (and the content can be used) or you don't and it can&#= 39;t be
used. =C2=A0If you've evaluated them sufficiently to conclude they won&= #39;t lie on the
OAR, you already know enough to just whitelist them.

<= /div>
I would argue they aren't the same.

= Trusting that they aren't lying on the OAR just means that I can implem= ent policy about the value of the OAR.

That doesn't mean that we agree on what policy we s= hould implement in regards to authentication-results.

<= div>An MLM could implement OAR but not enforce DMARC, for example. =C2=A0In= that case, a DMARC enforcing receiver could reject the message for DMARC i= f it fails, but not reject messages that passed auth for the mailing list.<= /div>

One could imagine using it for other things as well, th= e spam filtering for a mailing list may not be particularly strong, but wit= h OAR, we could apply different rules based on authentication. =C2=A0One co= uld imagine trusting "authenticated sender in address book" more = than "unauthenticated sender in address book", for example.


Brandon=C2=A0

= =C2=A0
--047d7b41431c503e8504fae1f504-- From nobody Mon Jun 2 15:46:53 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 298FA1A03C7 for ; Mon, 2 Jun 2014 15:46: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 MeyoOvvpFEv5 for ; Mon, 2 Jun 2014 15:46: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 0330B1A03A0 for ; Mon, 2 Jun 2014 15:46:49 -0700 (PDT) Received: (qmail 78641 invoked from network); 2 Jun 2014 22:46:43 -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:cleverness; s=13330.538cfed3.k1406; bh=BkzLLeoH+LeRhqNkmgDz+UfDpC/DPO/UvrCyaOSwKd4=; b=pwWEsM3pPFCpnJ0d5cWxOq5t56a2zMM19GRrwASFMaiIPDXxzjNo+29R5bajmOlPsQeq4qCPMjKGDUf674epU26lljiGCBhMmF0gj7Svcs+oT7lF00W5YwsGVlNkFIuLdALyxB4mWTqxHrW68wZx/Bavy6MUYGrm8W/Q4Dbmim0mdQMFEgiqStPMZvVcI0v6WSS0zttMuj3vHBq/8/ujOF2vJ1Ywbqr81n+MmefcwXeHpMfemjK0JKekvD2+KLcD 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:cleverness; s=13330.538cfed3.k1406; bh=BkzLLeoH+LeRhqNkmgDz+UfDpC/DPO/UvrCyaOSwKd4=; b=veaZ4JcUtrS/srO034d1D70tXqQIQ9ti/0e24GmoE3bHwZHp3S94id5kCKvfWkcCYJoubVcGXbqYfSkF0EdybOF0XwXQF9PrJtDGxq6JRpsjFugeOFAweD3xDIvAdBkM6PPrrru0X52rEiBarg/NPpZxtRaTGq8zbJdNKL+WLhT0TsWi1yf1/puMhY+y1n2tfvhEllayoP/u1rDAo1qEU5sjp0ARemLUU3/0/+j2NV/8Obp76N316r6PSLu8D9mt 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; 02 Jun 2014 22:46:43 -0000 Date: 2 Jun 2014 18:46:43 -0400 Message-ID: From: "John R Levine" To: "Brandon Long" In-Reply-To: References: <20140531031056.2397.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/mN-eX7mnOqB0kp95YsG8Ja1LOQ0 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Yet another mailing list solution thread 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, 02 Jun 2014 22:46:51 -0000 > I proposed internally a scheme where we would compute a reputation for > mailing lists, and ones which are sufficiently high will be whitelisted for > DMARC. The issue that was presented to me is spear phishing attacks > through mailing lists (which we've seen) ... Eww. My lists are set up so that they trap anything with DMARC failures on the way in (it uses the regular taboo words check on the A-R header) but I suppose an OAR would be a reasonable token of good faith. R's, John From nobody Mon Jun 2 16:39:27 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BC71A03E7 for ; Mon, 2 Jun 2014 16:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.201 X-Spam-Level: ** X-Spam-Status: No, score=2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_IS_IT_OUR_ACCOUNT=4.2, FREEMAIL_FROM=0.001, 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 OxbSAv2J0wQd for ; Mon, 2 Jun 2014 16:39:18 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3101A03CD for ; Mon, 2 Jun 2014 16:39:18 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id a108so11789641qge.25 for ; Mon, 02 Jun 2014 16:39:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=oYBbaGfXevrat6H0gGSjqoMYQ9PClDZawNU9WWIuLFk=; b=jJaHvBOlnVyFq4eBDUbujWIHIKFkRIhsD2mxfEimyPXfegl6LBReuHW+FpZvsdmY1V RFf2Js2yTWGvlf+3o1CnFlk+WFtCNvq/oii46E6qg0NnGESubCMMS6qQOqraXATmpUnq so806e7Q4TZuWyQiPlKsxFlXoFnkYvDvdYstRg7i98o+NeFDMiEl/HLjHX/Tj2nJsMN2 3aLcLcYjIH9RtNYSzam7Ysvz6OtkaPsGw1FsUtNPjmqH8EH5xd3eSD4TELitKtfHLkAH JZhnikC9Kzt2Ek1uuNMbsBJEKgCjRhxyvpj+i3Hktim5QKi+k4Be7PZOU7QQnTfKYkTx GAAw== X-Received: by 10.224.68.2 with SMTP id t2mr55199615qai.71.1401752352216; Mon, 02 Jun 2014 16:39:12 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id v19sm23770595qaw.21.2014.06.02.16.39.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Jun 2014 16:39:11 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_5AE6412F-454D-4DEC-ADA4-7962CB6C951B" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: Date: Mon, 2 Jun 2014 16:39:10 -0700 Message-Id: References: <20140528163723.63860.qmail@joyce.lan> <728937278.65439.1401312715643.JavaMail.zimbra@peachymango.org> <87tx887ry5.fsf@uwakimon.sk.tsukuba.ac.jp> <8761kn7f42.fsf@uwakimon.sk.tsukuba.ac.jp> <538917D0.7040604@isdg.net> <08F3556F-2470-424D-8BE2-2DF8B7E27B39@gmail.com> To: Brandon Long X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/dkMgQjL0PNqs0lezZLMGbs07-x4 Cc: "dmarc@ietf.org" , Hector Santos Subject: Re: [dmarc-ietf] Solution for DMARC disruption of normal email use while still offering its normal protection 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, 02 Jun 2014 23:39:23 -0000 --Apple-Mail=_5AE6412F-454D-4DEC-ADA4-7962CB6C951B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Brandon; See comments inline: On Jun 2, 2014, at 2:22 PM, Brandon Long wrote: > On Sun, Jun 1, 2014 at 7:56 PM, Douglas Otis = wrote: > It seems wrong to describe a mailing-list adding Subject Tags, List = Footers, while retaining the =46rom header field so people have an easer = task of knowing who is talking and at reviewing past conversations as = putting recipients in grave risk. Causing a massive number of people to = find different email providers so they can retain their effectiveness at = using a mailing list is far more likely to create risk simply due to the = resulting confusion. >=20 > There is also the case of Intuit sending "From" invoices on behalf of = various individuals and using their customer's email address given to = them by their Internet provider, only to find someone now thinks DKIM = can't possibly be considered valid when signing the Sender header field. = That is exactly the intended purpose for this field. This is essentially = the same issue with mailing-lists. In both cases, there is a valid = reason for the =46rom header field to contain that of their client or = the speaker, because that is what the recipient is able to recognize. = There are also MUAs that will create a synthetic =46rom on = behalf of . Most MUAs can also optionally display both headers.=20= >=20 > The real effort involved in the sequence of these messages is = establishing trust anchors. While there is going to be a massive number = of individuals involved, there are several orders of magnitude fewer = trust anchors. For any domain wanting to assert strict alignment for = their messages, it is only fair for them to work out relationships = between their users messages and the non-aligned third-party services = (trusted domain --> worthy third-party service). Their out-bound logs = and DMARC/User feedback should arrive at a reasonable estimate about = which domains are being trusted. Rogue services will be excluded and = any mistakes can be quickly corrected. >=20 > Rather than describing this as a permission to sign, think of this as = a type of server federation aimed at protecting the federated identity = much like single-user-sign-on. In this case, it would be which of these = services are normally used and maintain practices that protect the = federated identifiers. The TPA-Label scheme allows this type of = federation to be centralized or handled separately by each trusted = domain (senders) as described in = http://tools.ietf.org/html/draft-otis-tpa-label. >=20 > Why should I, or my users, trust Intuit? Why is =46rom domain alignment the only header trusted for user = accounts? For those you need to trust, ask them to use OAR. This can = be a stipulation included in the Authorization. Users may wish to = correspond with more than just transactional messaging after all. At = least allow TPA-Labels to permit exceptions. Be less dogmatic and consider a TPA-Label exception for Sender. There = are many MUAs able to display both Sender and From. Some MUAs even = create a synthesis of =46rom on behalf of . A = configuration script can be provided to users to ensure they are aware = of this option. One might even suspect there is a reasonable number of = users making use of these headers as well. :^) > Perhaps I do because I have friends who have worked there and I use = their software. What about the next payments start-up? Or the Russian = or Chinese equivalent of Intuit that I know nothing about and at best = rely on the google translate version of their home page? IMHO, it is wrong to say WE have decided that messages aligned with the = Sender header field will now be rejected, when for decades this = represented proper use. Yes, it means an email provider will be making = decisions. Welcome to email. :^) We have been making these types of decisions for about two decades = without the valuable resource of outbound domain logs and DMARC = feedback. Much of the information needed to do this properly will be = found in the feedback and logs. Once digested, what has been determined = to be an informally federated domain needs to be shared with recipients = so they can make better decisions without disrupting venerated services. = Since doing this better ensures recipients will be less confused or = upset when things needless change. =20 > Do you expect that we would pass 30k domains through some sort of = human vetting process, and that even if we were willing to do that, we = would be capable of actually vetting them all? Yes. Start with the easy stuff. Eventually, this will catch up. Ignore = newly created domains or have them contact your abuse desk for = escalation. There are far fewer systems identified by domain. There = should be enough redundant confirmations to the point not much human = vetting should be needed. These numbers should not be overwhelming. = Start with sources offering the most compliance information in their = messages. We did our best with much less for the entire address space. = In the long run your users will benefit by establishing these = domain-to-domain relationships. > Third parties that Google uses in this manner need to go through a = vendor security audit. I can certainly say that we don't have the = resources for doing that for 30k services. Even if we did, I'm betting = a good portion of them wouldn't pass. That is why the draft calls this informal federation because it is not = Google, but your users making informal use of services by establishing = their own credentials. Most are very happy with these services. > There's nothing preventing the Intuit case from having the mail sent = From: "Intuit Billing Services" or even "My Company Billing Services" = . Or, if you really want to send from your gmail.com = account, give Intuit permission to send using your account with OAUTH2. = That seems pretty acceptable for a billing arrangement. Vet message domains based on prior histories. Judy.c makes this process = very easy and quick. Please don't advocate companies become fast and = loose with their credentials. Especially in places like China and = Japan. Losses are adding up quickly, where each domain needs to stand = on its own. A provider willing to request a stringent DMARC domain = alignment should also be willing to offer the likely exceptions needed = to prevent tens of thousands of services from being disrupted. This is = especially true when the underlying reason for the request is = compromised user accounts. This then becomes about what is needed to = establish cooperation between sender and receiver. Regards, Douglas Otis --Apple-Mail=_5AE6412F-454D-4DEC-ADA4-7962CB6C951B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Dear = Brandon;

See comments inline:

On Sun, Jun 1, 2014 at = 7:56 PM, Douglas Otis <doug.mtview@gmail.com> = wrote:
It = seems wrong to describe a mailing-list adding Subject Tags, List = Footers, while retaining the =46rom header field so people have an easer = task of knowing who is talking and at reviewing past conversations as = putting recipients in grave risk.  Causing a massive number of = people to find different email providers so they can retain their = effectiveness at using a mailing list is far more likely to create risk = simply due to the resulting confusion.

There is also the case of Intuit sending "From" = invoices on behalf of various individuals and using their customer's = email address given to them by their Internet provider, only to find = someone now thinks DKIM can't possibly be considered valid when signing = the Sender header field. That is exactly the intended purpose for this = field. This is essentially the same issue with mailing-lists.  In = both cases, there is a valid reason for the =46rom header field to = contain that of their client or the speaker, because that is what the = recipient is able to recognize.  There are also MUAs that will = create a synthetic =46rom <sender> on behalf of <from>. =  Most MUAs can also optionally display both headers. 

The real effort involved in the sequence of these = messages is establishing trust anchors. While there is going to be a = massive number of individuals involved, there are several orders of = magnitude fewer trust anchors.  For any domain wanting to assert = strict alignment for their messages, it is only fair for them to work = out relationships between their users messages and the non-aligned = third-party services (trusted domain --> worthy third-party service). =  Their out-bound logs and DMARC/User feedback should arrive at a = reasonable estimate about which domains are being trusted.  Rogue = services will be excluded and any mistakes can be quickly = corrected.

Rather than describing this as a permission to sign, = think of this as a type of server federation aimed at protecting the = federated identity much like single-user-sign-on.  In this case, it = would be which of these services are normally used and maintain = practices that protect the federated identifiers.  The TPA-Label = scheme allows this type of federation to be centralized or handled = separately by each trusted domain (senders) as described in http://tools.ietf.org/html/draft-otis-tpa-label.

Why should I, or my users, = trust = Intuit?

Why is = =46rom domain alignment the only header trusted for user accounts? =  For those you need to trust, ask them to use OAR.  This can = be a stipulation included in the Authorization.  Users may wish to = correspond with more than just transactional messaging after all. =  At least allow TPA-Labels to permit = exceptions.

Be less dogmatic and consider a = TPA-Label exception for Sender.  There are many MUAs able to = display both Sender and From.   Some MUAs even create a synthesis = of =46rom <sender> on behalf of <from>.  A = configuration script can be provided to users to ensure they are aware = of this option.  One might even suspect there is a reasonable = number of users making use of these headers as well. = :^)

Perhaps I do = because I have friends who have worked there and I use their software. =  What about the next payments start-up?  Or the Russian or = Chinese equivalent of Intuit that I know nothing about and at best rely = on the google translate version of their home = page?

IMHO, it = is wrong to say WE have decided that messages aligned with the Sender = header field will now be rejected, when for decades this represented = proper use.  Yes, it means an email provider will be making = decisions.  Welcome to email. :^)

We have = been making these types of decisions for about two decades without the = valuable resource of outbound domain logs and DMARC feedback.  Much = of the information needed to do this properly will be found in the = feedback and logs.  Once digested, what has been determined to be = an informally federated domain needs to be shared with recipients so = they can make better decisions without disrupting venerated services. =   Since doing this better ensures recipients will be less confused = or upset when things needless change. =   

Do you expect that we would pass 30k domains through some sort of = human vetting process, and that even if we were willing to do that, we = would be capable of actually vetting them = all?

Yes. Start = with the easy stuff.  Eventually, this will catch up.  Ignore = newly created domains or have them contact your abuse desk for = escalation.  There are far fewer systems identified by domain. = There should be enough redundant confirmations to the point not much = human vetting should be needed.  These numbers should not be = overwhelming.  Start with sources offering the most compliance = information in their messages.  We did our best with much less for = the entire address space.  In the long run your users will benefit = by establishing these domain-to-domain = relationships.

Third parties that Google uses in this manner need to go through a = vendor security audit.  I can certainly say that we don't have the = resources for doing that for 30k services.  Even if we did, I'm = betting a good portion of them wouldn't = pass.

That is = why the draft calls this informal federation because it is not Google, = but your users making informal use of services by establishing their own = credentials.  Most are very happy with these = services.

There's nothing preventing the Intuit case from having the mail = sent From: "Intuit Billing Services" or even "My Company Billing = Services" <foo@intuit.com>. =  Or, if you really want to send from your gmail.com account, give Intuit permission = to send using your account with OAUTH2.  That seems pretty = acceptable for a billing = arrangement.

Vet = message domains based on prior histories.  Judy.c makes this = process very easy and quick.  Please don't advocate companies = become fast and loose with their credentials.  Especially in places = like China and Japan.  Losses are adding up quickly, where each = domain needs to stand on its own.  A provider willing to request a = stringent DMARC domain alignment should also be willing to offer the = likely exceptions needed to prevent tens of thousands of services from = being disrupted.  This is especially true when the underlying = reason for the request is compromised user accounts. This then becomes = about what is needed to establish cooperation between sender and = receiver.

Regards,
Douglas = Otis



= --Apple-Mail=_5AE6412F-454D-4DEC-ADA4-7962CB6C951B-- From nobody Mon Jun 2 18:30:00 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5F21A000F for ; Mon, 2 Jun 2014 18:29: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 aAhbM3iQfjDa for ; Mon, 2 Jun 2014 18:29:55 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 660491A000E for ; Mon, 2 Jun 2014 18:29:55 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 382C0D04630; Mon, 2 Jun 2014 21:29:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1401758989; bh=OcXBN4WMx2aYD8t9e0OdPGAS9+gwtW9jk2owGvDCUXA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=q2UH49F7LYzvSxKmu5kEzbBsLyZ6yxfMQO95UdWk8vGPR/KzfcRijnn38w45Druj3 Xh7N1m9DF4m6JgBiEhiA/xl9KhhR6IJG1OoQlhm78+qhJDoIWrnwqWYc9ShIFsyztt EB/HSE5RYvXkT5VsesRwBCmrZbfCCjZe1o16rNTI= Received: from scott-latitude-e6320.localnet (ip-64-134-157-170.public.wayport.net [64.134.157.170]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id ED8B9D0426F; Mon, 2 Jun 2014 21:29:48 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 02 Jun 2014 21:29:47 -0400 Message-ID: <1677893.qTRGoaNQnE@scott-latitude-e6320> User-Agent: KMail/4.13 (Linux/3.13.0-27-generic; KDE/4.13.0; x86_64; ; ) In-Reply-To: References: <1915486.LDfXbrr8S0@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/y9iewnWhHrs3WJgmZbYzELzggt4 Subject: Re: [dmarc-ietf] Yet another mailing list solution thread 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, 03 Jun 2014 01:29:57 -0000 On Monday, June 02, 2014 15:31:36 Brandon Long wrote: > On Mon, Jun 2, 2014 at 1:36 PM, Scott Kitterman > > wrote: > > Trust in this context means "trust not to lie on the OAR". Either you > > trust > > them not to lie (and the content can be used) or you don't and it can't be > > used. If you've evaluated them sufficiently to conclude they won't lie on > > the > > OAR, you already know enough to just whitelist them. > > I would argue they aren't the same. > > Trusting that they aren't lying on the OAR just means that I can implement > policy about the value of the OAR. > > That doesn't mean that we agree on what policy we should implement in > regards to authentication-results. > > An MLM could implement OAR but not enforce DMARC, for example. In that > case, a DMARC enforcing receiver could reject the message for DMARC if it > fails, but not reject messages that passed auth for the mailing list. > > One could imagine using it for other things as well, the spam filtering for > a mailing list may not be particularly strong, but with OAR, we could apply > different rules based on authentication. One could imagine trusting > "authenticated sender in address book" more than "unauthenticated sender in > address book", for example. Even if I grant you that (and I'm not sure I do), I also don't know why OAR is better than AR. In order to ensure OAR was added by the ML (or whoever you trust to add it correctly) you're going to have to grovel through the received fields and see if the MTA you trust added the field. Once you've done that, you might as well just use AR. Calling it OAR adds nothing beyond forcing us to re-invent the wheel. Scott K From nobody Mon Jun 2 20:17:26 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E125C1A0062 for ; Mon, 2 Jun 2014 20:17:24 -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 MGeQ3YJrlGwf for ; Mon, 2 Jun 2014 20:17: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 BAA581A0058 for ; Mon, 2 Jun 2014 20:17:23 -0700 (PDT) Received: (qmail 26353 invoked from network); 3 Jun 2014 03:17:16 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 3 Jun 2014 03:17:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=10777.538d3e3c.k1406; i=johnl@user.iecc.com; bh=fPm+W83C6WKUz6L75csIDDKB5XvWAT4M2GY0QgCIot8=; b=XpIwk6hkgzwae9A1D4tYHTTH84AV0GaqHgOSUZHBTHauIgz2vG8UJ80h6b1LiiFUiv97fifpeMZWkUlqka4Bm6+ObcCanPieMfRlZztUWyIYZXlydeTA2oP/N6VPswKOyY911UF/uR5rz+iOld/Oe6t9Abbq650OCvkhsAqGdCgecMxAEGe2kVNQ7Cl+H63SkWt98HFlt6/Xi5j/gPIuoXs0Q0R3QqnOf9WuZZq24PKPfUWwN13jGWwONGQJQSlQ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=10777.538d3e3c.k1406; olt=johnl@user.iecc.com; bh=fPm+W83C6WKUz6L75csIDDKB5XvWAT4M2GY0QgCIot8=; b=D9C29AqbAo2KRVqBDvZGueykw4luwZk1wEH71bMH5hy5F470DbKZzCBvvJTpi0gEcoLPOpOeGJ8FslCuFZzdvQT2SL5OMbmHqvtJqSfjEUxyObMpZN39sL9LWBgbZMOxIfkCv+NtD1xR2FPlK83iCoJUenQCXjQBMOnb8sBLKVrMqZeWSehloB698pfXlYjlZgC9bAs6j9jcmhMNAc/V0ykdUA87xnticAQ1bCLLr4cbEh1we7Ggki9fq5Fenjr6 Date: 3 Jun 2014 03:16:54 -0000 Message-ID: <20140603031654.67446.qmail@joyce.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: http://mailarchive.ietf.org/arch/msg/dmarc/j1PacplTxIUjZ8nmJumFk8L2hjM Cc: zwicky@yahoo-inc.com Subject: Re: [dmarc-ietf] Yet another mailing list solution thread 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, 03 Jun 2014 03:17:25 -0000 >A mailing-list and receiver change option that has also been suggested to me is to have mailing lists >include the original message as a MIME component -- you can then verify the signature on the original >message and do some kind of comparison to the new one and decide how you feel about it. Again, it's a >future-work solution. Well, yeah, we call those MIME digests. They work now in most list managers, but the UI leaves a lot to be desired. Most list managers let you set the digest frequency so you could set it to something like five minutes to limit the delivery delay, and most of the digests would have only one or two messages. It occurs to me that Yahoo has a set of 30,000 mailing list like hosts that send you mail according to last month's blog post, and due the way DMARC works, you can look at a copy of every message that is rejected due to DMARC policy. Have you looked at the DMARC rejected stuff from those hosts, or a sample thereof, to see whether they're really a hole you need to protect your users from? R's, John From nobody Tue Jun 3 03:46:17 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6A51A01AB for ; Tue, 3 Jun 2014 03:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 lbrFxS6tdDR7 for ; Tue, 3 Jun 2014 03:46:15 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id CFC461A01B4 for ; Tue, 3 Jun 2014 03:46:13 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id B3B0397086A; Tue, 3 Jun 2014 19:46:07 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 9FE0B1A31E2; Tue, 3 Jun 2014 19:46:07 +0900 (JST) From: "Stephen J. Turnbull" To: Scott Kitterman In-Reply-To: <1677893.qTRGoaNQnE@scott-latitude-e6320> References: <1915486.LDfXbrr8S0@scott-latitude-e6320> <1677893.qTRGoaNQnE@scott-latitude-e6320> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 03 Jun 2014 19:46:07 +0900 Message-ID: <87tx8246fk.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/xQ9wOXuDD2PH_XL-zcMdu5bV0Gk Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Yet another mailing list solution thread 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, 03 Jun 2014 10:46:16 -0000 Scott Kitterman writes: > In order to ensure OAR was added by the ML (or whoever you trust to > add it correctly) you're going to have to grovel through the > received fields and see if the MTA you trust added the field. Re: groveling. Received fields are easy to fake and nobody signs those (what would that mean, anyway?) Obviously you need to sign any *AR you did yourself, or nobody should trust it. That should make it "easy" to determine trust. Am I missing something? Besides the complexity of chains of trusted authenticators, of course. Obviously further protocol would be needed there. Steve From nobody Tue Jun 3 04:26:54 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C6C1A01CC for ; Tue, 3 Jun 2014 04:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.909 X-Spam-Level: * X-Spam-Status: No, score=1.909 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_110=0.6] 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 opzqcJizgt_8 for ; Tue, 3 Jun 2014 04:26:51 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id B9EAF1A01C4 for ; Tue, 3 Jun 2014 04:26:50 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 9096F970B2C; Tue, 3 Jun 2014 20:26:44 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 72AFA1A31E2; Tue, 3 Jun 2014 20:26:44 +0900 (JST) From: "Stephen J. Turnbull" To: Elizabeth Zwicky In-Reply-To: References: <5387F6E0.1070903@att.com> <15749590.z7A0vHW603@scott-latitude-e6320> <87ppiu57zt.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 03 Jun 2014 20:26:44 +0900 Message-ID: <87sinm44jv.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/jNbVxpv0uzsC83w4tsTqfot96Jo Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 03 Jun 2014 11:26:52 -0000 Elizabeth Zwicky writes: > At this point, I do not see going to p=quarantine in the hope > that attackers won't exploit data they already have exactly the same > way Has Yahoo! has already tried 'p=quarantine', or is that merely your expert opinion? (Nothing against expertise, but "experiment" beats "expertise" 10 letters to 9 in my dictionary.) Obviously, there is a risk to Yahoo! in experimenting. Nevertheless, DMARC is a *private* agreement among parties using the *public* Internet, and Yahoo!'s use of DMARC is *demonstrably* harming Yahoo! users as well as 3rd parties in no way participating in DMARC. Perhaps "corporate social responsibility" requires that Yahoo! accept those risks as an experiment. > what will happen then is that they go very aggressive at 2:00 in > the morning my time, Which is, I remind you, exactly what Yahoo! did to list subscribers and operators. The difference is that you will know to expect it, and you can probably arrange for an automatic tripwire to return to "p=reject" much more quickly than you responded to the last attack. You can also make an additional, even more private, agreement with AOL, Google, and Hotmail (which should cover the vast majority of very-vulnerable-to-fraudulent-recommendations-from-yahoo-mailboxes users out there) to give messages failing identity alignment with yahoo.com a more-thorough-than-usual spam check. > followed by a great deal of bad press. Yahoo's good press doesn't make our ugly mitigations any prettier, and we're not brimming over with good will toward Yahoo! now -- i.e., we're not happy that Yahoo! gets less bad press at our subscribers' expense. Does that matter? I don't know, but I can tell you that there is a "friends don't let friends use Yahoo!" meme spreading -- not just from disgruntled MLM developers! -- and Yahoo! could probably use more friends. For example, the Japanese Ministry of Education immediately broadcast warnings to dependent organizations that Yahoo! mailboxes will have trouble with unreliable delivery and cause bounces that upset mailing lists and sysadmins. They explicitly recommended avoiding use of Yahoo! accounts in connection with academic activity. Ironically enough, this was pure FUD. :-( yahoo.co.jp did not publish a 'reject' (or even 'quarantine') policy (AFAIK they never have, and as of this writing they don't). I don't know what MEXT thought they were doing (although I suspect what the US Trade Representative would call "structural impediments"). Do I tell my colleagues that truth? Oh, over beers (but I don't drink with the departmental computer committee), of course, and my local LUG has heard all about it and we all had a good laugh. I am not going to waste words on the bureaucracy, though. For one, trying to teach our Computer Center (forget the central bureaucrats) what they don't know is worse than dealing with sophomores. But this is also very useful to me, as on my educational lists I had few Yahoo! users (all with Asian domains), now I have none, and I just ban them going forward -- no RFC-violating mitigation necessary. I've told my subscribers, too, but they don't understand the difference between MEXT FUD about Yahoo! and the draconian policies on file-sharing software imposed by Japanese universities, so most had already switched anyway, and none consider my ban an imposition. So AFAICT, MEXT's FUD has been effective. Ban unnecessary? For now, but I don't feel like trying to figure out how closely Yahoo! Japan is going to follow the lead of the parent company, or when. Your own words make me sure that Yahoo! cannot be trusted to behave with consideration to 3rd parties or to give warning. Furthermore, it establishes a precedent: "p=reject" is grounds for banning a whole domain. I'll never need to use ugly mitigations on my university lists, even if this practice spreads beyond Yahoo! and AOL, and I have MEXT authority for it. So this misunderstanding suits me perfectly. I doubt I'm alone in that. One more note: all but one of my former Yahoo! users are Chinese, and they tell me the same meme is spreading there. If you think Japanese "structural impediments" are annoying, just wait until you have to deal with the Chinese version. Regards, From nobody Tue Jun 3 07:16:14 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE8D1A0171 for ; Tue, 3 Jun 2014 07:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 ZTCyMk03IE0k for ; Tue, 3 Jun 2014 07:16:13 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9401A0227 for ; Tue, 3 Jun 2014 07:16:11 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 19071970B2C; Tue, 3 Jun 2014 23:16:05 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 07B211A31E2; Tue, 3 Jun 2014 23:16:04 +0900 (JST) From: "Stephen J. Turnbull" To: Franck Martin In-Reply-To: <55382129.27361.1401740317786.JavaMail.zimbra@peachymango.org> References: <5387F6E0.1070903@att.com> <87ha456dlt.fsf@uwakimon.sk.tsukuba.ac.jp> <538A76ED.4050609@att.com> <8738fn6a96.fsf@uwakimon.sk.tsukuba.ac.jp> <55382129.27361.1401740317786.JavaMail.zimbra@peachymango.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 03 Jun 2014 23:16:04 +0900 Message-ID: <87r4363wpn.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/iV5DK74FnmsIddOSYuWJCfRydZ0 Cc: Tony Hansen , dmarc@ietf.org, Kurt Andersen Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 03 Jun 2014 14:16:14 -0000 Franck Martin writes: > But why would you accept emails from invalid domains in the first > instance? Because the email is legitimate, of course. I've seen people use "example.com" in their addresses on list posts to ensure they won't get personal replies. I've seen people use "noreply@personal.dom" as their valid return address. That kind of thing may not happen on your lists, and you may not care to play along with the game. Fine. But remember, the domain, or even the whole mailbox, in From: is only one consideration in making that judgment of legitimacy. Steve From nobody Tue Jun 3 07:40:25 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F631A02D5 for ; Tue, 3 Jun 2014 07:40:17 -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 XdW1kERKojul for ; Tue, 3 Jun 2014 07:40:13 -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 D308E1A02DA for ; Tue, 3 Jun 2014 07:40:12 -0700 (PDT) Received: (qmail 55558 invoked from network); 3 Jun 2014 14:40:06 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 3 Jun 2014 14:40: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:mime-version:content-type:content-transfer-encoding; s=11c30.538dde45.k1406; i=johnl@user.iecc.com; bh=1h78MWAQy9r5P7jcZVRxesfn6CBFRVL8zcYGJoHZr3g=; b=xKDqP64U0PRIXeyC08bMaOu80iPEDZnBQ11NvQeLECVt2kHSgnSq3h8upfxrsD1VRHUqS7SnuIzGliRRfCtgRELLPPeDUIrFs62jhrBbFWHNBbhy7yErHt+lwbvQrYgQ8k5X4v/OlSBaB6qjyxooERqyXttV65aSR19OK5UU54vdiBm/KGp2ZvfCX5WxNKYMSmCqillV8HC6Nh8ImPvf2Nk3OC6O/+YmEGJ90BlsDkWMg4lEhc24V1xNzkC+pwzx DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=11c30.538dde45.k1406; olt=johnl@user.iecc.com; bh=1h78MWAQy9r5P7jcZVRxesfn6CBFRVL8zcYGJoHZr3g=; b=TBYVJkZyOJJ6/dOz7hpXmurzyS+sDls92RrWr+7qSFOchDHx3n0kpxKQ6HOj8guuLKiTk9Y4TzZV6R/xpQfUfck7S/WnzQXdTwYo2k47W6rZH+WYnaay1YLAschINSaAjBQTJSwiOlX83edu2jMq9xVBFH2Kjz8lddhPTHkCH8qq4F4SBhXxRYkvcku5kBnu81G+wLUK/+r1lkDs/codErs2TySe2AOmXGBhZsenaA9/FZpyXbPSfM+Z1W0nVnbD Date: 3 Jun 2014 14:39:43 -0000 Message-ID: <20140603143943.72751.qmail@joyce.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: http://mailarchive.ietf.org/arch/msg/dmarc/K2aGctt-KePFy8QjJpJmOLMyEno Cc: blong@google.com Subject: Re: [dmarc-ietf] list side validation, was Yet another mailing list solution thread 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, 03 Jun 2014 14:40:17 -0000 >The OAR isn't necessary for a DMARC "compliant" MLM which would know to >make sure the message passed DMARC as sent by following one of the >mitigation strategies (don't munge the message, munge the from, embed the >message as an attachment, etc). It seems necessary for any whitelisting >scheme, however, otherwise an "anyone can post" mailing list on a host >which doesn't enforce DMARC is a wide-open hole. But any list that doesn't limit who can post is a wide open hole anyway. I don't think there are very many, and don't much care what happens to them. The only one I subscribe to is freebsd-users, whose managers apparently believe that limiting who can post is pointless because the spammers care enough to find the list and subscribe. R's, John From nobody Tue Jun 3 07:42:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 592A71A02C5 for ; Tue, 3 Jun 2014 07:42:49 -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 k2Vwr6mvg40z for ; Tue, 3 Jun 2014 07:42: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 738991A02BE for ; Tue, 3 Jun 2014 07:42:48 -0700 (PDT) Received: (qmail 56603 invoked from network); 3 Jun 2014 14:42:42 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 3 Jun 2014 14:42:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=11c46.538ddee2.k1406; i=johnl@user.iecc.com; bh=xquHPt5Q8JvZlw+FN648NVcGHqGIEJq/XxRWYwtPZ+4=; b=Yv9sPSsZoWd9W8xLG30wXr1vKM09u5gSnZgqwaZKSXOrLAZDr4Se0usYxzomdYgDVZ/sg4IxYy0mxmPr2/FfH31ff9H39cGJ/lBVEHCwXlES4yrumX3omVe0BUj4ZdV+zwaZzCc90UbcOUGmeOXKGTrVwUi7bc1uYegtZASc9jBAHdMuDOGkH6qvfY8WPC6WBODxV7OYiSrz3rldeS1HfErAZ0o/SyqD8B9EusPI3hsWm6XUVdkuoRfMGmWgSmST DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=11c46.538ddee2.k1406; olt=johnl@user.iecc.com; bh=xquHPt5Q8JvZlw+FN648NVcGHqGIEJq/XxRWYwtPZ+4=; b=nuHHIXdv7sPi98nPm+/ts6CdCB/UEqYOC+FKTRrBW1I88+VlA5Twkz8dswv3X4IzqFaF7vxpmVpPoJy5PKXdnCeybycjcPkX7VNzz2siax2icxrIFKiTmSkJiM+0hVFjM+pBVO0W1ef14vFauZ8gusxQ6pnTp9y8ge/GtOjtTQrsj9p9klptXacIvAbTbVfvL1dZP4XWyVi64FPJMozeVGdaYQNld1hWAV175x3BaCiw+UWnXoCgowUUuKDDkQZI Date: 3 Jun 2014 14:42:19 -0000 Message-ID: <20140603144219.72773.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <1677893.qTRGoaNQnE@scott-latitude-e6320> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/BTH32D13zq8UialF-i4wNCY1Mt4 Cc: sklist@kitterman.com Subject: Re: [dmarc-ietf] Yet another mailing list solution thread 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, 03 Jun 2014 14:42:49 -0000 >Even if I grant you that (and I'm not sure I do), I also don't know why OAR is >better than AR. I get the impression there are two reasons for OAR: a) A-R is likely to be stripped by intermediate MTAs, OAR isn't. b) whoever suggested OAR didn't understand A-R semantics Take your pick. R's, John PS: I just adjusted my lists to add OAR so I expect zero bounces now. From nobody Tue Jun 3 08:14:49 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A81E1A02D6 for ; Tue, 3 Jun 2014 08:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 zqrE6-1hYQCB for ; Tue, 3 Jun 2014 08:14:43 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id B008F1A02E5 for ; Tue, 3 Jun 2014 08:14:43 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 622A7970B27; Wed, 4 Jun 2014 00:14:37 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 4E8B81A31E2; Wed, 4 Jun 2014 00:14:37 +0900 (JST) From: "Stephen J. Turnbull" To: Franck Martin In-Reply-To: <466746097.24148.1401734879005.JavaMail.zimbra@peachymango.org> References: <5387F6E0.1070903@att.com> <87ha456dlt.fsf@uwakimon.sk.tsukuba.ac.jp> <538A76ED.4050609@att.com> <8738fn6a96.fsf@uwakimon.sk.tsukuba.ac.jp> <466746097.24148.1401734879005.JavaMail.zimbra@peachymango.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 04 Jun 2014 00:14:37 +0900 Message-ID: <87ppiq3u02.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/zS0WbvXGvsLpKNmGWkS82-KhsuU Cc: dmarc@ietf.org, Tony Hansen Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 03 Jun 2014 15:14:46 -0000 Franck Martin writes: > I'm not sure it is wise to encourage the use of "invalid" domains > in any of the email headers. Remember, we think *all* of the mitigations should be discouraged in favor of not permitting posts from "p=reject" domains. But we also know that will be unacceptable to most of our list operators. > The use of the .INVALID is likely to create problems in the future, > if not already with reputation systems. We'll warn our users (list operators) of the troubles we know of. Corrupting an existing mailbox in the header of a post in any way is at the bottom of the list of the things we think a mailing list should do, of course (unless it's part of the terms of service of the list -- eg, anonymous lists). BTW, I'm not particularly worried about reputation systems for spam- fighting. I believe it's a fundamentally unsound idea, aiming at the one resource that we *know* spammers put zero value on: reputation of Internet addresses. Both their own (because they keep those carefully hidden), and the reputations of the hosts, individuals, and services they parasitize. Regards, From nobody Tue Jun 3 09:18:06 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA451A030C for ; Tue, 3 Jun 2014 09:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 wG5CUwltB_Bt for ; Tue, 3 Jun 2014 09:18:01 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id 021631A02FC for ; Tue, 3 Jun 2014 09:18:00 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id BB03C970B27; Wed, 4 Jun 2014 01:17:54 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id AAA4E1A31E2; Wed, 4 Jun 2014 01:17:54 +0900 (JST) From: "Stephen J. Turnbull" To: "John Levine" In-Reply-To: <20140603144219.72773.qmail@joyce.lan> References: <1677893.qTRGoaNQnE@scott-latitude-e6320> <20140603144219.72773.qmail@joyce.lan> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 04 Jun 2014 01:17:54 +0900 Message-ID: <87oaya3r2l.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/uMd1Arwx9WzoWvE40QTwoDDHl4A Cc: dmarc@ietf.org, sklist@kitterman.com Subject: Re: [dmarc-ietf] Yet another mailing list solution thread 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, 03 Jun 2014 16:18:02 -0000 John Levine writes: > >Even if I grant you that (and I'm not sure I do), I also don't > >know why OAR is better than AR. > > I get the impression there are two reasons for OAR: > > a) A-R is likely to be stripped by intermediate MTAs, OAR isn't. > > b) whoever suggested OAR didn't understand A-R semantics You're joking, right? >From the O-A-R I-D: Some sites wish to take into consideration such authentication results claimed by trusted intermediaries, effectively extending the trusted channel to specific external entities. Although [AUTHRES] includes support for this notion, this separate mechanism is simpler, more robust, and requires no changes to existing authentication infrastructure. Therefore, this document defines a new field called Original- Authentication-Results. The content of the field is identical to that specified in [AUTHRES]. This field is required to be unique, appearing only once in a message, and thus it is possible to determine conclusively whether or not it is included in the part of the header covered by a signature. I think that's clear enough, although you might dispute whether it actually works as advertised (seems to, to me). It also seems good enough for 95% of all mailing list usage, including the "spear- phishing through an ML" case described earlier. I wonder if the d, s, i fields in DKIM could somehow be coopted to create a conventional authserv-id for A-R. That could make it easy to identify the "right" A-R in a header with multiple such. (Ignoring the case of a 3rd party deliberately introducing fake duplicates, which would make the message suspect all by itself.) Regards, From nobody Tue Jun 3 10:53:03 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946DD1A033E for ; Tue, 3 Jun 2014 10:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.722 X-Spam-Level: X-Spam-Status: No, score=-15.722 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, J_CHICKENPOX_110=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] 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 F_YH9_S-NIoV for ; Tue, 3 Jun 2014 10:52:59 -0700 (PDT) Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49D4C1A02FB for ; Tue, 3 Jun 2014 10:52:59 -0700 (PDT) Received: from GQ1-EX10-CAHT01.y.corp.yahoo.com (gq1-ex10-caht01.corp.gq1.yahoo.com [10.73.118.80]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id s53HpVVd075106 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Jun 2014 10:51:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1401817893; bh=x8QHE1ozgzviNoei/hoBOBaZyYVBWXfN7QEWmvpGpA8=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=AOvRSAPQCT1x/2sufL0diCYr2ppc2t5mGdI+2rv0KsF/tJ2LrWKnEXWhL3ItaRVzN nC9MWm14x2muzy/2fUolIYk6Yc2o1wWqjSZz2H7CW93Juo5FTR11BpwB3qnq4RtMDi DfZrFXd32f1S9DqNRBlY1b9Xx33gVBRxOwwh3awc= Received: from GQ1-MB01-02.y.corp.yahoo.com ([fe80::a049:b5af:9055:ada6]) by GQ1-EX10-CAHT01.y.corp.yahoo.com ([fe80::7c21:dcd7:76a1:8f1b%12]) with mapi id 14.03.0181.006; Tue, 3 Jun 2014 10:51:31 -0700 From: Elizabeth Zwicky To: "Stephen J. Turnbull" Thread-Topic: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) Thread-Index: AQHPe7Tw0rXUTivWFE2qV1g12n37IZtY8MgAgABrEACAAd3rAIAC2XCAgAGoIQD///YXAA== Date: Tue, 3 Jun 2014 17:51:27 +0000 Message-ID: References: <5387F6E0.1070903@att.com> <15749590.z7A0vHW603@scott-latitude-e6320> <87ppiu57zt.fsf@uwakimon.sk.tsukuba.ac.jp> <87sinm44jv.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87sinm44jv.fsf@uwakimon.sk.tsukuba.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [216.145.54.7] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 817892002 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/gx2RUAAPQARbjHw9EXNuBoRuCR4 Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 03 Jun 2014 17:53:01 -0000 On 6/3/14, 4:26 AM, "Stephen J. Turnbull" wrote: >Elizabeth Zwicky writes: > > > At this point, I do not see going to p=3Dquarantine in the hope > > that attackers won't exploit data they already have exactly the same > > way > >Has Yahoo! has already tried 'p=3Dquarantine', or is that merely your >expert opinion? (Nothing against expertise, but "experiment" beats >"expertise" 10 letters to 9 in my dictionary.) > >Obviously, there is a risk to Yahoo! in experimenting. That risk is not one my management team is willing to accept. But I do, in fact, have data, and that data tells me that the attackers forging our users based on stolen addressbooks have never stopped; we are still blocking them now. So I don't need to turn on p=3Dquarantine to see what will happen -- I know at least one thing that will happen. The only question is how the volume will change. By the way, yahoo.co.jp is an independent company with a separate mail system and a separate account database. Elizabeth Zwicky zwicky@yahoo-inc.com From nobody Tue Jun 3 12:39:29 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39241A0348 for ; Tue, 3 Jun 2014 12:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RP_MATCHES_RCVD=-0.651, 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 XK8ygRA0Y_vz for ; Tue, 3 Jun 2014 12:39:26 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC90E1A0309 for ; Tue, 3 Jun 2014 12:39:26 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id y20so6363703ier.34 for ; Tue, 03 Jun 2014 12:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2AKIPfcNXId538b56tNnwpr+/AUK2R8X4vK6VtGBJwY=; b=msdoyfewhVd3l/0d9Oc0D2M3oVt5W2JarJwYF9NNvtDsr+hGttULCPWjWY8FcHyjoq Gqvzv1iwq0FY4SwHyDTfMdP20CIJDahBDGkYPBPSpNt1U3qye3g5pRRbwd+qubeixoH1 Ytr2Vq94UFvl9WcG0FvlhwyWVPnSaEatHtBytVSsdG8uhoYyGk0qZZ+qERQuPBntFngf /Srd2PS0ClxCaoG2NOzHyHIS2985w+BMxCyzluqFLhFSat8TFfPR1RfW3VomqTsIh+cy VY93TSNl7poXlgUUBgKQKpylvDv+i1y4NFPzDncLNtcXu+usQckNhaoDjjlY5NmEAeJ5 hvtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2AKIPfcNXId538b56tNnwpr+/AUK2R8X4vK6VtGBJwY=; b=mVTWj5eM7oSFFolpBay7h4RKJMdI0Pq4slrc35vsjfWurqyZCvvAAaRFOjs16dRQWK KnZjinL16BHn1pcPMXzJUVJ+Kx+vAl5xx65OSgKYRqpduYW4k2f1kHYzECuEGCssHUQo x1mzUMoPZVCR/Z/+hqVmqdHH1bCYn+rencrVLgV3Ad9i1pjVVDU1RhR6bstfxPk1Hk+t 6szGbFoIWOOMEm/YgumS/vANsZ/KnHfS+PyLqqyI26E/u3A8FgNqa7Q22uq9q3o2T4T5 SGkNbDpvDTMAqXIfeU8FB0I/9q+uxn1H55G/NhkwD9s3CzfJtSh5xKpwwte5VxrmzG2Z d9sw== X-Gm-Message-State: ALoCoQlGQ+m9c5X+hZaTqMMPyuSGFkSpSe7ZPJWBapAlIyTnE2vNrB7+3g7UDtlhJ0KomSmzUk89 MIME-Version: 1.0 X-Received: by 10.42.212.18 with SMTP id gq18mr44514489icb.48.1401824360888; Tue, 03 Jun 2014 12:39:20 -0700 (PDT) Received: by 10.64.213.73 with HTTP; Tue, 3 Jun 2014 12:39:20 -0700 (PDT) In-Reply-To: <20140603143943.72751.qmail@joyce.lan> References: <20140603143943.72751.qmail@joyce.lan> Date: Tue, 3 Jun 2014 12:39:20 -0700 Message-ID: From: Brandon Long To: John Levine Content-Type: multipart/alternative; boundary=20cf303e9d8211a9ef04faf3ab16 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/u1mBXngkwgvCPOs0Ka2oyjf7Zy0 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] list side validation, was Yet another mailing list solution thread 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, 03 Jun 2014 19:39:27 -0000 --20cf303e9d8211a9ef04faf3ab16 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 3, 2014 at 7:39 AM, John Levine wrote: [quoting me, iirc] > >The OAR isn't necessary for a DMARC "compliant" MLM which would know to > >make sure the message passed DMARC as sent by following one of the > >mitigation strategies (don't munge the message, munge the from, embed the > >message as an attachment, etc). It seems necessary for any whitelisting > >scheme, however, otherwise an "anyone can post" mailing list on a host > >which doesn't enforce DMARC is a wide-open hole. > > But any list that doesn't limit who can post is a wide open hole > anyway. I don't think there are very many, and don't much care what > happens to them. The only one I subscribe to is freebsd-users, whose > managers apparently believe that limiting who can post is pointless > because the spammers care enough to find the list and subscribe. > All smtp is a wide open hole. The point of authentication and DMARC is to change that, to reduce the attack surface. The argument then becomes how big a hole is too much to leave open. DMARC p=REJECT was supposed to be nearly completely closed for those implementing it. Brandon --20cf303e9d8211a9ef04faf3ab16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 3, 2014 at 7:39 AM, John Levine <johnl@taugh.com> wrot= e:
[quoting me, iirc]
>The OAR isn't = necessary for a DMARC "compliant" MLM which would know to
>make sure the message passed DMARC as sent by following one of the
>mitigation strategies (don't munge the message, munge the from, emb= ed the
>message as an attachment, etc). =C2=A0It seems necessary for any whitel= isting
>scheme, however, otherwise an "anyone can post" mailing list = on a host
>which doesn't enforce DMARC is a wide-open hole.

But any list that doesn't limit who can post is a wide open hole
anyway. =C2=A0I don't think there are very many, and don't much car= e what
happens to them. =C2=A0The only one I subscribe to is freebsd-users, whose<= br> managers apparently believe that limiting who can post is pointless
because the spammers care enough to find the list and subscribe.

All smtp is a wide open hole. =C2=A0The point of = authentication and DMARC is to change that, to reduce
the attack = surface.

The argument then becomes how big a hole is too much to= leave open. =C2=A0DMARC p=3DREJECT was supposed
to be nearly com= pletely closed for those implementing it.

Brandon<= /div>
--20cf303e9d8211a9ef04faf3ab16-- From nobody Tue Jun 3 12:43:45 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79FD71A034F for ; Tue, 3 Jun 2014 12:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 qUMKzW1LCnMi for ; Tue, 3 Jun 2014 12:43:43 -0700 (PDT) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58BA11A0309 for ; Tue, 3 Jun 2014 12:43:43 -0700 (PDT) Received: by mail-ie0-f174.google.com with SMTP id lx4so6329590iec.33 for ; Tue, 03 Jun 2014 12:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=p/7g3R0E2wgPuy4d8xkPF9VE2jeT+3xOFPP3gZ2m6TA=; b=LQonwMQddq+Pvp0N8eXhhemCbouyNXwXJmfIAV7MoybLeIK+zuXzAV6mS22iNJjKwy ZTQ2DElCQcRvJN8ORYyq9nz06sOF1QyCJsAIygsXf+gqR/x32Zx9i0yBtFJjX3m59nMp SrJ4ft5iKrO9m2uRyMWgcgowwnE5Rbwp+qO5S4YxxNrhSsC6tYuA5D1qsEMznQnW4bmu 2nCDnED+uczq7f2FrUBDHS3hS66RYQhs4OvihwgeSoPHlGvbAAaXqOu82SK+VXLZ2huS ksTMDVjm5BxjD9/QQ8G22YxfRXsI9No+0F70LSe3aOBuG6F9Ew3zFiyJFupxreI25Dky oxkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=p/7g3R0E2wgPuy4d8xkPF9VE2jeT+3xOFPP3gZ2m6TA=; b=m96fbGdB+pTuAYqHfNA2owcLAdSbd5T20raNdxCCa7xmB1Q/E4m0cjkG1BYdxO+iFA R2VQQsa/Shab2ROl10sdADzUEEFdd0JIiOIxc9ThWLEbKpHT7GMxKlp4qgDWnkqanALQ YLZpU5W51v22J89kVXMDCoSf22oYaCPTcQE+afMrPztfNR9KQu9OCfEPfvUZ0QzNphYP 6UeG40PZBBkb6W9OFgLsRXzJej3f5UwEeZLgUiduthBWmRaaQI1vPPy5ZbcV0UwXoxxY Jb5dzBTAimc2zvFOMZcO3iuAtZvGCKk/tQSgNcoj66XfRrHy6Eu0OYtSIhG7Dh6IUCjB ofhg== X-Gm-Message-State: ALoCoQk30UiT9m/Cb7IR0eQ6qve5kXsX9Y4pJHaIFuhjsedDhqyrUO5FkTJYjS3Zt0JsRA2WTiLo MIME-Version: 1.0 X-Received: by 10.42.68.18 with SMTP id v18mr44326234ici.1.1401824617416; Tue, 03 Jun 2014 12:43:37 -0700 (PDT) Received: by 10.64.213.73 with HTTP; Tue, 3 Jun 2014 12:43:37 -0700 (PDT) In-Reply-To: <87ppiq3u02.fsf@uwakimon.sk.tsukuba.ac.jp> References: <5387F6E0.1070903@att.com> <87ha456dlt.fsf@uwakimon.sk.tsukuba.ac.jp> <538A76ED.4050609@att.com> <8738fn6a96.fsf@uwakimon.sk.tsukuba.ac.jp> <466746097.24148.1401734879005.JavaMail.zimbra@peachymango.org> <87ppiq3u02.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Tue, 3 Jun 2014 12:43:37 -0700 Message-ID: From: Brandon Long To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=20cf303636d95bf8b004faf3bac3 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/k02DmuvvMN39CrH3Ynca-crUkoY Cc: "dmarc@ietf.org" , Tony Hansen , Franck Martin Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 03 Jun 2014 19:43:44 -0000 --20cf303636d95bf8b004faf3bac3 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 3, 2014 at 8:14 AM, Stephen J. Turnbull wrote: > Franck Martin writes: > > > I'm not sure it is wise to encourage the use of "invalid" domains > > in any of the email headers. > > Remember, we think *all* of the mitigations should be discouraged in > favor of not permitting posts from "p=reject" domains. But we also > know that will be unacceptable to most of our list operators. You're being a bit free with the "we" there. I don't think I wish to be included in the "just exclude a billion people from mailing ilsts" category. This thread has strayed far from utility. Brandon --20cf303636d95bf8b004faf3bac3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Jun 3, 2014 at 8:14 AM, Stephen J. Turnbull <stephen@xema= cs.org> wrote:
Franck Martin writes:

=C2=A0> I'm not sure it is wise to encourage the use of "invali= d" domains
=C2=A0> in any of the email headers.

Remember, we think *all* of the mitigations should be discouraged in<= br> favor of not permitting posts from "p=3Dreject" domains. =C2=A0Bu= t we also
know that will be unacceptable to most of our list operators.
<= div>=C2=A0
You're being a bit free with the "we" th= ere.

I don't think I wish to be included in th= e "just exclude a billion people from mailing ilsts" category.

This thread has strayed far from utility.
Brandon
--20cf303636d95bf8b004faf3bac3-- From nobody Tue Jun 3 14:55:24 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B74041A038A for ; Tue, 3 Jun 2014 14:55:22 -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 AzQkf6uosH_D for ; Tue, 3 Jun 2014 14:55:21 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 116071A0377 for ; Tue, 3 Jun 2014 14:55:20 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id bs8so7411148wib.6 for ; Tue, 03 Jun 2014 14:55: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=CMw5OQ8l7qYkvu/FO1iHRNlUX+NGrJf6PPRtJOd/xAY=; b=t/HCyv9zuAjasv7qqC6PuxJUi3fe0KsSGg2xwF++nBsi8BtUuArb5rVDm8n9MW4B7I K2yoK9+jCyjq+tL0XA4U+UHkjQIpAtswYs6eeY+RQLJahcoYtI8uXMKOyqxhziBp9CFH kqeKa3PkIe4gJSIXjaz5m1sFqbYLXBPGckwcsx/VpDvhGECgRHGCxafs4yANhkEjDGRM J5+mEvzQAuVVs16uP/iNsC/a1CW/hZ92zVUChiLtYXkSsSRCc3UoW/7TcPkHbsD11UkX iRK1hiVCzXo3H6kLV4eaPDGee+JGUWWrNLRdZIZu2bLZKJcnsziTCyiqKELJ9BAoRnM6 RJBw== MIME-Version: 1.0 X-Received: by 10.180.20.210 with SMTP id p18mr36318296wie.8.1401832514176; Tue, 03 Jun 2014 14:55:14 -0700 (PDT) Received: by 10.180.210.194 with HTTP; Tue, 3 Jun 2014 14:55:13 -0700 (PDT) In-Reply-To: References: <5387F6E0.1070903@att.com> <87ha456dlt.fsf@uwakimon.sk.tsukuba.ac.jp> <538A76ED.4050609@att.com> <8738fn6a96.fsf@uwakimon.sk.tsukuba.ac.jp> <466746097.24148.1401734879005.JavaMail.zimbra@peachymango.org> <87ppiq3u02.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Tue, 3 Jun 2014 14:55:13 -0700 Message-ID: From: "Murray S. Kucherawy" To: Brandon Long Content-Type: multipart/alternative; boundary=bcaec53d5c610acc4b04faf59116 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/bSzm3eEBx0SbYJrazk49MvSclJ0 Cc: "Stephen J. Turnbull" , "dmarc@ietf.org" , Tony Hansen , Franck Martin Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 03 Jun 2014 21:55:22 -0000 --bcaec53d5c610acc4b04faf59116 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 3, 2014 at 12:43 PM, Brandon Long wrote: > > Remember, we think *all* of the mitigations should be discouraged in >> favor of not permitting posts from "p=reject" domains. But we also >> know that will be unacceptable to most of our list operators. > > > You're being a bit free with the "we" there. > > I don't think I wish to be included in the "just exclude a billion people > from mailing ilsts" category. > I think "we" there refers to Mailman users, given Stephen's context. He's free to correct me if I'm wrong. I didn't get the impression he's speaking for all operators everywhere. I do agree that we may be straying a bit off topic. I really think this group needs to focus on where we go from here. We are all aware of the predicament in which we find ourselves and how we got here. Re-analyzing the past might be interesting or cathartic, but I don't think it will identify a new path forward. I'm excited that we have representatives from Mailman, Yahoo, Gmail, and several other critical players engaged. I'd rather we take advantage of that opportunity than waste it. -MSK --bcaec53d5c610acc4b04faf59116 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 3, 2014 at 12:43 PM, Brandon Long <blong@googl= e.com> wrote:

Remember, we think *all* of the mitigations should be discouraged in
favor of not permitting posts from "p=3Dreject" domains. =C2=A0Bu= t we also
know that will be unacceptable to most of our list operators.
<= div>=C2=A0
You're being a bit free with the "we&qu= ot; there.

I don't think I wish to be included= in the "just exclude a billion people from mailing ilsts" catego= ry.

I think "we" t= here refers to Mailman users, given Stephen's context.=C2=A0 He's f= ree to correct me if I'm wrong.=C2=A0 I didn't get the impression h= e's speaking for all operators everywhere.

I do agree that we may be straying a bit off topic.=C2=A0 I = really think this group needs to focus on where we go from here.=C2=A0 We a= re all aware of the predicament in which we find ourselves and how we got h= ere.=C2=A0 Re-analyzing the past might be interesting or cathartic, but I d= on't think it will identify a new path forward.

I'm excited that we have representatives from Mailman, Y= ahoo, Gmail, and several other critical players engaged.=C2=A0 I'd rath= er we take advantage of that opportunity than waste it.

<= /div>
-MSK
--bcaec53d5c610acc4b04faf59116-- From nobody Tue Jun 3 15:14:43 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502A71A038A for ; Tue, 3 Jun 2014 15:14:42 -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_44=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 XtOHeQ8wxBkn for ; Tue, 3 Jun 2014 15:14:39 -0700 (PDT) Received: from ntbbs.winserver.com (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 9FAFC1A0386 for ; Tue, 3 Jun 2014 15:14:39 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1311; t=1401833668; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=8p09kSCr8OOKt6lKiInam5kfJJ0=; b=rDCvFC1WobKmGs90VPxz vLHvSwljExP/sBVyU/17wxkDJWY4B4skMXFXetLbxY0edskmhMBL3XvCNrqA3TFW 9GzEb/2vhQtYig+cicyeXtUQsX0/NSCWRUPDKWK3vqjIvjtsYa3VAb+YxmcXxOYg 6wWrjgkGIxCPyzsRBgVWTZA= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 03 Jun 2014 18:14:28 -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; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1313797660.10091.3016; Tue, 03 Jun 2014 18:14:27 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1311; t=1401833513; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=XixFT3y 8InUnYIK6OzGWRSpmNssm+oafjiD1W3YtJ8g=; b=bPMjyl8QtVJFxEX7pJIC868 7rrIAwKq0SxV61A6zE7pInntqWhFOi+6Ic2yn67DZr787PHqnXalhgWi22CvS11R hHqWFlqt6H+wYpVYQCYADkEtKdQr3KtmK9Av9Am+M6+AbskmiSwTNXqs5oi1kv8H GndEn518w6J5G5bZV05s= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 03 Jun 2014 18:11:53 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1330159578.9.2300; Tue, 03 Jun 2014 18:11:51 -0400 Message-ID: <538E48C1.2020707@isdg.net> Date: Tue, 03 Jun 2014 18:14:25 -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 CC: dmarc@ietf.org References: <5387F6E0.1070903@att.com> <87ha456dlt.fsf@uwakimon.sk.tsukuba.ac.jp> <538A76ED.4050609@att.com> <8738fn6a96.fsf@uwakimon.sk.tsukuba.ac.jp> <55382129.27361.1401740317786.JavaMail.zimbra@peachymango.org> <87r4363wpn.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87r4363wpn.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: dmarc@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/0OWv7ciVhA_ktge2_RoBjYJq-jk Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 03 Jun 2014 22:14:42 -0000 >> But why would you accept emails from invalid domains in the first >> instance? > > Because the email is legitimate, of course. Until it isn't..... The purpose of the ".invalid" TLD was not for bypassing a proposed security protocol. This is a malicious hack that will ultimately help break down one of the last remaining mail communications "inherent trust" headers we have left that is expected by ALL parties, all software, the world, in any language, society, etc, MUST NEVER be changed -- the 5322.From header. You just don't do it and those that do, well, I consider them the Enemy of Mail. It opens up loopholes. In fact, I think I will add a DATA filter script to check for this TLS and immediately reject it. A single line rule: if mail.from TLD is ".invalid" then REJECT "550 Invalid From Address" This rule can be added to our existing incoming DATA 5322 Validation script that checks for such things as multiple 5322.From headers violation, something that DKIM needs done by all receivers to protect against fraudulent fake 5322.From headers. I prefer to update my software with the above script for our MTA receiver rather to add logic to rewrite the 5322.From to bypass a security protocol in our list server. I think I can sleep better with that. -- HLS From nobody Tue Jun 3 17:30:00 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3261A00C9 for ; Tue, 3 Jun 2014 17:29:57 -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 P2992DWW4voD for ; Tue, 3 Jun 2014 17:29:55 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [192.254.77.197]) by ietfa.amsl.com (Postfix) with ESMTP id 420781A0350 for ; Tue, 3 Jun 2014 17:29:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 22B4DA0612; Tue, 3 Jun 2014 19:29:49 -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 9m-ZAYy-uhUG; Tue, 3 Jun 2014 19:29:49 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id F2678A0648; Tue, 3 Jun 2014 19:29:48 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id DC2C5A061A; Tue, 3 Jun 2014 19:29:48 -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 33R4AyIEa4wh; Tue, 3 Jun 2014 19:29:48 -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 C0AEBA0612; Tue, 3 Jun 2014 19:29:48 -0500 (CDT) Date: Tue, 3 Jun 2014 19:29:47 -0500 (CDT) From: Franck Martin To: "Stephen J. Turnbull" Message-ID: <610286136.61974.1401841787613.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <538A76ED.4050609@att.com> <8738fn6a96.fsf@uwakimon.sk.tsukuba.ac.jp> <55382129.27361.1401740317786.JavaMail.zimbra@peachymango.org> <87r4363wpn.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [216.3.18.37] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF29 (Mac)/8.0.5_GA_5839) Thread-Topic: DKIM through mailing lists (rebutting MLs won't change) Thread-Index: fUouKcUwGZxitbDoDnnbIQpjGTnWLw== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/_6coXU-O1NhsS0KOaZaUH4YNlXQ Cc: Kurt Andersen , dmarc@ietf.org, Tony Hansen Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 04 Jun 2014 00:29:57 -0000 ----- Original Message ----- > From: "Stephen J. Turnbull" > To: "Franck Martin" > Cc: "Tony Hansen" , dmarc@ietf.org, "Kurt Andersen" > Sent: Tuesday, June 3, 2014 7:16:04 AM > Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) > > Franck Martin writes: > > > But why would you accept emails from invalid domains in the first > > instance? > > Because the email is legitimate, of course. I've seen people use > "example.com" in their addresses on list posts to ensure they won't > get personal replies. I've seen people use "noreply@personal.dom" as > their valid return address. > Yes the email is legitimate, but how does the MTA knows it? Well a bayesian filter has learned that this type of content is legitimate, and then one day a spammer uses the same content, but change one link... Like Symantec has claimed "outrageously" that anti-viruses are dead, same for content based filtering. It means more rules have to be put in the authentication of the emails, so they can be linked to domain names that do exists, so you have some form of recourse... I know that an email is legitimate when I see one, is not really a practical rule... From nobody Tue Jun 3 20:45:12 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E231A0037 for ; Tue, 3 Jun 2014 20:45:10 -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 JdcIwE3c_kG3 for ; Tue, 3 Jun 2014 20:45: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 E5E091A0030 for ; Tue, 3 Jun 2014 20:45:08 -0700 (PDT) Received: (qmail 88857 invoked from network); 4 Jun 2014 03:45:01 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 4 Jun 2014 03:45:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=127c4.538e963d.k1406; i=johnl@user.iecc.com; bh=EvzY9Y6BscBDo4KEhUMoMSJT0lZ5sd4mj14UBXEXCVI=; b=Rh8MdCdyHxva3KLpzXR357HYgaAINdA4++cHbQlCMLWBTpDmhGGaIltNnLFZXZ7haOefcrAHlvn0ATNzsYX2NXQfr6quNvjFovNsF1gzNaeZoirzY1LyXaTWilwpWvU1dy0oY9IoR7F+FTMd0AcpilnyZyGZke3/0aZS8p/lQBiKJ0XejxNeRYcbiYoD9rAI5X8QQef6KXFliOInbF9awpMzXtPWQ5zZcVObsOa2xo/BrQ69Z7JwesnI4Mac5S14 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=127c4.538e963d.k1406; olt=johnl@user.iecc.com; bh=EvzY9Y6BscBDo4KEhUMoMSJT0lZ5sd4mj14UBXEXCVI=; b=i5AGEG8d9aHK/mg/NrsEXi2uw4ASWM4/McYU6vWrwfK1BDWKVWBqNchwacX9NdXYWoTZsESEwVoTno5WfVeNeGpzXZ72PXQjCrwP2wKbPWld1xo3dnF4iLhlTlaetleO9dVOqfEC9R1Jmoa887643OPI/petPrNP9QgxqJeH2ggDoZ1d49eO/nHMLVifrmtTB0nhy7vaP0WSkr3jlnyrIKXWI81APznZTX3KcAXasr/M+GatC5f4gI9cRdTXVP4J Date: 4 Jun 2014 03:44:39 -0000 Message-ID: <20140604034439.75715.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <610286136.61974.1401841787613.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: http://mailarchive.ietf.org/arch/msg/dmarc/isZeEhXU2CqJZ1JpIFXo8Uj5dM8 Cc: franck@peachymango.org Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 04 Jun 2014 03:45:10 -0000 >Yes the email is legitimate, but how does the MTA knows it? > >Well a bayesian filter has learned that this type of content is legitimate, and then one day a spammer >uses the same content, but change one link... That could happen to any mail feature you care to name. Big companies send buckets of mail with return addresses like "donotrespond". A non-deliverable or non-replyable From: line has never had much connection to whether to deliver the mail. R's, John From nobody Tue Jun 3 22:01:59 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FC21A0081 for ; Tue, 3 Jun 2014 22:01:56 -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 L0Nj5OX91tUk for ; Tue, 3 Jun 2014 22:01:54 -0700 (PDT) Received: from mail.theartfarm.com (mail.theartfarm.com [66.128.51.165]) by ietfa.amsl.com (Postfix) with SMTP id B89591A007F for ; Tue, 3 Jun 2014 22:01:54 -0700 (PDT) Received: (qmail 14798 invoked by uid 89); 4 Jun 2014 05:01:48 -0000 Received: from unknown (HELO mail.theartfarm.com) (127.0.0.30) by mail.theartfarm.com with SMTP; 4 Jun 2014 05:01:48 -0000 Received-SPF: Pass (mail.theartfarm.com: domain of tnpi.net designates 50.159.99.59 as permitted sender) receiver=mail.theartfarm.com; identity=mailfrom; client-ip=50.159.99.59; helo=[10.0.1.141]; envelope-from= Received: from [10.0.1.141] (c-50-159-99-59.hsd1.wa.comcast.net [50.159.99.59]) by mail.theartfarm.com (Haraka/2.5.0-toaster) with ESMTPSA id 900560FC-A445-43CB-A0F6-3C0D12DEAB13.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=AES128-SHA verify=FAIL); Wed, 04 Jun 2014 01:01:47 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Matt Simerson In-Reply-To: <20140604034439.75715.qmail@joyce.lan> Date: Tue, 3 Jun 2014 22:01:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5AA6D7A0-FF75-4775-8E63-E7BDB32981D1@tnpi.net> References: <20140604034439.75715.qmail@joyce.lan> To: dmarc@ietf.org X-Mailer: Apple Mail (2.1878.2) X-Haraka-p0f: os="iOS iPhone or iPad" link_type="Ethernet or modem" distance=11 total_conn=2 shared_ip=N X-Haraka-GeoIP: US, WA, Seattle, 2705km X-Haraka-GeoIP-Received: X-Haraka-ASN: 7922 50.128.0.0/9 X-Haraka-ASN-ROUTEVIEWS: asn=7922 net=50.128.0.0/9 X-Haraka-ASN-MONKEY: asn=7922 net=50.128.0.0/9 org=Comcast Cable Communications, Inc. date=1997-02-14 country=US X-Haraka-FCrDNS: c-50-159-99-59.hsd1.wa.comcast.net X-Spam-ASN: X-Spam-DCC: sonic.net: spamassassin.tnpi.net 1156; Body=1 Fuz1=1 Fuz2=1 X-Spam-SNF-Result: 0 (Standard White Rules) X-Spam-MessageSniffer-Scan-Result: 0 X-MessageSniffer-Rules: 0-0-0-3608-c X-MessageSniffer-Clean: Yes X-Spam-MessageSniffer-Rules: 0-0-0-3608-c X-MessageSniffer-Clean: Yes X-Spam-GBUdb-Analysis: 0, 10.0.1.141, Ugly c=0.327499 p=-1 Source Normal X-MessageSniffer-Scan-Result: 0 X-MessageSniffer-Rules: 0-0-0-3608-c X-MessageSniffer-Clean: Yes X-Haraka-Karma: connect: 4, history: 343, total_connects: 370, neighbors: -4461, pass:fcrdns.fcrdns, relaying, auth_user, fail:fcrdns.fail, neighbors, dnsbl.fail, helo.checks.fail, helo.checks.fail, skip:penalty DKIM-Signature: v=1; a=rsa-sha256; bh=Ts4niOwcr/2hmR7YDPy701JMSOR6c6QRS6X8UAMFTi0=; c=relaxed/simple; d=tnpi.net; h=from:subject:date:message-id:to:mime-version; s=mar2013; b=gBKMrShxzBHyi0Lrvp46mx7C+cEEUBbOfAzvioeAwwG6Klvgf8T3FsXZ/KEwSdySpv9SNe5PxcCmjuNULJtoJCbYRsYfLEJpoxapV6Kf0Go5GQSLcsOI4i3F0qg2y4bmolOsOgVzqzU4djX1oA8XEBO9UJS3Wo2+513S7RXju8/KbKXEcnsWW9+pFtOHzCb/z2m7bG40LqY7XRJMNMZJz14mH43HYANH2I7LvQ8yYLFu94O+7l0qJcZ4tvTL9avfT/CpsWMcvF2xQSJvnyqqPOkAyMCCXmV7mau+jBrIH0CfiACmk8Nq5wdEnv69PW5/FP+X8DuK4e0dCjRx7JuErw== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/p4RWvLu86TWqAq-a5QIdAcJ3jLQ Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 04 Jun 2014 05:01:56 -0000 On Jun 3, 2014, at 8:44 PM, John Levine wrote: >> Yes the email is legitimate, but how does the MTA knows it? >>=20 >> Well a bayesian filter has learned that this type of content is = legitimate, and then one day a spammer >> uses the same content, but change one link... >=20 > That could happen to any mail feature you care to name. >=20 > Big companies send buckets of mail with return addresses like > "donotrespond". A non-deliverable or non-replyable From: line has > never had much connection to whether to deliver the mail. I agree that =46rom addresses such as these will suffer no adverse = deliverability issues: noreply@github.com, DoNotReply@etrade.com But that is not equivalent to putting non-resolvable gibberish on the = right side of the @ sign. That's a reliable way of assuring that such = messages do not get queued on my server. As a matter of practicality, I = highly doubt that I'm unique in requiring that the sender domain = (envelope and header) resolve. Matt= From nobody Tue Jun 3 23:45:48 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591651A00B0 for ; Tue, 3 Jun 2014 23:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.902 X-Spam-Level: X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 5KoDcL-nMJCQ for ; Tue, 3 Jun 2014 23:45:44 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [192.254.77.197]) by ietfa.amsl.com (Postfix) with ESMTP id C88FA1A009C for ; Tue, 3 Jun 2014 23:45:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id CD4DA6027B; Wed, 4 Jun 2014 01:45: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 rjzWDHXWxVut; Wed, 4 Jun 2014 01:45:38 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id A5AE66031D; Wed, 4 Jun 2014 01:45:38 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 7B8F76027F; Wed, 4 Jun 2014 01:45: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 7wkvzy_zci24; Wed, 4 Jun 2014 01:45: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 629076027B; Wed, 4 Jun 2014 01:45:38 -0500 (CDT) Date: Wed, 4 Jun 2014 01:45:37 -0500 (CDT) From: Franck Martin To: Matt Simerson Message-ID: <779559852.64256.1401864337910.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20140604034439.75715.qmail@joyce.lan> <5AA6D7A0-FF75-4775-8E63-E7BDB32981D1@tnpi.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF29 (Mac)/8.0.5_GA_5839) Thread-Topic: DKIM through mailing lists (rebutting MLs won't change) Thread-Index: ahjj/X/nc4cXEqY0lQ/41FpQGEPcjA== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/tkwL096D2MsbJTGz7EKkJrLuEEE Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 04 Jun 2014 06:45:46 -0000 ----- Original Message ----- > From: "Matt Simerson" > To: dmarc@ietf.org > Sent: Tuesday, June 3, 2014 10:01:37 PM > Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) > > > On Jun 3, 2014, at 8:44 PM, John Levine wrote: > > >> Yes the email is legitimate, but how does the MTA knows it? > >> > >> Well a bayesian filter has learned that this type of content is > >> legitimate, and then one day a spammer > >> uses the same content, but change one link... > > > > That could happen to any mail feature you care to name. > > > > Big companies send buckets of mail with return addresses like > > "donotrespond". A non-deliverable or non-replyable From: line has > > never had much connection to whether to deliver the mail. > > I agree that From addresses such as these will suffer no adverse > deliverability issues: > > noreply@github.com, DoNotReply@etrade.com > > But that is not equivalent to putting non-resolvable gibberish on the right > side of the @ sign. That's a reliable way of assuring that such messages do > not get queued on my server. As a matter of practicality, I highly doubt > that I'm unique in requiring that the sender domain (envelope and header) > resolve. > You are not. I can't recall if it is in security considerations, but should likely go in the BCP, if you do DMARC you need to reduce some of the workarounds possible. Multiple From: headers is one Invalid or known bad domains in From: is the other one Otherwise it is easy to send an email with a domain that contains an extra letter and bypass DMARC. Granted, you can buy domains with a stolen credit card, or even better, just use a nearly untraceable prepaid credit card from your local store to buy domains, but this may require a bit more organization than a 15 year old may be willing to do... With a legit domain, you have 2 investigative/complain paths: the sending IP and the From: domain. From nobody Wed Jun 4 02:57:27 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360191A0175 for ; Wed, 4 Jun 2014 02:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 ZBXcnfN319Qg for ; Wed, 4 Jun 2014 02:57:23 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id D62A21A0174 for ; Wed, 4 Jun 2014 02:57:22 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 7611E970B34; Wed, 4 Jun 2014 18:57:16 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 661CA1A31E2; Wed, 4 Jun 2014 18:57:16 +0900 (JST) From: "Stephen J. Turnbull" To: Elizabeth Zwicky In-Reply-To: References: <5387F6E0.1070903@att.com> <15749590.z7A0vHW603@scott-latitude-e6320> <87ppiu57zt.fsf@uwakimon.sk.tsukuba.ac.jp> <87sinm44jv.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 04 Jun 2014 18:57:16 +0900 Message-ID: <878upd3slf.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/yjda5NbahZb7i1H0D389J21OGco Cc: "dmarc@ietf.org" , Scott Kitterman Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 04 Jun 2014 09:57:24 -0000 Elizabeth Zwicky writes: > But I do, in fact, have data, and that data tells me that the attackers > forging our users based on stolen addressbooks have never stopped; we are > still blocking them now. Interesting. No perceptible change at all? I am going to have to dig up that graph of the AOL attack. *They* show the attack on their users stopping dead in its tracks and returning to the pre-onslaught level. > By the way, yahoo.co.jp is an independent company with a separate mail > system and a separate account database. Sure, Japanese law means it almost *has* to be that way. But how am I to know whether the "independent" Japanese company takes its lead from the US parent/trademark licensor, or not? And, as I say, the bureaucrats (who should know that as well as you or I) chose to ignore it. From nobody Wed Jun 4 03:19:02 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27BA71A024A for ; Wed, 4 Jun 2014 03:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 Wigsk5_WG4ep for ; Wed, 4 Jun 2014 03:18:58 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id 929271A0279 for ; Wed, 4 Jun 2014 03:18:58 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 14EED970B34; Wed, 4 Jun 2014 19:18:52 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 016791A31E2; Wed, 4 Jun 2014 19:18:51 +0900 (JST) From: "Stephen J. Turnbull" To: Brandon Long In-Reply-To: References: <5387F6E0.1070903@att.com> <87ha456dlt.fsf@uwakimon.sk.tsukuba.ac.jp> <538A76ED.4050609@att.com> <8738fn6a96.fsf@uwakimon.sk.tsukuba.ac.jp> <466746097.24148.1401734879005.JavaMail.zimbra@peachymango.org> <87ppiq3u02.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 04 Jun 2014 19:18:51 +0900 Message-ID: <877g4x3rlg.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/m6o50rVAlXs-MySu2bGrUoZfK1M Cc: "dmarc@ietf.org" , Tony Hansen , Franck Martin Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 04 Jun 2014 10:19:00 -0000 Brandon Long writes: > You're being a bit free with the "we" there. Sorry if you understood it that way. I'm here as a delegate of the Mailman project, and in this case I believe my views are representative of a working consensus of the core developers and some influential users. So I wrote "we" rather than "I". From nobody Wed Jun 4 04:28:56 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23AF1A01BD for ; Wed, 4 Jun 2014 04:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 KZk4u-TJnJHb for ; Wed, 4 Jun 2014 04:28:53 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id E79CD1A0192 for ; Wed, 4 Jun 2014 04:28:52 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 0FFB6970945; Wed, 4 Jun 2014 20:28:46 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 025381A31E2; Wed, 4 Jun 2014 20:28:45 +0900 (JST) From: "Stephen J. Turnbull" To: Franck Martin In-Reply-To: <610286136.61974.1401841787613.JavaMail.zimbra@peachymango.org> References: <538A76ED.4050609@att.com> <8738fn6a96.fsf@uwakimon.sk.tsukuba.ac.jp> <55382129.27361.1401740317786.JavaMail.zimbra@peachymango.org> <87r4363wpn.fsf@uwakimon.sk.tsukuba.ac.jp> <610286136.61974.1401841787613.JavaMail.zimbra@peachymango.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 04 Jun 2014 20:28:45 +0900 Message-ID: <8761kg52xe.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/r79a9_6vzbZE17Z_urY9tISsWos Cc: Tony Hansen , dmarc@ietf.org, Kurt Andersen Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 04 Jun 2014 11:28:54 -0000 Franck Martin writes: > Yes the email is legitimate, but how does the MTA knows it? Aha! Precisely where this conversation should go. The MTA *doesn't* know. A mailing list knows more, though. And an MUA knows a lot more than that. Or they could. For bandwidth reasons, it's important (especially at Humongous ESP) to catch abusive mail as much as you can at the boundary MTA. But that doesn't mean you should abdicate all responsibility to the MTA. > Well a bayesian filter has learned that this type of content is > legitimate, and then one day a spammer uses the same content, but > change one link... Bad, bad, baaaaad Bayesian filter! No dessert for you tonight! But, while that kind of failure *does* happen, it should be rare. In a well-designed filter, you also need to use header features, like the content of the From: field and DKIM signature. The recipient is also an important feature, which should be part of the filter. I've heard of mailing lists where the topic word (eg, on this list "DMARC") is used: if the word is not present, the message goes straight to 4.5 on a "5 is spammy enough to quarantine" scale. In the old days (2007 or so) it apparently worked quite well, dunno if it still does. A conventional MTA *can't* be expected to know that kind of thing (Google and Yahoo! work differently, I'd guess). But an MUA easily could, and at least for PC users, there's enough storage and CPU power to do the analysis. > I know that an email is legitimate when I see one, is not really a > practical rule... Why not? As long as it's the last rule in a long chain! It worked against spam for quite a few years, with no other help. But more seriously, personal filters that learn what you like and what you think is spammy could probably do a lot more than they currently do. The other thing that MUAs could do to help mailing lists out here is allow signatures of MIME parts instead of the whole message. Unfortunately that doesn't help "on behalf of" services, but I'm not sure what to do for them. Somebody suggested OAuth2, if that works (for typical non-technical users) that would be very cool. Regards, From nobody Wed Jun 4 07:40:04 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F851A02AD for ; Wed, 4 Jun 2014 07:40: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 5t8wXAZ4iWDo for ; Wed, 4 Jun 2014 07:39: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 3928D1A028C for ; Wed, 4 Jun 2014 07:39:59 -0700 (PDT) Received: (qmail 432 invoked from network); 4 Jun 2014 14:39:52 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 4 Jun 2014 14:39:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=140c4.538f2fb8.k1406; i=johnl@user.iecc.com; bh=baKF81vrKI1G+T4Vu+z5t9iPkzIAMbfKEksU8/E1SWo=; b=dxK7hd1ogLpZBORPYS+6CRn9sIn6U3lD92eZxeIsMg3MyNwypQTkGK39EWWVxvuATphiAXrVEnWEs76SqwomG3ORAKFmFGilzEGGcX7yr042pcndpecOcLx9YN0hd4R2pgDjDjPMmZA0QLSnpPRHriYK9lp0nm02LrF5zi0otQ0ahP1gydk5SqBHShzhZZnAFZsxQnzYlxx8B2v0+I/+T/azMNmQGPm8ljjosZFQP3vj/CNLEeto0S2JFSvCziUh DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=140c4.538f2fb8.k1406; olt=johnl@user.iecc.com; bh=baKF81vrKI1G+T4Vu+z5t9iPkzIAMbfKEksU8/E1SWo=; b=KKvYoCXRhq44RPOhfadKggGpjamZgT90XfuVKXPpGXuxsb+5VZdo8KvpAXCg4hRpR3xGbQK3++5ZVlXdkz/gF8ZBpT1TamWVRviv22vW9F3Ku5VgOQxQfaoQJp/0WVjVS2Xi7fEqDZe2AdhM/pGufOJ0d/LPwEBNYYn7uGrCeFT+wiTSfSbD8p3LiEYZ1/kUJLUzZE8KTgAUD/5DDBt5CzbaWBLEtDknIVet/CQDmbdlvr6fpOZvjwnXrwPdo0u3 Date: 4 Jun 2014 14:39:28 -0000 Message-ID: <20140604143928.82115.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <5AA6D7A0-FF75-4775-8E63-E7BDB32981D1@tnpi.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/6rww1QwVFoCBavMb--nJMIsZliU Cc: matt@tnpi.net Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 04 Jun 2014 14:40:00 -0000 >But that is not equivalent to putting non-resolvable gibberish on the right side of the @ sign. That's >a reliable way of assuring that such messages do not get queued on my server. As a matter of >practicality, I highly doubt that I'm unique in requiring that the sender domain (envelope and header) >resolve. I've been using the .invalid hack on my lists for the past month, and I haven't seen any failure reports at all that seem to have anything to do with it. (Only AOL and Yahoo get the .invalid, so it's not hard to tell if recipients are treating the mail differently.) As I've said before, it's a user-hostile crock, but so is everything else other than the various forms of DMARC-bypass whitelisting. R's, John From nobody Wed Jun 4 07:58:36 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A291A0290 for ; Wed, 4 Jun 2014 07:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.401 X-Spam-Level: X-Spam-Status: No, score=-101.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, 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 PSevgO2bLyVR for ; Wed, 4 Jun 2014 07:58:32 -0700 (PDT) Received: from groups.winserver.com (listserv.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9B71A0080 for ; Wed, 4 Jun 2014 07:58:32 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3177; t=1401893903; h=Received:Received: Message-Id:From:Subject:Date:To:Organization:List-ID; bh=s976SmX nHczZD9xdohYwayHto2Y=; b=lHpRyJIO0PmFDUlZAcx8ptMy+q8uzzPKiA0eqEf LmHLz4gxNpa1OasuB4iuohiB0eCRk07BsnkMLlIasLy9emqUujh49WjX6XunYOJq Qma+Gi5N2tZRzuYU/xMBgdnfiB5ro2pzrPGt6szhjaZmrWKlU2D24X+RzyaJujm9 Y0Ko= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 04 Jun 2014 10:58:23 -0400 Received: from [192.168.1.162] (99-72-160-212.lightspeed.miamfl.sbcglobal.net [99.72.160.212]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1374032704.12054.2328; Wed, 04 Jun 2014 10:58:23 -0400 References: <538A76ED.4050609@att.com> <8738fn6a96.fsf@uwakimon.sk.tsukuba.ac.jp> <55382129.27361.1401740317786.JavaMail.zimbra@peachymango.org> <87r4363wpn.fsf@uwakimon.sk.tsukuba.ac.jp> <610286136.61974.1401841787613.JavaMail.zimbra@peachymango.org> <8761kg52xe.fsf@uwakimon.sk.tsukuba.ac.jp> Mime-Version: 1.0 (1.0) In-Reply-To: <8761kg52xe.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (11B651) From: Hector Santos Date: Wed, 4 Jun 2014 10:58:09 -0400 To: "Stephen J. Turnbull" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/o3vFVtuPinyPLUVf4W-uq4O1oK4 Cc: Kurt Andersen , "dmarc@ietf.org" , Tony Hansen , Franck Martin Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 04 Jun 2014 14:58:35 -0000 But it does know. It is not legitimate mail per the proposed security protoc= ol. The problem and conversation should be focused on resolving the 9 years o= ld mail integration dilemma -- the dearth of resigners not wanting to check f= or bad DKIM-secured transactions via a policy layer protocol. Keep in mind t= hat the suggested rewrite applicability for p=3Dreject domains implies that a= DNS lookup is presumed to be part of the DKIM framework. If we can get to t= hat level, we are home free. But unfortunately, the concept has been killed b= y the IETF when it decided to make ADSP historic. -- HLS > On Jun 4, 2014, at 7:28 AM, "Stephen J. Turnbull" wro= te: >=20 > Franck Martin writes: >=20 >> Yes the email is legitimate, but how does the MTA knows it? >=20 > Aha! Precisely where this conversation should go. >=20 > The MTA *doesn't* know. A mailing list knows more, though. And an > MUA knows a lot more than that. Or they could. >=20 > For bandwidth reasons, it's important (especially at Humongous ESP) to > catch abusive mail as much as you can at the boundary MTA. But that > doesn't mean you should abdicate all responsibility to the MTA. >=20 >> Well a bayesian filter has learned that this type of content is >> legitimate, and then one day a spammer uses the same content, but >> change one link... >=20 > Bad, bad, baaaaad Bayesian filter! No dessert for you tonight! >=20 > But, while that kind of failure *does* happen, it should be rare. In > a well-designed filter, you also need to use header features, like the > content of the From: field and DKIM signature. >=20 > The recipient is also an important feature, which should be part of > the filter. I've heard of mailing lists where the topic word (eg, on > this list "DMARC") is used: if the word is not present, the message > goes straight to 4.5 on a "5 is spammy enough to quarantine" scale. > In the old days (2007 or so) it apparently worked quite well, dunno if > it still does. >=20 > A conventional MTA *can't* be expected to know that kind of thing > (Google and Yahoo! work differently, I'd guess). But an MUA easily > could, and at least for PC users, there's enough storage and CPU power > to do the analysis. >=20 >> I know that an email is legitimate when I see one, is not really a >> practical rule... >=20 > Why not? As long as it's the last rule in a long chain! It worked > against spam for quite a few years, with no other help. But more > seriously, personal filters that learn what you like and what you > think is spammy could probably do a lot more than they currently do. >=20 > The other thing that MUAs could do to help mailing lists out here is > allow signatures of MIME parts instead of the whole message. >=20 > Unfortunately that doesn't help "on behalf of" services, but I'm not > sure what to do for them. Somebody suggested OAuth2, if that works > (for typical non-technical users) that would be very cool. >=20 > Regards, >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >=20 From nobody Wed Jun 4 08:14:17 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800A11A0170 for ; Wed, 4 Jun 2014 08:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.137 X-Spam-Level: X-Spam-Status: No, score=-3.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 UGEfThGpKt9u for ; Wed, 4 Jun 2014 08:14:13 -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 2E8251A00DF for ; Wed, 4 Jun 2014 08:14:13 -0700 (PDT) Received: (qmail 7722 invoked from network); 4 Jun 2014 15:14:05 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 4 Jun 2014 15:14: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:mime-version:content-type:content-transfer-encoding; s=1412e.538f37bd.k1406; i=johnl@user.iecc.com; bh=qZd2eObUIVK6NH1fpIaNQgfsrQqZbZx9xlwrBMiorRg=; b=rViRAKL9XS0y+03JZdhYsFHw4Pjd6Nj0ZKY/UGNpn3ZcXnJpJHNGUown1dzvho1vuumHlyfbPPUqFL6N7cBOUnDApzYkzoSaU84H5B9cloe9XFqN+XJfudnNwYKA5AQgIKXKFBWdpIXXWsGDi/UV/yYx9QpRqKSkyrUClRvYMbH6PAVJWKBa3XTA/4UOEtReog4rxno4mSj2I4u4ZTXNoCx4KCq4lgSN/8z59YcdEXATs18gZtq+t4RERGK4WfNH DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1412e.538f37bd.k1406; olt=johnl@user.iecc.com; bh=qZd2eObUIVK6NH1fpIaNQgfsrQqZbZx9xlwrBMiorRg=; b=r9RW1ucDA4dfrNMeH+rIdeBvHxc4Qbd2+xnqOpam8HjCN/52EWKTqXGAGiA4aUVLJqAPgTbs/JXz38yCo1AhktV/fhmoMRO1CBUW+PjRVkXXDQt8FLEdUNm8jizz7ePRAQjuavg5U4FrLNbDKJi6CKtcKPVl8YBtjlEC2AcBFb/9UjZRDEi8fLYTgCV6XVNxxRLASjM1kmQSArR7fGxWxrCEekXnAvVlMLgJFnorM6z5cjMFbygOTaxpDys4CSuz Date: 4 Jun 2014 15:13:43 -0000 Message-ID: <20140604151343.82221.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <779559852.64256.1401864337910.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: http://mailarchive.ietf.org/arch/msg/dmarc/IiD8wH-MrPGgyWGiODcZJiaUJTM Cc: franck@peachymango.org Subject: Re: [dmarc-ietf] fussp alert, was DKIM through mailing lists 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, 04 Jun 2014 15:14:14 -0000 > Otherwise it is easy to send an email with a domain that contains an > extra letter and bypass DMARC. It is ALWAYS easy to send an email with a domain that contains an extra letter and bypass DMARC. Lookalike or "cousin" domains are specifically not something it addresses. Keep in mind that is not always a bug. There are a lot of domains that publish DMARC policies, and it is unlikely that there are no other domains that are lexically similar and send their own legitimate mail. R's, John From nobody Wed Jun 4 09:18:08 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B57F1A00DF for ; Wed, 4 Jun 2014 09:18:06 -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 MFipynkAEIIF for ; Wed, 4 Jun 2014 09:18:03 -0700 (PDT) Received: from secure.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 892A81A0270 for ; Wed, 4 Jun 2014 09:18:03 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1780; t=1401898674; h=Received:Received: Message-Id:From:Subject:Date:To:Organization:List-ID; bh=CL+L4WU 6O6FfYx0eAISWuEzssWw=; b=K9hXssce261AfbkrOZn+1lyzZNFBhKf37jX8RZD L1kQi0VcGMPLkyhCuInOEu3MaPXwdKafppSUeAsfKzB72uckyHStEZ3ydmmA3Pgd AcITS2U9gjS9vVmOEDay4LnjTvFX2AgeM09tYevfzrqBCIAtocCseIFPlaINedLS dDgU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 04 Jun 2014 12:17:54 -0400 Received: from [192.168.1.162] (99-72-160-212.lightspeed.miamfl.sbcglobal.net [99.72.160.212]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1378802840.12054.2148; Wed, 04 Jun 2014 12:17:53 -0400 References: <20140604143928.82115.qmail@joyce.lan> Mime-Version: 1.0 (1.0) In-Reply-To: <20140604143928.82115.qmail@joyce.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (11B651) From: Hector Santos Date: Wed, 4 Jun 2014 12:17:53 -0400 To: John Levine Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/q7zEkR-j5X_S79_JOTWQfzTfTVI Cc: "matt@tnpi.net" , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 04 Jun 2014 16:18:06 -0000 John, I doubt these aol and yahoo users give a hoot of what u snuck into you= r small local site. The odds are high these kind of addresses were first use= d for junk, aliases, "throw away" addresses like most people did with these p= ublic email service bureaus. Sure, for many, these public addresses have bec= ome more of their mainstream contact address, i.e. I use my junk gmail accou= nt more for today's sign ups. But they are probably not even aware of what u= did and I would lean towards the reasonable presumed fact that most people,= including myself and maybe you, will not like the idea that your mail is be= ing displayed with "invalid" indicators on a wide spread set of mail reading= devices. -- Hector Santos http ://www.santronics.com On Jun 4, 2014, at 10:39 AM, "John Levine" wrote: >> But that is not equivalent to putting non-resolvable gibberish on the rig= ht side of the @ sign. That's >> a reliable way of assuring that such messages do not get queued on my ser= ver. As a matter of >> practicality, I highly doubt that I'm unique in requiring that the sender= domain (envelope and header) >> resolve. >=20 > I've been using the .invalid hack on my lists for the past month, and > I haven't seen any failure reports at all that seem to have anything > to do with it. (Only AOL and Yahoo get the .invalid, so it's not hard > to tell if recipients are treating the mail differently.) >=20 > As I've said before, it's a user-hostile crock, but so is everything > else other than the various forms of DMARC-bypass whitelisting. >=20 > R's, > John >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >=20 From nobody Wed Jun 4 10:43:27 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A641A0259 for ; Wed, 4 Jun 2014 10:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.791 X-Spam-Level: X-Spam-Status: No, score=-0.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6] 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 5z7HfyiWDTZ5 for ; Wed, 4 Jun 2014 10:43:23 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id 6418F1A0254 for ; Wed, 4 Jun 2014 10:43:23 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id E0236970B35; Thu, 5 Jun 2014 02:43:16 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id CDDB81A31E2; Thu, 5 Jun 2014 02:43:16 +0900 (JST) From: "Stephen J. Turnbull" To: Hector Santos In-Reply-To: References: <538A76ED.4050609@att.com> <8738fn6a96.fsf@uwakimon.sk.tsukuba.ac.jp> <55382129.27361.1401740317786.JavaMail.zimbra@peachymango.org> <87r4363wpn.fsf@uwakimon.sk.tsukuba.ac.jp> <610286136.61974.1401841787613.JavaMail.zimbra@peachymango.org> <8761kg52xe.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 05 Jun 2014 02:43:16 +0900 Message-ID: <87y4xc370r.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/l2CUKmxBDcmkj8V99b04kDY6p5U Cc: Tony Hansen , "dmarc@ietf.org" , Kurt Andersen , Franck Martin Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 04 Jun 2014 17:43:25 -0000 Hector Santos writes: > [Mail From: a domain under .INVALID] is not legitimate mail per the > proposed security protocol. Sorry, in this subthread, "legitimate", as used by Franck and myself, means "delivery desired by the addressee". If you want to insist on a different definition, go ahead, but that's very rude to the previous posters and confuses other readers. Nor does DMARC say it's nonconforming; in fact, it automatically passes identity alignment, because there's nobody who is allowed to create domains under .invalid, so there can be no _dmarc.x.y.invalid. I suppose it's nonconforming to RFC 5322, but I wouldn't reject mail merely because From contains a mailbox at an invalid domain. Of course you can do what you want in your domain. Like you, I think it violates the spirit of the security protocol -- but so do all mitigations that preserve the address in From in such a way as to indicate that is the mailbox of the author, and so lend the message whatever prestige the author may have with the recipient. Such mitigations are clearly desired by the users of mailboxes at AOL and Yahoo!, and some such mitigation recommended (and in the case of Yahoo!, practiced) by the ESPs publishing "p=reject". You can take a letter-of-the-law stance (I believe you do), and as far as I can tell that means banning those domains from your lists (unless the lists preserve signatures). But that's not acceptable to our users. > The problem and conversation should be focused on resolving the 9 > years old mail integration dilemma -- the dearth of resigners not > wanting to check for bad DKIM-secured transactions via a policy > layer protocol. Keep in mind that the suggested rewrite > applicability for p=reject domains implies that a DNS lookup is > presumed to be part of the DKIM framework. If we can get to that > level, we are home free. But unfortunately, the concept has been > killed by the IETF when it decided to make ADSP historic. DMARC resurrected the concept of a DNS lookup to discover policy, no? But I don't think it's as easy as you say. It may be trivial to publish records authorizing third parties to sign message with your mailboxes in From:, but I doubt it will be done, at least not for the thousands of tiny lists out there with no personal contact with the big ESPs. From nobody Wed Jun 4 10:54:15 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC8A1A02B7 for ; Wed, 4 Jun 2014 10:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Wc04hbDjCjxY for ; Wed, 4 Jun 2014 10:54:10 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A48681A0254 for ; Wed, 4 Jun 2014 10:54:09 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id x13so8905854wgg.10 for ; Wed, 04 Jun 2014 10:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=vrTa2Tvj3VyvHPiu85W/m58m8+IgLsVIspBAGn2h6pQ=; b=MhFVJ+9qgA4cX+C/p95i7386xMlCYhLptJMknoHqmNWXkm8mKDxAm5MmJ97MlxOzjC 9MmaN2vJG3UK7vKiTmlqzwTLbx52GdwBgPXTcWBev9PC0t33hcBjACzSwbDroBJ7yaYe PZGXG0V7OauAstistDCg+t7OUHT9F23kU/pCA= 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:date:message-id:subject:from :to:cc:content-type; bh=vrTa2Tvj3VyvHPiu85W/m58m8+IgLsVIspBAGn2h6pQ=; b=HoiQsWEtzDr+MVSPKMjdvsrlzRVoJrj64T3ARfXFjR0POfnrRkPSm6xryVvDApHoka sdJJ7BEMueZnUx7qJRoyMbkkqMAVf0aVCv9qa5innCUE1KPzlqvfhJlobSlaQvur+8WG 8aVizFdq5h3hPdH7KX3uvQ9iIjeAsfI/LEKT8XQf5q2QPRSfi2oQvaU1Kfd1I+XmHp+U VDVRyzjwnq+tbc3ArgAKG6P2lnSedXc4f/AxIQWBqecR3rkqBHdRvr+7SM1jZT74a+8O 7tW7Ag/i6WfSkVrX1Y6yUMiYThKvYLb5Vcww1ig24TMgCsDblU2qIhYd1o4DHN+0kyje eIVg== X-Gm-Message-State: ALoCoQlEt52f3bJ9tUrvxwaIMcxLJXuI9Wkb1ck+cydzIt8BlQUedZxRWPLWY+Idf58je6WhMhGM MIME-Version: 1.0 X-Received: by 10.180.79.9 with SMTP id f9mr7595848wix.52.1401904442469; Wed, 04 Jun 2014 10:54:02 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.194.235.164 with HTTP; Wed, 4 Jun 2014 10:54:02 -0700 (PDT) Date: Wed, 4 Jun 2014 10:54:02 -0700 X-Google-Sender-Auth: _CumBRxe_DZUOF9uNTi_XG_6Hag Message-ID: From: Kurt Andersen To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=f46d044282aa4d871d04fb0650b5 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/GFKKRdrnHv-68Oq5f9awOK0KQa8 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 04 Jun 2014 17:54:11 -0000 --f46d044282aa4d871d04fb0650b5 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 4, 2014 at 10:43 AM, Stephen J. Turnbull wrote: > Nor does DMARC say it's nonconforming; in fact, it automatically >> passes identity alignment, because there's nobody who is allowed to >> create domains under .invalid, so there can be no _dmarc.x.y.invalid. >> > Actually, it does not and can not pass alignment. The alignment status is undefined which is neither a pass nor a fail. --Kurt Andersen > --f46d044282aa4d871d04fb0650b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 4, 2014 at 10:43 AM, Stephen J. Turnbull <st= ephen@xemacs.org> wrote:
Nor does DMAR= C say it's nonconforming; in fact, it automatically
passes identity alignment, because there's nobody who is allowed to
create domains under .invalid, so there can be no _dmarc.x.y.invalid.
=C2=A0
Actually, it does not an= d can not pass alignment. The alignment status is undefined which is neithe= r a pass nor a fail.

=C2=A0--Kurt Andersen

--f46d044282aa4d871d04fb0650b5-- From nobody Wed Jun 4 11:34:11 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF5F1A02F8 for ; Wed, 4 Jun 2014 11:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 fc9hpPuNHM_1 for ; Wed, 4 Jun 2014 11:34:08 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id 03B4D1A02E1 for ; Wed, 4 Jun 2014 11:34:07 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 40A1E970945; Thu, 5 Jun 2014 03:34:01 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 2D1CC1A31E2; Thu, 5 Jun 2014 03:34:01 +0900 (JST) From: "Stephen J. Turnbull" To: Kurt Andersen In-Reply-To: References: X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 05 Jun 2014 03:34:01 +0900 Message-ID: <87sink34o6.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/C1ATZfU6RpOoBMe8QEFmK48C2KM Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 04 Jun 2014 18:34:09 -0000 Kurt Andersen writes: > On Wed, Jun 4, 2014 at 10:43 AM, Stephen J. Turnbull > wrote: > > > Nor does DMARC say it's nonconforming; in fact, it automatically > >> passes identity alignment, because there's nobody who is allowed to > >> create domains under .invalid, so there can be no _dmarc.x.y.invalid. > >> > > > Actually, it does not and can not pass alignment. The alignment status is > undefined which is neither a pass nor a fail. Urk. Thanks for the correction. Leaving-foot-in-mouth-until-brain-starts-working-ly y'rs, From nobody Wed Jun 4 12:08:56 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568131A02DA for ; Wed, 4 Jun 2014 12:08: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 BRJd4x_yF5sa for ; Wed, 4 Jun 2014 12:08:49 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [192.254.77.197]) by ietfa.amsl.com (Postfix) with ESMTP id D84CA1A007B for ; Wed, 4 Jun 2014 12:08:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id B4EA1A069A; Wed, 4 Jun 2014 14:08:42 -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 QeL4W92KLXzY; Wed, 4 Jun 2014 14:08:42 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 940D5A06A6; Wed, 4 Jun 2014 14:08:42 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 8519BA069A; Wed, 4 Jun 2014 14:08:42 -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 fM97rgJpRNbz; Wed, 4 Jun 2014 14:08:42 -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 6866FA06A4; Wed, 4 Jun 2014 14:08:42 -0500 (CDT) Date: Wed, 4 Jun 2014 14:08:41 -0500 (CDT) From: Franck Martin To: "Stephen J. Turnbull" Message-ID: <910410886.82936.1401908921967.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <87r4363wpn.fsf@uwakimon.sk.tsukuba.ac.jp> <610286136.61974.1401841787613.JavaMail.zimbra@peachymango.org> <8761kg52xe.fsf@uwakimon.sk.tsukuba.ac.jp> <87y4xc370r.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [216.3.18.37] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF29 (Mac)/8.0.5_GA_5839) Thread-Topic: DKIM through mailing lists (rebutting MLs won't change) Thread-Index: +RjwmkliM9HomPHqG/j+Mkj5dIp/Lw== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/NnxbyaYIUOkbavkA5H4ymla21EI Cc: Kurt Andersen , Tony Hansen , dmarc@ietf.org, Hector Santos Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 04 Jun 2014 19:08:54 -0000 ----- Original Message ----- > From: "Stephen J. Turnbull" > To: "Hector Santos" > Cc: "Tony Hansen" , dmarc@ietf.org, "Kurt Andersen" , "Franck Martin" > > Sent: Wednesday, June 4, 2014 10:43:16 AM > Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) > > Hector Santos writes: > > > [Mail From: a domain under .INVALID] is not legitimate mail per the > > proposed security protocol. > > Sorry, in this subthread, "legitimate", as used by Franck and myself, > means "delivery desired by the addressee". If you want to insist on a > different definition, go ahead, but that's very rude to the previous > posters and confuses other readers. As we are in semantics... There are two versions of legitimate and people will choose one or the other depending on context. May be we need a glossary to separate the two... May be there is legitimate in the sense of "follow the protocols and security" and legitimate in the sense "I want that email". Anyhow... my point is that moving an human decision to the machine is difficult, this is why we rely on protocols and we need to refuse more and more emails that are not following the protocols. Once again see the paragraph about the John Postel principle in the malformed emails RFC. John said (maybe?): if the protocol is vague, be lenient, but if the protocol is clear then be strict. He did not say "accept anything, the user will sort it out" >From the discussion I have this question: How an MTA knows the email is from a mailing list? Also looking at bayesian implementations in say spamassassin/amavis (I looked quickly) it does not seem the bayesian rules are organised around authentication identifiers. The bayesian is left to figure what is relevant in an email. Will it pick the domain in the From for that? May be, may be not.... It seems going forward, there should be different baeysian learning, depending on the authenticated domain attached to the email. I don't think we are fully there yet. For instance, the simplified rule should be if this is an email looking like made only by X, but not authenticated by X, junk it. I'm not sure there is any rule like this out there for lot of MTAs. My experience is that a phishing campaign using an email content of X will impact all emails that look the same regardless of source. So to close this long tirade, I think we are moving towards a domain authenticated world of emails, using valid domains as identifiers of source. And yes, MUA have their role to play, in filtering according to user preferences, but the tendency, is for the MUA to pass the user preferences to the MTA, so it can work on received emails even when the MUA is not connected. I don't want my mobile to do the filtering, but tell the MTA what emails I like/don't like. From nobody Wed Jun 4 12:16:07 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C291A0334 for ; Wed, 4 Jun 2014 12:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 NvLtnX0oQSGq for ; Wed, 4 Jun 2014 12:16:02 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A8E01A0302 for ; Wed, 4 Jun 2014 12:16:01 -0700 (PDT) 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; Wed, 4 Jun 2014 21:15:53 +0200 Message-ID: <82F820F43C124B2E9F86D4AA01BC43D1@fgsr.local> From: "J. Gomez" To: Hector Santos References: <5387F6E0.1070903@att.com> <87ha456dlt.fsf@uwakimon.sk.tsukuba.ac.jp> <538A76ED.4050609@att.com> <8738fn6a96.fsf@uwakimon.sk.tsukuba.ac.jp> <55382129.27361.1401740317786.JavaMail.zimbra@peachymango.org> <87r4363wpn.fsf@uwakimon.sk.tsukuba.ac.jp> <538E48C1.2020707@isdg.net> Date: Wed, 4 Jun 2014 21:16:15 +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: http://mailarchive.ietf.org/arch/msg/dmarc/s5YmHz2nzaXFjOGa2pbDFOkzW3E Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 04 Jun 2014 19:16:04 -0000 On Wednesday, June 04, 2014 12:14 AM [GMT+1=3DCET], Hector Santos wrote: > I prefer to update my software with the above script for our MTA > receiver rather to add logic to rewrite the 5322.From to bypass a > security protocol Rewriting the Header-From field in mailing list traffic is not = "bypassing a security protocol", because the rewritten Header-From = itself still is subject to the security protocol (in this case, DMARC = checking) at the Receiver's side, so the security protocol in question = is not bypassed. Regards, J.Gomez From nobody Wed Jun 4 12:21:30 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A9D1A03A1 for ; Wed, 4 Jun 2014 12:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 f-d9JkfWOcGz for ; Wed, 4 Jun 2014 12:21:27 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ED951A033A for ; Wed, 4 Jun 2014 12:21:25 -0700 (PDT) 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; Wed, 4 Jun 2014 21:21:17 +0200 Message-ID: From: "J. Gomez" To: John Levine References: <20140604034439.75715.qmail@joyce.lan> Date: Wed, 4 Jun 2014 21:21:39 +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: http://mailarchive.ietf.org/arch/msg/dmarc/FLKXhwxMzMmE-VN7BznCfr6iwd0 Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 04 Jun 2014 19:21:29 -0000 On Wednesday, June 04, 2014 5:44 AM [GMT+1=3DCET], John Levine wrote: > > Yes the email is legitimate, but how does the MTA knows it? > >=20 > > Well a bayesian filter has learned that this type of content is > > legitimate, and then one day a spammer uses the same content, but > > change one link...=20 >=20 > That could happen to any mail feature you care to name. >=20 > Big companies send buckets of mail with return addresses like > "donotrespond". A non-deliverable or non-replyable From: line has > never had much connection to whether to deliver the mail. That is true, but it is not the same to obfuscate the local part in the = ReturnAddress/FromHeader, than to obfuscate the domain. Obfuscating the domain is quite suspicious because then, what entity is = taking responsibility for that email? What abuse help-desk can the = potential receiver recourse to? Regards, J.Gomez From nobody Wed Jun 4 12:34:39 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7BF1A02A8 for ; Wed, 4 Jun 2014 12:34:37 -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 aY0bnKo0670S for ; Wed, 4 Jun 2014 12:34:34 -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 AB0A31A026B for ; Wed, 4 Jun 2014 12:34:33 -0700 (PDT) Received: (qmail 59396 invoked from network); 4 Jun 2014 19:34: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:cleverness; s=e803.538f74c2.k1406; bh=bfFkRX9at7xI22kcps5itCceYhlmfsJHKANEcVgQzNQ=; b=nxvU8xTYmekFBkVxD8Y7X/trrxFftE+jI3Ugq3jH2Ou0wpzCn831182rZ4wfudTMc2ksmgIwMdRiXFhgqrYWXBVdwzXzIC6zKXNZxazL9OEEiW85Q5Urye9m81a9dMyiK6yAV9SQBmOkHI6AnEg6zLe/c+cgnubNxFVO4gK03F/+qBM1/kGQEfXSp7+/z6qj2ToHJxfcF+9ieJAYrYyKtye6F+itS+4wcObfG68Tx1QQtL1fTLvhNW9Wp40iDoIr 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:cleverness; s=e803.538f74c2.k1406; bh=bfFkRX9at7xI22kcps5itCceYhlmfsJHKANEcVgQzNQ=; b=e5k7B0/bKtuITF+0fWwO0XIh54yiAmbIFd9DS/Ur3lZ7dZpcSd8MDAu1bTzwu3DVNVMT0ZQWAWDfrHqqzWyJSxJpPOzf+JsfGT+cXqeuQot0HUhAMgERV2LU69SvacZInGafZmKniE78ANozWzSvUoO/3uggHScLImBrIqTfhwDV4uqFMFR6OUPlp0ElROOTz8jXg2MFqsR5pDbvTPXqUoe7UA5PVGHpYW3L7SZIDUFR1MS7DOSGAFnzbyVgB6xn 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; 04 Jun 2014 19:34:26 -0000 Date: 4 Jun 2014 15:34:25 -0400 Message-ID: From: "John R Levine" To: "J. Gomez" In-Reply-To: References: <20140604034439.75715.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/u-3D4JQeo5kXz77c-F8T7mBqAgw Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 04 Jun 2014 19:34:37 -0000 > That is true, but it is not the same to obfuscate the local part in the ReturnAddress/FromHeader, than to obfuscate the domain. > > Obfuscating the domain is quite suspicious because then, what entity is taking responsibility for that email? What abuse help-desk can the potential receiver recourse to? The one whose DKIM signature is on the mail, of course. Sigh. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Wed Jun 4 12:41:42 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C236A1A0262 for ; Wed, 4 Jun 2014 12:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zMH6mnBQ4k8a for ; Wed, 4 Jun 2014 12:41:38 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2FD21A026B for ; Wed, 4 Jun 2014 12:41:37 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id cc10so2150991wib.11 for ; Wed, 04 Jun 2014 12:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=PCEMIPtWtLteM63kg3vRw/JIBLtNMmW3eJxG3x5Qvf8=; b=Kof3SYv1ujZkWz/B6T1zZDahXHXuYjRkedudBWMn6ZI/sEgRoTbf6F+9WmHaWYcPQH Eci4szJhd03nsg272VzfCYO9xnynkxxaC0vedPUf58aozk44u9mR76zPJCzR0pnnJbro d2+J6S9Z+Z6u4K82N6qHFOpDd2vTVGQfMFGIU= 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:date:message-id:subject:from :to:cc:content-type; bh=PCEMIPtWtLteM63kg3vRw/JIBLtNMmW3eJxG3x5Qvf8=; b=guNlxjfGBAYYpOgRd40Kqg/H4sVleA5zd8Mn56jHSCsO42ToxQ1k4rNtVp88pC60cL xBOy7aRa2tn6jcd2sVIkhLOVHhtiIAxEpV+4dxfONRBGwpFbuvJAr7jKK9lAhxMzE3F9 IvlSxkG4dJ1U6pd8biD5C18H64P6AO31iOXx/+R0248JIwL1vT6EUqBaV5kva62To7ez Wge6Dw5ePhtDaDKyyl6uYhiOMNpOBHf3bQmEAhkOWIMfvSTCNHCFWGcELxaYgLKLTnwv XV+azAG6sF+VQFpxHmcBIroK9hbqEXGqTtn4aQ9DlsyMrvPW05xsGPuDcszv8ozkpt+e RqHw== X-Gm-Message-State: ALoCoQn+wwVqnsxa73DaI6pYq2xP1O4OhcV/w/tF7icVWtk7PmAziwl0yCiKpmDTJHuDCM6XtEu2 MIME-Version: 1.0 X-Received: by 10.180.149.240 with SMTP id ud16mr8602946wib.3.1401910890330; Wed, 04 Jun 2014 12:41:30 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.194.235.164 with HTTP; Wed, 4 Jun 2014 12:41:30 -0700 (PDT) Date: Wed, 4 Jun 2014 12:41:30 -0700 X-Google-Sender-Auth: K2smQtXma3Twa1y_9enGAKn0600 Message-ID: From: Kurt Andersen To: John R Levine Content-Type: multipart/alternative; boundary=001a11c260e2a014be04fb07d047 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/DH3IEQXIX0kGDZdH3hE_8SetqlI Cc: "dmarc@ietf.org" , "J. Gomez" Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 04 Jun 2014 19:41:39 -0000 --001a11c260e2a014be04fb07d047 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 4, 2014 at 12:34 PM, John R Levine wrote: > That is true, but it is not the same to obfuscate the local part in the >> ReturnAddress/FromHeader, than to obfuscate the domain. >> >> Obfuscating the domain is quite suspicious because then, what entity is >> taking responsibility for that email? What abuse help-desk can the >> potential receiver recourse to? >> > > The one whose DKIM signature is on the mail, of course. Sigh. > That would be the no-longer valid (assuming it ever was) and non-aligned DKIM string? Why would you trust something that is not valid and can't *be* validated? Also, if there are multiple such strings - which one? --Kurt --001a11c260e2a014be04fb07d047 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 4, 2014 at 12:34 PM, John R Levine <johnl@tau= gh.com> wrote:
That is true, but it is not the same to obfuscate the local part in the Ret= urnAddress/FromHeader, than to obfuscate the domain.

Obfuscating the domain is quite suspicious because then, what entity is tak= ing responsibility for that email? What abuse help-desk can the potential r= eceiver recourse to?

The one whose DKIM signature is on the mail, of course. =C2=A0Sigh.

That would be the no-longer valid (assuming it= ever was) and non-aligned DKIM string? Why would you trust something that = is not valid and can't *be* validated? Also, if there are multiple such= strings - which one?

--Kurt
--001a11c260e2a014be04fb07d047-- From nobody Wed Jun 4 12:44:40 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0ED1A0262 for ; Wed, 4 Jun 2014 12:44:38 -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 WNMtkrdL7EKj for ; Wed, 4 Jun 2014 12:44:37 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C39B61A026B for ; Wed, 4 Jun 2014 12:44:36 -0700 (PDT) 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; Wed, 4 Jun 2014 21:44:29 +0200 Message-ID: From: "J. Gomez" To: John R Levine References: <20140604034439.75715.qmail@joyce.lan> Date: Wed, 4 Jun 2014 21:44:51 +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: http://mailarchive.ietf.org/arch/msg/dmarc/UqNGgsVWQgNZHo9TbPAbbyoyPak Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 04 Jun 2014 19:44:38 -0000 On Wednesday, June 04, 2014 9:34 PM [GMT+1=3DCET], John R Levine wrote: > > That is true, but it is not the same to obfuscate the local part in > > the ReturnAddress/FromHeader, than to obfuscate the domain.=20 > >=20 > > Obfuscating the domain is quite suspicious because then, what > > entity is taking responsibility for that email? What abuse > > help-desk can the potential receiver recourse to? =20 >=20 > The one whose DKIM signature is on the mail, of course. Sigh. But DKIM signatures are not mandatory, not even to be able to get a pass = in DMARC checking. I see holes in that remedy. Regards, J.Gomez From nobody Wed Jun 4 13:01:13 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73221A032D for ; Wed, 4 Jun 2014 13:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.663 X-Spam-Level: X-Spam-Status: No, score=0.663 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, J_CHICKENPOX_44=0.6, 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 aNif-mfxU76u for ; Wed, 4 Jun 2014 13:01: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 6C51C1A0329 for ; Wed, 4 Jun 2014 13:01:09 -0700 (PDT) Received: (qmail 65028 invoked from network); 4 Jun 2014 20:01:02 -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:original-authentication-results:user-agent:cleverness; s=fe02.538f7afe.k1406; bh=l4MEUaB4YgA/s3qtwT6eH+wuo1g5ciktQtvxqDZ8uVc=; b=B7384Y3cSe/rH3J2JoAtM4JiQFaouLKgJErqlF+2rwM3JM0PesOLflNRVr4G2OQulpzTEDztCfHPJ7SmCb0Uf+1+cpmWfQ3BqeZch4wZEckTpn6/b9c9xaMEX1SNcp9MheNQAnWqlXu5C41SNi5ej2m+Go0GXxI1vmOTmo8zAE4N+ySI817hJrzj1bPB6nMH6WUpu8MrJkMzlD8iToW0SyONkMPXrRxIwXOAvULopudXGXgalVug/Bhn9V/l1AYA 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:original-authentication-results:user-agent:cleverness; s=fe02.538f7afe.k1406; bh=l4MEUaB4YgA/s3qtwT6eH+wuo1g5ciktQtvxqDZ8uVc=; b=X+qZfIbAQKEKyQc/RXX+3HJMXb4eWHnrHomZPwqY2hsk+sTqN+WDAh8Cl2AI8MIKw6DxgIVpJuIcmgAaBajIQpe/xKqcDkKnn2b/656YM4GK1jG2sfYBzlgoqD/HkW3itjeV9m/YOXhMwa9ewsbbVEUA0DhR27Ri+UrP6gI35x/5jMNxMPEVkGnVCEMgl+CP1hrM9jIZmOmdeqglbIcRmff9DvXvluEJeQC7SZWc8YLAy+kaNjmD/Hk8IeEGAYQW Original-Authentication-Results: iecc.com; spf=pass spf.mailfrom=dmarc-bounces@ietf.org spf.helo=mail.ietf.org; 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; 04 Jun 2014 20:01:02 -0000 Date: 4 Jun 2014 16:01:02 -0400 Message-ID: From: "John R Levine" To: "Kurt Andersen" In-Reply-To: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/9Vw1Y2soHc4RGHfnIuJLgPGafHw Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 04 Jun 2014 20:01:10 -0000 >>> Obfuscating the domain is quite suspicious because then, what entity is >>> taking responsibility for that email? What abuse help-desk can the >>> potential receiver recourse to? >> >> The one whose DKIM signature is on the mail, of course. Sigh. > > That would be the no-longer valid (assuming it ever was) and non-aligned > DKIM string? Why would you trust something that is not valid and can't *be* > validated? Also, if there are multiple such strings - which one? No, it's the valid signature from the mailing list that signed the mail on the way out. If there are multiple valid DKIM signatures, you can use any or all of them, since that is the way DKIM works. Here, for example, is the signature from your message to the dmarc list to which this is a response: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1401910901; bh=Ss7UP6fdlg/Nn7B/DiNdPNOOAEUDmP2bqWwILrhzH7s=; h=MIME-Version:Date:Message-ID:From:To:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Sender; b=MG+QM40OoHTFFfoMx4ONQNlBZ4J63pI0KWkBEeXuDB+t1owHvEYV7svNAo9F0uIwd6LQIIVb+6kfy10c4nzZYkt1uSEFZ8uRnqN8x/yOa+SMy4OrHY+zMERFuxQnwW3cTUB LOpGzXqDnf5TZGgwPPhk4SES64N0dko/8gcZzlGo= And here is the A-R header that showed it was valid: Authentication-Results: iecc.com; spf=pass spf.mailfrom=dmarc-bounces@ietf.org spf.helo=mail.ietf.org; dkim=pass header.d=ietf.org header.b="MG+QM40O"; dkim=fail (bad signature) header.d=drkurt.com header.b="Kof3SYv1"; dmarc=fail.none header.from=drkurt.com policy=none DKIM has been a standard for over seven years. Why are we still dealing with these elementary questions about the way it works? Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Wed Jun 4 13:30:49 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C53E71A032D for ; Wed, 4 Jun 2014 13:30:47 -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_45=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 ju2dfXIYZDjU for ; Wed, 4 Jun 2014 13:30:45 -0700 (PDT) Received: from mail.winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 91C531A02F0 for ; Wed, 4 Jun 2014 13:30:45 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1963; t=1401913830; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=fbSiw7p/SIF+VD2tZCznOz2vqnk=; b=bDTpaCPlHQp9ektNPyz5 cNQvKtF/NWFa+5uZIM//40rNwGQO2xlXfqC3ec0pMs46W0cPtOUQJ7mA0hMsOkq5 NKZHeDvP79yFj7cPMloh7DqtjxfVXRp3/01bxkTx6YatBAGFv71I52W09gF+WI2R Ih0jF/6FV4+p8mUjTRnmWWk= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 04 Jun 2014 16:30:30 -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; Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1393958977.12054.3572; Wed, 04 Jun 2014 16:30:29 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1963; t=1401913673; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=0lZI7fR V/siSOpsBZLHlq8RvyRRgfJ6u2rjGr+RaMT0=; b=lAsI8j7udRixBphtaCnxpwU 5BTiYlGXz8P2wFp1OxrfmohH5VgnUAwyTQoXqEMYbrqHFNSUO/9Ceuv4cTxetyX9 l0q/QzgA42qWI7Mo6uxBeQFw4jM3lPcDpaEFDSKh87YHKdkAMdmXapGusg7oGr37 3wZEMkyLtHewVVPDSgUQ= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 04 Jun 2014 16:27:53 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1410320875.9.5288; Wed, 04 Jun 2014 16:27:53 -0400 Message-ID: <538F81E5.104@isdg.net> Date: Wed, 04 Jun 2014 16:30: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: "J. Gomez" References: <5387F6E0.1070903@att.com> <87ha456dlt.fsf@uwakimon.sk.tsukuba.ac.jp> <538A76ED.4050609@att.com> <8738fn6a96.fsf@uwakimon.sk.tsukuba.ac.jp> <55382129.27361.1401740317786.JavaMail.zimbra@peachymango.org> <87r4363wpn.fsf@uwakimon.sk.tsukuba.ac.jp> <538E48C1.2020707@isdg.net> <82F820F43C124B2E9F86D4AA01BC43D1@fgsr.local> In-Reply-To: <82F820F43C124B2E9F86D4AA01BC43D1@fgsr.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/7IgthsqyJ_1k2yY8-sMMdOfo9iI Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 04 Jun 2014 20:30:47 -0000 On 6/4/2014 3:16 PM, J. Gomez wrote: > On Wednesday, June 04, 2014 12:14 AM [GMT+1=CET], Hector Santos wrote: > >> I prefer to update my software with the above script for our MTA >> receiver rather to add logic to rewrite the 5322.From to bypass a >> security protocol > > Rewriting the Header-From field in mailing list traffic is not "bypassing a security protocol", because the rewritten Header-From itself still is subject to the security protocol (in this case, DMARC checking) at the Receiver's side, so the security protocol in question is not bypassed. > Hmmmm, thats a clear protocol security hole. The problem has always been that the middleware was intentionally ignorant of the proposed author domain DKIM signing protocol in order to allow it to offer an open-ended 3rd party DKIM signing service. It was not recognized, and the author of ADSP was not shy to advocate to everyone to not support it. The impact of this ignorance was real, proven and demonstrated by me to highlight the fact that we needed 3rd party semantics and MLS support. But it was yet to be felt and to close the deal, the ADSP proposal was make historic. That is until YAHOO enabled a strong policy via the alternative DMARC and now you feel it. Now, today, the list service is aware of the DMARC protocol but remains ignorant to follow it, honor it and knowing full well, DKIM+DMARC compliant downlink receivers will reject it, it violates the intent of RC2606 by using a ".invalid" TLD in order to bypass and preempt downlink rejections. That was not the intent of RFC2606. So rather than support DMARC fully, update it for 3rd party semantics to allow the resigner to exist in a DKIM+DMARC world, it proposes a hack to bypass the security. This is a major security loophole so the good news is that it was highlighted and now mail receivers will be aware of needing to add new ".invalid" check and rejection scripts. -- HLS From nobody Wed Jun 4 13:56:55 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA9C61A02F0 for ; Wed, 4 Jun 2014 13:56:54 -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 PLTzCadHL460 for ; Wed, 4 Jun 2014 13:56:53 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 614371A0024 for ; Wed, 4 Jun 2014 13:56:53 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id v10so52445pde.9 for ; Wed, 04 Jun 2014 13:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Ui/Su8OqYp16SyYpa15/7IFASBvnCNTbfzgINq/9Ajc=; b=rVE4YGWo05Qp54ejpJIdiP0RE8lN4lwwXbJI6KfnQKMs0+pksRo5tPYXULty/iiyXM pZ4dELxgBLJtXsrOpKUojzMaBl3PjPkf6OnJi5/y/45Xkz7AwPEodFt2t4uz1pSFVe4o yTi3yEPvEua6YrXPAWgeImAI4/A9CKtBDn1Ke/EdaCkvSiHTb4iUnNiPZem9vMeSp4tI JJg6R8CC6IVjZvpwlwLEmoe3YrMq6tuHMYM+XBufN03JkImn/e7yL0ZCpEQl1VUbnew6 zinyoTK9hm/Irsfs5c4459CfwB7YKtFixo1VbsHwO7H4s9Cc3HIgECnK0UumFw8+PUm0 b7Tw== X-Received: by 10.68.164.100 with SMTP id yp4mr66743979pbb.136.1401915407184; Wed, 04 Jun 2014 13:56:47 -0700 (PDT) Received: from ?IPv6:2601:9:7680:203:61d6:aff9:5791:6e70? ([2601:9:7680:203:61d6:aff9:5791:6e70]) by mx.google.com with ESMTPSA id gz11sm13903044pbd.1.2014.06.04.13.56.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Jun 2014 13:56:46 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=us-ascii From: Douglas Otis X-Priority: 3 In-Reply-To: <82F820F43C124B2E9F86D4AA01BC43D1@fgsr.local> Date: Wed, 4 Jun 2014 13:56:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5387F6E0.1070903@att.com> <87ha456dlt.fsf@uwakimon.sk.tsukuba.ac.jp> <538A76ED.4050609@att.com> <8738fn6a96.fsf@uwakimon.sk.tsukuba.ac.jp> <55382129.27361.1401740317786.JavaMail.zimbra@peachymango.org> <87r4363wpn.fsf@uwakimon.sk.tsukuba.ac.jp> <538E48C1.2020707@isdg.net> <82F820F43C124B2E9F86D4AA01BC43D1@fgsr.local> To: "J. Gomez" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/msUh6BBKeb3OoMzNLs0BWBVgeGg Cc: dmarc@ietf.org, Hector Santos Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 04 Jun 2014 20:56:54 -0000 On Jun 4, 2014, at 12:16 PM, J. Gomez wrote: > On Wednesday, June 04, 2014 12:14 AM [GMT+1=3DCET], Hector Santos = wrote: >=20 >> I prefer to update my software with the above script for our MTA >> receiver rather to add logic to rewrite the 5322.=46rom to bypass a >> security protocol >=20 > Rewriting the Header-=46rom field in mailing list traffic is not = "bypassing a security protocol", because the rewritten Header-=46rom = itself still is subject to the security protocol (in this case, DMARC = checking) at the Receiver's side, so the security protocol in question = is not bypassed. Dear J Gomez, Customers seeing =46rom headers changed will not have a practical means = to understand who sent the message. Of course, this assumes who = initiated content in an exchange is a critical aspect of any security = related goal. For mailing-lists, this understanding is critical to = being able to review conversations as well. For invoicing, it is the = client of a service likely to be recognized by recipients. In both of = these cases, TPA-Labels offer a practical and safe solution. If it is critical, have the TPA-Label require the OAR be checked. This = can be quickly added if that is the hold-up Bayesian probabilities are not very reliable when dealing with clever = malefactors since they can lead email into the proverbial ditch by = offering irrelevant keying of transient elements. TPA-Labels help = provide a clear trust relationships only author-domains are best able to = determine. To ensure accuracy, this domain related information needs to = be conveyed to receivers.=20 Regards, Douglas Otis From nobody Wed Jun 4 15:07:24 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDA91A032B for ; Wed, 4 Jun 2014 15:07:21 -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 Jk2ieYZRZafh for ; Wed, 4 Jun 2014 15:07:18 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEF8C1A0309 for ; Wed, 4 Jun 2014 15:07:17 -0700 (PDT) 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; Thu, 5 Jun 2014 00:07:09 +0200 Message-ID: <7441626507D0487CB262F447C2E5A843@fgsr.local> From: "J. Gomez" To: Douglas Otis References: <5387F6E0.1070903@att.com> <87ha456dlt.fsf@uwakimon.sk.tsukuba.ac.jp> <538A76ED.4050609@att.com> <8738fn6a96.fsf@uwakimon.sk.tsukuba.ac.jp> <55382129.27361.1401740317786.JavaMail.zimbra@peachymango.org> <87r4363wpn.fsf@uwakimon.sk.tsukuba.ac.jp> <538E48C1.2020707@isdg.net> <82F820F43C124B2E9F86D4AA01BC43D1@fgsr.local> Date: Thu, 5 Jun 2014 00:07:32 +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: http://mailarchive.ietf.org/arch/msg/dmarc/WnU6-Ctu-yHsoE7oqvSo05ZDWcw Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 04 Jun 2014 22:07:21 -0000 On Wednesday, June 04, 2014 10:56 PM [GMT+1=3DCET], Douglas Otis wrote: > On Jun 4, 2014, at 12:16 PM, J. Gomez wrote: >=20 > > On Wednesday, June 04, 2014 12:14 AM [GMT+1=3DCET], Hector Santos > > wrote:=20 > >=20 > > > I prefer to update my software with the above script for our MTA > > > receiver rather to add logic to rewrite the 5322.From to bypass a > > > security protocol > >=20 > > Rewriting the Header-From field in mailing list traffic is not > > "bypassing a security protocol", because the rewritten Header-From > > itself still is subject to the security protocol (in this case, > > DMARC checking) at the Receiver's side, so the security protocol in > > question is not bypassed. =20 >=20 > Customers seeing From headers changed will not have a practical means > to understand who sent the message. Of course, this assumes who > initiated content in an exchange is a critical aspect of any security > related goal. For mailing-lists, this understanding is critical to > being able to review conversations as well. =20 If the rewritten Header-From references the remote author Name in its = description and carries the mailing list Mailbox address (i.e., the = immediate author who invalidated the remote author's DKIM signature) in = the Header-From, I posit customers will have a practical means to = understand who sent the message through said mailing list. In fact, many = MUAs only display de Header-From description/name and not the = Header-From mailbox address to the user, so even less confusion would be = possible in those cases. =20 Plus, a mailing list is an opt-in device. If the user chooses to be part = of it, he accepts the mailing list terms of service, and if those terms = involve rewriting Header-From in a DMARC-interoperable way, then that's = what it is. The user is free to not use the mailing list service = operated thusly if he objects to such a practice. > If it is critical, have the TPA-Label require the OAR be checked.=20 > This can be quickly added if that is the hold-up=20 I, as a domain owner, do not want to go chasing my users around = demanding them to declare to me what mailing lists they subscribe to, in = order to publish them as whitelists/exceptions for my domain as a = Sender. What if I have a user subscribed to a transgender/whatever = mailing list? Do I want to know? Does he want to tell me? I as a domain = owner either trust my user, or fire my user, but I don't want to have to = preemptively monitor my user not do I want him to disclose to me the = minutiae of his email usage. If TPA-label involves this, I see no future = in it.[*] [*] But it may well be that TPA-label works in a completely different = way, I tried to read the draft but I could not understand much of it = (therefore my Klingon joke, for which I apologize to you). Regards, J.Gomez From nobody Wed Jun 4 16:33:44 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA1E1A03D0 for ; Wed, 4 Jun 2014 16:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.829 X-Spam-Level: X-Spam-Status: No, score=-0.829 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_16=0.6, RP_MATCHES_RCVD=-0.651, 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 9zUlsRiG8Eeq for ; Wed, 4 Jun 2014 16:33:40 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981FA1A03A1 for ; Wed, 4 Jun 2014 16:33:40 -0700 (PDT) Received: by mail-ig0-f176.google.com with SMTP id a13so2586957igq.3 for ; Wed, 04 Jun 2014 16:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yR9ubs6/tWVjIrvdr6H0b8zZt3i7aP1CIemN/5/gjKw=; b=WY5VVojC39RopCSBFpa+su7KM25JhdEPrXNtz5vfQWJ1ywRUQ886bWdKYvGs8wDKbt iRapbcxZOrLZrG07jHL+cNKuYwO4N8l7EUQmtzUM8AO5MlynlgIfYZQL/863WLyg1jvd revHXjv4h4z9lrLy0HnwfRHNUDhj9Fw7IxJ6hrX4y+WTZF+3elA0lACAcddHk8apBGWD uBMGIJvS+c5rEmtB9m2g/kBcYv0RFpG/R02wZTYqD9JGUlAmXwyBC/aY+dLKZpzz+0kq d0D+ig0qNOVdhEswT7zQqvzXagO6F1bTlNBvIO1+7esH23Cu7Du8ZvTG60T/9zxUJ1vo JSuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yR9ubs6/tWVjIrvdr6H0b8zZt3i7aP1CIemN/5/gjKw=; b=Qk/biVFyvmJiFSL6tKzie0WB9zJLORzLaYv/ML/3l4wCQy/ZADTCVjn5eDhDLyVuJZ /S/cxsKslML8kAwtDEW3GiioAiKsZLsiDaXdE+b9PyKM8+vGrceLMLBuYghf3Ch7Y14c Af5VTWfW83OVDPURgxhymneMZuhBELyV7k4gJBFikqSJfqiolqek3Yz+t7esrqXZGmtG f66DplaYjVX3Npdll5txNZCOVvKk1jLSUUzQwaVhxwtLJJedeFoH9lvzw85xfS3r6kiv 0RLbn6Z+/R/XLNg4n1X9Idqv+0p06y3cD6lgCP6u/C6jD9s91XMgTFgRCNQyjPo1GGYJ LUqg== X-Gm-Message-State: ALoCoQmUEtp8cDQjQzYBD4qN2zkAGDLnH9iqXb0oUr8dyMGQ2idQSwIUIK5lRjoLbuFJjvLBklT8 MIME-Version: 1.0 X-Received: by 10.50.109.202 with SMTP id hu10mr12885527igb.1.1401924814268; Wed, 04 Jun 2014 16:33:34 -0700 (PDT) Received: by 10.64.213.73 with HTTP; Wed, 4 Jun 2014 16:33:34 -0700 (PDT) In-Reply-To: <7441626507D0487CB262F447C2E5A843@fgsr.local> References: <5387F6E0.1070903@att.com> <87ha456dlt.fsf@uwakimon.sk.tsukuba.ac.jp> <538A76ED.4050609@att.com> <8738fn6a96.fsf@uwakimon.sk.tsukuba.ac.jp> <55382129.27361.1401740317786.JavaMail.zimbra@peachymango.org> <87r4363wpn.fsf@uwakimon.sk.tsukuba.ac.jp> <538E48C1.2020707@isdg.net> <82F820F43C124B2E9F86D4AA01BC43D1@fgsr.local> <7441626507D0487CB262F447C2E5A843@fgsr.local> Date: Wed, 4 Jun 2014 16:33:34 -0700 Message-ID: From: Brandon Long To: "J. Gomez" Content-Type: multipart/alternative; boundary=089e013a1d868e9bd104fb0b0e38 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/2T8jpuQgn9SMDYic6uMNWJxyvts Cc: "dmarc@ietf.org" , Douglas Otis Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 04 Jun 2014 23:33:42 -0000 --089e013a1d868e9bd104fb0b0e38 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 4, 2014 at 3:07 PM, J. Gomez wrote: > On Wednesday, June 04, 2014 10:56 PM [GMT+1=CET], Douglas Otis wrote: > > > On Jun 4, 2014, at 12:16 PM, J. Gomez wrote: > > > > > On Wednesday, June 04, 2014 12:14 AM [GMT+1=CET], Hector Santos > > > wrote: > > > > > > > I prefer to update my software with the above script for our MTA > > > > receiver rather to add logic to rewrite the 5322.From to bypass a > > > > security protocol > > > > > > Rewriting the Header-From field in mailing list traffic is not > > > "bypassing a security protocol", because the rewritten Header-From > > > itself still is subject to the security protocol (in this case, > > > DMARC checking) at the Receiver's side, so the security protocol in > > > question is not bypassed. > > > > Customers seeing From headers changed will not have a practical means > > to understand who sent the message. Of course, this assumes who > > initiated content in an exchange is a critical aspect of any security > > related goal. For mailing-lists, this understanding is critical to > > being able to review conversations as well. > > If the rewritten Header-From references the remote author Name in its > description and carries the mailing list Mailbox address (i.e., the > immediate author who invalidated the remote author's DKIM signature) in the > Header-From, I posit customers will have a practical means to understand > who sent the message through said mailing list. In fact, many MUAs only > display de Header-From description/name and not the Header-From mailbox > address to the user, so even less confusion would be possible in those > cases. > An obvious example many users are now familiar with is Facebook notifications, which all come from the same address and place the name of the poster in the subject. G+ notifications place the name in the from header and the post subject in the subject (so they thread). I've seen notifications from various bulletin boards work the same way. Y!Groups seems to have changed to always placing the name/address in the display-name portion of the from for all domains, not just p=REJECT ones, and I just noticed while looking for examples. Plus, a mailing list is an opt-in device. If the user chooses to be part of > it, he accepts the mailing list terms of service, and if those terms > involve rewriting Header-From in a DMARC-interoperable way, then that's > what it is. The user is free to not use the mailing list service operated > thusly if he objects to such a practice. > We were debating placing the poster's email address in the footer of the message, so that its visible, since X-Original-From or whatever wouldn't be, and we aren't placing the address in the From display-name (since in our experiments, Y!Mail would reject those messages with the same DMARC message, at least some times). i'm beginning to lean towards liking the "embedded message" solution that mailman has, though. In my testing, it works mostly fine in Gmail, though it assumes (and prefixes with) "forwarded message". YMail's handling isn't that pretty, however, as it ignores the headers of the embedded message completely. Brandon --089e013a1d868e9bd104fb0b0e38 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Jun 4, 2014 at 3:07 PM, J. Gomez <jgomez@seryrich.com> wrote:
On Wednesday, June 04, 2014 = 10:56 PM [GMT+1=3DCET], Douglas Otis wrote:

> On Jun 4, 2014, at 12:16 PM, J. Gomez <jgomez@seryrich.com> wrote:
>
> > On Wednesday, June 04, 2014 12:14 AM [GMT+1=3DCET], Hector Santos=
> > wrote:
> >
> > > I prefer to update my software with the above script for our= MTA
> > > receiver rather to add logic to rewrite the 5322.From to byp= ass a
> > > security protocol
> >
> > Rewriting the Header-From field in mailing list traffic is not > > "bypassing a security protocol", because the rewritten = Header-From
> > itself still is subject to the security protocol (in this case, > > DMARC checking) at the Receiver's side, so the security proto= col in
> > question is not bypassed.
>
> Customers seeing From headers changed will not h= ave a practical means
> to understand who sent the message. =C2=A0Of course, this assumes who<= br> > initiated content in an exchange is a critical aspect of any security<= br> > related goal. =C2=A0For mailing-lists, this understanding is critical = to
> being able to review conversations as well.

If the rewritten Header-From references the remote author Name in its= description and carries the mailing list Mailbox address (i.e., the immedi= ate author who invalidated the remote author's DKIM signature) in the H= eader-From, I posit customers will have a practical means to understand who= sent the message through said mailing list. In fact, many MUAs only displa= y de Header-From description/name and not the Header-From mailbox address t= o the user, so even less confusion would be possible in those cases.

An obvious example many users are now fami= liar with is Facebook notifications, which all come from the same address a= nd place the name of the poster in the subject. =C2=A0G+ notifications plac= e the name in the from header and the post subject in the subject (so they = thread). =C2=A0I've seen notifications from various bulletin boards wor= k the same way. =C2=A0Y!Groups seems to have changed to always placing the = name/address in the display-name portion of the from for all domains, not j= ust p=3DREJECT ones, and I just noticed while looking for examples.

Plus, a mailing list is an opt-in device. If the user chooses to be part of= it, he accepts the mailing list terms of service, and if those terms invol= ve rewriting Header-From in a DMARC-interoperable way, then that's what= it is. The user is free to not use the mailing list service operated thusl= y if he objects to such a practice.

We were debating placing the poster's = email address in the footer of the message, so that its visible, since X-Or= iginal-From or whatever wouldn't be, and we aren't placing the addr= ess in the From display-name (since in our experiments, Y!Mail would reject= those messages with the same DMARC message, at least some times).

i'm beginning to lean towards liking the "embe= dded message" solution that mailman has, though. =C2=A0In my testing, = it works mostly fine in Gmail, though it assumes (and prefixes with) "= forwarded message". =C2=A0YMail's handling isn't that pretty, = however, as it ignores the headers of the embedded message completely.

Brandon

--089e013a1d868e9bd104fb0b0e38-- From nobody Wed Jun 4 17:04:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE231A03E7 for ; Wed, 4 Jun 2014 17:04:29 -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 CcJJCJ0Q4q56 for ; Wed, 4 Jun 2014 17:04:28 -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 385B11A03E6 for ; Wed, 4 Jun 2014 17:04:28 -0700 (PDT) Received: (qmail 10882 invoked from network); 5 Jun 2014 00:04:21 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 5 Jun 2014 00:04:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=14a64.538fb405.k1406; i=johnl@user.iecc.com; bh=9nxX/fm3/uhX4RCIb+Xr5ebmS2vh1+3L7a0qguW15N0=; b=bB20rvomR3qHQ4UJR6c9tL8vQRxfKz3pcjOHbqvABfuR+b7DqbSA19ng+2+0eKMOKgmfPVUl0dOjvFZoENflQ2AHxpAgVCpW3WBX8DIiHgiCBp5bmFSY/si2nFGUlV6VGJcvS5ZpWJR9kGLtwHHiYU0sgQD7/Mpsada+2gQ8J/w75aPE3uLd/onGD8sVV4bzdHIFNarZyUKjaRfB5EoKyJ6Gq7M9ofq1OXXhNinwfGlTz7YHYPcDMfbWkFmsZ6bR DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=14a64.538fb405.k1406; olt=johnl@user.iecc.com; bh=9nxX/fm3/uhX4RCIb+Xr5ebmS2vh1+3L7a0qguW15N0=; b=pP06/eDtUiI7iZxBOg2P9tCce1mlZwZXS5fFz7aTK8zSDkWegD2Wyjpg6RCqS9wGj7ihqsrE2CAPLYc4WTVN3hzJE1VezQ5l6OBP6cIISB1Qs9eCrSf4h3cgiacyOVn474qGa8F+Y+nlkOAcNPHYEgGARA1KumOVhl+2qWbKFnPXmfBGMUa6rbHMhhfrb2Gf5i+AV2xBr+6xuyg0Ju+lyFDdTLKSbxZQmDzMoS/1U6PRTA4ohDFQn3reCFusWyZM Date: 5 Jun 2014 00:03:59 -0000 Message-ID: <20140605000359.84579.qmail@joyce.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: http://mailarchive.ietf.org/arch/msg/dmarc/tWjbyzqgoGBifLCrf04Q-LbY1XE Cc: blong@google.com Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 05 Jun 2014 00:04:29 -0000 X-List-Received-Date: Thu, 05 Jun 2014 00:04:29 -0000 >I'm beginning to lean towards liking the "embedded message" solution that >mailman has, though. In my testing, it works mostly fine in Gmail, though >it assumes (and prefixes with) "forwarded message". YMail's handling isn't >that pretty, however, as it ignores the headers of the embedded message >completely. It gets delivered fine, but it's basically a MIME digest, and most MUAs don't handle them very nicely. R's, John From nobody Wed Jun 4 18:41:04 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4482C1A03F4 for ; Wed, 4 Jun 2014 18:41:01 -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 1oqVI41Ok8pv for ; Wed, 4 Jun 2014 18:40: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 6E5611A03E6 for ; Wed, 4 Jun 2014 18:40:58 -0700 (PDT) Received: (qmail 26570 invoked from network); 5 Jun 2014 01:39:36 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 5 Jun 2014 01:39:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=14b90.538fca4d.k1406; i=johnl@user.iecc.com; bh=lzvbNnVv2JpswbBvkzObQyrGfe8BKKADQgLs6fB5Soc=; b=Emnum4JV23R/Y1TZKACGi1hLmGc5qYaDcI+EPcDpQ4aAIheNv+Cja0Vu/BkVwiBlHUwwkOlrXBu00wiealpAd4NzbhuvN+CAnZ1gASHfQLknu79P6Ls1JtB0XKkOuBh4a9cu+ma9P2wt0QOrGiXPvSobLcTc6aQy4UShsJNTmUFxhmK3MN8ZhZ4SQAQnR2fZrfkfdzeyvbQwGaO1WRcZMGMd/Z6BX3DxPBX0pAmeUgDsWa47E0fA2IAVLoPJ4UVe DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=14b90.538fca4d.k1406; olt=johnl@user.iecc.com; bh=lzvbNnVv2JpswbBvkzObQyrGfe8BKKADQgLs6fB5Soc=; b=yzXygYHHOTTqpCLhCsJneTA9U7zLVlQmvmpiazkt7wh7OobpG9x+FW8BZZyP3Wk9/yoDRLsAepc92N53Y/8MSEMn1MT06uHlOeiurGQeUVk8EV2IdsSLAwfOoJuhSw8mmm3qULvkD2cZcEwsoikvfP3VCrtW9UDOLv40Epl1ojpReRZjvmKzWhV/lsFVwulYgx8+/QmR3hfsYsaefuKf/4jbKO3VQSHpu/OaozA0Z01E3Um/DbCEGY8y8IrZfVSg Date: 5 Jun 2014 01:39:02 -0000 Message-ID: <20140605013902.84879.qmail@joyce.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: http://mailarchive.ietf.org/arch/msg/dmarc/9RibDrymyUEnu7Q7Rku6zPJks3k Cc: blong@google.com Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 05 Jun 2014 01:41:01 -0000 >I'm beginning to lean towards liking the "embedded message" solution that >mailman has, though. In my testing, it works mostly fine in Gmail, though >it assumes (and prefixes with) "forwarded message". YMail's handling isn't >that pretty, however, as it ignores the headers of the embedded message >completely. I meant to ask, what's your spear phish strategy here? Do you expect to see a valid DKIM signature on the internal message? Or do you just treat it as a digest and not look inside the wrapper? Or something else? >From what I can see on the mailman lists, looking for the internal DKIM signatures won't work too well, since mailman sometimes removes parts from multipart/alternative to fix to some formatting issue. Yahoo's mail is apparently particularly likely to need this. R's, John From nobody Thu Jun 5 00:39:05 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 217B61A00E9 for ; Thu, 5 Jun 2014 00:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.051 X-Spam-Level: X-Spam-Status: No, score=-0.051 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 plAU5kZCbGlH for ; Thu, 5 Jun 2014 00:39:01 -0700 (PDT) Received: from nm32.bullet.mail.gq1.yahoo.com (nm32.bullet.mail.gq1.yahoo.com [98.136.217.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 876841A009E for ; Thu, 5 Jun 2014 00:39:01 -0700 (PDT) Received: from [127.0.0.1] by nm32.bullet.mail.gq1.yahoo.com with NNFMP; 05 Jun 2014 07:38:55 -0000 Received: from [98.137.12.57] by nm32.bullet.mail.gq1.yahoo.com with NNFMP; 05 Jun 2014 07:35:57 -0000 Received: from [216.39.60.215] by tm2.bullet.mail.gq1.yahoo.com with NNFMP; 05 Jun 2014 07:35:57 -0000 Received: from [127.0.0.1] by omp1102.mail.gq1.yahoo.com with NNFMP; 05 Jun 2014 07:35:57 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 322262.97937.bm@omp1102.mail.gq1.yahoo.com Received: (qmail 40957 invoked by uid 60001); 5 Jun 2014 07:35:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1401953757; bh=DBHNjVvYoMC7cHR63gOTIh3NAOVyCa5/GQpZB8145IU=; h=Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=RcvWTSn7PyKKjrwlGrMdQbYlAxhC6C16igkjQ48VtlVx9zVQm7/xAhq93Ibf0CnBmvEdLX+H2t8ARSyJZk50jhMxZWAJdtBag332vw8a1GN7y6RPg7JHLrgfhViYm4IG3nRt7CMHYnOqi0K4Ex00d4oMWwyXNmTtvJBYmTSWAWM= X-YMail-OSG: TqXbDpEVM1k6GhsSD6Bz0r_9DflJkd_ECEBBYPTu0KR47f. eNFoLaCOBZ1IKQUs._tJ4jCDlp6soxibDgJmk004.eJGkV8CiDYq0MI3MfEs TCSatu.cE621ue5NXgsmRQM4hV2AEK2p5_Uqhnur06WdxjfUw.PALUuZTUcE jEEgeIBVKtoYSI4e2rfpGp2dOyxfRvUbue_mmEJGjBEOa5kecLgLodmnm4R0 P0Onq6thBv0p5rRpp7g4ZHBspauMLojaP70kAwtOmzXHN1cMPrMdI_5oBoVJ 8HcY6SMg.WsWtAfiSissR7NUQjyFUqm0mw8bDh1gB4URKYduhO.WtoYfDcEC fRyMs7xbexAtArUk5Cf9cK4J8v_Jmif.2FD68klKGi4wWVTT86LiGloXJq.w Dmy.GpPY1d9GI.bLP1TkVOp3gj.5wBvQfTMmOWB.zkiszJsjGeikf4._Apzt vj4EHgfpIlGVn7QQuyCswiaURCpwTXQhD30MZSFvs2_TWEEkPdW3uNzCkuwl Vij8HETwD_QeLqXL9dkJFlC9slZqnn3NNYBNj_yiPiZOYxKpVBCHI9hWptQn 1TH2SOPzjg9aQfpQCfgLqWiyADhCB3NBvDeArNkJgqtvQUfAGzNhkAyg7G5o - Received: from [79.175.117.203] by web164605.mail.gq1.yahoo.com via HTTP; Thu, 05 Jun 2014 00:35:57 PDT X-Rocket-MIMEInfo: 002.001, aXQgc2VlbXMgdG8gbWUgdGhhdCBtYW55IG9mIERNQVJDIGRlZmVuZGVycyBkb24ndCB1bmRlcnN0YW5kCm1haW4gcG9pbnRzIG9mIHByb3Bvc2VkIDNyZCBwYXJ0eSBzb2x1dGlvbnMsIGNvbmZ1c2luZyB0aGVtCmZvciBNTCBzb2x1dGlvbnMsIGFuZCB0aHVzIGRpc21pc3NpbmcgdGhlbSBhbHRvZ2V0aGVyLgoKd2hpbGUgaXQncyB0cnVlIDNyZCBwYXJ0eSBzdXBwb3J0IGZvciBETUFSQyB3b3VsZCBiZSBhYmxlCnRvIHNvbHZlIE1MIERNQVJDIHByb2JsZW1zLCB0aGF0IHBhdGggd291bGQgbW9zdCBsaWtlbHkBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 Message-ID: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> Date: Thu, 5 Jun 2014 00:35:57 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/kiDxof68SwLA4KJGNeT-emrjlW0 Subject: [dmarc-ietf] confusing 3rd party support so it remains out X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 05 Jun 2014 07:39:03 -0000 it seems to me that many of DMARC defenders don't understand main points of proposed 3rd party solutions, confusing them for ML solutions, and thus dismissing them altogether. while it's true 3rd party support for DMARC would be able to solve ML DMARC problems, that path would most likely be used only by small domains, whose users rely heavily on mailing lists, and where there's already some trust between domain-owner and MLs. it's surely not a ML solution for entities like ESPs. that doesn't mean it's not possible, even for domains such as Yahoo. it merely means such domains would prefer to rely on simple and performance friendly rigid logic. however, that, again, doesn't mean 3rd party support isn't REQUIRED. i have no idea why it's not obvious to so many experts here, but my best guess is that their viewpoints are limited by their own environment. most of u seem to look at the problem from ur big towers, trying to create a protocol that suits ur big towers. however, many small buildings get smashed while u do so. not very nice. small domains do such extensive and complex things with their email path, one would find crazy, and for multiply of reasons: to suit their needs, their users, their finances, u name it. and it's all pretty legitimate and standards-respecting. yet, they r being excluded. excluded cause they r not a big tower environment. very shortsighted, if u ask me. there's only so many big towers; world is populated with houses. so, to me, it's obvious current DMARC alignment requirements are just too rigid for real world, and anyone who doesn't realize it is not only cracking down on the usefulness of email, but in a way, sinking their own ship [and i'm looking at yahoo here]. btw, i can already see cpanel/plesk/whatever developers ignoring support for DMARC in their software, limiting it only to DNS records publishing, without any receiver support. and i can see many receivers disrespecting p=reject altogether from overzealous domains, turning the protocol into whitelisting, essentially. nobody wants to break their customers email with a rigid standard [excluding 200kg gorillas in a porcelain shop]. ps. to state an example, if anybody doesn't get it. i have trust in ymail to send email on behalf of my domain, and i want a way to state that in my DMARC policy. pps. and no, there's no abuse hole there. ymail verifies ownership of an email address added to yahoo account, and only the account that verified it can send such email through ymail. am i crazy to trust ymail on such things? maybe, but that's solely my decision. not DMARC's. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Thu Jun 5 01:31:32 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1ED71A0109 for ; Thu, 5 Jun 2014 01:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 NA00D50vWmU7 for ; Thu, 5 Jun 2014 01:31:23 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id CDC791A038D for ; Thu, 5 Jun 2014 01:31:22 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 0D0D9970B22; Thu, 5 Jun 2014 17:31:16 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id F1FED1A31E4; Thu, 5 Jun 2014 17:31:15 +0900 (JST) From: "Stephen J. Turnbull" To: "J. Gomez" In-Reply-To: References: <20140604034439.75715.qmail@joyce.lan> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 05 Jun 2014 17:31:15 +0900 Message-ID: <87mwdr3gh8.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/yVyHicVIBg_7TlKwvkkZf-HvcPY Cc: dmarc@ietf.org, John R Levine Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 05 Jun 2014 08:31:25 -0000 J. Gomez writes: > On Wednesday, June 04, 2014 9:34 PM [GMT+1=CET], John R Levine wrote: > > > Obfuscating the domain is quite suspicious because then, what > > > entity is taking responsibility for that email? What abuse > > > help-desk can the potential receiver recourse to? > > > > The one whose DKIM signature is on the mail, of course. Sigh. > > But DKIM signatures are not mandatory, not even to be able to get a > pass in DMARC checking. If there's no DKIM signature, John's rule doesn't apply, and you fall back to whatever your rule for unsigned mail is. Seriously, you guys have to give up on the idea that the whole world will follow arbitrarily strict protocols just because it makes spam fighting simpler. If a big ESP tries to impose them on receipt, and the users don't receive their mail, the users will vote with their feet and the ESP will cave. Conversely, if you try to impose them and a big ESP finds them inconvenient, the ESP will disobey (just as AOL and Yahoo! have done, implicitly, with "p=reject"). The best you can do is use protocols to gather information about the messages you receive, and use that information appropriately (for example, discounting the presence of a DKIM signature from a domain you have independent reason to believe is hacked and under the control of the Black Hats). So, if there is a valid DKIM signature, then you know who to complain to. Don't you? What's the problem? From nobody Thu Jun 5 02:07:56 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B22E1A0365 for ; Thu, 5 Jun 2014 02:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 gQkPjZX53I8v for ; Thu, 5 Jun 2014 02:07:52 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id A7F961A02FE for ; Thu, 5 Jun 2014 02:07:51 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id DB1EF970B37; Thu, 5 Jun 2014 18:07:44 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id CAE321A31E4; Thu, 5 Jun 2014 18:07:44 +0900 (JST) From: "Stephen J. Turnbull" To: Franck Martin In-Reply-To: <910410886.82936.1401908921967.JavaMail.zimbra@peachymango.org> References: <87r4363wpn.fsf@uwakimon.sk.tsukuba.ac.jp> <610286136.61974.1401841787613.JavaMail.zimbra@peachymango.org> <8761kg52xe.fsf@uwakimon.sk.tsukuba.ac.jp> <87y4xc370r.fsf@uwakimon.sk.tsukuba.ac.jp> <910410886.82936.1401908921967.JavaMail.zimbra@peachymango.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 05 Jun 2014 18:07:44 +0900 Message-ID: <87lhtb3esf.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/KMvwrl6i5PnXnrn0Sn4MkP8WLEs Cc: Hector Santos , Tony Hansen , dmarc@ietf.org, Kurt Andersen Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 05 Jun 2014 09:07:53 -0000 Franck Martin writes: > Anyhow... my point is that moving an human decision to the machine > is difficult, this is why we rely on protocols Sure. That's why the U.S. military relies on landmines, too. "Smart bombs" aren't perfect, obviously, but they're better than landmines! DMARC "p=reject" isn't life-threatening when used by Yahoo!, of course, but it has collateral damage in the same way. And also in the same way, eventually you get to a point where the filtering decisions need to be made by a human. Unconditional reliance on protocols is irresponsible. > principle in the malformed emails RFC. John said (maybe?): if the > protocol is vague, be lenient, but if the protocol is clear then be > strict. He did not say "accept anything, the user will sort it out" Indeed he did not say "accept anything". But no, he did not refer to the clarity of the protocol. He said (paraphrased), if you're producing output according to a protocol, conform strictly (implying: even if it's stupid). If you're accepting input according to a protocol, use your judgment (implying: give the end user what they want). I think Google's treatment of DMARC "p=reject" is in exemplary conformance to Postel's principle. In some cases (often indicated by an obs- production in ABNF), we even explicitly specify a certain degree of leniency as SHOULD. But that's not always possible; often it must be left up to implementations. > From the discussion I have this question: How an MTA knows the > email is from a mailing list? Because List-Post and/or List-Id is signed with a known key. > Also looking at bayesian implementations in say spamassassin/amavis > (I looked quickly) it does not seem the bayesian rules are > organised around authentication identifiers. No, because the rules labeled "Bayesian" are only part of the system. However, stuff like SPF and DKIM have add-on modules to generate auth results and assign them to variables, and then you can create rules which assign spam points according to the values of those variables, and thus take advantage of those facilities. Strictly speaking not an application of Bayes rule, but a sort of hybrid classifier. > the From for that? May be, may be not.... It seems going forward, > there should be different baeysian learning, depending on the > authenticated domain attached to the email. I don't think we are > fully there yet. We never will be "there". But I have to wonder if our time might not be better used in building a better Bayes rather than trying to repair the DMARC protocol (which for some use cases just ain't broke). > For instance, the simplified rule should be if this is an email > looking like made only by X, but not authenticated by X, junk > it. I'm not sure there is any rule like this out there for lot of > MTAs. Of course there is. I've never used it, but SpamAssassin has had an SPF verifier for something like 10 years. You can add a rule that says if SPF fails, give it 100 spam points, and that will cause it to be junked. > So to close this long tirade, I think we are moving towards a > domain authenticated world of emails, using valid domains as > identifiers of source. If you mean using valid domains with valid signatures as the *only* identifier, "I don't think I want to be part of that 'we'." I think a lot of your feeling about this is that (1) you just don't trust classifiers (and yes, there are plenty of real examples where they've been fooled badly), and so (2) you're really not up on the classifier technology. > And yes, MUA have their role to play, in filtering according to > user preferences, but the tendency, is for the MUA to pass the user > preferences to the MTA, so it can work on received emails even when > the MUA is not connected. I don't want my mobile to do the > filtering, but tell the MTA what emails I like/don't like. I don't blame you. I don't know any decent mobile MUAs. But consider the GMail app. The MUA may actually be integrated with the MTA (any Google Mail devs want to comment), I don't know, but in principle GMail is an MTA. The "advanced" version of the MTA part of GMail is a *distributed system*: much of it is implemented in Javascript in your browser, but the filter rules and so on are implemented in the Google cloud. I don't see any reason not to implement filtering in the mobile MUA when mobile MUAs are actually such distributed systems. Regards, From nobody Thu Jun 5 02:30:37 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8266D1A03C8 for ; Thu, 5 Jun 2014 02:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 5UK4OLQ5-W_K for ; Thu, 5 Jun 2014 02:30:32 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id ED2E51A0365 for ; Thu, 5 Jun 2014 02:30:31 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 49B1C970B37; Thu, 5 Jun 2014 18:30:25 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 3CB521A31E4; Thu, 5 Jun 2014 18:30:25 +0900 (JST) From: "Stephen J. Turnbull" To: "John Levine" In-Reply-To: <20140605013902.84879.qmail@joyce.lan> References: <20140605013902.84879.qmail@joyce.lan> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 05 Jun 2014 18:30:25 +0900 Message-ID: <87k38v3dqm.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/UXJ5NsSI2sPorF_5U1v-YxjomX0 Cc: blong@google.com, dmarc@ietf.org Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 05 Jun 2014 09:30:35 -0000 John Levine writes: > From what I can see on the mailman lists, looking for the internal > DKIM signatures won't work too well, since mailman sometimes > removes parts from multipart/alternative to fix to some formatting > issue. Mailman implements certain MIME structure manipulations as a per-list policy setting. Specifically, as a simple antivirus and resource conservation measure, disallowed MIME types are removed. I think this is a deal-breaker for DKIM signatures, as MTAs aren't supposed to break into MIME structure, and I don't think most sites want their users doing signatures in the MUA. But there is exactly one case where Mailman tries to fix up content for formatting: at the list owner's option, if the only text part is text/html, an external utility (usually lynx) may be used to convert it to atext/plain. There are third party patches that actually try to manipulate formatted text. A typical example is one to allow the footer to be added *inside* the BODY element of a text/html part. But AFAIK none have made into the mainline. From nobody Thu Jun 5 06:11:06 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C521A024F for ; Wed, 4 Jun 2014 10:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 P03gKUxn2HSv for ; Wed, 4 Jun 2014 10:49:01 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECA691A0312 for ; Wed, 4 Jun 2014 10:48:57 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id r20so1976597wiv.3 for ; Wed, 04 Jun 2014 10:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KccOmG6GIm2sKTD+cEA0kSLPPHlEkgQFKRZC94hmPto=; b=esdWY21+gI96D+RiMlhS5gFhfYV673vz2CqBUHtWe+UuckZcABRcR5mF78YRsd5kyv IE3yAhe9VnG9RFgi9C1XkJdpL7BX5PmgXKJxRNL39VbgicRfGXaTQgomxZ5N872w/tpy 7UAjRPO8Krb91+WOuXQk1Dy9D3g8RXlrwhZW8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KccOmG6GIm2sKTD+cEA0kSLPPHlEkgQFKRZC94hmPto=; b=UAS32kXg5WeNykD0FpfmFUKGWio5hOuZbKl6cPPF+LWKulxGLoIMGp+GVh5O9zhsBc ahU3gox/GofaFZsmi9RMpKKJyuGWKracQ7aaBo3jaSi5A0urriW6M1xSsYxFt6PpCPmG z+kXS/OKw6+QXq0DeuRstl+iTewlfAXl2kDSLsCWWSka8KTEABrtJddtz5rLybJSnaWC 1WVYT90BmIoy2r/RSktJEveEZPP1bOyuZYLJgfzBtjAJ7lS01X8RUTws92HNlrgQXIEQ LC+30ASivKlLWfJD3RxqGiS2wdgGpV2+gsI7lYN2jY7ozIVcl82l49QkWGvrSqqS6S3A P72A== X-Gm-Message-State: ALoCoQmzj+6hHeLltgw4Ai7mPa/hxZmplDmg42l8Qv7xU3BKKNaBCeY0pnKxtaVw/we0VcXjzGfX MIME-Version: 1.0 X-Received: by 10.194.87.200 with SMTP id ba8mr73672189wjb.28.1401904130735; Wed, 04 Jun 2014 10:48:50 -0700 (PDT) Received: by 10.194.235.164 with HTTP; Wed, 4 Jun 2014 10:48:50 -0700 (PDT) In-Reply-To: <87y4xc370r.fsf@uwakimon.sk.tsukuba.ac.jp> References: <538A76ED.4050609@att.com> <8738fn6a96.fsf@uwakimon.sk.tsukuba.ac.jp> <55382129.27361.1401740317786.JavaMail.zimbra@peachymango.org> <87r4363wpn.fsf@uwakimon.sk.tsukuba.ac.jp> <610286136.61974.1401841787613.JavaMail.zimbra@peachymango.org> <8761kg52xe.fsf@uwakimon.sk.tsukuba.ac.jp> <87y4xc370r.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Wed, 4 Jun 2014 10:48:50 -0700 Message-ID: From: Kurt Andersen To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=089e010d8afeb8d87b04fb063d0b Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/9AUt4F0blnES8QEFztHkyo7OrEE X-Mailman-Approved-At: Thu, 05 Jun 2014 06:11:00 -0700 Cc: Kurt Andersen , Tony Hansen , "dmarc@ietf.org" , Hector Santos , Franck Martin Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 04 Jun 2014 17:49:02 -0000 --089e010d8afeb8d87b04fb063d0b Content-Type: text/plain; charset=UTF-8 On Wed, Jun 4, 2014 at 10:43 AM, Stephen J. Turnbull wrote: > Nor does DMARC say it's nonconforming; in fact, it automatically > passes identity alignment, because there's nobody who is allowed to > create domains under .invalid, so there can be no _dmarc.x.y.invalid. > Actually, it does not and can not pass alignment. The alignment status is undefined which is neither a pass nor a fail. --Kurt Andersen --089e010d8afeb8d87b04fb063d0b Content-Type: text/html; charset=UTF-8
On Wed, Jun 4, 2014 at 10:43 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
Nor does DMARC say it's nonconforming; in fact, it automatically
passes identity alignment, because there's nobody who is allowed to
create domains under .invalid, so there can be no _dmarc.x.y.invalid.

Actually, it does not and can not pass alignment. The alignment status is undefined which is neither a pass nor a fail.

--Kurt Andersen
--089e010d8afeb8d87b04fb063d0b-- From nobody Thu Jun 5 10:03:15 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818C21A01F6 for ; Thu, 5 Jun 2014 10:03:13 -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 17W2KB_3l8dK for ; Thu, 5 Jun 2014 10:03:12 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 433101A0239 for ; Thu, 5 Jun 2014 10:03:10 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id w10so1350381pde.0 for ; Thu, 05 Jun 2014 10:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=L93jJQcqpf4g+ZNYLR+NlNh0uladu4eO/EEg1cnfgiM=; b=Qo19UALDenerYcRHFwGFtamm1/RZA0n8e+OXP9UmqZGDdHzYa1INuoL3rChvrvmdZB ca4tpTMusnC9LGxxwUxeVFf30yxsD+7cqJDTQKGylksgXkMwgIMUkkfqeMh0RWDqXCYV eaRKnf3u/oiN1i3Ghfn6ZLWLYmUU6aQq3SN3uNEZNaSD6FHgUDnMJhAs3PMfz39WAeDM 7FjBtfMXYIEyz75gLMH8A3ZQfhiEf4yQ+dhITp/u8WJ6UmbMBzDo4el1UBclphta0GAv CLOC/qljv5nT/gLdyNz+m8Ytqkc+XXtUWSDziPlYR/H1fSbZPJnAW3oJuQ8PCjzn4w/s Rn4A== X-Received: by 10.68.194.202 with SMTP id hy10mr79469846pbc.94.1401987783799; Thu, 05 Jun 2014 10:03:03 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id qf10sm24999005pbc.23.2014.06.05.10.03.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Jun 2014 10:03:03 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=iso-8859-1 From: Douglas Otis X-Priority: 3 In-Reply-To: <7441626507D0487CB262F447C2E5A843@fgsr.local> Date: Thu, 5 Jun 2014 10:03:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3C71FB24-AAE8-4455-9356-3EA7248E8791@gmail.com> References: <5387F6E0.1070903@att.com> <87ha456dlt.fsf@uwakimon.sk.tsukuba.ac.jp> <538A76ED.4050609@att.com> <8738fn6a96.fsf@uwakimon.sk.tsukuba.ac.jp> <55382129.27361.1401740317786.JavaMail.zimbra@peachymango.org> <87r4363wpn.fsf@uwakimon.sk.tsukuba.ac.jp> <538E48C1.2020707@isdg.net> <82F820F43C124B2E9F86D4AA01BC43D1@fgsr.local> <7441626507D0487CB262F447C2E5A843@fgsr.local> To: "J. Gomez" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/gYClNezgTZwXerdCuKN3b2ho8Ak Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 05 Jun 2014 17:03:13 -0000 On Jun 4, 2014, at 3:07 PM, J. Gomez wrote: > On Wednesday, June 04, 2014 10:56 PM [GMT+1=3DCET], Douglas Otis = wrote: >=20 >> On Jun 4, 2014, at 12:16 PM, J. Gomez wrote: >>=20 >>> On Wednesday, June 04, 2014 12:14 AM [GMT+1=3DCET], Hector Santos >>> wrote:=20 >>>=20 >>>> I prefer to update my software with the above script for our MTA >>>> receiver rather to add logic to rewrite the 5322.=46rom to bypass a >>>> security protocol >>>=20 >>> Rewriting the Header-=46rom field in mailing list traffic is not >>> "bypassing a security protocol", because the rewritten Header-From >>> itself still is subject to the security protocol (in this case, >>> DMARC checking) at the Receiver's side, so the security protocol in >>> question is not bypassed. =20 >>=20 >> Customers seeing =46rom headers changed will not have a practical = means >> to understand who sent the message. Of course, this assumes who >> initiated content in an exchange is a critical aspect of any security >> related goal. For mailing-lists, this understanding is critical to >> being able to review conversations as well. >=20 > If the rewritten Header-=46rom references the remote author Name in = its description and carries the mailing list Mailbox address (i.e., the = immediate author who invalidated the remote author's DKIM signature) in = the Header-From, I posit customers will have a practical means to = understand who sent the message through said mailing list. In fact, many = MUAs only display de Header-=46rom description/name and not the = Header-=46rom mailbox address to the user, so even less confusion would = be possible in those cases. >=20 > Plus, a mailing list is an opt-in device. If the user chooses to be = part of it, he accepts the mailing list terms of service, and if those = terms involve rewriting Header-=46rom in a DMARC-interoperable way, then = that's what it is. The user is free to not use the mailing list service = operated thusly if he objects to such a practice. What tools will recipients have for relating a plethora of re-writing = techniques to then review both current and prior conversations? In = addition, this may take once secure messages that may have had alignment = with the Sender header field and damage a DKIM signature which MUST = include the =46rom header field. Once the =46rom header field is = "rewritten" to comply with a "non-compliant DMARC scheme" unable to = accommodate perfectly legitimate RFC conforming messages, the receiver = and recipient alike are left guessing. =20 IMHO, re-writing schemes to not represent practical solutions, just very = poorly considered bandaids. >> If it is critical, have the TPA-Label require the OAR be checked.=20 >> This can be quickly added if that is the hold-up=20 >=20 > I, as a domain owner, do not want to go chasing my users around = demanding them to declare to me what mailing lists they subscribe to, in = order to publish them as whitelists/exceptions for my domain as a = Sender. What if I have a user subscribed to a transgender/whatever = mailing list? Do I want to know? Does he want to tell me? I as a domain = owner either trust my user, or fire my user, but I don't want to have to = preemptively monitor my user not do I want him to disclose to me the = minutiae of his email usage. If TPA-label involves this, I see no future = in it.[*] As a domain owner, you would be doing your users a valuable service by = making an effort to exclude rogue sources while avoiding what should be = clearly evident normal use. If you feel this opens the door too wide, a = ORA condition in TPA-Label can be added for when such problems occurs. = One might assume there is a desire to ensure delivery of 100% legitimate = AND desired messages and not NOT alter messages. > [*] But it may well be that TPA-label works in a completely different = way, I tried to read the draft but I could not understand much of it = (therefore my Klingon joke, for which I apologize to you). I have made a few changes to the draft hoping to make it easier to = understand. If you read it again and still have trouble, please = indicate where and I'll make another pass. The basic goal is to devise a means to establish information federations = of domains with the goal of not altering messages. With this goas and = therefore can be assumed to protect the underlying identities. Once a = message is re-written by an unknown third-party, nothing can be trusted. = Very soon, domains will be the only practical means to follow chains of = trust. Domains that are making use of DMARC are receiving valuable = feedback that should help avoid any need to ask users about which = services they are using, especially those reported as not passing an = alignment test. Before throwing the switch to p=3Dreject, the provider = should make their best effort to ensure no legitimate email is lost and = that no message is modified just to suit a non-compliant DMARC scheme. = A fully transparent informal federation scheme will provide fCall this = the emailmen's credo. :^) Regards, Douglas Otis From nobody Thu Jun 5 11:15:20 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B691A01A0 for ; Thu, 5 Jun 2014 11:15:17 -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 o6-R0oaasFc2 for ; Thu, 5 Jun 2014 11:15:16 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF14F1A0144 for ; Thu, 5 Jun 2014 11:15:16 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id w10so1418561pde.28 for ; Thu, 05 Jun 2014 11:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version; bh=K1CngUVBwStaF9uVVZ+dvQ+yPZFAh7EcSjYwnpVbAqY=; b=aHychnxWJ+/mCM5jxA9zZPResNHrEuiGJAF0NUIsf5vVUkgfym+/9C2K3UprAgh9kr TrcbeYYfAx4/rfk0rJSxMSDTN5y1achOY2yRHC6LO//A16HmAmLaKnxeTWzJzl9ePqPB pH8PtT9gEdnXA6BWQSN7h6Ky0vRGH38O5LdZGOLM8x6aAtoVvAt4O+ZgEh4ZJEfD1N/2 TA5ZaLRoYTuBp4B/yqV6d8x14TG4TX2XlQR3B+PPlIfjLTwSkwyjTFtx1ml/XavuuQHh XXBPJ+ZCBQHyda+S+XdczC/ilDAEXurjJKOj3n28S1RWr9hJO4g2ToAtpAnFdopLLauI e1Ug== X-Received: by 10.68.202.194 with SMTP id kk2mr78563626pbc.156.1401992110282; Thu, 05 Jun 2014 11:15:10 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id ei4sm25572847pbb.42.2014.06.05.11.15.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Jun 2014 11:15:09 -0700 (PDT) From: Douglas Otis Content-Type: multipart/alternative; boundary="Apple-Mail=_E52EE2AC-8771-458B-86FA-18EC36B6F8D1" Date: Thu, 5 Jun 2014 11:15:07 -0700 Message-Id: <70F8CF9F-2FDD-4CA6-8B52-522953EB4633@gmail.com> To: "J. Gomez" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/oQSgPnDJ2rWY03TGRplOOaKezow Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DKIM through mailing lists (rebutting MLs won't change) 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, 05 Jun 2014 18:15:17 -0000 --Apple-Mail=_E52EE2AC-8771-458B-86FA-18EC36B6F8D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear J. Gomez, Oops. Multi-tasking too much between conversations it seems. This is what was intended in the last paragraph. The basic goal is to devise a means to establish informal federations of = domains with a goal of not altering messages. With this goal, it can = therefore be assumed to protect the underlying identities. Once a = message is re-written by a third-party with an unknown relationship, = nothing can be trusted. Very soon, domains will be the only practical = means to follow chains of trust. Domains that are making use of DMARC = are receiving valuable feedback that should help avoid any need to ask = users about which services they are using, especially those reported as = not passing an alignment test. Before throwing the switch to p=3Dreject, = the provider should make their best effort to ensure no legitimate email = is lost and that no message is modified just to suit a non-compliant = DMARC scheme. A fully transparent informal federation scheme will = provide this feature by making use of TPA-Labels. Regards, Douglas Otis= --Apple-Mail=_E52EE2AC-8771-458B-86FA-18EC36B6F8D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Dear J. Gomez,

Oops. Multi-tasking too much between = conversations it seems.

This is what was intended in the last = paragraph.

The basic goal is to devise a means = to establish informal federations of domains with a goal of not altering = messages.  With this goal, it can therefore be assumed to protect = the underlying identities.  Once a message is re-written by a = third-party with an unknown relationship, nothing can be trusted. =  Very soon, domains will be the only practical means to follow = chains of trust.  Domains that are making use of DMARC are = receiving valuable feedback that should help avoid any need to ask users = about which services they are using, especially those reported as not = passing an alignment test.  Before throwing the switch to p=3Dreject,= the provider should make their best effort to ensure no legitimate = email is lost and that no message is modified just to suit a = non-compliant DMARC scheme.  A fully transparent informal = federation scheme will provide this feature by making use of = TPA-Labels.

Regards,
Douglas = Otis
= --Apple-Mail=_E52EE2AC-8771-458B-86FA-18EC36B6F8D1-- From nobody Thu Jun 5 13:22:15 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1A81A0302 for ; Thu, 5 Jun 2014 13:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 HpMAdoYm5xzD for ; Thu, 5 Jun 2014 13:22:10 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66CC11A0262 for ; Thu, 5 Jun 2014 13:22:09 -0700 (PDT) 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; Thu, 5 Jun 2014 22:22:01 +0200 Message-ID: <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> From: "J. Gomez" To: Vlatko Salaj References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> Date: Thu, 5 Jun 2014 22:22:20 +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: http://mailarchive.ietf.org/arch/msg/dmarc/nyBhVi-mPcS1gko4ynEJxhTPlKo Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 05 Jun 2014 20:22:12 -0000 On Thursday, June 05, 2014 9:35 AM [GMT+1=3DCET], Vlatko Salaj wrote: > it seems to me that many of DMARC defenders don't understand > main points of proposed 3rd party solutions, confusing them > for ML solutions, and thus dismissing them altogether. (...) >=20 > ps. to state an example, if anybody doesn't get it. > i have trust in ymail to send email on behalf of my domain, > and i want a way to state that in my DMARC policy. Thanks for the example, makes it so much clearer. For that use case, you should do an SPF-include of Yahoo's SPF inside = your own SPF record. Yes, provided Yahoo had any SPF at all (which they = did not until very recently), and also provided the included-SPF already = involved less that 10 DNS-queries. If those conditions were false, I would take it as an implied = declaration from ymail that your use case is not welcome with them, so = why force the issue with them? Regards, J.Gomez From nobody Thu Jun 5 14:13:13 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398811A02CC for ; Thu, 5 Jun 2014 14:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 L0l05gRHwGta for ; Thu, 5 Jun 2014 14:13:10 -0700 (PDT) Received: from nm34.bullet.mail.ne1.yahoo.com (nm34.bullet.mail.ne1.yahoo.com [98.138.229.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6199D1A02BF for ; Thu, 5 Jun 2014 14:13:10 -0700 (PDT) Received: from [127.0.0.1] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 05 Jun 2014 21:13:03 -0000 Received: from [98.138.100.102] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 05 Jun 2014 21:10:11 -0000 Received: from [216.39.60.184] by tm101.bullet.mail.ne1.yahoo.com with NNFMP; 05 Jun 2014 21:10:11 -0000 Received: from [98.137.12.232] by tm20.bullet.mail.gq1.yahoo.com with NNFMP; 05 Jun 2014 21:10:10 -0000 Received: from [127.0.0.1] by omp1040.mail.gq1.yahoo.com with NNFMP; 05 Jun 2014 21:10:10 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 922372.51106.bm@omp1040.mail.gq1.yahoo.com Received: (qmail 26332 invoked by uid 60001); 5 Jun 2014 21:10:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402002610; bh=bDyZSIxvKHfUcCsN3+lPdPa187bb+111cNLt27vmzwo=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=MlMAkq+A+fIMbkm4Qflfe1mkImnVG/p1rU6ywAzN6523yvQuO64fjpx/GyJxg+3NQy1ggfg5IOHRoytZqT5BFYQEvSCt92AEpijJ55vcNK+mcEHSVGsaETM0DESsnf63hMWWrvEx363rUKLRze8K4NukUTSDR1WyhiwNcOyr2eY= X-YMail-OSG: GrwrQLUVM1m7ZHd62MmBQMfiVSVlD.0pL8ZofVA3xN9XNrm eOEpPOcAzclZTDLLOCkVkzMgQbElBuLvrB2WBFOWpfIoZFRngGrJb0rCZ2bs wi7IwIepZgMvtrDMRvRx5WM1JJ4f2F6y9U27Lb.A8zhUMEq7HWD2mHEeQ6R8 owL7DYeRMZM.OaaQnMIiJcG8qzgvMT6YoSUL_tNDx7o1AvSWZ5jL9jgg7VHs fPGAzHpCk8Q_.knvWgETKVZJL7hgkVPUHIY4qb2tae53UrXaQVqQdyYZQiLc BK94HWRQofxq2xw9GeDZQsd9idMFfAKRtU_M1oHsrG88nm0bg3wJufxm9wPa HSOC2ytBWhPdmYxjWT_SpzqZwIJDKv61JMQDpLvag_LwJ6r39KtC9d9utpHq AKZs_FxuVE8dh9DrfUhZCb3V1i8jOHDo1xWUdCZmJ8GzDc7O2YEXVwY2Dhcq ycFyaQh4audbfQHzZYJuhj9KW8LBwPm08gPZEE.TxTnVGL5SglO1NbP2wfZe JQIDHGTzjsG5WKZWsWDRxS9Y5TP6eweQcS8h4Vl8fNUp28hOYRYKauVSOvzi qzG8.ALEeu3bKAIG169p1bT6v3BkahsbYMPOHAmUmD_VQTmQkway.LTPmfxR d0S7d9.fEMdfkaEYnSgieFb1xl1brYCZ_LC8- Received: from [79.175.117.203] by web164601.mail.gq1.yahoo.com via HTTP; Thu, 05 Jun 2014 14:10:10 PDT X-Rocket-MIMEInfo: 002.001, T24gVGh1cnNkYXksIEp1bmUgNSwgMjAxNCAxMDoyMiBQTSwgSi4gR29tZXogPGpnb21lekBzZXJ5cmljaC5jb20.IHdyb3RlOgoKPj4gcHMuIHRvIHN0YXRlIGFuIGV4YW1wbGUsIGlmIGFueWJvZHkgZG9lc24ndCBnZXQgaXQuCj4.IGkgaGF2ZSB0cnVzdCBpbiB5bWFpbCB0byBzZW5kIGVtYWlsIG9uIGJlaGFsZiBvZiBteSBkb21haW4sCj4.IGFuZCBpIHdhbnQgYSB3YXkgdG8gc3RhdGUgdGhhdCBpbiBteSBETUFSQyBwb2xpY3kuCj4gRm9yIHRoYXQgdXNlIGNhc2UsIHlvdSBzaG91bGQgZG8gYW4gU1BGLWkBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> Message-ID: <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> Date: Thu, 5 Jun 2014 14:10:10 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" In-Reply-To: <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ZMbJ2CROVeNmiLEv3F7kZJW7FBM Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 05 Jun 2014 21:13:12 -0000 On Thursday, June 5, 2014 10:22 PM, J. Gomez wrote: >> ps. to state an example, if anybody doesn't get it. >> i have trust in ymail to send email on behalf of my domain, >> and i want a way to state that in my DMARC policy. > For that use case, you should do an SPF-include of Yahoo's SPF > inside your own SPF record. nope, that doesn't work. ESPs send email using account's original address during SMTP MAIL FROM, not user's 3rd party address. in my case that's @yahoo.com, not @goodone.tk. and that's perfectly regular and quite logical, since that's the address that is transmitting email. it would be wrong for any ESP to claim they send email for a domain they don't control. only domain-owner can do that. however, while DMARC was created exactly for something like that [domain owners specifying how they want their mail treated], it doesn't offer such choice. so, ur suggestion just shows how DMARC ppl don't understand wide scale of broad email usage scenarios. if DMARC had Sender-ID as one of underlying protocols, sure, that would work, since Sender-ID does PRA processing, which covers bunch of these scenarios, including ML, forwarding, broad 3rd party, whatever... however, for the sake of this discussion, it's obvious DMARC MUST include some 3rd party support, or it will be a failure at the end, as much as many previous policy attempts, now merely historic references. and, btw, i do have ymail in my domain's SPF. it's there for Sender-ID compatibility. not that it matters for this discussion. currently, DMARC rigidity excludes my usage scenario, and that's wrong. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Thu Jun 5 14:42:32 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1286C1A0292 for ; Thu, 5 Jun 2014 14:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 NS7vI36uKPwJ for ; Thu, 5 Jun 2014 14:42:25 -0700 (PDT) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50EF51A026D for ; Thu, 5 Jun 2014 14:42:25 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id at1so1310169iec.3 for ; Thu, 05 Jun 2014 14:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jGAiCCvsg8VsYF+KogDMfvmmblJkw7NFy0ry2acL6/g=; b=PQarLJcCEynl7i3YsW1Ojswp2kmNq/jdVj9AWKoUr4g/5NV/6CWrX9937t/JiWtqgB 58dqlMyPgjzu6b3bl7sLpHjaIL93jFckulsjRjuSnyvqqNn4f2qMqDUaXiPK8N8+XPCY q0ZUIDBoWwJYOMmZxM0bTPfa4Zt2yzs+yB+iI5wtNpNuQ48SkE8sEet/Wg/bEcgtr7A+ 9SMoqEKQ1oHMQvXhhJFmPTtH/TYqwV5QzEKzATJUnSo7+F2whN1DDeuAeFJBMDLQXpku vFtsRl6SAVnLhTj19DHrNBMLFP9UFcnnhJ6+/jfOFhLhcQy+UttWtPW8c7PMKSarxt2x ebJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jGAiCCvsg8VsYF+KogDMfvmmblJkw7NFy0ry2acL6/g=; b=JEDTJ0EK7V5CUnpDwqJHqQ3oq0lt9XRFIdQd22mgoltFzyEnSn+CfIoF3avQYQeGQx A532RwTQ7AbejjI9PyhJ99m9GHjLjciLtF2cnCF5aGwzaHchS9VN62K5mmF2BDupIczW 6/sH/vNAhKMGfdb/aGy8GgBJy2eXOe0CMovEKow35uB2fWTBx9mDU787Qbslf8mz0IKL UijNVC+X6gFaqlOTRVwW015ed1VCfX55vwVw8zSvJ0ncfmcBHtg3KMbEVy56FIh4tO7V w5vwnR7oyHTFGdZC7wmQ92aGM6CsjpVcKrtdr9N6jEJCRvBS5Euxsru5C5LZ1MXhKhrD Vgcg== X-Gm-Message-State: ALoCoQnDKvjPdrABsVDubIkLC80uMcNwMgA3HUbmCUGufPf88AGdSU3i3sUKJMWpsCDri47sU+A2 MIME-Version: 1.0 X-Received: by 10.50.79.131 with SMTP id j3mr24577778igx.23.1402004538390; Thu, 05 Jun 2014 14:42:18 -0700 (PDT) Received: by 10.64.213.73 with HTTP; Thu, 5 Jun 2014 14:42:18 -0700 (PDT) In-Reply-To: <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> Date: Thu, 5 Jun 2014 14:42:18 -0700 Message-ID: From: Brandon Long To: Vlatko Salaj Content-Type: multipart/alternative; boundary=089e011609f47c502504fb1d9ebd Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/K5w36VjcuF5nozY4E0GWTHWIxqE Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 05 Jun 2014 21:42:30 -0000 --089e011609f47c502504fb1d9ebd Content-Type: text/plain; charset=UTF-8 Let me see if I understand this... you want to be able to use a strong DMARC setting for your domain, and let YMail send mail on behalf of your domain? Most here are arguing against using strong DMARC settings for personal use cases, you are arguing for 3rd party support because you do want to use DMARC? For consumer Gmail, you'd have one option, to set up outbound-msa and have your email go through your own mail server to be signed or allow the envelope sender to align for SPF. For Google Apps, you have several more options, including giving us a dkim key for your domain that we'll use to sign your messages, or smarthosting and other advanced routing options for using your own mail server (or a third party server). Theoretically, we could include a DKIM signature option for consumer Gmail, but that seems like a 1% of 1% feature that's unlikely to be much use. There's an argument for having a "Gmail for your own domain" product, but the more one looks at that, the more it ends up being Google Apps. Its unfortunate that TPTB removed the free version of GAFYD. Even if something like TPA-labels was established to give third parties permission, I'm not clear if/how that would affect YMail/Gmail's handling of "custom from", "allow custom from if TPA-Label exists at send time"? Brandon On Thu, Jun 5, 2014 at 2:10 PM, Vlatko Salaj wrote: > On Thursday, June 5, 2014 10:22 PM, J. Gomez wrote: > > >> ps. to state an example, if anybody doesn't get it. > >> i have trust in ymail to send email on behalf of my domain, > >> and i want a way to state that in my DMARC policy. > > For that use case, you should do an SPF-include of Yahoo's SPF > > inside your own SPF record. > > nope, that doesn't work. ESPs send email using account's > original address during SMTP MAIL FROM, not user's 3rd > party address. in my case that's @yahoo.com, not @goodone.tk. > > and that's perfectly regular and quite logical, since > that's the address that is transmitting email. it would > be wrong for any ESP to claim they send email for a domain > they don't control. only domain-owner can do that. > > however, while DMARC was created exactly for something > like that [domain owners specifying how they want their > mail treated], it doesn't offer such choice. > > so, ur suggestion just shows how DMARC ppl don't > understand wide scale of broad email usage scenarios. > > if DMARC had Sender-ID as one of underlying protocols, > sure, that would work, since Sender-ID does PRA processing, > which covers bunch of these scenarios, including ML, > forwarding, broad 3rd party, whatever... > > however, for the sake of this discussion, it's obvious > DMARC MUST include some 3rd party support, or it will be > a failure at the end, as much as many previous policy > attempts, now merely historic references. > > and, btw, i do have ymail in my domain's SPF. it's there > for Sender-ID compatibility. not that it matters for this > discussion. > > currently, DMARC rigidity excludes my usage scenario, and > that's wrong. > > > -- > Vlatko Salaj aka goodone > http://goodone.tk > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --089e011609f47c502504fb1d9ebd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Let me see if I understand this... you want to be able to = use a strong DMARC setting for your domain, and let YMail send mail on beha= lf of your domain?

Most here are arguing against using s= trong DMARC settings for personal use cases, you are arguing for 3rd party = support because you do want to use DMARC?

For consumer Gmail, you'd have one option, to set u= p outbound-msa and have your email go through your own mail server to be si= gned or allow the envelope sender to align for SPF.

For Google Apps, you have several more options, including giving us a = dkim key for your domain that we'll use to sign your messages, or smart= hosting and other advanced routing options for using your own mail server (= or a third party server).

Theoretically, we could include a DKIM signature option= for consumer Gmail, but that seems like a 1% of 1% feature that's unli= kely to be much use. =C2=A0There's an argument for having a "Gmail= for your own domain" product, but the more one looks at that, the mor= e it ends up being Google Apps. =C2=A0Its unfortunate that TPTB removed the= free version of GAFYD.

Even if something like TPA-labels was established to gi= ve third parties permission, I'm not clear if/how that would affect YMa= il/Gmail's handling of "custom from", "allow custom from= if TPA-Label exists at send time"?

Brandon




On Thu, Jun 5, 2014= at 2:10 PM, Vlatko Salaj <vlatko.salaj@goodone.tk> wr= ote:
On Thursday, June 5, 2014 10= :22 PM, J. Gomez <jgomez@seryrich= .com> wrote:

>> ps. to state an example, if anybody doesn't get it.
>> i have trust in ymail to send email on behalf of my domain,
>> and i want a way to state that in my DMARC policy.
> For that use case, you should do an SPF-include = of Yahoo's SPF
> inside your own SPF record.

nope, that doesn't work. ESPs send email using account's
original address during SMTP MAIL FROM, not user's 3rd
party address. in my case that's @yahoo.com, not @goodone.tk.

and that's perfectly regular and quite logical, since
that's the address that is transmitting email. it would
be wrong for any ESP to claim they send email for a domain
they don't control. only domain-owner can do that.

however, while DMARC was created exactly for something
like that [domain owners specifying how they want their
mail treated], it doesn't offer such choice.

so, ur suggestion just shows how DMARC ppl don't
understand wide scale of broad email usage scenarios.

if DMARC had Sender-ID as one of underlying protocols,
sure, that would work, since Sender-ID does PRA processing,
which covers bunch of these scenarios, including ML,
forwarding, broad 3rd party, whatever...

however, for the sake of this discussion, it's obvious
DMARC MUST include some 3rd party support, or it will be
a failure at the end, as much as many previous policy
attempts, now merely historic references.

and, btw, i do have ymail in my domain's SPF. it's there
for Sender-ID compatibility. not that it matters for this
discussion.

currently, DMARC rigidity excludes my usage scenario, and
that's wrong.


--
Vlatko Salaj aka goodone
http://goodone.tk

_____________________________= __________________
dmarc mailing list
dmarc@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dmarc

--089e011609f47c502504fb1d9ebd-- From nobody Thu Jun 5 15:44:08 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA871A02CC for ; Thu, 5 Jun 2014 15:44:06 -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 TcvmSek4cdLO for ; Thu, 5 Jun 2014 15:44: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 1DB751A02B5 for ; Thu, 5 Jun 2014 15:44:04 -0700 (PDT) Received: (qmail 64890 invoked from network); 5 Jun 2014 22:43:57 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 5 Jun 2014 22:43:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=16bf.5390f2ad.k1406; i=johnl@user.iecc.com; bh=0SjBmMI0m5twDvz+mGHAHAoAMhRuNXUb3RTxzVLs4BM=; b=gTlC37Ld9U6rmQCXdk0s+ykgfGdxgpcnJEcn/s3KY5Az21Sl1d4zKeVv4Ea4M55tfS4wFszv1K+tmY9W3GLD+ugiSNRSYqe6VjIzJl+PjG0kPnry5JrnrhtTLv0WmwoIJq1X3lkSKmG2kE2M2ikBnYB6H0DcgVrUMMFDcYgJwniIYavavlSZdseX5L+FwYfJcPBFK3McGA5vS/zZ203xhb3y/V3/eVNgcSmcbW8d+6iyagGXwB7NnoU1B6PNWjYQ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=16bf.5390f2ad.k1406; olt=johnl@user.iecc.com; bh=0SjBmMI0m5twDvz+mGHAHAoAMhRuNXUb3RTxzVLs4BM=; b=lGMzLrbddgGp8OFaZKlv69Fz1XTE/3b5RW5748y1wH8xWV95vr8eCUoLsDAfW/aZ5iQfWU/Y6K6ZneUhxZ0seHL18oxrVY22HmvEwAqWSkHBQCFmC0RVbOmZJ2D+LdJNH7iD8i6+LwZMhHFsgkRk7SUd5iq4IRGgSeWx2mj3LE3wvdd5NI7j6varCJuu82dQwdN87qeTPGJ630Y5I600o604GKKqoLa1WX6+omRQWDoQuD2+0/pt83H3pg+kamMd Date: 5 Jun 2014 22:43:35 -0000 Message-ID: <20140605224335.5822.qmail@joyce.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: http://mailarchive.ietf.org/arch/msg/dmarc/xFTG-L2wwFoKvKYxjD6AmWz6Zto Cc: blong@google.com Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 05 Jun 2014 22:44:06 -0000 In article you write: >-=-=-=-=-=- >-=-=-=-=-=- > >Let me see if I understand this... you want to be able to use a strong >DMARC setting for your domain, and let YMail send mail on behalf of your >domain? I think the use case here is for hosted mailing lists for small entities. I was on a call with some ESPs the other day, and they said the number of lists for church groups and scout troops and the like is huge, most of them use the list owner's individual e-mail address at a consumer ISP or mail provider, and in most cases there is no practical way for them to use an address in their organization's "official" domain. This is somewhat different from discussion lists since the messages typically originate from a web form at the ESP, not the author's mail provider, so O-A-R approaches don't work since there's no O to A. It's a real issue. All of the solutions scale pretty badly, but approaches that start by enumerating reasonably trustworthy ESPs seem less awful than something that requires cooperation from the users' mail providers. R's, John From nobody Thu Jun 5 15:47:35 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABFA1A02B5 for ; Thu, 5 Jun 2014 15:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 qju58K90lGmt for ; Thu, 5 Jun 2014 15:47:31 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C927E1A025B for ; Thu, 5 Jun 2014 15:47:31 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id at20so1383649iec.39 for ; Thu, 05 Jun 2014 15:47:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JIXmYyX2yzPEkDZyICGlavs85bxiFyA/HZZqUd08qLU=; b=XEW7o8bppDcGud9LjC7P8bqkMoh39GsbpRkhwksVsCrzfjbpTUPQDnxUZJp+gGgLz4 PiixODoXMLwUqs23qkuGkzetnVVaPunkW+GADyma40Zdsumm4dlHOvDOApNoJ70xTeCt COiq63U+FoswfHHwnrqe+EOYnhvN56zjvD6xmnCVAM8Wf3t7XOMNwWOUBAByZsLCz9fW 5UoHONaPd/77BJcrFc/eUhpAwMQT9V3IFOiBnqm2aTNXE5EQEST+j4OaHXLog2xuxzY4 nOEfWtsOh/XR76Byin/p34ItfcfRAg2g1vg6aPm7sfzaV/rd1m+RyJ7IHUqO8f/A5zEl RNvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JIXmYyX2yzPEkDZyICGlavs85bxiFyA/HZZqUd08qLU=; b=R9ZiW4d/ZamHdiqRP9m8YI2hzOl2kwCUjvNaYODCNTJQ+5A1T0EqbX4odiQqCyd/9S dhQAzDGqWrXfJMMQUdWiqhPCpwKtK3eQeV7aseGk3iME6xgSBB50FyZKyjC685IzpPV7 rIkZM3GiKEo56ygBuWRNlrXg85MnkLjstn5QavQ9zyj1j5S6QnD4+3vQmOYZSgbHMJ2+ wZBs2AyioonSKbP5UWC0s24biNGXgMFWyUDO1kcfVXsJTe6Tk5rnofIxqaRoEGkaXsHH BBmFc48EaToXcPUYkXtc8x/aL/VzkvPLutCPCPxiC94KMgokYU1nxvmble5fOZUD7+62 H5zQ== X-Gm-Message-State: ALoCoQkkMFsKUVGHDjymhy7nzseUFDTC22V+3VzS/rdaEBdo2f8QfAdgIU8rFb/4KQ5eLmpvf8N7 MIME-Version: 1.0 X-Received: by 10.50.111.161 with SMTP id ij1mr2892240igb.12.1402008445112; Thu, 05 Jun 2014 15:47:25 -0700 (PDT) Received: by 10.64.213.73 with HTTP; Thu, 5 Jun 2014 15:47:24 -0700 (PDT) In-Reply-To: <20140605224335.5822.qmail@joyce.lan> References: <20140605224335.5822.qmail@joyce.lan> Date: Thu, 5 Jun 2014 15:47:24 -0700 Message-ID: From: Brandon Long To: John Levine Content-Type: multipart/alternative; boundary=047d7b3a8a6258001704fb1e87f6 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/0cGQWAz7rlQU3D94eJq9ruobVx0 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 05 Jun 2014 22:47:33 -0000 --047d7b3a8a6258001704fb1e87f6 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 5, 2014 at 3:43 PM, John Levine wrote: > In article < > CABa8R6ttzt+Vtv4oQVX-S7DEsV+cU72Xm9-pcAZt3+M6eCbPHw@mail.gmail.com> you > write: > >-=-=-=-=-=- > >-=-=-=-=-=- > > > >Let me see if I understand this... you want to be able to use a strong > >DMARC setting for your domain, and let YMail send mail on behalf of your > >domain? > > I think the use case here is for hosted mailing lists for small > entities. I was on a call with some ESPs the other day, and they said > the number of lists for church groups and scout troops and the like is > huge, most of them use the list owner's individual e-mail address at a > consumer ISP or mail provider, and in most cases there is no practical > way for them to use an address in their organization's "official" > domain. This is somewhat different from discussion lists since the > messages typically originate from a web form at the ESP, not the > author's mail provider, so O-A-R approaches don't work since there's > no O to A. > > It's a real issue. All of the solutions scale pretty badly, but > approaches that start by enumerating reasonably trustworthy ESPs seem > less awful than something that requires cooperation from the users' > mail providers. > So, this is the constantcontact or announce list solution, ie instead of just using their mail client directly (possibly because of sending limits)? Brandon --047d7b3a8a6258001704fb1e87f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Jun 5, 2014 at 3:43 PM, John Levine <<= a href=3D"mailto:johnl@taugh.com" target=3D"_blank" class=3D"cremed">johnl@= taugh.com> wrote:
In article <CABa8R6ttzt+Vtv4oQVX-S7DEsV+cU72Xm9-pcAZt3+M6eCbPHw@mail.gmail.com= > you write:
>-=3D-=3D-=3D-=3D-=3D-
>-=3D-=3D-=3D-=3D-=3D-
>
>Let me see if I understand this... you want to be able to use a strong<= br> >DMARC setting for your domain, and let YMail send mail on behalf of you= r
>domain?

I think the use case here is for hosted mailing lists for small
entities. =C2=A0I was on a call with some ESPs the other day, and they said=
the number of lists for church groups and scout troops and the like is
huge, most of them use the list owner's individual e-mail address at a<= br> consumer ISP or mail provider, and in most cases there is no practical
way for them to use an address in their organization's "official&q= uot;
domain. =C2=A0This is somewhat different from discussion lists since the messages typically originate from a web form at the ESP, not the
author's mail provider, so O-A-R approaches don't work since there&= #39;s
no O to A.

It's a real issue. =C2=A0All of the solutions scale pretty badly, but approaches that start by enumerating reasonably trustworthy ESPs seem
less awful than something that requires cooperation from the users'
mail providers.

So, this is the constan= tcontact or announce list solution, ie instead of just using their mail cli= ent directly (possibly because of sending limits)?

Brandon=C2=A0
--047d7b3a8a6258001704fb1e87f6-- From nobody Thu Jun 5 16:11:22 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37FB1A0347 for ; Thu, 5 Jun 2014 16:11:20 -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 gjqhh9QQ13DD for ; Thu, 5 Jun 2014 16:11:13 -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 360811A025B for ; Thu, 5 Jun 2014 16:11:13 -0700 (PDT) Received: (qmail 68798 invoked from network); 5 Jun 2014 23:11: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:cleverness; s=10cbc.5390f909.k1406; bh=SUf8+NMWlw5Ul5P7hrgLDeacTQxo6Y867dS3b0xrdgA=; b=F0mqxXf7/i3+uDefJivyZTr8AbZTj372lcLH0cF2s+cs6KHgFKPPWQTNQWA+vu7OFJfKPowpzOrpI4fQ9/GR9Murp7cGXbf5LO6ipMbNM4ZjdDzzCPdy1349/PL6tA04SOxxJiYTwdnjKjYJdsSmzQcTP2b72FmAe4oMjxSieU5bel90FfkoKfg8PKlovyD2PmMWb1Q8qbz5Niii4VF9doNIrSM4FImBnfJ9D6i3WEf+OdVKKl0nri0vim5QsmW/ 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:cleverness; s=10cbc.5390f909.k1406; bh=SUf8+NMWlw5Ul5P7hrgLDeacTQxo6Y867dS3b0xrdgA=; b=TOstUZpkr+BxT2Vf6omR8Z1cKWu68ZnZNqPkVqtOd0MaeFNeI+TEjmVyw2nIGaQgE7Sh6ffKzYGl7nuE787jj3HKfE+SUHqJeS2p4EagpTbnqgyNgdl9JBCHwTKxe5MA/8DQui3M6q7qH914HovL2kqj9zC2J0GVIoOScLqAlhnnrp9WEEiYQih/wJANsyHl3w+ZKsCpzIYqsqsA0nWgs8OclyIAHAGuPu8XU3oCslyLBRjzaKiSnhMTttV3oPLm 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 Jun 2014 23:11:05 -0000 Date: 5 Jun 2014 19:11:04 -0400 Message-ID: From: "John R Levine" To: "Brandon Long" In-Reply-To: References: <20140605224335.5822.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/4e1p2T_mDbR9LBjJLIuMcCdsQzQ Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 05 Jun 2014 23:11:21 -0000 >> It's a real issue. All of the solutions scale pretty badly, but >> approaches that start by enumerating reasonably trustworthy ESPs seem >> less awful than something that requires cooperation from the users' >> mail providers. > > So, this is the constantcontact or announce list solution, ie instead of > just using their mail client directly (possibly because of sending limits)? It's not just sending limits, it's also list management and message design tools. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Thu Jun 5 18:55:03 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5052A1A039B for ; Thu, 5 Jun 2014 18:55:01 -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 Lcw-UbVGY2QE for ; Thu, 5 Jun 2014 18:54:59 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A13F61A037C for ; Thu, 5 Jun 2014 18:54:58 -0700 (PDT) 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, 6 Jun 2014 03:54:49 +0200 Message-ID: <96EA87B2959246E4B4916A0DEF9CAF4A@fgsr.local> From: "J. Gomez" To: Vlatko Salaj References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> Date: Fri, 6 Jun 2014 03:55:07 +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: http://mailarchive.ietf.org/arch/msg/dmarc/sLTnAmOP0PwK4itqNsepNlHjICA Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 06 Jun 2014 01:55:01 -0000 On Thursday, June 05, 2014 11:10 PM [GMT+1=3DCET], Vlatko Salaj wrote: > On Thursday, June 5, 2014 10:22 PM, J. Gomez > wrote:=20 >=20 > > > ps. to state an example, if anybody doesn't get it. > > > i have trust in ymail to send email on behalf of my domain, > > > and i want a way to state that in my DMARC policy. > > For that use case, you should do an SPF-include of Yahoo's SPF > > inside your own SPF record. >=20 > nope, that doesn't work. ESPs send email using account's > original address during SMTP MAIL FROM, not user's 3rd > party address. in my case that's @yahoo.com, not @goodone.tk. Yes, and why is that a problem for the use case you stated? =20 When you said "i have trust in ymail to send email on behalf of my = domain", were you meaning that you wanted ymail using your domain in the = MAIL-FROM envelope (1), or in the Header-From field (2)? =20 If (1), that would be something unreasonable to expect from ymail, and = please explain why would you need it. If (2), please explain whether = ymail allows it or not, and if not please explain why would that be a = DMARC limitation instead of a ymail limitation. =20 You should describe your indented use case with more detail, I'm afraid = I'm not following your reasoning here. > so, ur suggestion just shows how DMARC ppl don't > understand wide scale of broad email usage scenarios. It's a way to put it. Another way would be: your use case is obscure and = you shed no light on it. > currently, DMARC rigidity excludes my usage scenario, and > that's wrong. Please, explain with more detail how is your usage scenario excluded by = DMARC. I fail to see how, as described by you up to now, is your usage = sceneario impeded by DMARC instead of by ymail/whatever, given that = DMARC leverages SPF and SPF has the concept of includes available to = you. Regards, J.Gomez From nobody Fri Jun 6 01:18:02 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FF61A0409 for ; Fri, 6 Jun 2014 01:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 MpWkIXm8cnDH for ; Fri, 6 Jun 2014 01:17:58 -0700 (PDT) Received: from nm32.bullet.mail.gq1.yahoo.com (nm32.bullet.mail.gq1.yahoo.com [98.136.217.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C45F1A0404 for ; Fri, 6 Jun 2014 01:17:58 -0700 (PDT) Received: from [127.0.0.1] by nm32.bullet.mail.gq1.yahoo.com with NNFMP; 06 Jun 2014 08:17:51 -0000 Received: from [98.137.12.58] by nm32.bullet.mail.gq1.yahoo.com with NNFMP; 06 Jun 2014 08:14:51 -0000 Received: from [98.137.12.245] by tm3.bullet.mail.gq1.yahoo.com with NNFMP; 06 Jun 2014 08:14:51 -0000 Received: from [127.0.0.1] by omp1053.mail.gq1.yahoo.com with NNFMP; 06 Jun 2014 08:14:51 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 634564.59802.bm@omp1053.mail.gq1.yahoo.com Received: (qmail 69203 invoked by uid 60001); 6 Jun 2014 08:14:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402042491; bh=Q2vYAGjuBUhnqK+43JcQM48MK5sFDXbTZbWqDQ1yz68=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=kqEaeffmxtNtjj9NzwtfQpMptTCtyX6VvhcYfDSaAEhxdf/vP+EVZpT3C8uHi6JhUr5/VhivJXU0mQy0dVMWYwHL5T/SvyE8ROZzlCi/oDPtswyVbqMQ+yNrzBorSLVgMOfVSZx9FcjoYK9QXq9wzDECnnp0XAniD1XyX1YAvTI= X-YMail-OSG: f0dMW24VM1l9vb2NtwG_nTcIRLKSTzCBUYLmw4jbyryjE0U 3_tzOzo_YpvHJv1KhUfb9jV22itB9Uiht3cB8uC4PRGw_dd5ARPZxPZ8mvBG Oe.nlu6LbJtCayO9PNr_iywJPGz2N2uTWKAG5OGJTn2MwGfZM.JchuzacFQq G6qoVWw3kP5nKAKIdy1AZRhNtYy6tSVKY29xBu0g8BcUlDx49tjqNv5HqHEo l2aA63KUrVOaTDOYcmlKyx31ZU_FaQ6Z0TZVSN8eJR565K6s8C50ELyVcwdX VUvXM56dnjfkejwBwkGmQetYnzYAimu6tt.KsAL9wg6F8EQHTph47Pg5I56h onsPj.YHQ9eZpIJ_Lb8Ebs4U2qCjMh1HPxu5qPkP2QxKUItH4OMEAnpqokSl mBy_werkDqNj89aoSTA8jlyUTHV2a66djRPpSAyrqNMmE3BlnTRRYhLgbn8M kd0SLTf_cvg0Jvd8MrrXto9qNedqZGoNhwgfB.Za.x8U.CsQn84.rz9eBZRj .s3L7JjYp.o4B7bHH7ee6i.QPAl3Pwn3U4LYXs4NFDQSNqs7c2IYLEcUlAPU K43I70DmShGHfmy10YGl7HgN.hwb3.xekHK7p8i81EYXU6UyUruhbmOVKqmE - Received: from [79.175.112.242] by web164601.mail.gq1.yahoo.com via HTTP; Fri, 06 Jun 2014 01:14:51 PDT X-Rocket-MIMEInfo: 002.001, PiBMZXQgbWUgc2VlIGlmIEkgdW5kZXJzdGFuZCB0aGlzLi4uIHlvdSB3YW50IHRvIGJlCj4gYWJsZSB0byB1c2UgYSBzdHJvbmcgRE1BUkMgc2V0dGluZyBmb3IgeW91ciBkb21haW4sCj4gYW5kIGxldCBZTWFpbCBzZW5kIG1haWwgb24gYmVoYWxmIG9mIHlvdXIgZG9tYWluPwoKaSB3YW50IHRvIHVzZSB3aGljaGV2ZXIgRE1BUkMgc2V0dGluZyBzdWl0cyBtZSwgYW5kCnRvIGFsbG93IHRydXN0ZWQgM3JkIHBhcnRpZXMgdG8gc2VuZCBlbWFpbCBvbiBteSBiZWhhbGYuCgoKPiBNb3N0IGhlcmUgYXJlIGFyZ3UBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> Message-ID: <1402042491.15608.YahooMailNeo@web164601.mail.gq1.yahoo.com> Date: Fri, 6 Jun 2014 01:14:51 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/zzym3-nv7tHpN3cD71vebuwN1kw Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 06 Jun 2014 08:18:01 -0000 > Let me see if I understand this... you want to be > able to use a strong DMARC setting for your domain, > and let YMail send mail on behalf of your domain? i want to use whichever DMARC setting suits me, and to allow trusted 3rd parties to send email on my behalf. > Most here are arguing against using strong DMARC > settings for personal use cases, you are arguing > for 3rd party support because you do want to use DMARC? what's the point of DMARC then? r we building a safer email, or r we just introducing protocols that can't be used cause they r not-to-be-used from the start? ppl r arguing against strong DMARC settings cause they r broken, not cause they r not useful. > Even if something like TPA-labels was established > to give third parties permission, I'm not clear > if/how that would affect YMail/Gmail's handling > of "custom from", "allow custom from if TPA-Label > exists at send time"? i don't see how or why would 3rd party support in DMARC change anything regarding ymail 3rd party email account capability. it wouldn't, cause it has little to do with it. ps. and no, i don't want to pay for google services. and i don't want to use my own MTA, cause that's not the point. i want to send email the way i trust it to be sent, using whatever ESP i trust. pps. by not including 3rd party support in DMARC, u actually have to build more than one complex workaround just to workaround DMARC's inefficiency, just as u specified in ur examples. it's trivially obvious to me that adding 3rd party support would be much less complex, much easier, with much better control... at least to majority of domains. is using aidbands better than actually patching up the patient? -- Vlatko Salaj aka goodone http://goodone.tk From nobody Fri Jun 6 01:52:41 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779E01A0409 for ; Fri, 6 Jun 2014 01:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 ob8ijMLoCOWX for ; Fri, 6 Jun 2014 01:52:38 -0700 (PDT) Received: from nm45.bullet.mail.ne1.yahoo.com (nm45.bullet.mail.ne1.yahoo.com [98.138.120.52]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8DDE1A02EE for ; Fri, 6 Jun 2014 01:52:37 -0700 (PDT) Received: from [127.0.0.1] by nm45.bullet.mail.ne1.yahoo.com with NNFMP; 06 Jun 2014 08:52:30 -0000 Received: from [98.138.226.180] by nm45.bullet.mail.ne1.yahoo.com with NNFMP; 06 Jun 2014 08:49:30 -0000 Received: from [216.39.60.184] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 06 Jun 2014 08:49:08 -0000 Received: from [98.137.12.50] by tm20.bullet.mail.gq1.yahoo.com with NNFMP; 06 Jun 2014 08:49:08 -0000 Received: from [127.0.0.1] by omp1065.mail.gq1.yahoo.com with NNFMP; 06 Jun 2014 08:49:08 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 257382.17331.bm@omp1065.mail.gq1.yahoo.com Received: (qmail 4259 invoked by uid 60001); 6 Jun 2014 08:49:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402044548; bh=OXWekLOT7U1bt3HGKd1oZ5Pz8FEZlDk5Gw3bwWK4t8E=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ABWAy6iv7f84jW3OvzVOPq+jaSoQxB9KqKMxr8XIL8xbLJPMXXqOHxaD/SNWxsG1xYJTWyVyWtXW4hyqW9eZ8Y05XDWu+qOMYxzwvIOKVSsQwB20YjZ1O7DuzKMpIEGVoDsbtD0+zg/+r7afHpYnaFPqCWn1SpCjOGX0Meq8zrA= X-YMail-OSG: GQliawQVM1ns4vJ8KTaYn0hei0myHj9SFRBU.Tve3OdCcMy iS0N4aO0Okd_52_GB4MDqzxFfZvJyDxZcnNQN2.lZdDbcn0B5eMSy7cGh1B5 3q.pfW8s4nmzg9ppW5ezqfyWgCOlGDlGb74dzBA_HxFnOHzDVmHr5Al2uuUx Brte0Tzx2Ff3uz0SSu604dWpSy9kfHARkvyl9Gvtdwm4kiSj7VBveirDqByg h2kFcfRZkUo7H6TTEUfWoXfigOD_hJj6AElC7..9k.__8XxtV7m8_ogi_L63 B2Gsz5sJQpUIQQSVGlPN7SnMalDQueIAcgrJBtE4AvUehW1qRmGbmmfl5_w4 TmoV2GEuKE3H4ySkHpvAK2nyWnz4uoBj3C9ndWisf31POYLeaa9Z8erpaSza EYFjJipqWan1IhHZvKACRTeaxE4n1kmLFGuKCy5.bQl082iYjtNeh_q57Z9U SBMT2gf1o_P4ppaBCaZzmBF96x0cyJhRjzkIJ5cIxRMIaS7gRzHx18ajPZMw YJXvVnJFB1tehe3EEYC1wX2CPMx5U3UH9j.kQtDUR0z3OgxI9ON2hbKV.Fwb m1DiPfgsG1PbDMbLX3D9.ZiiqkIJx6gvXXMtzsk_i1kKs1N1E9HvB1tpEbZr 4tWccQVLMx.g5kaGE36zG8Xke7KfKQLs.7bk- Received: from [79.175.112.242] by web164603.mail.gq1.yahoo.com via HTTP; Fri, 06 Jun 2014 01:49:08 PDT X-Rocket-MIMEInfo: 002.001, T24gRnJpZGF5LCBKdW5lIDYsIDIwMTQgMzo1NSBBTSwgSi4gR29tZXogPGpnb21lekBzZXJ5cmljaC5jb20.IHdyb3RlOgoKCj4gV2hlbiB5b3Ugc2FpZCAiaSBoYXZlIHRydXN0IGluIHltYWlsIHRvIHNlbmQgZW1haWwgb24gYmVoYWxmIG9mIG15IGRvbWFpbiIsCj4gd2VyZSB5b3UgbWVhbmluZyB0aGF0IHlvdSB3YW50ZWQgeW1haWwgdXNpbmcgeW91ciBkb21haW4gaW4gdGhlIE1BSUwtRlJPTQo.IGVudmVsb3BlICgxKSwgb3IgaW4gdGhlIEhlYWRlci1Gcm9tIGZpZWxkICgyKT8KCigxKSBuby4KKDIpIHkBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> <96EA87B2959246E4B4916A0DEF9CAF4A@fgsr.local> Message-ID: <1402044548.59713.YahooMailNeo@web164603.mail.gq1.yahoo.com> Date: Fri, 6 Jun 2014 01:49:08 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" In-Reply-To: <96EA87B2959246E4B4916A0DEF9CAF4A@fgsr.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/hYi2tt7Y5RTnQsqlDuo0vL0KsVY Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 06 Jun 2014 08:52:39 -0000 On Friday, June 6, 2014 3:55 AM, J. Gomez wrote: > When you said "i have trust in ymail to send email on behalf of my domain", > were you meaning that you wanted ymail using your domain in the MAIL-FROM > envelope (1), or in the Header-From field (2)? (1) no. (2) yes. > If (1), that would be something unreasonable to expect from ymail, > and please explain why would you need it. yes, as i said, no one expects such a broken behavior, so i don't. > If (2), please explain whether ymail allows it or not, it does. > and if not please explain why would that be a DMARC limitation instead > of a ymail limitation. well, since it does support it, i guess there's nothing to answer here, but let me make as plain as possible example: === FROM header: vlatko.salaj@goodone.tk MAIL-FROM envelope: my_yahoo_account@yahoo.com DKIM domain: yahoo.com === results: 1. mail legitimate; validated by sending ESP using: 2. valid DKIM @yahoo.com, 3. servers validated by SPF at yahoo.com, 4. goodone.tk SPF records r of no importance here, 5. DMARC is unable to authenticate this email: no 3rd party support. > Another way would be: your use case is obscure > and you shed no light on it. actually, this is a pretty common practice, especially for personal or small business domains. out of my 15 business customers, 13 use exactly this. and i mainly support small business, so my experience is pretty in line with this world, unlike, i imagine, ppl working for ymail, google, paypal, fb or whoever sat and designed DMARC. > Please, explain with more detail how is your usage > scenario excluded by DMARC. I fail to see how, as > described by you up to now, is your usage sceneario > impeded by DMARC instead of by ymail/whatever, given > that DMARC leverages SPF and SPF has the concept > of includes available to you. i hope u understand now. if not, i won't be able to provide more str8-forward examples of this scenario, cause i'm not able to specify it more clearly than this. i hope others understand my example. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Fri Jun 6 02:23:43 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A90D11A0409 for ; Fri, 6 Jun 2014 02:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.753 X-Spam-Level: X-Spam-Status: No, score=-1.753 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_72=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.651, 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 wt3oqvjykjtt for ; Fri, 6 Jun 2014 02:23:40 -0700 (PDT) Received: from smtp.anubisnetworks.com (smtp.anubisnetworks.com [195.22.26.198]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B62651A0448 for ; Fri, 6 Jun 2014 02:23:40 -0700 (PDT) Received: from loki.anubis.local (localhost [127.0.0.1]) by smtp.anubisnetworks.com (Postfix) with ESMTP id 3glJLp31vtzCsCk for ; Fri, 6 Jun 2014 10:23:30 +0100 (WEST) Received: from zimbra2.anubis.via (zimbra2.anubis.via [192.168.23.74]) by loki.anubis.local (Postfix) with ESMTP id 3glJLp2fkNzCsGq for ; Fri, 6 Jun 2014 10:23:30 +0100 (WEST) Received: from zimbra2.anubis.via (localhost [127.0.0.1]) by zimbra2.anubis.via (Postfix) with ESMTP id E569A383D0E for ; Fri, 6 Jun 2014 10:23:29 +0100 (WEST) DKIM-Filter: OpenDKIM Filter v2.8.4 zimbra2.anubis.via E569A383D0E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anubisnetworks.com; s=DE5D398A-DC66-11E3-92F6-76AE37576441; t=1402046609; bh=SaLF+pBeLGVqxPzJH8wwkqRQ1ohmG3B5Jv8aynLVU+c=; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=KaOP3tw4f/jz7EFlQCRpVD/9LIZZDMxcgcCsd9sUnMDgXkq0tCiUrjnInF0cvRy42 UomBEGGfnUp+fRclIoCuu2pT3jBsRP0+yMvJR5ZcnuP78t8PN6rx1eeRa6YgbVWqYK VuOAyFZB7LTtfffdJqiyRmzyiopcgxV3yR3eemQA= Received: from zimbra2.anubis.via (zimbra2.anubis.via [192.168.23.74]) by zimbra2.anubis.via (Postfix) with ESMTP id E39DE383B19 for ; Fri, 6 Jun 2014 10:23:29 +0100 (WEST) Date: Fri, 6 Jun 2014 10:23:29 +0100 (WEST) From: =?utf-8?B?Sm9zw6k=?= Ferreira To: dmarc@ietf.org Message-ID: <1604175574.1025554.1402046609775.JavaMail.zimbra@anubisnetworks.com> In-Reply-To: <1402044548.59713.YahooMailNeo@web164603.mail.gq1.yahoo.com> References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> <96EA87B2959246E4B4916A0DEF9CAF4A@fgsr.local> <1402044548.59713.YahooMailNeo@web164603.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - GC35 (Linux)/8.0.6_GA_5922) Thread-Topic: confusing 3rd party support so it remains out Thread-Index: UH3FrOrmGdr3uNt4D2pVZ8Ax2uq8/A== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/LEUKodNL6bKtvRDOVW4UiZ6KBW4 Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 06 Jun 2014 09:23:42 -0000 ----- Original Message ----- > From: "Vlatko Salaj" > To: dmarc@ietf.org > Sent: Friday, June 6, 2014 9:49:08 AM > Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out =20 >=20 > well, since it does support it, i guess there's nothing to answer here, > but let me make as plain as possible example: >=20 > =3D=3D=3D > FROM header: vlatko.salaj@goodone.tk > MAIL-FROM envelope: my_yahoo_account@yahoo.com > DKIM domain: yahoo.com > =3D=3D=3D >=20 > results: > 1. mail legitimate; validated by sending ESP using: > 2. valid DKIM @yahoo.com, > 3. servers validated by SPF at yahoo.com, > 4. goodone.tk SPF records r of no importance here, > 5. DMARC is unable to authenticate this email: no 3rd party support. >=20 Just to keep this out of the Y! realm, GApps also does this for Domain alia= s. example.com : primary domain example.net : alias domain =20 FROM header : Alias_Domain_User@example.net MAIL-FROM envelope: primary_domain_user@example.com DKIM domain : example.net Makes some sense to be this way but DMARC will always fail for example.net. Jos=C3=A9 Borges Ferreira AnubisNetworks From nobody Fri Jun 6 02:49:11 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7141A02C1 for ; Fri, 6 Jun 2014 02:49:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 WK9od_o6xReD for ; Fri, 6 Jun 2014 02:49:08 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id F3A891A0109 for ; Fri, 6 Jun 2014 02:49:07 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 7E68E970B26; Fri, 6 Jun 2014 18:48:59 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 6CBA0127D77; Fri, 6 Jun 2014 18:48:59 +0900 (JST) From: "Stephen J. Turnbull" To: Vlatko Salaj In-Reply-To: <1402042491.15608.YahooMailNeo@web164601.mail.gq1.yahoo.com> References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1402042491.15608.YahooMailNeo@web164601.mail.gq1.yahoo.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 06 Jun 2014 18:48:59 +0900 Message-ID: <877g4u2ws4.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/NIfGBWRcwI8Ogj7g7vkrFLheAc0 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 06 Jun 2014 09:49:09 -0000 Vlatko Salaj writes: > i want to use whichever DMARC setting suits me, and > to allow trusted 3rd parties to send email on my behalf. AFAICS, DMARC was designed to deal with phishing for credentials via fraudulent messages claiming to be from customer service of a large large business entity. This is a big hurt *all by itself*, and so worth a whole protocol to reduce it. The reason is that even with a low "conversion rate" on the phishing message, individual customers can be hurt very badly, and the profits are big enough that there's strong incentive to engage in email fraud for this purpose alone. You have a different use case, you need a different protocol. > what's the point of DMARC then? Building safer email, one brick at a time. You need a different brick. Why delay DMARC implementation because your brick isn't baked yet? > ppl r arguing against strong DMARC settings cause they r broken, But they're not broken when used in a "direct mail" context. The "on behalf of" use cases and the "mailing list" use case are a harder problem. Standardizing DMARC (in or out of the IETF process) is a case of "don't let the best be the enemy of the good." > is using aidbands better than actually patching up > the patient? It is if you have a Band-Aid, but lack a sterile needle and thread to properly suture the wound. We *don't have* a protocol for your use case yet. Many proposals have been made, but they all failed because some party essential to the success of the protocol would refuse to cooperate. :-( From nobody Fri Jun 6 07:12:21 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F01CF1A0166 for ; Fri, 6 Jun 2014 07:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 rNjCaiIjVCjD for ; Fri, 6 Jun 2014 07:12:10 -0700 (PDT) Received: from nm32.bullet.mail.gq1.yahoo.com (nm32.bullet.mail.gq1.yahoo.com [98.136.217.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7584D1A00ED for ; Fri, 6 Jun 2014 07:12:10 -0700 (PDT) Received: from [127.0.0.1] by nm32.bullet.mail.gq1.yahoo.com with NNFMP; 06 Jun 2014 14:12:03 -0000 Received: from [98.137.12.188] by nm32.bullet.mail.gq1.yahoo.com with NNFMP; 06 Jun 2014 14:09:15 -0000 Received: from [98.137.12.232] by tm9.bullet.mail.gq1.yahoo.com with NNFMP; 06 Jun 2014 14:09:15 -0000 Received: from [127.0.0.1] by omp1040.mail.gq1.yahoo.com with NNFMP; 06 Jun 2014 14:09:15 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 693976.54752.bm@omp1040.mail.gq1.yahoo.com Received: (qmail 26992 invoked by uid 60001); 6 Jun 2014 14:09:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402063755; bh=T2FdEwnCBZVBB6GV7yX2Lau3D6KaW8TH4WbYZMBBI1Y=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=VQpc+0TIuRgiCwPohm51fd4ozgp5yxln6TuSW6Jn7SSeVhe94GlqKD75p/GuaVb7JoyAL1XULTktREpoWg/Z8KHUe574/P6+SmJRJ+vPyaZni76vJc9MEbtFVbHGqF86iEvkVGEMGaYyyZehtggXXKHCwzS3FcA/ePoAajb21ps= X-YMail-OSG: PBsdURYVM1mnE4s2H5UZw3gws8CNxpnlqivs0P3T_f8HSDE kVDy6x8bI8ifzHh0PKxZ2HXE4qaGDBdlZt1NM6csGZeWA6.gacRkDp4h6xPS V2DIHIjl7R2v1OYAGThX9OpI9aXVsfFZimsTNxIPvvPcS3_obPopRc7p4wID mJD4cOd0pE4A_bOcjGmMZADLBP7N72jJRRSd5cEsRgMmSvLx9lF9GVg4m8lm BmYrzZCNAzSmkdZnI8FakpRqrUDELQn2LBsYPn0hKzSkLFjnWYLZM81bqx4q ZmDq_kTfM.6VfoK3.tVQCIFy8cPf1w0NuN7F2OQDwSMB2zovJJzFtaqo0esz mWfDrNGV52pJuohcH3YqNFZMsny98fxMSFVtXiY.3fVhQIaqWAI_6SojeyTL L_406eQuposIqCMeuEu4e1PnwuJs9kDl0MX_Ysm4BCXpCL0Ca42Bszb3Rc7h 5O6qh_C__jHgvqQ4tCEyi0U80Z4FDJ5BVL.DJDl1CSuaYN5n.DOFxFbOJBXJ ZipT.n23ebttzbeDE85nP0kgMtn08lB2oezlMJVG7.IYFfhnMc.91bA8jqAm uapw3Fga4WhLG1RnSvpBq1Ua4oiDh2FksKPdzorTRmISnHujc.w-- Received: from [79.175.112.242] by web164602.mail.gq1.yahoo.com via HTTP; Fri, 06 Jun 2014 07:09:15 PDT X-Rocket-MIMEInfo: 002.001, T24gRnJpZGF5LCBKdW5lIDYsIDIwMTQgMjo1NiBQTSwgU3RlcGhlbiBKLiBUdXJuYnVsbCA8c3RlcGhlbkB4ZW1hY3Mub3JnPiB3cm90ZToKCgo.PiBpIHdhbnQgdG8gdXNlIHdoaWNoZXZlciBETUFSQyBzZXR0aW5nIHN1aXRzIG1lLCBhbmQKPj4gdG8gYWxsb3cgdHJ1c3RlZCAzcmQgcGFydGllcyB0byBzZW5kIGVtYWlsIG9uIG15IGJlaGFsZi4KPiBBRkFJQ1MsIERNQVJDIHdhcyBkZXNpZ25lZCB0byBkZWFsIHdpdGggcGhpc2hpbmcgZm9yIGNyZWRlbnRpYWxzIHZpYQo.IGZyYXVkdWxlbnQgbWVzc2FnZXMBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1402042491.15608.YahooMailNeo@web164601.mail.gq1.yahoo.com> <877g4u2ws4.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <1402063755.61291.YahooMailNeo@web164602.mail.gq1.yahoo.com> Date: Fri, 6 Jun 2014 07:09:15 -0700 (PDT) From: Vlatko Salaj To: "Stephen J. Turnbull" In-Reply-To: <877g4u2ws4.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/_YYE_zi2BDjpXxRj3LK7tFOLjq0 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 06 Jun 2014 14:12:19 -0000 On Friday, June 6, 2014 2:56 PM, Stephen J. Turnbull w= rote:=0A=0A=0A>> i want to use whichever DMARC setting suits me, and=0A>> t= o allow trusted 3rd parties to send email on my behalf.=0A> AFAICS, DMARC w= as designed to deal with phishing for credentials via=0A> fraudulent messag= es claiming to be from customer service of a large=0A> large business entit= y.=0A> You have a different use case, you need a different protocol.=0A=0Aa= nd how is my use case different? is it cause:=0A1. i don't have a phishing = problem?=0A2. i'm not a big money entity?=0A=0Achoose ur answer wisely, and= beware how u thread.=0A=0Aif ur answer is 1: u don't know that. and it's n= ot ur business to know=0Athat. if i wish to protect my domain from phishing= , it is my sole=0Aright to do so. it is also my sole right to do it the way= i trust is=0Asufficient for me.=0A=0Aif ur answer is 2: building protocols= that suit big tower corporations=0Ais just like net neutrality discussion = we have now at FCC.=0A=0Ajust like FCC's recent corrupted moves to promote = what was almost=0Aunimaginable a few years back, which, even if successful,= will be=0Adismissed sooner than later, and whole fiasco will be looked as = a dark=0Ahistory of internet, DMARC support will be left out by worldwide= =0Adevelopers, cause it's a complete waste of their time and energy, and=0A= doesn't serve high goals it proclaims it does.=0A=0Ai will repeat myself: n= obody will develop a support for a lousy=0Aprotocol that has a high probabi= lity of breaking delivery of a=0Aperfectly legitimate email, while trashing= everything developed for=0Aemail last 20y or more: mailing lists, forwardi= ng, send2friend, and=0Awhatever 3rd party email processing someone imagine = useful to them.=0A=0Aif u rly want DMARC to succeed and have a wide scale s= upport, u will=0Ado ur best to adapt it to internet at large. otherwise, u = will be left=0Awith a half-baked protocol supported mostly by the same enti= ties that=0Adeveloped it. and that's not whole internet. not even close.=0A= neither that solves ur phishing problems completely, as the rest of=0Ainter= net will ignore ur DMARC records completely and let ur phishing=0Atake plac= e.=0A=0Awhy? cause u failed to develop a protocol useful to all parties.=0A= =0Aso all that energy and work will go to waste, when IETF puts=0A"historic= " on DMARC standard, and moves on to some better place.=0A=0A=0A> Why delay= DMARC implementation because your brick isn't baked yet?=0A=0Acause buildi= ng houses while missing some bricks will surely result in=0Atheir collapse = at some point. and then u will have profit loses when=0Aur reputation as a = builder gets tarnished by angry customers=0Aobsessing with ur customer supp= ort.=0A=0Aconsidering how many things DMARC doesn't support, that's actuall= y=0Aa logical consequence.=0A=0A=0A>> ppl r arguing against strong DMARC se= ttings cause they r broken,=0A> Standardizing DMARC (in or out of the IETF = process) is a=0A> case of "don't let the best be the enemy of the good."=0A= =0Ai would rather say it's a case of "history repeating". how many=0Aemail = policy protocols were developed in last 10y? a bunch of them.=0Aall of them= failed. all of them "historic" now.=0A=0Awhy? cause they were unlucky enou= gh to be half-baked.=0A=0ADMARC has a chance. will it use it? i'm quite sur= e it won't...=0A=0Awhy? cause, unless genius and creativity kicks in early = in development=0Aprocess, things produced r usually mundane and mediocre. t= hat's how=0ADMARC feels now.=0A=0Abut at least i'm giving my best not to le= t that happen. it must be=0Athat period of my life when a completely unknow= n individual=0Aopenly and unconditionally contributes essential stuff to a = future=0Asuccess. or i just care enough. whichever suits u to agree with me= .=0A=0Ait's beyond obvious DMARC needs a 3rd party support. every email=0As= tandard has it: SPF has it, DKIM has bunch of them, ESPs have them,=0Awebsi= tes have them... name any email thing that works on wide scale=0Aand take a= few seconds to realize what's its 3rd party support=0Ain its basic functio= ns.=0A=0A=0A>> is using aidbands better than actually patching up the patie= nt?=0A> It is if you have a Band-Aid, but lack a sterile needle and thread = to=0A> properly suture the wound.=A0 We *don't have* a protocol for your us= e=0A> case yet.=0A=0Aactually, AFAICS, we have three complete solutions for= 3rd party support,=0Aand that's counting last few months, not from the beg= inning of DMARC=0Adevelopment, which may have produced many different solut= ions; and i=0Adon't doubt it did, cause problems r obvious and real.=0A=0At= he real problem with 3rd party support for DMARC r DMARC "gate-keepers".=0A= they r like FCC now, listening to small minds from big towers, reluctant=0A= to make "a small step as a jump for email kind".=0A=0A=0A> Many proposals h= ave been made, but they all failed because=0A> some party essential to the = success of the protocol would refuse to=0A> cooperate. :-(=0A=0Aif DMARC do= esn't assimilate some kind of 3rd party support soon, it=0Awill be a failur= e too. and i don't think it has much time left:=0A1 year probably, 2 years = if u r rly pushing it.=0A=0Appl already dismiss DMARC as a failure... and i= don't blame them.=0A=0Ahaving it at IETF as an informational RFC speaks vo= lumes on its fate.=0Aif it was actually beneficial to internet, it would go= most common and=0Aregular IETF standards track.=0A=0A=0A-- =0AVlatko Salaj= aka goodone=0Ahttp://goodone.tk From nobody Fri Jun 6 10:33:00 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E08D1A01C9 for ; Fri, 6 Jun 2014 10:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 OnJ2X1iAJvj1 for ; Fri, 6 Jun 2014 10:32:50 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id E39381A01D2 for ; Fri, 6 Jun 2014 10:32:48 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 73AEC970B37; Sat, 7 Jun 2014 02:32:41 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 5299D1205A8; Sat, 7 Jun 2014 02:32:41 +0900 (JST) From: "Stephen J. Turnbull" To: Vlatko Salaj In-Reply-To: <1402063755.61291.YahooMailNeo@web164602.mail.gq1.yahoo.com> References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1402042491.15608.YahooMailNeo@web164601.mail.gq1.yahoo.com> <877g4u2ws4.fsf@uwakimon.sk.tsukuba.ac.jp> <1402063755.61291.YahooMailNeo@web164602.mail.gq1.yahoo.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 07 Jun 2014 02:32:41 +0900 Message-ID: <8738fi2bba.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/eeFpSLhUcSvD4hGm0KTdEbAlGDY Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 06 Jun 2014 17:32:51 -0000 Vlatko Salaj writes: > and how is my use case different? is it cause: 2. DMARC is designed for business entities big enough to be willing to maintain MTAs to do the signing for them, or pay for somebody trustworthy to maintain such an MTA for them. You aren't willing, so your use case is different. That doesn't mean your use case isn't important. It means that DMARC isn't designed for it. I don't have a protocol that works for your use case. If you have one, propose it and see if you can get Yahoo! to agree to use it. But Yahoo! hasn't done it for you, and I'll bet you they won't -- they're not particularly interested in your use case. > it's beyond obvious DMARC needs a 3rd party support. every email > standard has it: SPF has it, DKIM has bunch of them, ESPs have > them, websites have them... name any email thing that works on wide > scale and take a few seconds to realize what's its 3rd party > support in its basic functions. I'm not sure what you mean by 3rd party support in SPF and DKIM. Can you put a third party mailbox in From: with SPF? Sure. *And nobody trusts it, and nobody should.* Anybody with an account at Yahoo! can put your mailbox at your domain in From:, and it will pass SPF authentication as Yahoo!. Ditto DKIM. That's not support. Yahoo!'s use of "p=reject" causes you pain? Tell Yahoo! about it. Or switch to GMail. > actually, AFAICS, we have three complete solutions for 3rd party > support, What are they? AFAICS, there are none, but I'm willing to be educated. > ppl already dismiss DMARC as a failure... and i don't blame them. DMARC is working for the people who designed it (and they claim to represent 80% of the users in the US and 2 billion mailboxes worldwide). Unfortunately, this is not one of those cases where it happens to work for everybody else. A shame, but "there ain't no such thing as a free lunch." From nobody Fri Jun 6 10:50:41 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00BF1A0217 for ; Fri, 6 Jun 2014 10:50:35 -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_51=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 z3TppmdCitzW for ; Fri, 6 Jun 2014 10:50:34 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15A5E1A0216 for ; Fri, 6 Jun 2014 10:50:33 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id bs8so1414169wib.12 for ; Fri, 06 Jun 2014 10:50: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=vu9N5UZglHPJN7l9P6oziy0a/6OHbaigshRKNIhM66g=; b=KXXAvxMhlbSDv8+xrB25oNTNeFttwCJZq0w7DbjngJwumSRJ+SxXuTIcQYXIJEX/Ce RWMSqrLBKAc4uK36ms3GOU3z3F2zNPkDuQGFTHNiaTbrM5khhqig5/aaq+a84Nn2kOWX c2fGa03tDyuM0lKh6rmuVYNpbrz34tWfLnMQgCxF8MjmAphIKSs+p6NDNr/BPJN4VI43 2TcK0zvPMfPC0CC29BigMcVVxHLPjpcsX6/IxWMVHy3XXNiAp+QpvAgqNwQZC0b/vIz5 1Sa8uVkswOrjoLbnC92Kh6G8+har5j41AnV8hh/6PMee7M8NWQqHN0EYcfG4Nsp/MFJk X4hg== MIME-Version: 1.0 X-Received: by 10.180.94.163 with SMTP id dd3mr7548494wib.26.1402077026147; Fri, 06 Jun 2014 10:50:26 -0700 (PDT) Received: by 10.180.23.104 with HTTP; Fri, 6 Jun 2014 10:50:26 -0700 (PDT) In-Reply-To: <1402063755.61291.YahooMailNeo@web164602.mail.gq1.yahoo.com> References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1402042491.15608.YahooMailNeo@web164601.mail.gq1.yahoo.com> <877g4u2ws4.fsf@uwakimon.sk.tsukuba.ac.jp> <1402063755.61291.YahooMailNeo@web164602.mail.gq1.yahoo.com> Date: Fri, 6 Jun 2014 10:50:26 -0700 Message-ID: From: "Murray S. Kucherawy" To: Vlatko Salaj Content-Type: multipart/alternative; boundary=f46d04462e5e17674604fb2e7f87 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/fK056JXe_CULPYV8KKnJc7b3OeI Cc: "Stephen J. Turnbull" , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 06 Jun 2014 17:50:36 -0000 --f46d04462e5e17674604fb2e7f87 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 6, 2014 at 7:09 AM, Vlatko Salaj wrote: > just like FCC's recent corrupted moves to promote what was almost > unimaginable a few years back, which, even if successful, will be > dismissed sooner than later, and whole fiasco will be looked as a dark > history of internet, DMARC support will be left out by worldwide > developers, cause it's a complete waste of their time and energy, and > doesn't serve high goals it proclaims it does. > The current deployed base of DMARC appears to disagree. Setting aside Yahoo! and AOL (the controversial cases), there are several operators who have been using DMARC for quite some time now that don't cause problems and they have enjoyed huge benefit from it. > i will repeat myself: nobody will develop a support for a lousy > protocol that has a high probability of breaking delivery of a > perfectly legitimate email, while trashing everything developed for > email last 20y or more: mailing lists, forwarding, send2friend, and > whatever 3rd party email processing someone imagine useful to them. > Reality appears to differ. PayPal, Bank of America, and Facebook at least have been using it for a long time, and I'd bet you didn't even notice. > why? cause u failed to develop a protocol useful to all parties. > > so all that energy and work will go to waste, when IETF puts > "historic" on DMARC standard, and moves on to some better place. > I have to assume you're referring to ADSP here, which was recently marked "Historic". However, DMARC has already enjoyed more adoption than ADSP ever did, even with its controversy. I think I know some of the reasons why, and we can go into them if you like. > > Standardizing DMARC (in or out of the IETF process) is a > > case of "don't let the best be the enemy of the good." > > i would rather say it's a case of "history repeating". how many > email policy protocols were developed in last 10y? a bunch of them. > all of them failed. all of them "historic" now. > Which ones, other than ADSP? > it's beyond obvious DMARC needs a 3rd party support. every email > standard has it: SPF has it, DKIM has bunch of them, ESPs have them, > websites have them... name any email thing that works on wide scale > and take a few seconds to realize what's its 3rd party support > in its basic functions. > Although SPF and DKIM do have third party delegation tools (in DKIM's case, at least two), they have never had much uptake. Perhaps that will change as DMARC continues to evolve, but so far the industry as a whole (not the IETF) has not found their use to have more benefit than risk. > actually, AFAICS, we have three complete solutions for 3rd party support, > and that's counting last few months, not from the beginning of DMARC > development, which may have produced many different solutions; and i > don't doubt it did, cause problems r obvious and real. > To answer Stephen's question, I'm guessing you're referring to ATPS (RFC 6541), use of CNAME to point to an externally-posted key, and a key exchange where an operator give a third party a signing key. If there are others, I'd like to know what they are. All three would require the Yahoo!s and AOLs of the world to grant signing keys, signing key aliases, or ATPS records to every domain that might re-send their mail. There are some obvious issues with such solutions: (a) users will have to register every list to which they subscribe and wish to post; (b) they will have to automate DNS updates because every new entry into that registry will require a new DNS entry; and (c) if any of those third parties gets compromised, it's a big problem for the domain trying to protect itself. If any bit of this fails (and I suspect (a) is actually the bigger problem), they don't work. the real problem with 3rd party support for DMARC r DMARC "gate-keepers". > they r like FCC now, listening to small minds from big towers, reluctant > to make "a small step as a jump for email kind". > I don't think that's a fair characterization. I think the more likely explanation is that the proposals on the table are much too risky and costly given the benefits. If a better one comes along, I'm sure it would be considered. > > having it at IETF as an informational RFC speaks volumes on its fate. > if it was actually beneficial to internet, it would go most common and > regular IETF standards track. > > The status of the current document has nothing at all to do with the quality of what's in it, but rather the procedural path it's taking toward publication. On the Independent Submission track, the only status available is Informational. -MSK --f46d04462e5e17674604fb2e7f87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 6, 2014 at 7:09 AM, Vlatko Salaj <vlatk= o.salaj@goodone.tk> wrote:
just like FCC's recent corrupted moves t= o promote what was almost
unimaginable a few years back, which, even if successful, will be
dismissed sooner than later, and whole fiasco will be looked as a dark
history of internet, DMARC support will be left out by worldwide
developers, cause it's a complete waste of their time and energy, and doesn't serve high goals it proclaims it does.
The current deployed base of DMARC appears to disagree.=C2=A0 S= etting aside Yahoo! and AOL (the controversial cases), there are several op= erators who have been using DMARC for quite some time now that don't ca= use problems and they have enjoyed huge benefit from it.
=C2=A0
i will repeat myself: nobody will develop a support for a lousy
protocol that has a high probability of breaking delivery of a
perfectly legitimate email, while trashing everything developed for
email last 20y or more: mailing lists, forwarding, send2friend, and
whatever 3rd party email processing someone imagine useful to them.

Reality appears to differ.=C2=A0 PayPal, Bank = of America, and Facebook at least have been using it for a long time, and I= 'd bet you didn't even notice.
=C2=A0
why? cause u failed to develop a protocol useful to all parties.

so all that energy and work will go to waste, when IETF puts
"historic" on DMARC standard, and moves on to some better place.<= br>

I have to assume you're referring t= o ADSP here, which was recently marked "Historic".=C2=A0 However,= DMARC has already enjoyed more adoption than ADSP ever did, even with its = controversy.=C2=A0 I think I know some of the reasons why, and we can go in= to them if you like.
=C2=A0
> Standar= dizing DMARC (in or out of the IETF process) is a
> case of "don't let the best be the enemy of the good."
i would rather say it's a case of "history repeating". = how many
email policy protocols were developed in last 10y? a bunch of them.
all of them failed. all of them "historic" now.
<= div>
Which ones, other than ADSP?
=C2=A0
it's beyond obvious DMARC needs a 3rd party support. every email
standard has it: SPF has it, DKIM has bunch of them, ESPs have them,
websites have them... name any email thing that works on wide scale
and take a few seconds to realize what's its 3rd party support
in its basic functions.

Although SPF an= d DKIM do have third party delegation tools (in DKIM's case, at least t= wo), they have never had much uptake.=C2=A0 Perhaps that will change as DMA= RC continues to evolve, but so far the industry as a whole (not the IETF) h= as not found their use to have more benefit than risk.
=C2=A0
actually, AFAICS, we have three complete solutions for 3rd = party support,
and that's counting last few months, not from the beginning of DMARC development, which may have produced many different solutions; and i
don't doubt it did, cause problems r obvious and real.
=

To answer Stephen's question, I'm guessing you&= #39;re referring to ATPS (RFC 6541), use of CNAME to point to an externally= -posted key, and a key exchange where an operator give a third party a sign= ing key.=C2=A0 If there are others, I'd like to know what they are.

All three would require the Yahoo!s and AOLs of the world to= grant signing keys, signing key aliases, or ATPS records to every domain t= hat might re-send their mail.=C2=A0 There are some obvious issues with such= solutions: (a) users will have to register every list to which they subscr= ibe and wish to post; (b) they will have to automate DNS updates because ev= ery new entry into that registry will require a new DNS entry; and (c) if a= ny of those third parties gets compromised, it's a big problem for the = domain trying to protect itself.=C2=A0 If any bit of this fails (and I susp= ect (a) is actually the bigger problem), they don't work.

the real problem with 3rd party support for DMARC r DMARC "gate-keeper= s".
they r like FCC now, listening to small minds from big towers, reluctant to make "a small step as a jump for email kind".
=

I don't think that's a fair characterization.= =C2=A0 I think the more likely explanation is that the proposals on the tab= le are much too risky and costly given the benefits.=C2=A0 If a better one = comes along, I'm sure it would be considered.
=C2=A0

having it at IETF as an informational RFC speaks volumes on its fate.
if it was actually beneficial to internet, it would go most common and
regular IETF standards track.


The sta= tus of the current document has nothing at all to do with the quality of wh= at's in it, but rather the procedural path it's taking toward publi= cation.=C2=A0 On the Independent Submission track, the only status availabl= e is Informational.

-MSK
--f46d04462e5e17674604fb2e7f87-- From nobody Fri Jun 6 11:39:00 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D29B61A016C for ; Fri, 6 Jun 2014 11:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 KOoKi78BUh2m for ; Fri, 6 Jun 2014 11:38:58 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0CD1A0156 for ; Fri, 6 Jun 2014 11:38:57 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id C6D2A970B35; Sat, 7 Jun 2014 03:38:50 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id A85401217EB; Sat, 7 Jun 2014 03:38:50 +0900 (JST) From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1402042491.15608.YahooMailNeo@web164601.mail.gq1.yahoo.com> <877g4u2ws4.fsf@uwakimon.sk.tsukuba.ac.jp> <1402063755.61291.YahooMailNeo@web164602.mail.gq1.yahoo.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 07 Jun 2014 03:38:50 +0900 Message-ID: <871tv13mth.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/V1XQ3matl41KpytRYvDrT15QRWw Cc: Vlatko Salaj , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 06 Jun 2014 18:39:00 -0000 Murray S. Kucherawy writes: > To answer Stephen's question, I'm guessing you're referring to ATPS > (RFC 6541), use of CNAME to point to an externally-posted key, and > a key exchange where an operator give a third party a signing key. > If there are others, I'd like to know what they are. Though they *are* solutions technically, I don't consider any of those "complete", in that I presume that Yahoo! has not offered any of those solutions to Mr. Salaj. And, for the reasons you give, confirmed by the fact that it hasn't happened yet, I believe they aren't going to do so any time soon. Steve From nobody Fri Jun 6 11:50:25 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83CE1A0225 for ; Fri, 6 Jun 2014 11:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 wYN2SWjXLgdI for ; Fri, 6 Jun 2014 11:50:22 -0700 (PDT) Received: from nm44.bullet.mail.ne1.yahoo.com (nm44.bullet.mail.ne1.yahoo.com [98.138.120.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B32CC1A0223 for ; Fri, 6 Jun 2014 11:50:21 -0700 (PDT) Received: from [127.0.0.1] by nm44.bullet.mail.ne1.yahoo.com with NNFMP; 06 Jun 2014 18:50:12 -0000 Received: from [98.138.100.113] by nm44.bullet.mail.ne1.yahoo.com with NNFMP; 06 Jun 2014 18:47:25 -0000 Received: from [216.39.60.181] by tm104.bullet.mail.ne1.yahoo.com with NNFMP; 06 Jun 2014 18:47:24 -0000 Received: from [216.39.60.154] by tm17.bullet.mail.gq1.yahoo.com with NNFMP; 06 Jun 2014 18:47:24 -0000 Received: from [127.0.0.1] by omp1071.mail.gq1.yahoo.com with NNFMP; 06 Jun 2014 18:47:24 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 615681.52732.bm@omp1071.mail.gq1.yahoo.com Received: (qmail 889 invoked by uid 60001); 6 Jun 2014 18:47:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402080444; bh=c7ibAqDm4mc/2rFWGCWt23nGlcLVA/a6fYoBVel2gFI=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bfaLwu0miQXb6BbYIZWJtsSqsARYTHi/f56mUIxh7SBUtg9f3vocOYlgXzJChNV2gghMT47H55CJsYiTfZ+mmPMovc40XznphKiU5AR2iMOY82YGO6w4lcR1/rr/mJHVgUM3lgkGzpSj1K8u7hfsdjT8V2visRAFYlNI1RPYbBI= X-YMail-OSG: 2tlc7UQVM1mPd9b69QaiE5L7un.Wq3vIuWGqh6TVy9qD.WT TSIdhHG0LfE_JvJH2uMtJQuYsxEXW5_4jeXVa.bxclQVpg675EeMUGT4YuHN X3n68opp2VHS.9nUQdKpWn7V_z_wgrvoMc3V0ZlZWvwnDJHxbytZj5NtjdTq sVWklBwgTNQcTvI_XghjXEzrqq57lzK4PKjo17XoCoquOc4csuSnfpjk2GGV wz70xQNnmjM0eiOR4myt4TsrZINCATMJh_B3BUI98WN8VcW_8fh2ly.wKwpS q8h2SDlf7bftYQ_5mj9kczpkwColbwAAhzYDhnVnme16VrocIy_EtuclDisG XVtfuIZA3kshz91Tpl5vDtiNlNPb205JKIVuvJzukaBEws8ZmXnxMQ.vwL7c G846TJCJDmiOCEahTJafhfnAMht6L9f69V7FMfmEWh4uY.XgHc3ZwRtyUwUH _9UL2GJB8O8GUuqwah1Ez9gJyT9TlQd.gIpYjHh636rQ2wpvUrbieS5FQ.FH 6Pkht8SxnSFhL.pPVop1.SMFSHVdzTxRRcN8ahb.DVGrf_GhMAmIFMP6nWNn xA.twrEczK795QJoLY.QQTgMsr4RtpXw9Qgh11yQeZ8Jx7lLvfA-- Received: from [79.175.112.242] by web164602.mail.gq1.yahoo.com via HTTP; Fri, 06 Jun 2014 11:47:24 PDT X-Rocket-MIMEInfo: 002.001, T24gRnJpZGF5LCBKdW5lIDYsIDIwMTQgNzozMyBQTSwgU3RlcGhlbiBKLiBUdXJuYnVsbCA8c3RlcGhlbkB4ZW1hY3Mub3JnPiB3cm90ZToKCgo.IERNQVJDIGlzIGRlc2lnbmVkIGZvciBidXNpbmVzcyBlbnRpdGllcyBiaWcgZW5vdWdoIHRvIGJlIHdpbGxpbmcKPiB0byBtYWludGFpbiBNVEFzIHRvIGRvIHRoZSBzaWduaW5nIGZvciB0aGVtLCBvciBwYXkgZm9yIHNvbWVib2R5Cj4gdHJ1c3R3b3J0aHkgdG8gbWFpbnRhaW4gc3VjaCBhbiBNVEEgZm9yIHRoZW0uIFlvdSBhcmVuJ3Qgd2lsbGluZywKPiBzbyABMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1402042491.15608.YahooMailNeo@web164601.mail.gq1.yahoo.com> <877g4u2ws4.fsf@uwakimon.sk.tsukuba.ac.jp> <1402063755.61291.YahooMailNeo@web164602.mail.gq1.yahoo.com> <8738fi2bba.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <1402080444.6636.YahooMailNeo@web164602.mail.gq1.yahoo.com> Date: Fri, 6 Jun 2014 11:47:24 -0700 (PDT) From: Vlatko Salaj To: "Stephen J. Turnbull" In-Reply-To: <8738fi2bba.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/6tIbPs92CtQXaTb9IXvRrKMIv5s Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 06 Jun 2014 18:50:24 -0000 On Friday, June 6, 2014 7:33 PM, Stephen J. Turnbull w= rote:=0A=0A=0A> DMARC is designed for business entities big enough to be wi= lling=0A> to maintain MTAs to do the signing for them, or pay for somebody= =0A> trustworthy to maintain such an MTA for them. You aren't willing,=0A> = so your use case is different.=0A=0Abe free 2 enlighten me with a link to D= MARC draft section saying=0Aexactly that, cause i can't find it.=0A=0Aalso,= u r here directly contradicting bunch of other DMARC developers=0Awho stat= ed exactly the opposite numerous times.=0A=0AASAIK internet standards r sta= ndards for all, not wealthy and mighty.=0Amaybe i'm living in a dream world= .=0A=0A=0A> I'm not sure what you mean by 3rd party support in SPF and DKIM= .=0A=0ASPF: u can put 3rd party servers in ur domain's SPF records that=0As= end email on ur behalf.=0ADKIM: TPA, and other proposed standards similar t= o it. search for it.=0A=0A=0A> Can you put a third party mailbox in From: w= ith SPF? Sure. *And nobody=0A> trusts it, and nobody should.*=0A=0Aif u r s= o nice to make an example for this, cause i sure can't figure=0Aout how wou= ld anything like this work.=0A=0A=0A> Anybody with an account at Yahoo! can= put your mailbox at your domain=0A> in From:, and it will pass SPF authent= ication as Yahoo!. Ditto DKIM.=0A=0Ano they can't. only owners of a domain = address can do such a thing,=0Asince every 3rd party domain email address g= ets validated 1st.=0A=0Aso, ur point, invalid. be free to try ur example ur= self.=0A=0A=0A> Yahoo!'s use of "p=3Dreject" causes you pain?=A0 Tell Yahoo= ! about it.=0A> Or switch to GMail.=0A=0Ai don't rly care about yahoo's "p= =3Dreject". it just shows how=0ADMARC is broken as it is, but it doesn't af= fect me much.=0Anor do i care to use gmail, or trust it.=0A=0A=0A>> actuall= y, AFAICS, we have three complete solutions for 3rd party=0A>> support=0A> = What are they?=A0 AFAICS, there are none, but I'm willing to be=0A> educate= d.=0A=0Ai'm not a search engine. but it seems u r not following this mailin= g list.=0A=0A=0A> A shame, but "there ain't no such thing as a free lunch."= =0A=0Asure there is. it even has a name - FOSS. it's also called=0Aopen sta= ndards. it's also called free books. and let's not forget=0Aall those free = kitchen for homeless.=0Awhy am i even commenting on this...?=0A=0A=0A-- =0A= Vlatko Salaj aka goodone=0Ahttp://goodone.tk From nobody Fri Jun 6 12:09:51 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D511A0220 for ; Fri, 6 Jun 2014 12:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 fTMWsHrodNXl for ; Fri, 6 Jun 2014 12:09:47 -0700 (PDT) Received: from nm31.bullet.mail.gq1.yahoo.com (nm31.bullet.mail.gq1.yahoo.com [98.136.217.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E06F1A0175 for ; Fri, 6 Jun 2014 12:09:47 -0700 (PDT) Received: from [127.0.0.1] by nm31.bullet.mail.gq1.yahoo.com with NNFMP; 06 Jun 2014 19:09:40 -0000 Received: from [98.137.12.188] by nm31.bullet.mail.gq1.yahoo.com with NNFMP; 06 Jun 2014 19:06:41 -0000 Received: from [98.137.12.217] by tm9.bullet.mail.gq1.yahoo.com with NNFMP; 06 Jun 2014 19:06:41 -0000 Received: from [127.0.0.1] by omp1025.mail.gq1.yahoo.com with NNFMP; 06 Jun 2014 19:06:41 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 872281.36807.bm@omp1025.mail.gq1.yahoo.com Received: (qmail 16503 invoked by uid 60001); 6 Jun 2014 19:06:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402081601; bh=2wb0AE0QOPu/Tcq9J8lvurhgqzRsTdsu9niU9XTePro=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Xj3Y1kFJla0mrPAR/BxPzWzqi9XvJFKKI/7mZOq5lyDEow55xWUbaqklVk3oJBMlur4EXUpcOoO2YZJuJ6s2l3sQE0RO9abwWU9nEFzCTsWywSRa7x3bKpoaoDnDayRTc9Hyd/l8PorpHs2apthiNX6mv2m21lJvPo6bWu81RWg= X-YMail-OSG: eLe0VzwVM1k1aVe6no6QQ9lpeGL3dwzq5cNx1rn1tOi5Hnp 54nT1VocLt2oXvSEUHF1sjjTdhHwRErnwXxzXTn9VKkGzdM9ob0blwYoPFiS y_P3It1XA3XNqCDaofO4DTnhXeZlzha4aEdklwu4GsElDL9YKoPZlxMZP2YU ADsZdYgIShp105aJz03X.HAwjBPCaLD5ExPS3W1sgaO3QgSK8jHBUtp.9TJp Um50Szbb_yJFzQDAyyCOVsCFDFHR8581NfwUHoNu9iivIoejxnJ2Q4bm7XFz bEmgAj45arYCLSGBhWe0XuDLIWVHY0XwioWFi.1Oj0_E.FRpuet82MpOL2zu fdZ4weCEf_EtdE9nJSBX3bbLGOOTZg1EzANOgOl5B36J56WM4_Vh5RIi3GbW pKJY1XmnTt64BWx97rYDy_uVxT6mOMuVMWKE7vSIVR5eZ1ar5PgYYXAhJKIW Umj8mdeZGqHK3uSy0TEA6qbdT9.vvwEimLOkGOVCEir2DUx4TKLJM1s3EBOv 7hrwThrbwsg0XC.EmGfss9tOVJvECapwD1yj28Jn0Rnf5arQSmLXsHjcFLuY si_ratJWK55AZ0_KU8IRe0MEsuPY.HW_VoQlgwnAWRvTMh07xvQ-- Received: from [79.175.112.242] by web164602.mail.gq1.yahoo.com via HTTP; Fri, 06 Jun 2014 12:06:41 PDT X-Rocket-MIMEInfo: 002.001, T24gRnJpZGF5LCBKdW5lIDYsIDIwMTQgNzo1MCBQTSwgTXVycmF5IFMuIEt1Y2hlcmF3eSA8c3VwZXJ1c2VyQGdtYWlsLmNvbT4gd3JvdGU6CgoKPiBQYXlQYWwsIEJhbmsgb2YgQW1lcmljYSwgYW5kIEZhY2Vib29rIGF0IGxlYXN0IGhhdmUgYmVlbiB1c2luZyBpdAo.IGZvciBhIGxvbmcgdGltZSwgYW5kIEknZCBiZXQgeW91IGRpZG4ndCBldmVuIG5vdGljZS4KCmkgZGlkIG5vdGljZSBidW5jaCBvZiBNVEEgZXJyb3JzIGluIGluZnJhc3RydWN0dXJlIGknbSBzdXBwb3J0aW5nLCB0aGF0CnByZXZpb3VzbHkBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1402042491.15608.YahooMailNeo@web164601.mail.gq1.yahoo.com> <877g4u2ws4.fsf@uwakimon.sk.tsukuba.ac.jp> <1402063755.61291.YahooMailNeo@web164602.mail.gq1.yahoo.com> Message-ID: <1402081601.11792.YahooMailNeo@web164602.mail.gq1.yahoo.com> Date: Fri, 6 Jun 2014 12:06:41 -0700 (PDT) From: Vlatko Salaj To: "Murray S. Kucherawy" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/jJcWxv24m7bo5-MsyykMOR0_teg Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 06 Jun 2014 19:09:48 -0000 On Friday, June 6, 2014 7:50 PM, Murray S. Kucherawy wrote: > PayPal, Bank of America, and Facebook at least have been using it > for a long time, and I'd bet you didn't even notice. i did notice bunch of MTA errors in infrastructure i'm supporting, that previously weren't there, all DMARC errors on legitimate email. >> i would rather say it's a case of "history repeating". how many >> email policy protocols were developed in last 10y? a bunch of them. >> all of them failed. all of them "historic" now. > Which ones, other than ADSP? i'm not a search engine. but one could even argue that SPF, Sender-ID and bunch of DKIM addons were exactly in that group. >> actually, AFAICS, we have three complete solutions for 3rd party support, > To answer Stephen's question, I'm guessing you're referring to ATPS, > use of CNAME to point to an externally-posted key, and a key exchange where > an operator give a third party a signing key. nope, i'm not referring to any of DKIM's 3rd party support. we r in DMARC mailing list. i'm referring to DMARC 3rd party support proposals, all of which have been mentioned many times on this mailing list. > I think the more likely explanation is that the proposals on the table > are much too risky and costly given the benefits. i see no risks with me publishing a DMARC records saying exactly this: do DMARC alignment against yahoo domain too. and i'm sure u can't find any, other than breaching yahoo itself, my account, or my dns records, all of which isn't DMARC's field of protection anyway. be free to make an example, i would really like to see what additional risks and costs u r mentioning. if possible, ofc. >> having it at IETF as an informational RFC speaks volumes on its fate. > The status of the current document has nothing at all to do with the quality > of what's in it, but rather the procedural path it's taking toward > publication. anyone can trust whatever they like. but considering u work for ur DMARC bosses as a document shepard... i'll just consider u biased in evaluating this. nobody interested to fix email would publish such a protocol as independent RFC. more brains, better solutions, more contributions, better standard... there have been many calls to make a working group. but, they don't want a working group, they don't want somebody else taking control, fixing stuff that's broken, cause they would be forced to introduce support for it. why would they care, right? they build it for themselves. very caring, for sure. no wonder major US ICT companies r losing reputation. so many times we make same mistakes... -- Vlatko Salaj aka goodone http://goodone.tk From nobody Fri Jun 6 12:10:42 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254A01A0230 for ; Fri, 6 Jun 2014 12:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 46BUv65k5rZU for ; Fri, 6 Jun 2014 12:10:38 -0700 (PDT) Received: from msginmsm04vapp.fmr.com (ltm-fwus409m-410m.fidelity.com [155.199.16.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BB9C1A0220 for ; Fri, 6 Jun 2014 12:10:37 -0700 (PDT) Received: from msgrtphc03win.DMN1.FMR.COM (MSGRTPHC03WIN.dmn1.fmr.com [10.95.11.183]) by msginmsm04vapp.fmr.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.1) with ESMTP id s56JAIN4015789 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Fri, 6 Jun 2014 19:10:19 GMT X-DKIM: OpenDKIM Filter v2.1.3 msginmsm04vapp.fmr.com s56JAIN4015789 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fmr.com; s=2012-05-26; t=1402081819; bh=r4pAu8r0NTeLJ3ekvysEDjC3ehm540IGBOY1OxeXKN0=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=vW03t97PejOLi6Rxe+QsrGtKcRNepn6E8Clz6CIJLWiAwIv8UWvHT9le/W68JukxW v1bMdmMqaf3APrPEhx0LoWAgdsYLeZbBsnptETTmBLEncPcyRNXV0K/j47/qWPxktd 9jbd5rANpMs4EsPUrqmS4XQ5mrOKhZ4TweYCMY6Y= Received: from MSGRTPCCRF2WIN.DMN1.FMR.COM ([10.95.12.32]) by msgrtphc03win.DMN1.FMR.COM ([10.95.11.183]) with mapi; Fri, 6 Jun 2014 15:10:18 -0400 From: "Popowycz, Alex" To: Vlatko Salaj , "Stephen J. Turnbull" Date: Fri, 6 Jun 2014 15:10:17 -0400 Thread-Topic: [dmarc-ietf] confusing 3rd party support so it remains out Thread-Index: Ac+BuCy8K0FAg+U4RjOPR3FLxYTe9gAAmHRw Message-ID: <9495B91F5CA0E24C9161D71CD46E43DB011C8D62B7FE@MSGRTPCCRF2WIN.DMN1.FMR.COM> References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1402042491.15608.YahooMailNeo@web164601.mail.gq1.yahoo.com> <877g4u2ws4.fsf@uwakimon.sk.tsukuba.ac.jp> <1402063755.61291.YahooMailNeo@web164602.mail.gq1.yahoo.com> <8738fi2bba.fsf@uwakimon.sk.tsukuba.ac.jp> <1402080444.6636.YahooMailNeo@web164602.mail.gq1.yahoo.com> In-Reply-To: <1402080444.6636.YahooMailNeo@web164602.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/pvXH1akityW6s-D6tttIEBEJaaI Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 06 Jun 2014 19:10:40 -0000 As an implementer of DMARC in a large institution and also on my personal d= omain, I don't believe there are limitations in the deployment of the proto= col solely at the large scale, as along as individuals doing so understand = what potential ramifications it might have. As admittedly a stretch analog,= S/MIME could be viewed similarly since it "breaks" email in MUAs that don'= t support it. On the institutional side, it's been extremely successful in mitigating the= risks stemming from email attacks (e.g. phishing) for traffic destined to = mailboxes supporting the protocol. On the personal side, even though my volumes are but a trickle, it's been e= ffective in ensuring the integrity of my domain from spammers, etc from MTA= s as far flung as Sudan, Vietnam, Argentina, India and many other locations= around the globe. So I would have to say out of personal experience that i= t's not solely for the "wealthy and mighty" as you put it. My point being that even individuals care to protect those their message fo= r those who might otherwise be tricked into some malicious activity because= of the trust placed on the source address (and the individual behind it). = While DMARC may have had a focus on transactional messaging, its use should= n't be precluded from other situations. -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Vlatko Salaj Sent: Friday, June 06, 2014 2:47 PM To: Stephen J. Turnbull Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out On Friday, June 6, 2014 7:33 PM, Stephen J. Turnbull w= rote: > DMARC is designed for business entities big enough to be willing > to maintain MTAs to do the signing for them, or pay for somebody > trustworthy to maintain such an MTA for them. You aren't willing, > so your use case is different. be free 2 enlighten me with a link to DMARC draft section saying exactly that, cause i can't find it. also, u r here directly contradicting bunch of other DMARC developers who stated exactly the opposite numerous times. ASAIK internet standards r standards for all, not wealthy and mighty. maybe i'm living in a dream world. > I'm not sure what you mean by 3rd party support in SPF and DKIM. SPF: u can put 3rd party servers in ur domain's SPF records that send email on ur behalf. DKIM: TPA, and other proposed standards similar to it. search for it. > Can you put a third party mailbox in From: with SPF? Sure. *And nobody > trusts it, and nobody should.* if u r so nice to make an example for this, cause i sure can't figure out how would anything like this work. > Anybody with an account at Yahoo! can put your mailbox at your domain > in From:, and it will pass SPF authentication as Yahoo!. Ditto DKIM. no they can't. only owners of a domain address can do such a thing, since every 3rd party domain email address gets validated 1st. so, ur point, invalid. be free to try ur example urself. > Yahoo!'s use of "p=3Dreject" causes you pain?=A0 Tell Yahoo! about it. > Or switch to GMail. i don't rly care about yahoo's "p=3Dreject". it just shows how DMARC is broken as it is, but it doesn't affect me much. nor do i care to use gmail, or trust it. >> actually, AFAICS, we have three complete solutions for 3rd party >> support > What are they?=A0 AFAICS, there are none, but I'm willing to be > educated. i'm not a search engine. but it seems u r not following this mailing list. > A shame, but "there ain't no such thing as a free lunch." sure there is. it even has a name - FOSS. it's also called open standards. it's also called free books. and let's not forget all those free kitchen for homeless. why am i even commenting on this...? --=20 Vlatko Salaj aka goodone http://goodone.tk _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Fri Jun 6 12:46:25 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340D01A0119 for ; Fri, 6 Jun 2014 12:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 uLpLOLZjseKT for ; Fri, 6 Jun 2014 12:46:21 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81DD71A00FC for ; Fri, 6 Jun 2014 12:46:21 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id uq10so1268820igb.14 for ; Fri, 06 Jun 2014 12:46:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LKzqAV1oZDAyiHe4P3k2bTDncZa5X4UCtADK49R2j/k=; b=oVILtv7Pwtae/ckcB1XZveC399gQZ1mlp5k+xCJdULJSQKoGU2Sb7y1YbBaxU0GfXZ l9f/SwiAyLeffsHoXFjZGcvKTS1py4J9ha2XdAoedik5Lg4VnXe9jgPq/XYCsrQpVc9Q 5gToUDU7Ggo67ZaQMda+I1MgZh9ciA324jtFf4SblKK+lN9PmF/NRRm3JUI4hqLNUR6C ZYcscr3y9qUCFBF9bc6TnDKcRuZoLD4whIu1YWo27uHjMBJo96nmXzcbTXpHf9+JJSSA X48ed4vIv5PFhRS+2HXxPcRbfoiYE3hHQ2L5M9ZSF2rW4Ql5vMPeX32Az8Vvy3idzO2d KUbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LKzqAV1oZDAyiHe4P3k2bTDncZa5X4UCtADK49R2j/k=; b=TEtA+CZs6Av5xjMY4epqgVZRbrTj4Mq/1vRZfY4sb0f3GcxuBdA6t6fXh9tK2faNw6 U3Ts2wG5d1n+G9zi+RaSZVEjjLQz1c7pAU3LFQElJ31hXp6OcG4ug8EIb2+3Ghg//HQe 1nlM2UCVLSOQfqDCZqgeHP3hxBLbOcjSl/Pqkpv/Ef/IpSR81koFDkc0Wmvcq/r2xC5h B/L7lVcHi53/Dr2SBGdisjHWCiCbPnDHRAhHRvIpZP2PRE5aDrtpDZ/eOCvJ6D8pXaIi ZpEoABBV2bd38NCx729HVyQL0fQN/wyH0nbJlnFIfn6YsgBI2EF+sVcgk7VOKBhLv3fO IaDQ== X-Gm-Message-State: ALoCoQkpRl36YvXBbMvQK6PNgxWtc2teXfQQqWUx0D+Uetk/mg3P7j9rXAq6tAbXFArez9PY/aM+ MIME-Version: 1.0 X-Received: by 10.43.117.133 with SMTP id fm5mr8948912icc.3.1402083974301; Fri, 06 Jun 2014 12:46:14 -0700 (PDT) Received: by 10.64.213.73 with HTTP; Fri, 6 Jun 2014 12:46:14 -0700 (PDT) In-Reply-To: <1402080444.6636.YahooMailNeo@web164602.mail.gq1.yahoo.com> References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1402042491.15608.YahooMailNeo@web164601.mail.gq1.yahoo.com> <877g4u2ws4.fsf@uwakimon.sk.tsukuba.ac.jp> <1402063755.61291.YahooMailNeo@web164602.mail.gq1.yahoo.com> <8738fi2bba.fsf@uwakimon.sk.tsukuba.ac.jp> <1402080444.6636.YahooMailNeo@web164602.mail.gq1.yahoo.com> Date: Fri, 6 Jun 2014 12:46:14 -0700 Message-ID: From: Brandon Long To: Vlatko Salaj Content-Type: multipart/alternative; boundary=bcaec517c9203bff8204fb301dc0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/vdZF1okHvJzyOS1EZeVhIFPZ8I8 Cc: "Stephen J. Turnbull" , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 06 Jun 2014 19:46:23 -0000 --bcaec517c9203bff8204fb301dc0 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 6, 2014 at 11:47 AM, Vlatko Salaj wrote: > On Friday, June 6, 2014 7:33 PM, Stephen J. Turnbull > wrote: > > > > DMARC is designed for business entities big enough to be willing > > to maintain MTAs to do the signing for them, or pay for somebody > > trustworthy to maintain such an MTA for them. You aren't willing, > > so your use case is different. > > be free 2 enlighten me with a link to DMARC draft section saying > exactly that, cause i can't find it. > I think its inherent in it. To use DMARC, you have to be able to authenticate your mail using either SPF or DKIM. Doing that requires running a server that does it or using a service which does it. There is nothing that says that YMail has to support your use case, if you want DMARC auth'd mail for your domain, you're going to have to use a service which supports it. Either run your own, or pay someone who offers the service. There are those who think we must move to an authenticated sender world. In that world, either we have a third party auth system (which we don't), or third parties need to have the ability to provide auth (upload a dkim key, include: for SPF). Neither or those things are particularly in the wheelhouse for the average consumer on a free service, and its not clear to me that those services would be willing to add the complexity to handle it, knowing that the user is then on the hook for editing domain entries. Heck, the domain registrars are more probably more likely to offer smtp-msa service instead... well, if there's enough money in it for them. Brandon --bcaec517c9203bff8204fb301dc0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Jun 6, 2014 at 11:47 AM, Vlatko Salaj <vlatko.salaj@goodone.tk> wrote:
On Friday, June 6, 2014 7:33= PM, Stephen J. Turnbull <stephen@= xemacs.org> wrote:


> DMARC is designed for business entities big enough to be willing
> to maintain MTAs to do the signing for them, or pay for somebody
> trustworthy to maintain such an MTA for them. You aren't willing,<= br> > so your use case is different.

be free 2 enlighten me with a link to DMARC draft section saying
exactly that, cause i can't find it.

I think its inherent in it. =C2=A0To use DMARC, you have to be able to au= thenticate your mail using either SPF or DKIM. =C2=A0Doing that requires ru= nning a server that does it or using a service which does it.

There is nothing that says that YMail has to support yo= ur use case, if you want DMARC auth'd mail for your domain, you're = going to have to use a service which supports it. =C2=A0Either run your own= , or pay someone who offers the service.

There are those who think we must move to an authentica= ted sender world. =C2=A0In that world, either we have a third party auth sy= stem (which we don't), or third parties need to have the ability to pro= vide auth (upload a dkim key, include: for SPF). =C2=A0Neither or those thi= ngs are particularly in the wheelhouse for the average consumer on a free s= ervice, and its not clear to me that those services would be willing to add= the complexity to handle it, knowing that the user is then on the hook for= editing domain entries. =C2=A0Heck, the domain registrars are more probabl= y more likely to offer smtp-msa service instead... well, if there's eno= ugh money in it for them.

Brandon

--bcaec517c9203bff8204fb301dc0-- From nobody Fri Jun 6 12:53:53 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D281A00FC for ; Fri, 6 Jun 2014 12:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 6crMDmtpP9Hi for ; Fri, 6 Jun 2014 12:53:50 -0700 (PDT) Received: from nm42.bullet.mail.ne1.yahoo.com (nm42.bullet.mail.ne1.yahoo.com [98.138.120.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4000C1A0078 for ; Fri, 6 Jun 2014 12:53:50 -0700 (PDT) Received: from [127.0.0.1] by nm42.bullet.mail.ne1.yahoo.com with NNFMP; 06 Jun 2014 19:53:43 -0000 Received: from [98.138.101.132] by nm42.bullet.mail.ne1.yahoo.com with NNFMP; 06 Jun 2014 19:50:49 -0000 Received: from [216.39.60.184] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 06 Jun 2014 19:50:49 -0000 Received: from [98.137.12.53] by tm20.bullet.mail.gq1.yahoo.com with NNFMP; 06 Jun 2014 19:50:48 -0000 Received: from [127.0.0.1] by omp1068.mail.gq1.yahoo.com with NNFMP; 06 Jun 2014 19:50:48 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 920401.98040.bm@omp1068.mail.gq1.yahoo.com Received: (qmail 19562 invoked by uid 60001); 6 Jun 2014 19:50:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402084248; bh=goYc+E4NSaSYc/AaMhrt6tvQE4EyhkEJBi5eRWXMvWo=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=stF8WdCgYPSGPv+oTAVrSExa1rzyxRfq0qo9UhZ/MWSTTqDZpyNcXV0jR9WRi/vaJwX2QibVVGaxEsQoJl/E6KUDjB+IGdE9x1E3R4IFN8YDspUFaH+yGcG/lAMzmLsuwtfV1be85uJu/p6LcOmiXW7RMGQ85RtTNIKeuDFc4hQ= X-YMail-OSG: H2yepakVM1kR6J5pnQTIzaZeh5Q9Ca_o3Nlp9XFSINa5NE1 NkMYyLw4zb8GNKvLwk.tOSVmH96Z8QvCbb.xHItf4f9vkhoGkxDhIb.IQGp6 1ZCu0.XqhLPFa0VIsmRBH.sgVSwW1R1w8mVnqg_1r4F2oOcItuHSO1iPRKeb GEZ4Kk18AmnKTAJVMwYALgg64sTNuQQ4moWb.E2e3yCxt1iMdm507oyQ72.N qg4hYmPVfi2i7Y8H0fPXmpwDB9uV8KOveXH9pgxmbb137Yctnrm8.yoQIAFj AMqhDkGw5Cid.gPi4oKjW5uw6N1YRsi4I2k5t8UqVbcRx785sxtAZZBQZf4I jm5rZJPYZO5.P60AkbsAFxZmsvVO2x6W3aqth0JjhZxw7VV88x5JFFVTL1ow zEH4Nu9NrtrEBJ2yk3YkciC07ZSo5Ewca7UXTmdzxpK68_9Bo8evkMlNRuvr mrEE.ziupmtUEpIc_pFMaxqNAQA7WQguPw7lnFgqr5Zn7wBIIdy2RnwT325w yWWp4Uzfr14r3GRVwbehAThJxTW9FcSZlgWqSYlCPiz.Y.h6f0MyAlbVYszR fR4y8s1oOBqnhRiMDbMkrttpSsmLDkIyUSLf6AWVL.jJfmLbtOKCPZdJxW_l KC0PGU_i6OApKSqSMJtVIL5C.Uw-- Received: from [79.175.112.242] by web164606.mail.gq1.yahoo.com via HTTP; Fri, 06 Jun 2014 12:50:48 PDT X-Rocket-MIMEInfo: 002.001, T24gRnJpZGF5LCBKdW5lIDYsIDIwMTQgOToxMCBQTSwgIlBvcG93eWN6LCBBbGV4IiA8QWxleC5Qb3Bvd3ljekBmbXIuY29tPiB3cm90ZToKCgo.IE9uIHRoZSBpbnN0aXR1dGlvbmFsIHNpZGUsIGl0J3MgYmVlbiBleHRyZW1lbHkgc3VjY2Vzc2Z1bAo.IGluIG1pdGlnYXRpbmcgdGhlIHJpc2tzIHN0ZW1taW5nIGZyb20gZW1haWwgYXR0YWNrcyAoZS5nLiBwaGlzaGluZykKPiBmb3IgdHJhZmZpYyBkZXN0aW5lZCB0byBtYWlsYm94ZXMgc3VwcG9ydGluZyB0aGUgcHJvdG9jb2wuCj4gT24gdGhlIHBlcnNvbmEBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1402042491.15608.YahooMailNeo@web164601.mail.gq1.yahoo.com> <877g4u2ws4.fsf@uwakimon.sk.tsukuba.ac.jp> <1402063755.61291.YahooMailNeo@web164602.mail.gq1.yahoo.com> <8738fi2bba.fsf@uwakimon.sk.tsukuba.ac.jp> <1402080444.6636.YahooMailNeo@web164602.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8D62B7FE@MSGRTPCCRF2WIN.DMN1.FMR.COM> Message-ID: <1402084248.69843.YahooMailNeo@web164606.mail.gq1.yahoo.com> Date: Fri, 6 Jun 2014 12:50:48 -0700 (PDT) From: Vlatko Salaj To: "Popowycz, Alex" In-Reply-To: <9495B91F5CA0E24C9161D71CD46E43DB011C8D62B7FE@MSGRTPCCRF2WIN.DMN1.FMR.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/QVp9OQi58VEXwRfLsgAOvaDjSm0 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 06 Jun 2014 19:53:52 -0000 On Friday, June 6, 2014 9:10 PM, "Popowycz, Alex" wrote: > On the institutional side, it's been extremely successful > in mitigating the risks stemming from email attacks (e.g. phishing) > for traffic destined to mailboxes supporting the protocol. > On the personal side, even though my volumes are but a trickle, > it's been effective in ensuring the integrity of my domain from > spammers, etc from MTAs as far flung as Sudan, Vietnam, Argentina, > India and many other locations around the globe. interesting. let me guess, none of these undocumented examples is fmr.com, the domain u r posting here from, which, as of today, isn't protected by any DMARC policy record, but merely a "p=none", which, ofc, isn't a protection as u specified in ur post. since there's no webserver behind that domain, i guess that's ur personal domain, but i'm willing to accept it's something completely else. or u meant DMARC essentially didn't protect u, but provided reports upon which u might have had acted. not that such case counts as a point towards DMARC protection usability or efficiency, actually; it dismisses ur DMARC praise completely, instead. if that's the case, i'll guess i'm just not fool enough. > While DMARC may have had a focus on transactional > messaging, its use shouldn't be precluded from other > situations. sure it SHOULDn't. but it is. i'm still waiting on 3rd party support. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Fri Jun 6 13:17:04 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55BAB1A0291 for ; Fri, 6 Jun 2014 13:16:53 -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_72=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 Rbqwyu_WRUtP for ; Fri, 6 Jun 2014 13:16:51 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA921A0289 for ; Fri, 6 Jun 2014 13:16:51 -0700 (PDT) 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, 6 Jun 2014 22:16:43 +0200 Message-ID: From: "J. Gomez" To: Vlatko Salaj References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> <96EA87B2959246E4B4916A0DEF9CAF4A@fgsr.local> <1402044548.59713.YahooMailNeo@web164603.mail.gq1.yahoo.com> Date: Fri, 6 Jun 2014 22:17: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: http://mailarchive.ietf.org/arch/msg/dmarc/1VSMAhDwQ2hugt87m3FHQ2HCy9w Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 06 Jun 2014 20:16:54 -0000 On Friday, June 06, 2014 10:49 AM [GMT+1=3DCET], Vlatko Salaj wrote: > On Friday, June 6, 2014 3:55 AM, J. Gomez wrote: >=20 >=20 > > When you said "i have trust in ymail to send email on behalf of my > > domain", were you meaning that you wanted ymail using your domain > > in the MAIL-FROM envelope (1), or in the Header-From field (2)? >=20 > (1) no. > (2) yes. >=20 >=20 > > If (1), that would be something unreasonable to expect from ymail, > > and please explain why would you need it. >=20 > yes, as i said, no one expects such a broken behavior, so i don't. >=20 >=20 > > If (2), please explain whether ymail allows it or not, >=20 > it does. >=20 >=20 > > and if not please explain why would that be a DMARC limitation > > instead=20 > > of a ymail limitation. >=20 > well, since it does support it, i guess there's nothing to answer > here, but let me make as plain as possible example: >=20 > =3D=3D=3D > FROM header: vlatko.salaj@goodone.tk > MAIL-FROM envelope: my_yahoo_account@yahoo.com > DKIM domain: yahoo.com > =3D=3D=3D >=20 > results: > 1. mail legitimate; validated by sending ESP using: > 2. valid DKIM @yahoo.com, > 3. servers validated by SPF at yahoo.com, > 4. goodone.tk SPF records r of no importance here, > 5. DMARC is unable to authenticate this email: no 3rd party support. I think DMARC would be able to authenticate that email as long as = GOODONE.TK included in his SPF record the SPF record of YAHOO.COM. In = that case, DMARC checking for DKIM would fail, but DMARC checking for = SPF would find that the Header-From domain is aligned with SPF, = therefore the net result would be a DMARC pass. If the particular SPF record of YAHOO.COM does not lend itself to be = SPF-included with third parties (as it uses the "redirect" mechanism), = that is not a SPF problem nor a DMARC problem, instead it is a YAHOO.COM = problem and an implicit declaration from YAHOO.COM that your use case = does not fit with them (but if you don't have your own MTA, then again = your use case could indeed fit with YAHOO.COM). > > Please, explain with more detail how is your usage > > scenario excluded by DMARC. I fail to see how, as > > described by you up to now, is your usage sceneario > > impeded by DMARC instead of by ymail/whatever, given > > that DMARC leverages SPF and SPF has the concept > > of includes available to you. >=20 > i hope u understand now. if not, i won't be able to > provide more str8-forward examples of this scenario, > cause i'm not able to specify it more clearly than this. I don't understand why you say DMARC impedes your described use case, as = I keep seeing that a simple SPF-include in your own SPF record --which = you control yourself-- would make your use case DMARC-compliant. >=20 > i hope others understand my example. I hope so too, so that I can be enlightened about why am I wrong. Regards, J.Gomez From nobody Fri Jun 6 13:18:09 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB491A023E for ; Fri, 6 Jun 2014 13:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 XBwfmuukI7bc for ; Fri, 6 Jun 2014 13:18:05 -0700 (PDT) Received: from nm36.bullet.mail.ne1.yahoo.com (nm36.bullet.mail.ne1.yahoo.com [98.138.229.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CBB01A00FC for ; Fri, 6 Jun 2014 13:18:05 -0700 (PDT) Received: from [127.0.0.1] by nm36.bullet.mail.ne1.yahoo.com with NNFMP; 06 Jun 2014 20:17:58 -0000 Received: from [98.138.100.116] by nm36.bullet.mail.ne1.yahoo.com with NNFMP; 06 Jun 2014 20:15:10 -0000 Received: from [98.137.12.190] by tm107.bullet.mail.ne1.yahoo.com with NNFMP; 06 Jun 2014 20:14:50 -0000 Received: from [98.137.12.233] by tm11.bullet.mail.gq1.yahoo.com with NNFMP; 06 Jun 2014 20:14:49 -0000 Received: from [127.0.0.1] by omp1041.mail.gq1.yahoo.com with NNFMP; 06 Jun 2014 20:14:49 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 899170.50256.bm@omp1041.mail.gq1.yahoo.com Received: (qmail 95577 invoked by uid 60001); 6 Jun 2014 20:14:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402085689; bh=1gz2nd9ZhjHegVp5ieJEwZAWjEanU2scUSIP59NIG4Y=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=CYzhd6B1IucPCl+ofHaUrXlD9Dm7mYTVeNV3+rHCwiDNG80Rr9WUOByPJo1RR5zjU5QNJJWI2pEDZ+3aeVqHNlNbS8EIwTXmyDrjZDRWVRm4OHyBep6GHWXU6iMxt+7l63Lx/CnzIhZkfxZUnFUXQG87/OnEJaIBY0rrVd+xYrI= X-YMail-OSG: xkpeOcgVM1nXY_tKjZk9mfwMcGeKloEj3_bFRJPAfodID6k z_nVQn7PATGyCKRKkTMLTmdlpmGc1nfTzQixmLWx7WPXqM9iZHjWPgf4yn1R 5jZ9K3cVfXL1OeWpsOTHOS.s0RGEwNCIcKCD9U4X84O6bDMIbTro9hdKOE3u puIrB7BWFra9v6668XWS1gF5o0LazQtJ9Ob5uhuNFWPgd5d.UX0IOwR3RTOo JoXcqxf1oOllL9gaadC0tjQrCXsqdrtoKKyF1nx1fQ_D8I6iqov0FCsBtzzB vtZvEFQzRov_8AFPA80ryQLwlFwNMnftmZpAxhThQtxbgJkb9fcuGnA_01gq u2LPuDKjPqVrckvS7KdOzU21BbVfnIamuoKnSRkvgVVPdzDwhdUHbto2gnlE 5AC6YeP5a2fvQG9eyaI8VSjrGF5xwb27zPd.pYBWnO1kB1Qa.OvcIatgYIWa tw.56Z1qV8pgW_Ycy2wntAJ8yrDzQe9sUcX.X1j1JGgIzmfZdE8MOo33Qj0P iLmgTqZcJWSXGYLtMpyQQlsveRWFEq636p11pHGq0SStsbodK86Y8o7Stkks L5oHSnVU9Fnn5SEkfYyhX5teUCp3K.7NcLvKLYNNmfJy_rOrR814- Received: from [79.175.112.242] by web164604.mail.gq1.yahoo.com via HTTP; Fri, 06 Jun 2014 13:14:49 PDT X-Rocket-MIMEInfo: 002.001, T24gRnJpZGF5LCBKdW5lIDYsIDIwMTQgOTo0NiBQTSwgQnJhbmRvbiBMb25nIDxibG9uZ0Bnb29nbGUuY29tPiB3cm90ZToKCgo.IFRvIHVzZSBETUFSQywgeW91IGhhdmUgdG8gYmUgYWJsZSB0byBhdXRoZW50aWNhdGUgeW91cgo.IG1haWwgdXNpbmcgZWl0aGVyIFNQRiBvciBES0lNLgoKaSBhbS4KCgo.IERvaW5nIHRoYXQgcmVxdWlyZXMgcnVubmluZyBhIHNlcnZlciB0aGF0IGRvZXMgaXQgb3IKPiB1c2luZyBhIHNlcnZpY2Ugd2hpY2ggZG9lcyBpdC4KCmkgYW0gLSB5bWFpbC4gaXQgYXV0aGVudGljYXQBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1402042491.15608.YahooMailNeo@web164601.mail.gq1.yahoo.com> <877g4u2ws4.fsf@uwakimon.sk.tsukuba.ac.jp> <1402063755.61291.YahooMailNeo@web164602.mail.gq1.yahoo.com> <8738fi2bba.fsf@uwakimon.sk.tsukuba.ac.jp> <1402080444.6636.YahooMailNeo@web164602.mail.gq1.yahoo.com> Message-ID: <1402085689.90267.YahooMailNeo@web164604.mail.gq1.yahoo.com> Date: Fri, 6 Jun 2014 13:14:49 -0700 (PDT) From: Vlatko Salaj To: Brandon Long In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/3kjLm0L3M2zVOu2m3SvPnOhovOA Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 06 Jun 2014 20:18:08 -0000 On Friday, June 6, 2014 9:46 PM, Brandon Long wrote: > To use DMARC, you have to be able to authenticate your > mail using either SPF or DKIM. i am. > Doing that requires running a server that does it or > using a service which does it. i am - ymail. it authenticates it's own DKIM signatures and SPF servers on my email perfectly. for free, imagine that. > There is nothing that says that YMail has to support your use case. ymail supports my use case. DMARC doesn't: it needs 3rd party support. i need nothing from ymail, they have been doing wonderful job for me 13y now. i need DMARC alignment rigidity gone. and some wise ppl to accept it. well, we may lack that, i guess. > There are those who think we must move to an authenticated sender world. > In that world, either we have a third party auth system (which we don't), > or third parties need to have the ability to provide auth (upload a dkim key, > include: for SPF). or simply we add 3rd party support to DMARC. and walla, we r there. ps. all messages to this mailing list r failing DMARC. just so u ppl know. my forwarder keeps annoying me about that. please fix it. ohhh, yes, u can't. sorry for mentioning. at least u can say receivers u don't care about DMARC, right? imagine if they didn't include DMARC-ignore in records, either. btw, i do find it ironic how messages to a mailing list about DMARC r failing the same protocol they mean to discuss. just the way world works, i guess. ppl make broken stuff, then defend them as if sky will fall if they gets fixed. pps. i'll just turn off my DMARC testing scripts... i have enough data. anybody wants to see it? actually, there's nothing to tell what i didn't say already anyways. ppps. i'm quite sure many ppl here have enough of my posts for a lifetime. so, i'll just stop replying now, as there's very little i can additionally say, beyond mocking various posters for their obvious incapability to follow my posts or whatever, which isn't my intention, interest or pleasure. i will keep in touch if u eventually fix DMARC, sure. but i predict u won't. so, farewell. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Fri Jun 6 13:33:28 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB2E1A01B2 for ; Fri, 6 Jun 2014 13:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 bP3ANPP6uNf7 for ; Fri, 6 Jun 2014 13:33:25 -0700 (PDT) Received: from nm40.bullet.mail.ne1.yahoo.com (nm40.bullet.mail.ne1.yahoo.com [98.138.229.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B701A1A0025 for ; Fri, 6 Jun 2014 13:33:24 -0700 (PDT) Received: from [127.0.0.1] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 06 Jun 2014 20:33:17 -0000 Received: from [98.138.101.128] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 06 Jun 2014 20:30:18 -0000 Received: from [216.39.60.181] by tm16.bullet.mail.ne1.yahoo.com with NNFMP; 06 Jun 2014 20:30:01 -0000 Received: from [98.137.12.209] by tm17.bullet.mail.gq1.yahoo.com with NNFMP; 06 Jun 2014 20:30:01 -0000 Received: from [127.0.0.1] by omp1017.mail.gq1.yahoo.com with NNFMP; 06 Jun 2014 20:30:01 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 107444.90864.bm@omp1017.mail.gq1.yahoo.com Received: (qmail 94995 invoked by uid 60001); 6 Jun 2014 20:30:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402086601; bh=EeMmjdh6TNCAYFoeH7jcHdforwQsCylvdXCobHMVSPg=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=CwgZibRITg3vAirpNhPmhdXEW8uCqA0ss1bTXlRWXYidnhm5va/Hnp+ZnCDt8x/CIAvboDP7WJkjQut9GDgK5ID6jkOgKIRpvYaM1pH4ruMrzN7QmgT9eBqo7w2t7BLxg47QErZRk6y+5UBxd5IlBGPIssI0GwOVI7lf0eEqyjs= X-YMail-OSG: dinPELMVM1mTXeC3jOsSH6UK1PW4L.fMo1gUDKzGF2ToIwL EIsbd8263RXY0Gi4YWA3PlWTRiVX9rJV396Q8Ow22sSk1Og3vfzo3gfRpp6L 7QsftqOi88cN_kWkZbiOebvI_tVOA64kCvpFebWhH_Dy7XtZZ5TMI5KrZCq3 65jXXWorsUgs6jOne04MZGwBqXhu4TT9tkTl8bBH.CxZ5GSPtm_Jpo0Ok6GL MeRuKuXE7fLWCa02QwqL7bnAU1zQDfqBhVJMR.5gBubpep1_mXFj5h2ELw4l c1b.fcrSM7JsnzDuuSU3UbOvBu26iyg3adsCFuhi5XBGIh7puCuk7b2ORzv5 4Z15fxb5TBBy_6jpW97gvohIDOPwlw_gUMZ.aWIXkq0.uKpqFSexODdUIwA0 GPRcXbL60ePLWAnEzuH1hPVQPmRzr9CqqlUTUJH1khMiRkdxbcibZHyieaAr MscwQT.ZkwljdyQ6AkhWoC817tMvpU6zNPfz9qAZaiGaK3x7AtPtqk3hCGth QOPX8Wcs2TCwtGjuqXWrRn1my1Yn2idChRFXIlsubucX3k3yp4dnY956EKIB sLGsA1J_H7HLW0sXBwvuBT.vCTaW1ZA2X0Q9No4nemZ8naao35WHTruq1loN FHTdAkt2Q8y67b41m5r6.FrL8wFpnIutg4A-- Received: from [79.175.112.242] by web164602.mail.gq1.yahoo.com via HTTP; Fri, 06 Jun 2014 13:30:00 PDT X-Rocket-MIMEInfo: 002.001, T24gRnJpZGF5LCBKdW5lIDYsIDIwMTQgMTA6MTYgUE0sIEouIEdvbWV6IDxqZ29tZXpAc2VyeXJpY2guY29tPiB3cm90ZToKCgo.PiA9PT0KPj4gRlJPTSBoZWFkZXI6IHZsYXRrby5zYWxhakBnb29kb25lLnRrCj4.IE1BSUwtRlJPTSBlbnZlbG9wZTogbXlfeWFob29fYWNjb3VudEB5YWhvby5jb20KPj4gREtJTSBkb21haW46IHlhaG9vLmNvbQo.PiA9PT0KPj4KPj4gcmVzdWx0czoKPj4gMS4gbWFpbCBsZWdpdGltYXRlOyB2YWxpZGF0ZWQgYnkgc2VuZGluZyBFU1AgdXNpbmc6Cj4.IDIuIHZhbGlkIERLSU0BMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> <96EA87B2959246E4B4916A0DEF9CAF4A@fgsr.local> <1402044548.59713.YahooMailNeo@web164603.mail.gq1.yahoo.com> Message-ID: <1402086600.16464.YahooMailNeo@web164602.mail.gq1.yahoo.com> Date: Fri, 6 Jun 2014 13:30:00 -0700 (PDT) From: Vlatko Salaj To: "J. Gomez" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/N1sV2Bl7sErl_6QZr0i1LGWpqJQ Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 06 Jun 2014 20:33:26 -0000 On Friday, June 6, 2014 10:16 PM, J. Gomez wrote: >> === >> FROM header: vlatko.salaj@goodone.tk >> MAIL-FROM envelope: my_yahoo_account@yahoo.com >> DKIM domain: yahoo.com >> === >> >> results: >> 1. mail legitimate; validated by sending ESP using: >> 2. valid DKIM @yahoo.com, >> 3. servers validated by SPF at yahoo.com, >> 4. goodone.tk SPF records r of no importance here, >> 5. DMARC is unable to authenticate this email: no 3rd party support. > I think DMARC would be able to authenticate that email as long as > GOODONE.TK included in his SPF record the SPF record of YAHOO.COM. well, u think wrongly. i suggest rereading both of SPF, DKIM and DMARC drafts. > If the particular SPF record of YAHOO.COM does not lend itself > to be SPF-included with third parties (as it uses the "redirect" > mechanism), that is not a SPF problem nor a DMARC problem, > instead it is a YAHOO.COM problem and an implicit declaration > from YAHOO.COM that your use case does not fit with them > (but if you don't have your own MTA, then again your use case > could indeed fit with YAHOO.COM). omg. u rly don't know much about SPF... >> i hope others understand my example. > I hope so too, so that I can be enlightened about why am I wrong. good luck getting help on this mailing list, lol. maybe some DMARC's 3rd party support supporters can replace me here, cause i lost all my interest in participating in this black hole called DMARC mailing list, for now. sorry for that. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Fri Jun 6 13:56:33 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D939F1A0274 for ; Fri, 6 Jun 2014 13:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.653 X-Spam-Level: X-Spam-Status: No, score=-7.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, 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 R6ay9eAji_P5 for ; Fri, 6 Jun 2014 13:56:28 -0700 (PDT) Received: from sj2.jpmchase.com (sj2.jpmchase.com [159.53.110.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F2B11A0290 for ; Fri, 6 Jun 2014 13:56:28 -0700 (PDT) Received: from sg3.svr.us.jpmchase.net (sg3.svr.us.jpmchase.net [155.180.248.7]) by sj2.jpmchase.com (Switch-3.4.4/Switch-3.3.3mp) with ESMTP id s56KuAdC023638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Jun 2014 16:56:10 -0400 X-DKIM: OpenDKIM Filter v2.1.3 sj2.jpmchase.com s56KuAdC023638 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jpmchase.com; s=d2048-1; t=1402088171; bh=1KHqVL7UyBoS7eMNz8C+80b3N3nU2DehFEnUtXOt53E=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=HsEWbolqhW6Sm9+QVGBc/KKXj+Ds0N2ZIeHFy3BuQyH2UbSgtFTnUdYDO/wpVj59T A6KbBb+wGDMMWIaxQmchwD13Os9B2A1Q2LiDr4bTfDr+hydZQvcqLrb2nW7OPXGGH4 Zqt0Qqa0yex5howhZKoBp1lMj0szvxHud7+g6xWOHKR/+LfsfhuEn6fe/ePcBkWqbO vRmj/IuJgAXNzcBWElbudjGbkRtmv8APUPoCfPKj4vJfYYNCooWTbtP5d/72OTBKA3 rg57zpw0PphAGLdoB0Jil3rtiQlhgmXlwJRRsP5646mqndF9eRGUNit02g0nLVyZEQ Xn5OunGP0yQ1g== Received: from smgj1.svr.us.jpmchase.net (smgj1.svr.us.jpmchase.net [169.89.220.170]) by sg3.svr.us.jpmchase.net (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s56Ktgo1019103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Jun 2014 16:56:07 -0400 X-AuditID: a959dcaa-b7fe28e000005ba0-92-53922ae64a2a Received: from SEGHHB007.exchad.jpmchase.net ( [169.81.24.93]) by smgj1.svr.us.jpmchase.net (Symantec Messaging Gateway) with SMTP id A1.1B.23456.6EA22935; Fri, 6 Jun 2014 16:56:07 -0400 (EDT) Received: from SBECDI001.exchad.jpmchase.net (169.83.4.237) by SEGHHB007.exchad.jpmchase.net (169.113.252.29) with Microsoft SMTP Server (TLS) id 14.3.136.1; Fri, 6 Jun 2014 15:56:04 -0500 Received: from SBECMX003.exchad.jpmchase.net ([169.254.7.161]) by SBECDI001.exchad.jpmchase.net ([169.83.4.237]) with mapi id 14.03.0136.001; Fri, 6 Jun 2014 16:56:03 -0400 From: "Talamo, Victor" To: Vlatko Salaj , "Popowycz, Alex" Thread-Topic: [dmarc-ietf] confusing 3rd party support so it remains out Thread-Index: AQHPgJE6IwXIT/Nu2k+ZjeIvHtOJqZti9pZfgABQZwCAAAj6AIAAsLuAgAAaTYCAAEi4gIAAONeAgAAU4ACAAAZlgIAAC1IA///ETwA= Date: Fri, 6 Jun 2014 20:56:02 +0000 Message-ID: References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1402042491.15608.YahooMailNeo@web164601.mail.gq1.yahoo.com> <877g4u2ws4.fsf@uwakimon.sk.tsukuba.ac.jp> <1402063755.61291.YahooMailNeo@web164602.mail.gq1.yahoo.com> <8738fi2bba.fsf@uwakimon.sk.tsukuba.ac.jp> <1402080444.6636.YahooMailNeo@web164602.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8D62B7FE@MSGRTPCCRF2WIN.DMN1.FMR.COM> <1402084248.69843.YahooMailNeo@web164606.mail.gq1.yahoo.com> In-Reply-To: <1402084248.69843.YahooMailNeo@web164606.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.6.67.93] Content-Type: multipart/mixed; boundary="_002_F2971C2F9E42BE40858A18C5F62C91EE2DBB0D12SBECMX003exchad_" MIME-Version: 1.0 X-DLP-FWD: Yes X-Brightmail-Tracker: H4sIAAAAAAAAA7VTa0hTYRjm29mOc7k6LbO3RXE6JInlcq7LAmcZQVpQ2qRQKj1tB7fazsbO tDtohYWaefvjHKZlWpq2ougmJAtjKY71wyCJdTPMiugGml3ouI9A6Hffr+d93+d9nvf7eD85 oXpLquVW3s25eNbGkArp5WzYnTSaWGtMvjGh1gf9XYS+1d+F9AN9T8n1REb3cS+Z8cbXLcto bf0uySLySlAqy/MON+vmaDMnmAzMRqtgsrFWO+eik+jNTrvJwgqcxuSwM7TVbGB0DO20sSbO zvFuA8M6nRxvZtIU9D8nVaRZeZrjTQ6zlS80MJnGbUl6/aq1SVomLcdiFWhR017EFwypLaPV AdLZdVF6cGywX1qCjtdLy1G0HKiV4Pv1TYZxHITCV8lypJCrqAcIAhPhKBz0IghdOiXBgQ/B s8YJsSKXk5QOvMN5U92x1A7w3a+LqBJUPDwPPSem8BxqE7x+W4kwJwMawu1RGBfDyfM/Ihwp tQTqXt2K9CqpHPDevICwV4sMTge8kfGiqUy4MNkaISFx1PH+KxJsNg+GR85J8BVi4eXjARLj uTD2+rdsak6gFkHvbwWmW8HjGUPYazY8ahiJSKqopeBvDEswfSbcKjtSjcAzzcAzrdszrRvn l0PzvS8kxsugreU9gbEG+vo/RmHMQO2ZHlFHIeJOBCPfOxEuLIb6ipdRzSi6A80X7IX7tBqh 2KUpEjT7/i4Hz7mvo6nly33WcRu1VRj8iJIjJkZZ/bXGqJKxxcIhux8tEbVe+TpDSC3lHTzH xCpLr1/LVinN7KHDnMuR7yqycYIf1SDxyWsI9VyTQ9xr3p2v1a3Wa5N1KWuT16Sk/M80M0/Z VL5gu4oqFH/Dfo5zcq6/Q0nk0eoSZHliHGK9dcasyuHRAVWw2+dKX7qhbaAsfLpr4Yefd6va +gJx+eMJnt7gwzX0ZG7McNyxPPvWS+9ySqs6Jg/smtVftmXnyfiSmrS9vWxC+p7QkxWW4J2C s7kPF6d+Lku+WVr5osehLdR5mBnr9qgPtoyfGGxaEIhZEcw6+kn1PlvfzkgFC6tNJFwC+wey ZH3L+wMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/PNbaZ7AHXEIAEAhMJHSvaGiDJbE Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 06 Jun 2014 20:56:31 -0000 --_002_F2971C2F9E42BE40858A18C5F62C91EE2DBB0D12SBECMX003exchad_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable I concur with Alex. Attached is very dated list of DMARC adopters from some= time last year and it is in no way comprehensive. The list is simply a sampl= e to identify dmarc adopters, and included a mix of senders and receivers ad= opting DMARC. With that said if you check the DMARC records for these domain= s today, the vast majority of these domains are DMARC REJECT comprising bill= ions of emails. Enough said. -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Vlatko Salaj Sent: Friday, June 06, 2014 3:51 PM To: Popowycz, Alex Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out On Friday, June 6, 2014 9:10 PM, "Popowycz, Alex" wr= ote: > On the institutional side, it's been extremely successful in > mitigating the risks stemming from email attacks (e.g. phishing) for > traffic destined to mailboxes supporting the protocol. > On the personal side, even though my volumes are but a trickle, it's > been effective in ensuring the integrity of my domain from spammers, > etc from MTAs as far flung as Sudan, Vietnam, Argentina, India and > many other locations around the globe. interesting. let me guess, none of these undocumented examples is fmr.com, the domain u r= posting here from, which, as of today, isn't protected by any DMARC policy= record, but merely a "p=3Dnone", which, ofc, isn't a protection as u specif= ied in ur post. since there's no webserver behind that domain, i guess that's ur personal do= main, but i'm willing to accept it's something completely else. or u meant DMARC essentially didn't protect u, but provided reports upon whi= ch u might have had acted. not that such case counts as a point towards DMAR= C protection usability or efficiency, actually; it dismisses ur DMARC praise= completely, instead. if that's the case, i'll guess i'm just not fool enough. > While DMARC may have had a focus on transactional messaging, its use > shouldn't be precluded from other situations. sure it SHOULDn't. but it is. i'm still waiting on 3rd party support. -- Vlatko Salaj aka goodone http://goodone.tk _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc This communication is for informational purposes only. It is not intended as= an offer or solicitation for the purchase or sale of any financial instrume= nt or as an official confirmation of any transaction. All market prices, dat= a and other information are not warranted as to completeness or accuracy and= are subject to change without notice. Any comments or statements made herei= n do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries= and affiliates. This transmission may contain information that is proprietary, privileged, c= onfidential and/or exempt from disclosure under applicable law. If you are n= ot the intended recipient, you are hereby notified that any disclosure, copy= ing, distribution, or use of the information contained herein (including any= reliance thereon) is STRICTLY PROHIBITED. Although this transmission and an= y attachments are believed to be free of any virus or other defect that migh= t affect any computer system into which it is received and opened, it is the= responsibility of the recipient to ensure that it is virus free and no resp= onsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affilia= tes, as applicable, for any loss or damage arising in any way from its use.= If you received this transmission in error, please immediately contact the= sender and destroy the material in its entirety, whether in electronic or h= ard copy format. Thank you. Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures re= lating to European legal entities. --_002_F2971C2F9E42BE40858A18C5F62C91EE2DBB0D12SBECMX003exchad_ Content-Type: image/jpeg; name="SnipImage.jpg" Content-Description: SnipImage.jpg Content-Disposition: attachment; filename="SnipImage.jpg"; size=49232; creation-date="Fri, 06 Jun 2014 20:17:16 GMT"; modification-date="Fri, 06 Jun 2014 20:17:16 GMT" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAcFBQYFBAcGBQYIBwcIChELCgkJChUPEAwRGBUaGRgV GBcbHichGx0lHRcYIi4iJSgpKywrGiAvMy8qMicqKyr/2wBDAQcICAoJChQLCxQqHBgcKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKir/wAARCAK+BDQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD6Rooo oAKKiubiK0tZLi4kWOKJS7ux4UDqa8R1f9pewh1GSDQ9EnvoY2IExbG8eoHpRYVz3Oivn7/hpi4/ 6FWb/vo/4V3fh/4mahq/w+1TxXeaG1nb2iloInb5psdT7CnZhdHo1FcL8L/iMfiLo93enTzZfZpR Ht37t2RnNdpdT/ZrOafGfKRnx64GaQyaivNPhp8Wz8QNd1DTjpZs/sab9+/du+bFeklsAlsAAc+1 ADqK8UuP2i9Pg8bNpC6aWsVufs5vN/vjdj0zXtCSCSNXQhlYZUjoR60WEPoriviN8TdM+HdhA95E 9zd3JIht4zgkDqSewrzQftL3LAEeFJ8HkEOT/SiwXPoCkzXh+ifH7VNf1u10uw8JTGe5kCDc5AUe pOK7z4leP2+H3h231JrH7WZZREUDYwcZosF0drRXz8v7TFw6hk8LTMp6FWJFTW37RuoXl1FbW3hG 4eaZwiKGPJP4U7MLo97pOar2cs8tlA93EIZ3QGSMHOxscjNZHivxVZ+FtKa5um3SsCIogfmdqcYS nJRirsidSMIuUtjcyRn396Uk+uK+efFPiTVdTsdLvpb2WOSbzSRE5UABhgcVgQa9qtrdRzw6hdB4 2DDMrH8xmvVhlc5K/MkeNPN4RlbkbXc+pQc55NOBzXE+BPH1v4ltltLrEWoxr86EYEnuK7Uda8up TlTlyy3PXo1Y1YKcdh1FFFQbBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRWdqmv6VokltHq 1/DaPdv5cAlbHmNxwPzH50Buct8YdQvdM+G95c6bdz2dwroFlt5DG457EHNa/wAPbq4vfh9o9zeT yXE8luC8srlmY5PJJ5NYHxwIHwtvckDMifzrb+G6tH8N9DVwVb7MOD9TWa/ifI1/5d/M5P49avqW j+EbKbSNQurCVrraz2szRMRtPBKkcV6JZEXHhy3NzM6+ZaqZJfMKsMoMtu6g9815h+0X/wAiXYf9 fn/sprrYPBqav4es4dR1vVpbaS3TfAs4jVgVHynaoOPxpJvnY2lyI5f4H6zq+qP4ii1LULrULa3u gtvLczNKVGW4DMScYArG+I114ms9T1fXdF1rUYodKvIVktY7lxFsYZyUBxjOARjvXsWiaFpnh3TE sNFtI7W2TkInc+pPUn3Nc3pWnQatrfjOwvF3QXMkcbj2MZFJxfKo3GprmcrG74W1+DxN4ZstWtj8 txGCy91buD+NeN/FbxNrcqyaxo2sX1jYQ3/9nQLa3DRrMVUmRztIz8wwKqeENe1TwHe694GZXe8m l2abjOBI52hvpg7s+1a3xq0eHQfhl4e023HywXihm7s2xsk/U5qZScoFxioz9T1aXXbPQ/CEWra1 c+XBHbo0kjHJYkD8yTWRZ+M9Y1PS11XTfClzLp7rvjMlyiSyJ/eCe/pmuI+NxmHwy0AR7vKM0fm4 6Y8s4z+Ner6EIh4asBB/qvsybfptFaJtysZNJRuZ+ieMrHxN4ffU/D8Ut4yNsktSVSSNu6tk4B/G uetvjBpdzcXtlHpWovqVrKYlsYkEkkrDrtwcYHc1yvwSMx8ceLDF/wAeJfjb93fvP9Kb8I40b4v+ MXZAXQttYjlcyHOKhTk7eZbhFc3kdv4a+KGl67DqrXtpc6TJpK77pLtcbF+vrx0pdP8AH19rejS6 zofhu4udMj3bHknWOSYKeSic+ncirvj/AMOvrvgfVrHTkijuriPdu4XzGXoGP+Nct8PvFltZfDyL SprK9Oo2UbwtbQWryb2ycYZQVwfXNVdp2bJtFq6Rd0z4sR+I9V0y38MaPd3ltM5F/PIhQWQ9zyCf xq9p3xEk8R3t7D4S0WbUobJ/LkuZZlhjZvRc5JrN+E/hO/8ACHh3Ur3xCot5byQztb7g3lIB396q eC/EOo+Kbi//AOED0vTNC0SO4IkupoS0k0hHJCKQM4x1PpSTlpfqNxjrZbHSeEPiJZeKtVvdJezn 0/U7EkTW8xDZwcHaw64NVdX+JsHh3xXbaNr2mS2a3RJjuvNV02jOGIHPOOnXmuI+Hsc8Xx915Luc XEyxSb5Qm0McjnHapPixGk3xg8KJIoZGCZHr85pc8uW/mPkjz28jrNY+K66CsF3q3hrVbXS53Cpe SKo69CUzkeuDg13dpdQ31lDd2rh4Z0EiMO6kZFeefHlQ3wvm3AHFzGRnsea6f4f/APJPtF/69Vq0 3zOLM5JcikjoqKKK0MwooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKM0Ach8VmZPhT4 iZCQRZtgg47ivNv2adI06fwvql5cWkM1wbkJ5kiAkLt6DNemfFC3lu/hb4ggt0Mkj2bBVHU9K8e/ Z88caB4f0HUdO1u/jspnnEkfm8Blxjr601sSz6B/snTv+fC2/wC/S1z3xGijh+F+uRxIqILRsKow Pypx+J3gz/oYLP8A7+VW8canZax8JdZvdMuY7m2ktG2SxnIPNIZ4V8GvitoPw/0C9s9ajuWluJxI hhUEYxjnJr0G8/aQ8G3FjPCkV/uliZFzGvcEetYP7O3hnRdd8LalLq+mW15JHdBUaZAxA29K9Z1D 4f8AhOPTLp18P2IZYXIIhGRwarQSueL/ALNMgl8ba7IvR7bcM+716n8ZfGQ8IfD+5aCTbfXwMFuA eRkct+Ary79mxQvjnX1AAAgxj0+fpWH8WdX1D4kfFIaL4cia8SwzFBGh4Zh95v6U3uK+gtt8KXuP gPP4laJjqrSfaUI6mEdvxzn8K9h+BnjI+KfAMNvcSBr3TQIJBnll/hP5cV5/FP8AHGHTF0+PTIha rF5Ij8tMbcYx09K5f4c6pqnwu+K0Vl4jt2s0v8RXEZPADH5W+gNLdD2Oj/aXsbmHxJouqyRM1kE2 s+OFIbJB+tb9p+0H4ChsYIpNIuVaONVYC3TAIHbmvWvEk+gR6KT4pez/ALPcgf6VjYx7Yz3rhvL+ DueDovr94UkBW0L48+AtT1WK2ihk0+SVtqTTQqq5PuOlU/2lSJPh7ZMhDBrsEEd+DzXnHxvHgsTa T/whX2Qy5Pni06Y4259812Hxq80/A7w6J8+ZmLdu652U9mBV8B/GfwT4d8D6dpWrWkj3lshWUiBS Cck5ya7bwz8ZvBPiTxHa6VpVpIl3cNiNmgUAH6iuf+HEvw1X4e6UNe/sj7f5Z87zwu/OT1/DFdlp V38MIdXt30eTRo77fiFotobcfShgjvegPNfO/wAS7q4uvHV7HPKzrCQsSk8IMdq+iW6GvD/iJ4YV PFlxeXmpRWqXZDpvQkdMYzXo5bKMa15djyc2hOVG0TrPhto2nan4FtX1CzhuWSRwpkXOOa3tX8Na LaaPd3EOlWgkihZ1/djggcVy3gvxh4e8MeGodNu9TWWVHZtyIccmtq78e6BrOm3ljY3m+4kt32rs IzxU1Y1XWbs7XFRnQ+rqLavY8j03xfqUOrWzQR2kTiZRuWEAgE4r6Pj5VTjtXy/oGk3mr6/bWthE ZJPODN6KAckmvqCPgKPats0UFKNjPJ5TlGTltckoooryD3QooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigArlPHXgGy8cwWX2m6mtLmxkMlvNGAdpOM5U9egrq6KTSasxptO6OH1f4e3XiiK2tfFOvy3 lhAyubW3t1hErDuxySfwx1q3qngQX3ibSdUtNXu7GDTUWNbKE/u3UdB149D1rraKXKh88jivGXw3 i8buq6vrV6trG5eK2iVAqE++Mn8a3dO0O4sdBk0ybVrm6BhMMc7qqvENuBgqByPX2rYoo5Ve4czt Y5rwd4Rm8J6DPp51m61B5ZGdZ5+THn0Bz9aTQvCE+ia3eal/b17dm+cPcRTJHtdgMAjAyuPQV01F HKg5nqYNx4O0u58a23iiSM/b7eEwrj7pz0J9wMj8ayvGnw6h8cSRLqmsXsVtC2+O2hVAqtjGc4yT XZ0UOKegKTTuc8fB9teeFZNA126m1W1ZQgadVV1A6YKgcj1qla+E9csNITSLHxQ6WMaeXG72itOi dgHzjOO5Wuuoo5UHMznNF8F2Xhrw4+leHp5bJ5Dve7wryu/djuGCfwrD0D4VR+G9cn1bTPEOpLdX J/0gusbCbnPOV9a7+ijlQc8tTjvinaW994Au7W71dNJSR0AuJM7Wbdwhxzg9K4i20b4y2VpBBp+t afLaxoBEUERBUDjkpk8V6f4q8L6f4v0KTStV8wQsyurxNhkYHIIqlZ6B4jsLFbSHxOkscahI3nsF Z1A4HIYA/lUSjeVy4ytGxzfgrxL4pm8TXXhTx9ZRfaHtjNFNGABInQ528EVPpPwqk8P3d0nh/wAT 6hp2mXb75LSJEJH+65Bx6Zxn3rqdH8NQ6Zfzalc3U2oalOoR7qfAIQchVUABV9hW1TUdNROevunn P/Cm9Mt/EL6npWr6lYCZdtxFFLkyg/eBc8/N3p+s/CO21zV7fULvX9SWW0AW0EYjUQKpyqj5e3qe T3r0OinyR7C9pLucl4r8Cf8ACX6Pb6bqmt3ot4sGQRpGPOYdGb5f0HFafhbw63hjSE00alc30EQ2 w/aAuY19MgDP41tUU+VXuLmdrBRRRVEhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAMkRXUo4DIwIIPINeW61+z54N1fUZLuFLixMhLNHA2Ez7DtXqtFGoHjX/DNHhP/AJ/L7/vsV1Oh fC3TdB8Jaj4ctr67l0++BysjZ8onrt+td5RgelO4rI5LwF8PtN+H2nXNnpM00sdxIJGMpzzjFdPP EtxbywvnZIhQ49CMVNRgelIZwHhP4S6P4NudTuNJu7rzdRgaF2dslATnI96XwR8JdD8DazPqlhLc XN3OpQyTtkrk5OPrXfUYHpRcVhM1wvjz4VaF4+vra81OSaC5tk2CSBsErnPNd3RgelGo7HAeKvhR p/jDTdNsdW1O9a30+IJGqvjef7zeprmP+GafCXe8vj/wOvZsD0owKLsVjyvRf2fPB2kalFeSrcXp iYOkcz/Jn3Heur8ceBNN8d6LDpmpSSwwwyCRDCcHIGMV1NFA7HjX/DNPhM8/bL7/AL7pU/Zr8LRS K8d9fo6kFWEmCCOQa9kop3YrFWztmtLGC3eZp2ijCeY/3nx3NUtd0Cx8RaY9pqEIkVujEfMh9Qa1 8D0oojJxd0TOEZx5WfPGs/DHxFp2pywWNjLfW/8ABNHjke/oateFfA/iK315XudJlgjMTp5kgAUE jAzzXvuBRgelek8zrOHK0jyVlFFT5k36HL+DfB1r4V00qmJLuX5ppscsfQe1dKB81PwPSjA9K86c 5TlzSPVp0o048sVoFFFFSaBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQBj+J/E+n+EtH/ALS1bzvs/mLF+5Tc2TnHGfauR/4Xl4R9NQ/8Bv8A69Hxy/5J1/2+xf8A s1TfDPwzo+j+A7PU5bSGS6uYPtM9w6BmwcnAz0AHYV1xhTVLnkm3exi5Sc+VEY+N/hM9F1D/AMBv /r0o+NnhQ/w6h/4D/wD1689+JfjbQ/Ftrp8eh280Rt5HaQyQhAwIAGMH2rgBXbTwdOUbyTRhKvJO ydz6C/4XX4V9L/8A8B//AK9L/wALq8K/3b//AMB//r18/ilrT6jS8yfrEz3/AP4XV4V/u3//AID/ AP16P+F1eFf7t/8A+A//ANevAKKPqNLzD6xM9/8A+F1eFf7t/wD+A/8A9ej/AIXV4V9L/wD8B/8A 69eAV6B8IdE03XPEV7Fq9lFdxxWwdFlGQG3AZxWdTCUacXJ30KjWnJ2O+/4XX4UPQX//AID/AP16 X/hdXhX+7f8A/gP/APXrz/4w6fZ6Z4stYNPtYbWL7Gp2QoEGdzc4FcBRTwlGpBSV9RSrTi7Hv/8A wurwr/dv/wDwH/8Ar0f8Lq8K/wB2/wD/AAH/APr14BRWn1Gl5i+sTPf/APhdXhX+7f8A/gP/APXo /wCF1eFf7t//AOA//wBevAKKPqNLzD6xM9//AOF1eFf7t/8A+A//ANekPxr8KDqL/wD8B/8A69eA 17/4e8KaAvw5t7/+yLRrqXTvMeZ4gzFtmc5PesK2HoUUm09TSFSpN6B/wurwr/dv/wDwH/8Ar0h+ NfhQfw3/AP4D/wD168AHQUjdK3+o0vMz+sTPqvw14lsPFek/2jpXm+R5jR/vU2nIxnj8a1688+CX /JPT/wBfkv8A7LXodeRVioVHFdDsg3KKbCiiisiwooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKAOe8ZroL6RAPFnkf2b9pG/7QSE3bW29PfFX9OGkjw3C NN8r+yfs/wC62H5PKx29sVxfxy/5J1/2+Rf+zVs+Ff8Akklh/wBgv/2Q10OH7pSv1M7++0efaxF8 N28V6BHph01dN3TNfujNtwE+RWPua6ix0j4U6rdpZ2EWlTXEpwkaSsGY+g5rzn4WeBbPxjd3c2qy SCzswgMcbbTIzZxk9gAK9Ci0f4aeH/GVpp0cYi1qOaMwpvlYhzyvPSuuraL5FKTaRhC7XM0rM5P4 mfDqz8PmyvPD6yLFdzi3a3ZiwVz93aTzg8jBrsNP+G/hHwroIvPE6w3MiKDPcXTHYrHsq9MZ47k1 o/EtlSx0JnICjWrbJP1NQ/GKKSX4ezeWjPsuImbaM4GetZqrUnGEHLdlOEYuTsc9r6/C+88P6g2l HTVvkt3aDyy0bbwDjA4zz2qXwR8NNCg8Lw634oiFzJND9oKysRHDHjI4HU45Oa8XCPIrbEZsDJ2q TivqLS5oF+H9nNNCbqBdNRniVQxkURjKgd89MVtiFKjBRjJ6sim1OV2tjmNL0L4b+Nbe5i0ayt2a HAdoEaF0z0I6Z6e9Znw68PP4W+J2uaU0hlSO0VopCOWRmBBPv2/Cl0/4q+CdLdzpmg3Vo8gAfyLS NC2Oxw1XPBviG28T/FLU9Qs4biCM6ZHHsuE2tkP6ZPHNZNVYxmnflt1LTg2rbm14rXwLFq0M3i42 P2xogsYuSSdmT27DJPNYnjf4b+HZfCd3qWiWcdncW8JuEeA4SRQMkEdDkdDXI/G8Z8aWoAJJsVAA HX52r1K+VoPhROkylGTRirK3BBEPSptKnGE4yeo9JOSa2ON8A/DHR38OQaz4liFzJcR+csUjFY4o +oJx1OOeeK27Hw78NvFKz22kW1hO8Q+c2pKOg6ZBGPz6VrWytP8ACaNIAZGfRwFC8knyegrzL4HR Sf8ACWXz+W2xLMqzbTgEuvB9+DVXnUU6jk00Kyi4xtuVJvhhIvxMTw6lw/2KSP7SJyPmEPcf72eP 1r0K98NfDjwnDBDrFtZQtKMI12S7vjqf88VoSun/AAuO3XcN39ivx/21Fef/AB1jf/hINLl2NsNq yhscE7+n15FVGc604wlK2gnGMItpGz43+GGiTeG59X8MRLbTQw+eEiYmOZAMnA7HHIIrq9A/5JRZ /wDYK/8AadO05Gt/hRCk6mNk0j5lcYK/uu9L4XeOP4Xac88fmRLpil0zjcAnIrnnOUoWbvZmkYpS uuqOB+F3w4stR0dtY8S2a3EdwMWsEmQAvdz9e3t9a4bx5daHL4iktvDFhBa2VrmPzIs/v27tyenY fn3r3jUi3iX4cy/8IpcLB9rtP9GZRjAx9z2OAV9q+YZEeGRo5UMboSrKwwVI4INd+GlKrOU5P5HP VSjFRR9A/BL/AJJ6f+vyX/2WvQ688+CX/JPT/wBfkv8A7LXodebiP4svU6qfwIKKKKwNAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAOE+MGlX+s+Bfs uk2c15P9rjby4V3NgZyaz9F8Q6lp3ge20Wbwhr7Tw2f2dnW3XaW24yPmzivS6K2VW0FBq/Uhw1um eC/DpfF/gjUZzP4V1K5srpVEyJFhlK5wwz9TxXf33ici6W+svh/q1zf4AE01oiMo/wB7JNd3RVzr qcuZx1+ZMabirJnk/wAQ7/VvFvh6Gx03wtrkM0dys2+a3AGAGHGGPPIrW8PeM/EiafHbeJvCGrST Iu1ri3hDCT3KkjB9a9Cope2i48nKPkd73OA8Q+Ibq98P32n6Z4O1sSXUDxBjaqgUsMZPNYvgfX/F vh3S49K1jwpqd3aw8QyxR/PGv90g8EenNes0UKtFR5eUOR3vc5JvFarl4/B+uNJ1/wCPFAfz3Vym naprdn8Q9U8QSeD9ZNvfQJCsaxrvTaF5POP4a9YopRqxjf3dwcG+pyZ8WiUrLL4Q10yL0JsVJH47 q5Txt4h8WeIdJl0rR/CWp2tvP8s000fzuv8AdAHTPfmvV6KIVYxd1EHBtWueT+B9f8W+HdKj0rWP Cep3VrDxDLDH86L/AHSDwR6c11Fx4zuoIGbT/BmuSytzta3WME+5yf5V2FFEqsZS5nEFBpWueCSt 8QZPG48T/wBgXi3SnasPknYI8Y8v6Y7+vNek23jS8uLdf7T8F63FKOSqW6yLn2OR/Kuyoqp11O14 rQUabjszyrxt4j8Wa9pM2l6J4T1S1gnG2aeaP52XuoAPGe5zV7TPEGo2PgmDRpPCWutPHZfZy626 7d23GfvdK9Hope2jyqPKHI73ueM/Di98VeD7a4sNU8Matc2LnzIhDDlo379SOD/Me9Z3inRrvVfG C63pfg7WFSZSbmCe3UAyf3xgnr3/ADr3eir+s++5qOrF7L3eW5xXwq0+803whLFqFhLp8j3ssiwS rgqpxiu1oornnLnk5dzWKsrBRRRUDCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiuA+Meu3GhfDm8ksJXiurmVLeJ 0bawLHkg/QVzlj8KPEl1p9tPN491KJ5oldo+flJAO373bpW8aScOaUrGUqjUuWKuexUV5KPhH4jQ 5i+IWphh6qf/AIqodH8U+JPAniq28O+P7qO9sL4kWOqdMHPRzxxyByMj3FP2Kkvcldk+1a+KNj2C iuPvvij4L02RorrxDaeYOqo27+VSaX8TfB2sXK29jr1q0zdEdthP51n7Odr8rNOeO1zrKK5h/iF4 SjYq/iCxVgSCGlAORwatab4y8O6veLZ6Xq9rdXDZxHE+ScVPJLew+aPc3aK5qfx94UguJIJteskl iYo6mTlSOteYTvqfxN+K+rW3h7xNc2OkWNrHsmtXJRj0OBnnJzz7VpCi5X5tEupEqqW2rPdKK8l/ 4VB4g/6KDqf5H/4qoLzwH4+8OWzaj4d8YTanJbjebO7XIlx1HJwfpx9ar2UHopr8Re0kt4nsNFcD 4V+KWhat4YTUtau7fSrtCY7m3mfBRx1wOpFTN8YfAvmhf+EggPuFbH54qHRqXa5WUqsLXuds5Ixg /pWPP4u8P2tw8F1rdhDNGcPG9woZT6EZp2n+JNH1fTpL3SNRt76CJC7NFIDgAZ/CvHvhj4H0Lx/p mq+JPEtgbuS71GQwEyOhVeuOCB3H5VUKcWnKpdJClN3Sj1PXovF/h64nSC31ywklc4VEuFJY+gFb SknrXhNn4N0Sx/aF07S9Ashb2mmWpup13s+ZMcZJJ/vD8q91TvnrSqwjBrle6uFOUpXv0HUUUVia hRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQB5N8XD/AGv4v8H+Gl+YXN79plH+yuBXY/EHV5dA8A6rf2gc3KQlYPLGWDsQoI9xnP4Vxdsv /CQftL3M4bdBoVh5YHUB2GPzy36V2Hjbx1pfgmCzfVoLif7ZIyRpAgc5Az0/GuuSd6cEr9beuv5H PFr3pNnnPwU1Pxlq2u3UusXl7c6VHBtZrxSB5meNuQM981P+0DPa3H/CO6WSv2iW6MjZOMRkbT/P 9Kv3Pxu+0xCDwx4U1W9u24RJoTGqntnHWuQ8F+Gbv4p+NNT1jxu7tFZsI5LZTtBftGPRQAT75rpi n7R15rlSMJP3PZRd2zpxqvwV8Nn7Ih06d1+VisbTkHvk/wCFdLc/D3wN4x0CKey063WC4j3W91aL sIz0I/wNZviDxP8AD/4d30OjtosLXRUMILWzV2UN90knua725vYdL8NzX0cKwxW9s0wiAC7cLuxj tXLOU1aUb693udEYxd07aHhXwj8J6LqfiPxFo3iGwi1CSycCKSTP8Lspxj14o+JGmR+AfH+ky+C7 JLSe8s5Ioki5zI+UyM9/mFVPgpcXNl8TYjebgusWcrozf8tPm3Z/8davcdS8K2eqeMdJ168xI+lx SrDGVyA7EfP+ABx7muqtVdKu+Z3VjmpU1OlaOjv+px2ifCzwt4d8FrceLbGC6uoITPe3MpPXqR74 6D1NN+ClvZ3VvruuadYx2Npe3nl20CD7kSDgH35zXOfHHxjLdySeF9HZ3hs1E+qSRngf3UPpjgn8 K9F+FeknRvhlo9uV2ySxfaJAf7znd/WsZ86oc83rJ/gaw5fa8sVsebfGLxX4jt/H0Ol+G7zUII4L VAUtUJ8yViT6YPG2vX/Cz6lF4R05/Ej41BLcNdM/UHHJPvXF3Pxx8OQX1xbrpuqTvbytEZIbbcCQ cHBH0rivHvxO8S+INClttK0S70jSrlhA11MMSTMx+4D2BHpzT9lOpGNPl5bdRc8YNzve/QpeCYvA l5rfiTWvGk1olsL4/Y0nkIDAkkkAda9H8Pah8K/E2ojS9EstOnuCCwj+y4yB1wSKZ4Z+GXhfwd4b Gpa9awXt3BD51zc3C7li4yQq9MD9a0vAvjTwz4t1C8i8NaU0AslDNcG1WNTuJAwR3IHSirNTvKF7 Lz0HTg4pRla7PP8A4teEbPwDFB4g8JPJpzXsjWdzbxOfLZWRjkA/TpXp3ww0gaL8N9GtSuGaAStx 3c7v61wPx5mk1TVvDXhy3bMtxPvx7khBn8zXqXiC9i8PeDL+5j+SOys2EfbG1cD+lKpKUqMIvVv+ kEIqNSUlsjgPhTJ/b/j/AMZeJeSjXQtYSf7o/wD1V60K88+B+mGw+GdtPIP3t/K90x/3jxXolYYh 3qtLpp9xtS+BBRRRWBqFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFRzSLFG0jnAQFifYCpKa67uDyO4oA+d/AvxK0Tw7r3iTVNaivJbjVLwvG 0EO792CcA8/StT/hI7T4m/Gfwy2lxXA0/TY5JpBcx4BYZPTP0/KvaxplioAWxtwB/wBMl/wp0Vjb QPvhtoonxjciBT9MgV2OvC7ko62tv5WOZUpWs3oSJGq8rGqH1UCvFLTWZvhF431u316yuZNC1Wf7 Vb3kMe4Ix65P44I9hXuHaoJraKePy7iJJUz911BH5GuenNQupK6ZrOHNZp2aPIdY+L/gR9Wtb620 l9WukYKbs2ozAnfBPJPsKz/Hnxn0TW/BOo6ZosGoLeXUYQGWDauM885zyM17PHo+mwLiHT7VB1+W FR/SuU+IurDw14Ylk0fRxeajcfurZIbXfsJ/jOBwBXRTnScklF39TKUZqLbf4HnWgWXnfFbwhp+h L5reHdPEeozg/KpKsWH1y+Px9q9T+IPi+Lwd4UuL/h7yT91aRd3lI449uteS/D7xc/gjR5YG8Ga5 eaheSebd3YibMjdsfLwPb3Nb2h2uo/E/4iReINd0y50/R9FVfstldIVLynvggZAPP4AVrVhefNP4 Y/j/AMOzOnK0bR3f4HHeKdFk8MfDaw/tgO+s+JL4XWoSYyyxr82w+xznHr9K7mT45+FoNFa1sLbU hLFbmODNsAoYLhec8CvVprO3uCpngjl29N6A4/Om/wBm2WMfYbf/AL9L/hWLrwmvfjf5mipSi/dZ 5/8ABHR/sHw1t5548zX08lw25ckDO0cn2AP41d+Lnhq/8QeCMaOm+8sJkuYoh/Ht6ge+K7uONYlC RqEUcBQMAewpzDIrF1X7X2nmaqmuTkPJbH43+F5dH8jxLbXNne+X5VxZyWxbdxggD0PvVTRvjT4L 0qOaC00O606APiNLe2X94PU4Ix9K9Ym0jT7ibzbiwt5ZP77xKSfxxTxpdiOljb/9+l/wrT2lHX3X 95HJU7r7j5y1Lx9pWr/Gaz8U3cN3/ZNkirFGYgXJUHnbn+8fXtW58Rfi5pXivwVcaJ4fivVvL10j PnQhVK7uRnP0r3H+zLH/AJ8bb/v0v+FH9mWQ5Flbg+oiX/CtPb0rxfL8O2pCpTSa5t/IreHNPXSf Dmn2Crt+z20aEe4UZ/XNalNQEE5p1cTd3dnSlZWCiiigYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFQXjXCWM7WSLJcrGxiRjgM+OAT6ZoAnor5X8SaZ4sjsNX1rxp8Qo 9I1uAs9rpNtfA7gOQMKfwH05rctPiB4g1f8AZe1DVZ7+VdTtJxALtDtdl3DHI7470AfRlFfH+rX/ AMR4Phvo3jy48USi2EgihtkdgwAOAzdmyR3q34s1j4kaXpeg+Pr7xKVTVGBjs7clViA6Ar0ORQB9 a0V4/wDEqXxvr2gaCfD+o22jaVdwJJqV+9wsRjLAcDPOMc8V5v4d8Ran4L+NOkaJpHjSTxNpV+6R zM83mr8xwRkk8jrxQB9UUV4T8a9G1/RTf+K4vHU2l2JVUt9PTdl5P7owe/Wsb4deJ/Fnhj4Ta945 8TX1xeRyoI9OhuWJy2cB/pn+VAH0fRXygF+IJ+G5+J//AAl9154m3/Y8ny/LzjOOnXtWv8S/idre pfDTwZ4h0a9lsri8mZbhIW2h5E4I+maAPpiivlTW9S+IfgLx14c1bWvEj3v9seXI9ujERqCQDGVP HQ9RXsvxd8U6ppGhaZpfh6XyNU127S1jmHJhU/eYe+KAPRqK8ii8F+KPh/4j0W98P6zqevWV1OIN Wtr2TeFU/wDLVfTB7Vn6bZap8Y/FGvXdx4gv9L0PTLk2djBp8nll2Xq7EdfpQB7bRXznq3jPxLoX gDxb4dvdVlm1bw9eQfZr7OHmgZxjd79qu+MtO8T+BvDWnfECHxPe3mrPJCt1aTP/AKNIJBjaE7Y4 5oA9/orwbxZpfiLwBHonjQeJ768vrq+hi1C0lfNu6yHlUToMdBXsekaXc2V/f3M+oS3MV3IHiifp CMdBQBrUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRR RQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFYvi99Qj8F6u+jhvty2khh29d209PetqjFAHxb4S1Dw9/wAIRrthqug3ereM752j tWeBnZQR1yehByTW34cNz/wy/wCJ7GaxuImgvVId0IDksMgfTvX1XDpGnW9493b2NvFcP96VIgGP 41W1HT3FsVsYLeSLkvaSINknv9azqT5I81r+hUY8ztex85+KopD+yRoCCN93nLldpz980/4qRyH4 AeBlWNyRsyApyOK94j1nR2hGn6pYpZhOkE0QKZ9u1au3R762jiK2k0KfcQhSF+g7VlSxdCr8E0/z +7c0nQq0/iifM/xjnuY9a8Errkdy/htLGBpY4gdrdN4OO+KxtW1DS7j4w+HNc8F+GLm10KGeKKBY 7Yp9oZW+Ygfj+lfWt1aade2ywXsFtPCvRJVVlH4GopZ9HsYog7WkaQf6pQF+T6DtWsqsIK8mkZqE pOyR8zfGR/F3jj4myWGn6JeX+maM6qlvHGdjngsSe+eldTLq+tfE34ba/wCDbrwrJod/plrHPbQg EJIFbhQCOvFerzXMWsXcj2V1eLAqlmli+RFwP1rU8Ni4bRopLt2kkbJDP94rniuOjjlWq+zjHTXW +mlv8zoqYZ04c0nr29T5bT4i2w+AbeATY3h14y+QIPJONu7Oc+vtU/xC8MXvhf4SeAtKvYXFyl08 8qBSShc7sH6Zr6m/sTS/t/27+zrX7V18/wAld/54zU9zY2t4FF3bxT7DlfMQNg+2a9A5T52+PEcj 654C2Ru2FjztUnutdJ8VdWg1OSw1XQRJfXPg/UY31KBEOUjYckeuPavZJ7C0uWja4toZWi+4XQHb 9PSlSytY3maO3iVp/wDWkIBv+vrQB5tc/FyDxB4k0LR/h28eqSXcwfUJDE221gH3snjDe1c74G8T aX8KvEfifw14wuDpsb3z3tlczIdlwj88EDr7V7NY6Rp2mM7adY29qZOXMMQQt9cUX+kadqmz+0rG 3u/L5Xzog+36ZoA+aPEkFxr/AIO8d+N/ss8Vpqt3bwWKuhDSRJIPnx1r0f42IzfA6zVVZm8+y4AJ PUV6s9nbSWwt5II2hGAIyo2jHTilmtoLiERTwpJGMfI6gjjpxQB5Z8dFZ/hxpARWY/2laHAGe4r1 WL/VJ/uimzW0FzGI7iFJUBBCuoIBHQ1LQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRjNFFAFa7060v0C3lukwHTcKpDwtoq/ dsEH0Zh/WtaiueeGoVHzTgm/NI1jXqwVoyaXqZf/AAjekkYNoMf9dG/xpo8LaKrBhp8ZI9ST/Wta ip+pYb/n3H7kV9Zr/wA7+9kJtIPsxt/KUREY2AYFSqiooVAAAMADsKWiuhRitkYtt7hRRRVCCiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAopGdUH zsF+pxSggjI5FABRSFgoyxAHqaFYMMqQR6g0ALRRRQAUVQ1LW7DSJLePUJ/Ka5fZENpO48ccfUVf ptNK4k03YKKY0saMFeRVY9AWANPpDCimvIkYBkdUz03HFOBBGRyKACiiigAopGZUUs5CqBkknAAq GzvrTULcT2FzDcwkkeZC4dcjtkUWC5PRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAHA/FZHk0/S4487nuSoAOMkrWh8OtXa +8PtY3JP2nT38lw3Xb2/qPwqp8S/u6H/ANfw/lVO/kXwd8ShfOfL0/U0JlPZT3/I4P416EUp0FDr q18jz5NwrufTRP5jvidqskgt9EsyWkcG4mCnkKoJA/Qn8K1/h5MkPgO3lnkVEV5Czu2ABvPc1zWj xSa4nibxPdLw1tNDbg9hsPT6DA/GsmAvfaD4Z0aSZobS6uJDKQcbv3mB+X9a0dNOmqXZ6/c2zNVG qjq91p96SPWItd0meJ5YdStXRDhmEy4B9+all1OxhOJryBCU3gNIB8vr9K8/8e+ENH0rwx9s06D7 PLEyocMT5gPGDnv3qpdaXb6x440OzvAWgfToi6g43AJnGawjQpyXMm7a/gbyr1IvlaV9PxNLx3f2 moXXh6axuYriP7ZjfE4YZyvHFdzqGp2WlW4n1G5jt4idoZzjJrz7xrpNnoR0K30q22J9saTyw3LN leMn8qNFUeMfGM8viWTy5LJv3OmNwBj19cd/X6VbpxlTjK/uq/ruQqko1JRt7zt6bHA/GWWa/wDH 1pcaTI7/APEvWeNoyQcKSdw/LNe1eCPEaeKvB1hqqkGWSPbOB/DIvDD8+fxrgvEMUcn7ReiQyIrR vYsjIRwVKuCPyrA0LxG3wn1jxX4fvCTEiNc6duH3nI+QfiCM/wC6a1nD2tGMIrVJNfkyIT9lVlKW zdjN+NGvz694suLSxZmsdEjCSMpwBIxAY/nhfwNe3wa5pmg+ENNu9ZvobOH7LEA8rY3HYOAOpP0r xKbQJdP+Ad9rN8Cb7Wb2Kd3brs3/AC/mST+NadnYQeMPjLaaV4iJlsdP06I21sxIWTESN+pYk+u2 rqU4Tgo30jf8LfqTTqTjNy6yt+N/0PXNE8aeHfEU7Q6Lq9vdTKMmJSVbHqAcE0l9428NaZdXNtf6 1ZwT2ozNE8nzJ07de4ry/wCMHhzSPCNtpOv+GbeLS9RiuwqJbDYHABOcD0IA/GoNG0XT/Evx/wBX TW7NLiNLYXHkSjK79kY5HfG41zxw9KUfaXdrP10N3XqKXJZXuvTU9Tg1/wAN+MdC1CGy1SK5tPJZ LkxuVaNCDknPI4zzXnd3feH/AAD8J72LwR4jWa6uZt9vN5iszsHQOFGMcL1rOj0+10H40+IdP0mJ bW0fSJiYU4UZhDYA9M81iaXpNjdfs53+o3Fskl5ZXrC3mPWPc8QbH1FbQoxjbV8rcdPXuZTqylfR cyT19Ox7F4D8W2ereBrW8vtWgmuba3U38jOB5TEfx9hVm0+I/hC+vls7XX7R53baoLFQx9ASMH86 8U1qwtbbwd4J063QWNrrhSXUZkJHnMCFBb6Bia9G8d/DjwnZ/DzUZbXTLezmsrYyw3CDDllHAZv4 snjn1rKdGipat+83by1saQrVXHRLRK53GqeJdF0S5ht9X1O2s5ZxmNJpApYdMisaX4h6LdaTd3Xh 65j1WW1wHiiJG3JwCcjp7+teJXDyeKf+FeW+tM8q3DNaSOT8zxicKOfXHGa+g9F8L6L4eWddF06G zW4x5ojHD4GB1rOrRp0Uua7f4aMunVnVb5dF+OqLGjaidW0e2vmhaAzoGMbHO38avUdBgUVxvfQ6 1tqFFFFIYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFAGF4n8NnxELEC58j7JP533N27260vivw1H4n0xLZpfIlik3xy7d2OxGPetyitFUkrWe2xm6cJX ut9zGtPD0Vl4RbRIJMBoHiMu3qzA5bH1NY7fD6CXwpbaTNdt59o7yQ3SJgqWOcYz0/wrsaKarTWq fW4nRg9Guljgbv4e6rqtp5Wr+JJbgx/6oGMlV9SQTycVsw+ETF4lsNV+2AiztVt/L2fewuM5zxXS 0VTr1GrXJWHpp3sYHiXw0fEFzp0oufI+xTeZjZu38g468dKj8ReEYdauob+zuGsNRgYFbmNckgdi O9dHRUKrONrPYp0oSvdbnGTeBbi6+IOmeKbrUkaWyt/JeJYcCQ4I3Zzx16VV8f8AwutvHGq2N99t NnJAvlzYj3eamc46jBHPPvXe0VSr1IyUk9VoJ0YOLi1ucx4y8HJ4o8G/8I/bXAsY1Mexwm4KqdBj I9Kx/E/wth1wade6dqcumazp8CQpeRL98KMDIBB9eQa7+iiNapC3KxyowlujzLTfhPe3eu2+qeOf EM2utaEGC3KlYwR65PrzgYz3rc0rwI2m/EvUvFZvxIL6Ix/ZvLxszs53Z5+56d67GinLEVJbvpYS oU47LzOHuvh21x4/v/Ev9ohReWb2vkeV93dHs3Zzz61TsfhY1n8Lb3wh/aoc3U/nfavJxt+ZDjbn /Y9e9eiUUfWKlkr7W/DYPYU7t23v+O5xd78NdP1X4f2HhrUp2d7CMLDeRrhkYfxAeh7iuZb4ReIt Sii0/wAQeNrm70iIjFuqHcwHQHJx+ea9aopxxNWOzFLD05bo4XVfhlbXeveGrzTrpbK10Db5dsI9 28K4brnjp1967qiispVJTSUnsaRhGLbS3CiiioLCiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooA+LfiTeXafFLxKqXlyijUZAFWdgB9BmuZ+3Xv8Az/Xf/gQ/+NdB8S/+Sq+Jv+wjJ/SuYrVb GTJ/t17/AM/13/4EP/jR9uvf+f67/wDAh/8AGoKu2OlT36s0ZVEHG5q0hTlUlywV2Z1KkKceabsi H7de/wDP9d/+BD/40fbr3/n+u/8AwIf/ABrS/wCEauf+e8X60f8ACNXP/PeL9a6PqOJ/kOX6/hv5 0Zv269/5/rv/AMCH/wAaPt17/wA/13/4EP8A41pf8I1c/wDPeL9aP+Eauf8AnvF+tH1HE/yB9fw3 86M37de/8/13/wCBD/40fbr3/n+u/wDwIf8AxrRbw3dBSRLEx9BnmshgVYqeoODWNWhUpW9pG1ze lXpVr+zlexJLf3vkv/p9390/8vD/AONfcvhUlvB2jFiSTYQEknJP7ta+E5f9S/8Aumvuvwp/yJmi /wDYPg/9FrXPI6YmtRRRUFhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB8T/Ev/kqvib/ALCMn9K5iun+Jf8AyVXx N/2EZP6VzFarYyYV1ujR+XpUQ7tk1yYGSB68V7H4K8BDxLpcPlavaW0/3Ft5D85wOuK9XLZRpylU nsl+Z5GZxlUhGlDdv8jl6K7jxJ8NH8N2MktxrNpJOgBW2Une+fQVB4e+HN7rlkZp72DTZWbbFDd5 RpPcA817qxVFw5+bQ8B4Ssp8nLqcdRWv4j8L6n4X1MWWqQ4dhmN05WQeorqNP+EupS6XHfaxqFpp ccgyqTthvx7VUsRShFSctHsTHDVpycVHVbnnsr+XC7/3VJrh2bc7N/eJNdx4khGmJfW6zJMIWMYl jOVfnGRXDV4uazvKEV2v957mUU3GM5Pvb7hsv+pf/dNfdfhT/kTNF/7B8H/ota+FJf8AUv8A7pr7 r8Kf8iZov/YPg/8ARa14cj3omtRRRUFhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUHpSDpyaAFopARSk0A FFIDnpS0AFFGPekx70ALRSY96Me9AC0UmPelxQAUUUUAFFB6U3OeAaAHUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAx+1NzSynpWR4h8Q6f4Y0SfVNWl8uCIcAfeduyqO5NNJt2Qm0 ldmtVGbXNKtpDHcapZROOqvcKCPwzXzzf+L/ABt8VtbbTNCWW2syf+PaB9iIn96V+/8AnArrNJ/Z 6svKEniHWZ5525dLVQqg/wC82Sa7Hh4U1+9lZ9lqcqxEqj/dRuu+x7FbXtreoWs7mG4UdTFIHH6V NmvKH+Btnp7/AGjwt4j1PS7peUYsGXPvjBrY0HxNr2g6rBoHxAjjZrhtllrEI/c3B7I/91/51jKn Fq9OV/wZrGpJaTVjv80Zpua8x+IGs63a+MLew0a9ni823UrFGcbmyf1rjq1FTjzMdWoqUeZo9QzR muR8EeMF8Q2htL4iPVLcYlQ8eYBxuA/mK6wH5h9aqE1OPNEqE4zjzRHZozXnPg7XNTvviBqtneXs s1tF5uyJjwuGwMV6HmlTqKoroVOoqkeZD80Zrznxp4g1S58U2fh/w3dPDP8A8tWjPViM4P0Aqz8O PE91qaXemavO0t7bsXVpPvFc4I/A1CrxdTkM1iIupyHe5ozTM1xXiXx89nqY0bw7ai+1ItsJ6qje gA6n9BWk5xgryNZ1I01eR3FHPpXAQ+G/Geqqs2r+JWsSefJthyvtkYH86kfwV4hiG+z8ZXZkHQTA lf51n7Sb1UH+Bn7Wb1UH+B3eaM1jag13YeDrppLoyXkFmxM44JcL94Vzfwv1jUNW0/UH1O7kuWjl QIZDnAK1TqJTUO5TqpTULas73NGaZmuC+KOs6jpEGmnTLyS2MjSb/LON2AuP506k1Ti5MdSoqcHJ noGaM1Q0aaSfQ7KWZy8jwIzMepJHWotf1iPQ9ButQlIzEnyL/ec8KPzquZKPMyuZKPMzUzRmvE7X xT4m0w6brGo3001jczN+7JyGUHDD9ePpXs0M8dxBHNCwaORQysO4PSs6VZVb20MqVaNW9lYmzRmm ZozWxuPzUg+6KgzU6/dH0oAWiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig D4n+Jf8AyVXxN/2EZP6VzFdP8S/+Sq+Jv+wjJ/SuYrVbGTJrSPzb2GP+84r134cD/i4elf8AXQ/y ry3Q4/M1VD/cBau50bVrjQ9Yt9SsghngbcocZH417+X0nLDTtu9PwPnsxqqOJp32Wv4noPxIA/4X Bp/HaL+dWvjUtxJ4o0MWgdpzGfK2jnduGMVwWteLNQ13xFFrN2sK3MW3YEXC/L04rpJPjL4hkKu1 ppxkT7rtBkr9Oa3WHrQ9lKKT5U09TB4mjNVYybXM01odn8QpII5PBa6qV+0LdRmfd124G7Ptmsb4 5Q3z3WnTBXbTxGcFeVDe/wCFeba3r2o+IdQN7qtw002ML2Cj0A7V0ulfFbxDpunJZS/Z76GMYT7T HuYenNTDCVaPJONm4309ew54ylW9pCV0pWs/TueZ+IpNmnon998Yrma6nx7rU+ua59suljSWUbmW Jdqj0wK5avKzCbnXd+lj18ugoYdW63Gy/wCpf/dNfdfhT/kTNF/7B8H/AKLWvhSX/Uv/ALpr7r8K f8iZov8A2D4P/Ra150j0omtRRRUFhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAHpTTu2HbjdjjNOPSmg0AcP 4R8eXOr+LdW8NeILKLT9UsG3RIjErPF2YZroPFfiWz8KeGLzWdQYCK3QlVJ++3ZR9TXDfFzQbuyk sfHfh5T/AGporAzqg5mgz8wPriudfV1+N/jvTLCyV18NaVGl3e5GBLKeQh9eeK71RpzSrfZXxLzX +f8AmPzPSPDXiy6uPAa+JfFltDpMToZvLBJ2Rdi2e59K6DSNXstd0uHUdLnWe1nGY5F7ivOvipN/ bOqeH/AdlkDUpxJdrHxst06/hSfC2ZvDPiXxB4DuGIWxm+02APeB+cD6VLoRdH2m0t7f3b2/ryC2 h3Vx4s0e18Tw+H57oLqc6eZHBtOWX1zWyTgZrx7xTcWtl+0foVzeyxwxrpzZkfgDk16T/wAJXoXT +1Lf/vqs6lBxjCUU3dX/ABaBiaJ4s0fxHPeQ6PdC4eykMc4Axsb0qnc+PtCh1CSygnlvriI4kSzi Muw+hI4FeBR+IZtC8H+MTokojudV1w2sU8Z5CtySD9DX0D4L8N2XhjwtY2FhEq4hVpZMfNI5GSxP c5rbEYaFD3ndrZfcm/zG1YXS/G2iatf/AGCG5aC9xkW1yhikYewPWte81C20+zku76ZLe3iXdJJI 2Ao964b4x+HodQ8CXWq248jVNKAubW6Th0KnkZ9DXn2t+Jbn4hv4A0C6kZbfUlW51BFOPN2nGD7c ZqaeHVa0o6K9n917/cmJI9RsvH762TJ4Z0K91G1zhbpsQxv7qW6j3pz/ABDttMvYbbxRpt1ovnsE jnmw8Jb0LjgfjXV29tDa20dvbRrHDGoVEUYCgdhWf4i0K08Q+Hr3S9QiWaC4iZdrjODjgj3BrHnp 3ty6euv+X4AW7y+S202a8GHSOIygg8MAM1z3w98XS+NvDH9rzWX2PMzxhAchgpxmvOPAPiO7n+Cf iWwvpmlm0ZZraORjlinIXmvRvhppX9jfDjR7RlKyfZxI4/2m5Nb1aEKNOSlrK6s/K1/1Q7WR1lFF FcJIUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAEUx+7Xzp8eNfm1DxfBokLk29hGGKDv K/r+GBX0VcH7tcjqngLwprmo3N9faLbXF/IR5k0u/k44JAYV0YerGlPmkjnxFOVSHLFjfAfh3TvB PhK3s2lgjupEEt3KzgF5COmfQdBXM+M/ihP4M16D7Hc2OuadcgloElHnW5HX5l4IPbNQax4AjsNz 2/grSNRhHeKafdj3UvXJy/2BbSmKfwLpcUgOCjmZT+rVk8Xh4Tcqt3fy/wCCctSs6ceRe7b1/wAj 0vw98YPCmvlY3vDptyePKvBtBPs3Sur1PTrHxDostndbZ7W4Xh0IOD1VlI7g4INeaW3w5S5jDyeB /D8KsARvuZTkH6NUl1LN8N2g+x6PpUDXOcR2087AAdyrNipqV6EVzw5l6o1VaUY3qrT0Z6VpRuBp cEd62+4iXy5H/vleN344zXnXjY/8XU0c+0X/AKHXb+FtXudc8OwajewxwyTFsJHnGASAea4fxt/y VLR/92L/ANDrjxMlKmpLq0PENSpJrui3468NXOmaiPFHh3Mcsbb7hIx90/3wO4PcV1XhHxTb+J9N WZCsd1HgTw5+6fUexrabDAhgCDwQR1FeX6/o114F8QReINCDGwZ/30I6Jk8qf9k9vQ0TToy547Pf /MJp0Je0j8L3X6j/AAJ/yUzWf+2v/oYr0TVtTi0jSLm/uCAkCFsep7D8682+HlxHd/EDU7mHPlzR ySLnqAWBq18T9Wku7qz8OWJ3SSMryqO5Jwi/1rOnU9nQcl3ZnSqezoOS7uw74Z2Emoalf+JtQIMs rskRY/xHlj/IfnVLxVG3g/4g22uWYH2a6be6r0z0dfxHNdBbfDDREtY1uJLwyhR5hS4Kgt3wKp69 8NdNj0O5l0prpruJC8ayzFw2OowfapdKoqSVtVre/X7iXSqKkklqtb36/cdnqGoCPw9c39q24C2M sbD/AHeDXnnwktY57/Ur+Yb7iNVVWPONxJJ+vFafw21dNW8Nz6LdsS9spQA9TE3H6dPyrntKubr4 b+K5rfUopGsLj5fMUZDLn5XHqR3FVKopSp1Xt+Q51FKVOq9vyZ7BmjNULDWdO1SFZdPvYJ1b+64y PqOoqzLcwwIXmmjjUDJLuAB+ddyaauj0E01dFPxGf+KX1P8A69ZP/Qa8u8Aa5qmkWV4mmaHNqiyS KztG2Nhx0r07xA6yeFdSZGDK1o5DA5BG2uO+EBxpep/9dk/9BrjqpuvGztoziqpuvBJ20Zof8Jn4 k/6Ey7/7+CuP8f61qerw2I1TRJtLERfYZGz5mcZx9MfrXsm73rzb4wHNtpX+9L/JaWIhJUm3K/3C xMJKk25X+47zQj/xT2n/APXun8hXBfEO+l13xHYeGbBs4cGXnjcemfoOa6+DUotI8EwX9wfkgs1b HqdowPzrz/wb4YTxfcahq+ttMI3kIUxPtLOeTz6AYFOs3KMaUd3+Q6zcoxpR3f5Ha+JvDNvfeCDp doE32cYa25H3lH9efzrN+F2uG90OTS7hj59ifkB6mM9PyPFWP+FZ6B/fvv8AwKauQurc/D34g28s Bc2EoGCxyWjPDAnuQeamblTmqjVlsyZuVOaqNWWz1PYc0ZqNXV0V0YMrDII7inZrvPQHZqyn3B9K qZq0n+rX6UAOooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA+J/iX/yVXxN /wBhGT+lcxXpHxA+H/jDUPiR4gvLHwzqVxbT38jxTRw5V1PQg+lc9/wrTxz/ANClq3/fitUzJop+ Go8zzyf3VA/OuhrPg+Hvj+1cvb+FtXRj1Igqx/whnxJ/6FzWP/AevawmYUqFJQknc8PGZdVr1nUi 1YsUVX/4Qz4k/wDQuax/4D0f8IZ8Sf8AoXNY/wDAeur+1qPZ/h/mcn9j1+6/H/IsUVX/AOEM+JP/ AELmsf8AgPQfBnxIIwfDmsc/9O9H9rUez/D/ADH/AGPX7r8f8jnNcl8zVXAOQoArOrqD8NfHTMS3 hPViT1JgpP8AhWnjn/oUtW/78V8/Vqe0qOfdn0NKn7OnGC6I5aX/AFL/AO6a+6/Cn/ImaL/2D4P/ AEWtfHcnwz8cmJgPCWrZIP8Ay719j+G4JbbwppMFxG0U0VlCjowwVYIAQffNYyN4mnRRRUFhRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAHoaYDTz0NRDpQBFfJG+m3SyKGUwuGUjgjBry34BiztPA2qz7UhVdQmM r9PlHTPsBXqk8fnWssWceYhXPpkYrkfA3gCLwh4dvtIuroajDezvK+V2jDdVropzgqU4y3dv+CBx Pgi21fx1431zxxp9+tlCJDY2TPEJMxr1xmjx/Zaz4M8UaH47vtRS9S3mFpeFIRHiJ+5x1r13S9Ks NFsEsdJtI7S1j5WKMYAp2pabZaxYSWOqW0d1ayj54pBkNWv1t+15kvd2tptta/oO55Rr0ljqX7RX h3cIriCbSyyhgGDA5wa9U/sHSP8AoG2v/fpaqxeFdDg1C2votMhW6tI/Kgm53Rp/dHtWxnIxWVWq pqMY9Fb8WFz5ls/Dk3ibwr40i0WINd6brZuoIUHUKeQB9BXu/gnxTY+JvDVpc2c6ecsSpPbscSRO Bghh1FaOl6BpWiy3Emk2MVo90++Yx/8ALRvU1Uu/B+g3l614+nrFct96WAmMt9cda3r4mNZOMlpo 19yT++w27nMfGLxJBa+DbjQrI/atX1YC2trSI7nOTyxA6CuH8Q+F7n4ew+BfEMkbSw6Qot9RZBny w3OT7AkivY9M8K6Jo9211Y6fGty3BnfLv+Zzj8K07iGG6t5ILmFJopBtdHXKsPcVFLE+x5VBXSd3 56W+Wgk7CWd7Df2cV1ZSrPBModJEOQQaz/FHiG08MeHLzVNSmWKOGNioY8u2OFHqc1j2/wAPrLTJ HPh7UtQ0eNiWMFvJmP8AANnFKnw90me/ivtcnu9anhO6P7bJlEPrtGBWPLRUr3du1tf8g0PO/Bnh LVV+DupPJayi78QXgmMQHzJEzZya9tgjWG2iiQYEaBQPYCsDxJoGpa1caXJpetS6UtlN5kqRLxOn 90+ldDVV6zqvmb36dtl+SBko6UUDoKK5xBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUA QXJ+7+Nc5rd1NolyusRxPNabRHexoMsq9pAO+O49K6K7/g/GqxwQQcEHgg96mSutCZK60I7O+ttQ tUubGdJ4XGQ6HIqHUdJ0/VojHqVnDcqf768j8etc3qHgYxXT3nhbUZdInc5aJCfKY/TtWZNYfEdV MSX8Dr0EiOoP16ZrGVSSVpwv6amEqkkrThf01OuludP8KaNm7u3W2iGIllbc+Oyr3PtXkt5PqHxA 8XgW8ZXf8sankQRDqT/P61vw/DjW9Vu/P8Raoo55IcyuR7dhXeaJoGneH7QwabDs3ffkbl5D7msH CpXspLlijBwqV2lJcsV95dsLOHTtPgsrYYigjEa/QCs3UfDGlanrVvql4H+1W+3yyJdo4ORx3rXz XNeIfC8OseItHv2tI5RbyN9pZnKkptOwYB5w2DXeoQl7stjsnFctrXOnDhhlWDA9wcio7mKG4tpI LpUeGVSrq/Rge1ea2ug+PNF8OtZ6TeBv3SssbOhMLecSyxnHdCDz3rR17QvEGpad4cL7rq5s5Ga8 OIwWyuBlWO0mtnSje3MrE+0bXws39C8I6NoN693pSyCRlMZ3S7wBnpT4/COlJ4hOtlJpL3eX3PIS oOMdPYVxFho3jqwAj0wmxtpdTuZplOxmIZwUYgnlCAeAa0X03xjcrFNfTXZuLbVPMZLe4jSOW3OQ Ngx2GMhqh4amtE1YhctkuTY9BzQWCjLEAep6V5zc2XxGjtbD7PfedM24zgNGPLfeNu4kcpszkDnN TzaZ43m+1LPdJPDP5qiFim1AJFMZHGeV3dav2S/mRp7T+6zo9O8IaRpWsvqliksVw+7cPNOwhuox 6Vq3llaalamC+t47iFv4XXI+orkYbHxRd6D4jtNXZ2vJ1kSyZJVEJQj5AmOVPqTWa3hvxdoFhYWn hm8M5lm868d3CpFwo8tUOfl4bnPWojQgk4pr9CU1FWUdDZuPhn4dmkZ4o7i3LH/llMQBTI/hh4fX /XG7nHo85xWbZr4x1Se+WDVJY7S2vhbwThAjSxZJeTDDkjIUcY4qOWx+JEWkzLFqAnuJFiYnMYZC GYSKnAH3dp56nNT9TpX6GXJS35PwO9bTrY6QdMCFbUw+TsU8hMYwDVTQvDmn+G4ZodMSRFmYM/mP uOQMVzJ07xxLdAvqZWEhI2X5FypiId8AZDB8dDTvDFn4tsdQ0mHUmuJLCKzMd0JpkO2UE/MCOXzx wcYqnQj8V1dG105J8p3O4ZxkZrJ17w1pviRIF1RJGEBYp5b7euM/yrkYdC8XWmvatq8cqK2qRTIE jk3tblT+5bDHaeB0HrTxH8QDGnl4SU6ZtIkmQrHcgfezj5iffp7iqlRjJWbTQnJSVpROs1Lw7Yar o0Ol3fnfZYtu1UkKk7RgZPerOladaaRpkVlpy7bePO35txOTkknvXE2Nv4+BsDqMsrWn2h/Ojjlj FwE2jZvbG0jdnIXnGKhi07x+txYWUZht7FIGiuHSVedwbkDsQdvSksPFO91cOZJ8yi7+h6RuG4rk ZHUdxWVrvhzTfEcUMeqRu4hYlCjbSM+/pXFrpfji00WI2hkFyttBFOTNG07lWbftcjHcEZ7Vdt7D x3JLavf3qGMeQlxAjJtkUhhKScZyBjp3pyoxas2rDclJWcWdpYWkWn2ENpbszRQqEQu244HQZqxm qmn2FvpdjHZ2YYQxDCh2LH8zVnNZWS0RqlZDs1dj/wBWv0FUM1fj/wBUv0FAx1FFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUABGRimeX/tU+igBnl+9Ls96dRQAzZ70bPen0UAN2e9Gz3p1FADdn vRs96dRQA3Z70bM96dRQA3Z70bPenUUAN2e9J5fvT6KADtRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFAEU0Pm4+bGPao/sf+3+lWaKAK32P/b/Sj7H/ALf6VZooArfY/wDb/Sj7H/t/ pVmigCt9j/2/0o+x/wC3+lWaKAK32P8A2/0o+x/7f6VZooArfY/9v9KPsf8At/pVmigCt9j/ANv9 KPsf+3+lWaKAK32P/b/Sj7H/ALf6VZooArfZD/f/AEo+x/7f6VZooArfY/8Ab/Sj7H/t/pVmigCt 9j/2/wBKPsf+3+lWaKAK32P/AG/0o+x/7f6VZooArfY/9v8ASj7H/t/pVmigCt9j/wBv9KPsf+3+ lWaKAK32P/b/AEqwq7UC+gxS0UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFIxC8k4HvUEl5DGMlifpWc6kIaydhpN7FiisifXooQSI3asybxoIicWhIHq1cc8ywkN5 /mdMMJXn8MTqqK40eP0B+eyb8GqeLx7p78TRTRH1xmojmuDltP8AMp4HEL7J1dFZFn4l0q+wsN6g Y/wucGtRWDqGVgwPQg5Brup1adRXhJP0OaUJQdpKw+iiitSAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACo buVobZ3T7wHFTVW1D/jyk+lY1240pNdmVFXkkUInec7pWJPp2pZ1whpiTR29sZp3VI0GSzGuc1/x PcLaMdNQQxFeJpB8x+g7V85ShKpC71Z2/bsibVbiC0hMl1PHCg7yNivP9X8eaBZMwFw9ww7RLkVx fiTU5ry7d7m4kmYcZdq429mA4WoWXwk7zZ6EK8oKyO6vPiraxk/ZtNlfPdnArJl+LlwufL0qLH+0 9cBcXHNUpJua64Zbhv5fxZEsZV7noZ+MFx/y00eI/wC69dX4F+Meoalri6dawSW5KF8SSbkIHtXh Lvu6V1nwtP8AxXsQ9bd6K2BoUKM6tKPLJJtNN/5ihiKlScYTd032R9t2cxuLGCZhhpI1cgepGamq rpf/ACB7P/rgn/oIq1XvQd4ps8aStJhRRRVkhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFGaKACiiigAooooA KKKKACiiigAooozQAUU1pFXqcVhT+OfDNtO0NxrdkkinDKZRwaqMZS2REpxj8Tsb9Fc5/wALA8Kf 9B+x/wC/oo/4WB4U/wCg9Zf9/RT5Jdhe1h3OjornP+FgeFP+g9Zf9/RSr4/8Ks4VdesiWOAPNFP2 c+zF7an/ADI6KimQTx3MCTQOskbjKspyCKKzNU7j6KKKACiiigAooooAKKKKACq2of8AHk/0qzVb UTixkI9KxxH8Gfo/yKh8SPNm1G61fxFcWrLvhsm+SEHj/ePqaxvFl/KJGtXGJchdueCT0rQ8NPu8 a64CejCuY8dXOzxr5QPBlj/pXz1Cq1+7WyS/I9dwS1Ob8VeC9f0bTZNV1BLcWykA7Hy3PTiqFt8K PEmrWy3E3kWMcihk81ssQfUCvV/i8QPh3Kf+msP8xS+KtQudK+H09/ZPsuIbNWjb0OKxniasYrkt du35FwipbnhniH4VeI9Htmuo/Kv4oxlxD94D6Vw1tbXF/dx2trE008jbUjUck17f8MPHeo+J/tdj rUizXMCiRJQMblPUGl0vw5ZaT8UdUuYUUGa2EsK4+7k/MRW8cwqUHUp10uaKurdSnho1FGdN6N29 Dgo/hHr72++a5toZu0RJP60/wNoeoeH/AIlw2mqQiOTyHIwchh6it74j+JvEXh/VIP7NHl2BQHzN m4M3oT2rP8L+KH8VfETTrqeERTxWbxybehPqKn2uLq4WdSpyuEovbdaA4UKdaMYX5k1v1PrvS/8A kD2f/XBP/QRVqqul/wDIHs/+uCf+girVfS0/gXoeHP4mFFFFWSFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFITwcGgnFYWsa99lkN rZAPcY+Zm+6n+J9quEJVHyxMa1eFCHPN6DrTXGvdamtI2jiSEcB/vSc4P0x/WtsMPWvPxpIuWMtw fMkLbiQMYJ71HNa3Fmd9ndXELjoVkOPyPFd8sJGTtGVjw6WaVKcW6kb67/8AA/4J6JkUtcPovjKS O5S01vHzHalyMAZ9GA9fWu2VgVFcVWjOlLlmj2MNi6WKhzU3/wAAdRRRWR1BRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAATgZNU49VsJbjyYr23eXOPLWVSfyz VqX/AFL/AO6a+NPhhz+0ZECTj+0Ljv7tQB9mE4qCe+tbYqLq4ihLfdEkgXP5mrHbivB/jb8JvEHj nxZaalpGoWwgSERGKeXZ5Jz1HsetAHu6kMoIIIPIIpaxPDVi+h+F9N02/vVuLi3t1jeUv98gckZ7 VfuL21tolkubqCFW6O8gVWP1oAuVSj1XTppvJjv7WSXONiyqWz6YzVhXjlhLxusiMOGTkGvjL4dD H7RtmozgapJxn/aNAH2iOlLWff6zpmmTKmpalaWjSAlVnmVC30BNLa6nY3tp9qsr2Ca3XrKkgZB+ PSgC/RXPnxt4Y+0m2Gv6f527aVNyv3vTrW4jKy7lbcpGQRyCPXPegCSq11qFnZkC7u4ICeglkC5/ OqGo+J9D0aQR6rq9naSkfcmmVT+Wa+dv2pLu21C78O3en3MdzAYZQJYZAy9RxxQB9DeI7tW8Ianc 2U6nFrIUliYHB2noa+TQiPHulXcxG52YZZm9a978Fcfs5QZHXTZD+hrw7SrmO01SyupoPtEUMqO0 IGd4HavXy6yTZ4OaXdSCuQvaOkcbS2rIsoypaIjp9ajCoR9xf++K9b+Ivj/Rtf8ACBsNPs7kzzMu HkgKCDHOcn8uK8qeCaOMySQzIgG4u0Z24+tejSqymrzVjyq1FU3aLuRbIyPuL/3yKPLjwcxqf+AV ObS5MXm/ZJzCB/rPKYKfxxUabSvByPX09q1XJK5g+aK1ufTnwsLH4X6JvJJ8g9Tn+NqKT4Vf8ku0 T/ri3/obUV8tU+N+p9rR/hx9EddRRRWZqFFFFABRRRQAUUUUAFVdSONPl/3atVU1QH+zZsdlNY4j +DP0f5F0/jXqjyXwvL/xW/iI5+7IorjvHlxn4hAZ/wCWsf8AStfQtVjsvihrdjcuIzd4aIseCfSr niHwMNd8Rxaql8bYgqZIyuclfSvj4V40qv7x2TivyR77puS07lr4uzbvh1Nz/wAtYf5imeOn/wCL WXo/6cV/lVT4tTqPh9MjMFPnRBQTycEVf1mwOueDzpiyiFri1VBIedvHWuf2q5KcntzP9C409ZRX Y8h+CSsfEV+4Hyrark1pfEvxFc+HPG2lX1gQZEhIkjPR0z9011fg/wAIWvgXSbgyXYmnl+a4uSNq hR0Arh0hsPiZ431hLiRlt7eALaSoeVIPXHfNd6q0q2NniN6cY6v8CeScMPGntJvQ63RPE+j+M7GS KJFZtv76zmGSPp61zmm+FofDXxVtTYkizureRkQ87D3FXfCPw6/4RrW21F9QNywQoiKmOD61em1C K9+JVnaWzK5sbV3mKnOCe1cvNCE6lPCyvTcW35aG7UpwhKsrSTVvvPpLS/8AkD2f/XBP/QRVqqum DGkWYP8AzwT/ANBFWq+2p/AvQ+Xn8TCiiirJCiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKD0NeNSftGaLDPJDJomoFopGjJBTkg4yOa2pUKtZtU1ew0m9j2WivGx+ 0foZ/wCYHqf5x/8AxVafh745aN4k8RWej2ulahDNdvsSSQJtBwTzhvatZYLExTbhoh8rPUaKbvoz XISOopuaM0AOophbjgZrzG7+PnhSzv57Sa31IyW8rRPshUjIODg7q1p0alW/s1caTex6jRXn9n8Y fDl9aR3EUd6EkXcA0Iz/ADqwPit4ex927/79f/XrgeMw8W4uauj0FleNkk1Sdn5HcUVyOl/ELRdY 1WCwtPP8+4JCB48dBn+QNdWp+WtqdWFVc0HdHLWw9bDy5a0XF+Y+im5ozWhgOopoPNOoAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAMzXdS/szTJJl/1hOyP/eNcvo9h9ot/ tEk26ST58KcHr1PrV3xrMfMtbfqPmcj9B/WsWwZBbJC8UqyJwjRj7w9c9q9ahTcaHMup8tjq6njH CWqivx3Okt04ZWHKnGR3pfLtoxPcXpAgtozLJn0AJP8AKo7JjFBunkJZj1b+VOe5WJidoljdSskf Hzr+Nc823eMXqdNFwjyyqbHPX0mi+LfBY8R6ANsS5zmMoWAbDBl/WtXwLrjXdm+m3Tlp7UAxsx5a P/6x4rM1G5sLDw+mh+H9PWwsV6oq7QBnJAHueprC0O8On+KLCYHCtL5T+6vx/PFdMKM54Vqe61Ry VcZSpZjGVHZ6Sts/+G0PYaKKK8g+rCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKAGy/6p/9018afC//AJONi/7CFx/Nq+y5eIX/AN018MeH/E9v4P8AjHPrt1C0 8NrfzkxoeWyzCgD7pr5T/aev7y08f2SWt3PCrWYJWOQqDz6A12J/as0DHGi3pP8AvLXnH7RGqx69 4h0DVoUMcd9paTojdQG55oAm+N+oXttZeC2gvbmIvosZYpMw3H1PPNWrP4TeNvG/w4svEN34iVYY LLNnYuXO6JQSDnOMnnrWb8dXxZeCQOv9hx19CfDnA+AmjMeg0c5/75NAHiv7N3jnU08Z/wDCM3t3 PcWV7A5iSRy3luo3Egn2BrifCmr2fh/44jU9UkMcFrfyyMQOpBbA/GrvwAYN8cdKZCNrCfb9PLas vQvDtr4q+Nn9i37ultdalIshU/NjceAaAOk0bTdV/aA+K9zd6lcCCxhO503cwwg8Io9fetz47+If 7AudO+H3hgrpWkW0StOIjtLsT/EfQDmuV8QWer/Av4uibS2kS1WTzLck/LcQE8ofXjj61Y+NPl6/ rWneOdNU3OjarAm5l58uReGibHQj3oA1NY8CfCuLwLM+l+Mo5degi81XMwxK+M7dtaPwt+LWpaR8 KfE8d3M93PpESyWTO2Su87B17AkGo9Gm+Al/pUU9/b3VjcmMCSF2PDd8EV0S+CvBXiP4TeJ5/hbD O1w8YjfzWyW2MHwB7gcUAecfDH4eXnxi8TajfeINUnEFvh55h8zyMxPyrngVU+Mnw5b4b6vZWNtq M15p1zG0lusx+ZCMbhgcela3wO+J1l8O9S1DT/EqSx2V5jlU5hkHXcOtVvjp8Q7L4g6xZTaJbzDT tPRoluZU2+azcnHtxQB714L/AOTcoOv/ACDZOv0NeJaD/wAh/Tv+viOva/BLh/2crfacj+zZB+hr xPQf+Q9pp/6eE/nXr4Bfupng5l/Gge8/GK3gi8AF4oY0bzoxlVA71v3i6TZ+BRcapaRSWkVojyIE HzfKKw/jJ/yTw4GT50f86veLh/xaS7GcH+zh9PuiuKPvRjHzPQn7spSt0KfgfxzpPjNrjTbXTDaL bLlYpFBVk9RXkvxP8P2/h3xpLHYgJb3aiZYx/Ce9bnwJwPFV1jGPsvbp2pPjl/yOtkcc/ZCM/wDA q9ChBU8VyLax5leXtMJ7R7pnqPwp/wCSW6H/ANcW/wDQ2opfhX/yS7RP+uLf+htRXk1f4kvVnuUd acfRHXUUUVmahRRRQAUUUUAFFFFABUc8YmgeNujqRUlIwzSaTVmGx8ufGDSZ9J1+LVEDIp/czMON rD7p/GuVTx74iitxHFqsuFGAW5NfT3jrwhD4h0yYNCJvMTbLF3ceo9xXyv4q8Dat4Ynlkijku9PU /LIq/PGPRxXz8aUKb+r1lt8LfVf5rseyqjnH2kPn5Mx9U1rUtWuY31K+mufnXh246jtXufiXUJ7D wHPdWchjnitVZHHbivnYzBmRg3AcE/nXq/iHx/4f1Dwbcafa3jPcvbLGqlDywFY5hh5ynRUI3Set l6G2FqJRm5PWx5tqni7XtbgEWp6lLLEQMoDtB+tZlte3FhcLNYzyW8o6PGcGoRwg9gM008sFGSx6 ADk17kKcYrlilY86U23dvU35vHfiaaEwvq0mwjlgMGvRfgl4auby4k1KcM8uoSCONn6lAcs1cr4P +Gd/rdxDcatE9tZsQVhx+9m9gOwr6q8E+E00K0SaWJY5tgSOJRxCnp9a8+cadaX1agla/vNLS3b1 f4G6lKmva1H6X79/Q62NBFEsa9FAUfhTqKK9s8oKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAK+Gbr/kJXn/XzL/6Ga+5q+Frs/wDEzu/+u8n/AKEa97Jt5/L9 TWnuekeDPgxeeMfC8Oswa1DaLM7J5TQFsYOM5DCu18I/A2/8NeLtO1ibW4LiOzk3mJYGUtwR1z71 4da+I9a023FtYa1f2sCn5YoLhlUE98A10Phf4na/4f1C4vJdRu9Sb7M0cEN1cO8SucYdgT25/wDr V216OMlGXLNNPpb9S2n3PrdpEiTdIyqPVmpsU8U2fKljfH9xs18iWieL/if4ga3+2T6hcuNz+dNs hhX1wOFHsBVrxH4C8W/DiKHUJrkRQtIFF3p9ww2uegbgHPB4xivM/s2KahKolJ9P6/yM+Tpc+taO 2TXh3w++NW/RdQg8XzeZPptsbiK5UYNyg42kf3vp1rzDxV8RfEvi++eS9vpre1Z/3VjaMyoAeAOP vH6/hWdPLK06jhLRLr/kJQdz6/DBvukHHoa+J9cOfFGrH/p+l/8AQjXQ2+i/EPwlbR+IILXVLCCP Ehm3kgj/AG0ycL/vACuTuLhru7mupDmS4kaV+Mcnk162X4RUJycZKSfY0jGx3GhcaDZn/YFdvo3g DVtd0qK+spbURSk4DswIx68Vw+gt/wASKzH/AEzFdFY+Ktb0u1W1sNRmhhU/LGoXH8q/IZyorE1H WTau9vU/VZQxUsJTWGklKy37WO68LfDzWNH8UWWo3cto0MDMziN2LcoRxkepr1AdK8V8M+J/EOte JLXTbjWp1jn3gkKuVIRiD09QOKj1vxB4y0DVGsb/AFadWU5STy1xInZgcV6+HxdDD0eanF8t/wAb I+UxuV4zG4pQrVIc6jputLvy7nt9FeZeE/iUrWMtv4llImhUslwF/wBd/s4HRvSua1P4k6/dX8k9 jdtZWx4jgVFbA9yQTmuqeZ4eMFO979Op5tLh/G1K0qTSVur2fpp/w3U9zHWnVxHgNPEt2g1HxBqM rwyL+6tmjUEjH3mIFdvXdSqe0gp2tfueRiaH1eq6fMpW6rYKKKK1OcKKKKACiiigAooooAKKKKAC iiigAooooAKKKKACism91sWl2YBFv29Tuxz6UxfEAb/l2b/voVg69NO1zRU5tXsbNQzXMUA3TSLG vqxxVAayrdYXH0NclqmseZ4nlFyrLGAohV+gGOT+ea6sOo158qZw46vLCUvaON9bf8OL4vvFl1eG WLdJCsQBdVJAOTWdY3NxF94rMhJIK8ED6d60rzUNgUrgxnsBWUbaVrxTpqq3m8mMttGfavdStQ5G 7WW/Y+NqydTE+0irtvbv5GmJobn5pJwfYngfhUc13FANscpfPG0c1UfTdVyXNkyE/wB1wc1VuLfV LeIn7C4LHG93XAP51+XYbhrGLM/ayxOl78yfvPyt39dPXY+9r5rRWBcfYSvb4WtF5t9vx9CnqcuX Ek84XachVOB+J71Qt5HuNRt2hjkcCZDvVCVGGHOenaunsdFsbVlmv8Xt2eSW+6h9AK1lvERdqRhV /wBkYr9T55WskfnyowvzSlqdrFMkyhopFkX1U5FSVyOg3qjWXjDiOJoizAnAyCMHFdR9phz/AK6P /voV4NaCpT5Wz7bCV/rFL2liaimLLGxwsik+zU+szqCiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAR13IykZBGMVw03wb8C3Nw88/h+FpJWLuxJ5J5Nd1RQBwR+CvgHB /wCKeg656mrurfC7wjrS2w1PR0uBaQC3hBYjag6CuwooA5PV/hr4V11bUato8dyLSEQQBmPyIOgF ben6NZ6ZosWk2cAisYYvJjiB6JjGK0aKAOS0b4ZeEvD2rxapo+jRW15EG2SqTkZGDSWHww8Jabrk er2WjxRX8cplWcE53E5J/WuuooAwPEngzQfFiwLr+mRXn2ckxM3VM9QPY1X0z4e+GNI0m50uy0iF bC6bfNbP8yM3rg966eigDzmX4E/D+W6ac6CoZjuIWVgv0xXXeHvDGk+FtP8AsehafDZwk5KxjqfU nua2KKAOJ174R+C/Eeptf6nocTXLnc8kZKbz7gdasXPwx8IXGh2+jy6Hb/Yrdt8cS8YY9ST3NddS HrQBzGraPZaH8PdQ07SbfyLaK0kEcS5OOD0r5etpZLd4bi3fZJGwdW9DX2JPEk8RjkUMrDDAjgju K4C6+DHhS6u5JljuIBI24xxvhc+1d+DxUKScZdTy8dhKleSlF7Hi2qeNfEWuWRs9W1Hz7ZmDFNgG MU+78deJrzTX0+51TzLJ4/LMPlqML0xmvYf+FIeFv795/wB/R/hR/wAKQ8Lf37z/AL+j/Cur65hu VK2xxfUcXdvm3PD9G13UvDty0+iXJtZGQozbQ24fQ0axrmp+ILpLrWbr7VMibQ+0LgdcYFe4/wDC j/C39+8/7+j/AApP+FJeFlPJu2HcGTIP6VTx1By50tSf7OxHKoX0Nr4UnPws0Mj/AJ4N/wChtRXT abYW2l6bBY2MYit4E2og7CivGm+aTZ9BCPLFR7FmiiipLCiiigAooooAKKKKACiiigBCM1jaz4Ys dXUtIvlTEY8xB1+o71tUhGayq0oVY8tRXRcJypy5oOzPn3xv8Dre4eS5t7c28p/5eLUZU+7LXi2u eAdd0JmZ7YXcAOBLAMkfUdq+6tmR1rH1TwppeqEtLD5Uv/PSLg/j61wfVq9H+BK67S/R7/fc7FiK dT+KrPuv1R8b6H8NNc1kpLcoNOtmxgyjLt9Fr2nwV8Fbaw2TpaYbvd3Yy3/AV7V7FpnhjTNLAMEA eUf8tJPmatN4Q6FSxGRjI7U/qtat/Hlp/LHRfN7v8BPEQh/CWvd/otjJ0fw1YaON0CebcEczSct+ HpWyFqpZWBs2c/aJJQ3QP2q5XdSpxpwUYxsuxyVJSnLmk7sKKKK1ICiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAA9DXwxPxqN0f+m7/wDoRr7mf/VtwTwelfI0 3wr8c/bZ5R4buHV5nYEPHyNxOfvele1lVSEHPmaW36mkGj2/4KWdtN8K7BpreJ23y8ugP8VcD+0V Z/Z9Y0KSGBIrdoZgSiYG7cvX8P616h8J9I1DQ/h3ZWGrWz2l0juXifGRk8dDVv4geCbbxz4abTp3 8ieNvNtrgDPlOPbuCOCPeueGIjTxrqN6Xf4iTtK58y+DPCeueLby6t/DdzHDcQIryK9yYiykkAjA 5x+mR611dx8FviC0JS7vbaSJjkibUGIz+Irnb3wj438BawtzHZ31vNCT5V7YqXRh35A6ezD8Kbe3 /j3x1JDb3i6tqhRsxxC3KKpPU/KAPxNe7OVScuanOPL/AF5mt3fQXxN8MfEPhXRm1XVVsmt1dUJg n8xgWOOmOBVf4bNZJ8SdCOplfswulGX6bv4M/wDAsV694B+Cws9Dv38YMZLrUYDCsCtkWyHvnu/0 4FeT+LPht4h8HXskd5aTXNnu/dXtshZCvYkjlT9fwqKWKhW5qLmm++1/TUXMnofWd99nFhcG+2C2 ET+cXxt24O7PtiviM+X5knk58ve2zPXGTius0298deMY49Asr3Ur+3barRByUUD+8x6L9TVWf4fe LIbiSJfDuoOI2Kh0t2KtjuDjpUYGhHBuUZzV3YIpRNjQP+QHZ5/55ivZvA+n+GrjwlayarbaY9zl tzXCIXIzx15ryrSfDeuQaNaxzaPfJIiAMpgYEH8quNoGrZydKvf/AAHb/CvyeNWVDFVJ8nNdv8z9 NxFGnjcJTpqryWs7prt6o9ystN8Mw36Saba6YlypOxoEQPnHOMe2aqeO7TR7nw9K2tsI1jy0Mi/f D9gvqfavMvCFnfaT4rtL+70y9SG3EjORbtn7jAAcdScU3xNea/4l1E3Fzpt5HCmRDB5DgKPy6+9e jLHJ4d3p6vS36nzsMonHHxtWvGKT5r67vRas5teRk4/x9/aut+Hdjo994i26s4MyANbwuPlkP+I9 K0PDXw1l1PSZ7rVnktpZU/0aMrgof7zD+lcrfeHtY0jUWt5LO4E0DfLLFGWBPZgQK8mNCrh3CtOF 12PpKmMw2OhUwtKraS0v/l37P/hj6IiUKMLjGe1S1xPgLxVd6tELDWLWaG9hXiRoyqyrjrk967av r6VWNWCnE/McTh6mGqulU3QUUUVqc4UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVFPMIIXkboqk1L WN4hudlukCnBkOT9BWdWfJByKhHmkkYeWnmaV8ku241aii6cVXh64q/CcfhXlU1fVndJ22Ob8QeL rfQdUs7FBFJJK6i4aVyFgQn7xx7ZrVeTw94ispnS8t7iG3G55kkA8odiT2rmLZ7HWPjLcC+aDy7O LyYoZcfvXA9D1PLVzyRS3Wo+IdDsl8qCS5kuLplHyrDEGO0Y9Wxx7V70MNBJW0aSdz5mpjailLmt KLbSXp/n1uegW+gW8aQSrq8UtpKw8vc4w/sD3qtPpeox+NYINLtY307AeScTrmFweQRnPtjHeuf8 DWD+J9Q0rzkB03QYBhSOHnYk/wCB/AetL4aisZbzxrrwj8uzWOWJNhKnnJOD1Gf610v2ibvK7St9 5zJUZwjy00k3fR9ldv06aWO1tPE2k6gNVMDSCHSs/aJWT5eN2dvr90/pWNc3764GubFCLKJN+9xg Yxn8zXBtoUNj8L01ya4uVu7uby441fEbrnGSvfgE10erNL8P/Btrp1leSfa9UYOzy4ItlwN+0emT /OlClGlK9Pe9l+oqmJqYinavpFK7t1v8K/4BrWVvc6qW+yAxwIPmkYfePoKkex1R42KWyx7P4Xbl qyfCWqzWnjIaTBrp1nTHszM0hxhGAycHtj+oqTw/4g8VeI7gTW0dsNNW9KvcMi7lj/uAdTxjn39q KtbEKUpRaS0/rUnD4bBOEYyi3LVafLXR7K+huWGnSQK0t0F81h0HO2p5EGKvzLjNUZehFfOV5yqS c5u7Z9dh6UKMFTpqyRnXbPvt44XZHknVVZTgjmvRF4UA9RXCWMf2rxTYxY+WMGU/gK7sdK3wS91s nEvVIWiiiu85QooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKQ0tFACdqTHNOooFYSilooCwlFLRSsMKKKKYBRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAGKMUUUAJigKB0AH0paKADFIVyMHpS0UANVFUHaAM+gpce9L RQAmKWiigApKWigBMUYpaKAECjdnAz60tFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAHp XM69YarJf+fYwRXMZUDYZdjKfx4NdNSYrOpTVSPKy4TcHdHCGTUbbAudHvQO7oBIB+RpU1+xRsTu 8DDqJo2Wu5KZUjNYuqabNMGK/OD2IzXL9V5fhkbe3vujn45LK5MtykdtPc5IiulQbiD7464q3aWW kRGe3htEV7yMrcsi48wf7R/Os57eWydkMLDHI2jAFc3q1zfBme1jljlP/LQyEfoK+ewssyWMnFRb jF2u+ybfV+a1122OmpDDOmm7K+tvM9C0rTdO0fSzp2lw/Z4Du4DEtk9SSeSayT4OsLXwTf6FZ3M0 cdyTK074Z85B9sj5cfjXnH/CYeK7A95gPU/45rpfDvjW+1uF4JolgvE+/FKMCRO5Uj09K97E42ph abqTTt1e9uzfWxwRwlGq1BW2t206pE974L1e98H6XZW+qW9y1lMZYllj2JsxhV46kc9fWrPjHQta 1C40XVbe2t7+7sFAuLRThZDkElc9RnNT6hqwsreCF45Jk34VYepA9fSpm8Z2ELLHepLbM3ZwP8a5 8BnyxSUtL/m2ve03snoTWyeCi0r2dvw23uUYxdR+GNY1FvC8Ok6gIWjt0t13SOGGCSB6HFX/AAPY nSvBljBKjRyOGldGGCCx6GrEXiTTZuUvYwT6kirAvIZ+Yp45M/3XBrsni1OLiu4qWCVOanfZW6dX e+hNK4qlMc9KkkfPrVV2HJzjAzXBOVz0Yqxa8LRGbX7646pFGIx+J/8ArV2IrmvBMZOmXNy3Weck H2FdLXp4WNqSOSu71GFFFFdJiFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFGKKKAI5LeKUYkRWHuKoz6FYzghoQM+1aVF AHOT+C9PmP3cfhVQeBLaGdZ4GVZEyVOK66ionCM4uEtU9BptO6OQXwteToRNKIjkgbT2qqfh1C7l 3cMx6sTkn8a7miuXB4GhgqfJRjbz6v1ZpVrTqu8mcdF4AtU+8VP4VaTwLpn/AC0iUn1GR/Kunorr cIy3VyFKS2ZzTeCbBR/o91fQN/0znOP1zUE3g+82sLfWZMEdJoQ36jmusorF4ak+harVF1KGi2B0 zSYbR2DtGuGZRgMfWr9FFbxSirIzbbd2FFFFMQUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFAHBfFr4lP8MfD1lqcelrqRurr7P5bT+Vt+Rmznac/dryYftbXBOB4NjJ/7CJ/+N10 H7V3/JP9H/7Cg/8ART18po7RurocMpyD6GgD6R/4as1AFgfA3KjLD7c3A9/3VH/DVuoFlUeBvmYZ A+3tkj1/1VdlZGxvrCHUptpPiKzgt+AP+eTnH/jx/KuYt51H7QOn6ShVk0zQDDwO/BP6Yr5GnxHK bmvZfCm9+2/Tvodrwtra7lNv2rr5HVH8EBXb7qm/YE/T91Tpf2qtSgmWKbwKY5G+6j3zAn6Dyqbq d5c/8Ls0KeTTb7U0hs59iSWIgaP5sFkBxvAyOfeqPxb1DUtJ03w/4p02+SZbW+byEvLMLMjkNweh KjBGCOwNdVPOp1KlOn7Ne+r79dbLby62/Ah0Ek3fYvv+1ZqEa7pPA2xemWvmA/8ARVD/ALVmoRIW k8DbFHUtfMB/6KrO+MviK/TTfDOmKYRbaqkVxcjyxuLqyEYPYZJ4rc+OM8yeDruCM3PlNJCXVbLM X+sHJmxwenH+NKnndSbo3ppe0bW+yTS7f13G8Olza7FR/wBqzUI0LyeBtqjqzXzAf+iqaP2r74xi QeCAUJwGF+2D+PlV3GtSb9K1O1ieK4lGjtILCRAFPykby2O+MY9q5T4bQ2eofCPQNJvMB7syyQnH 8UU2/wDp/OuaHEbdF1XS2aW/Rpu+3S3/AAS3hPe5blP/AIatv9zL/wAIP8y43D7e2Rnpn913qaP9 qPWJl3Q/D+WRckZW8cjI6j/VVx3jOVj8XPGFmhw0+mCWMAdZIVjmX/0XXp/w2vEkXXbaNgUTUvtc fH8FxGsoP5s1dGJzudDDxrKne6Ttfo7eXd2Ihh1KXLc56H9qfVLguIPATymM7XCXrHafQ4i4pW/a n1RLhLd/ATrM/wByM3rBm+g8rJra+Guk/wBmX/jFiuPN12UDI7BQ3/s5qXVtL8/45+EL7Z8qWlzl sd1xj/0ZWK4iTxDo8miV73/u37fIr6r7nNcw5v2n9atoy9x8PZokAJLPduoAHXrFSR/tRaxNGskX w/ldGGVZbxyCPY+VXffGmTf4P1uLjEOjzOeO7nA/RDWb8M/+SZeHf+vJP5munMs7eC5uWHNaSW9t 437EUsP7S12ZfgT9o248ZeOtN8Oy+F0svtsjIZvtpcptRm+75Yz93HWvdK+N/hbq99dfHfQdMnm3 WlnqN2YI9ijZuWUnnGT+NfZFe/TlKUU5KxzNJPQKKKK0EFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFBIUEk4A6k0AFFUf7c0n/AKCll/4EJ/jR/bmk/wDQ Usv/AAIT/GldF+zn2Zeoqj/bmk/9BSy/8CE/xo/tzSf+gpZf+BCf40XQezn2Zeoqj/bmk/8AQUsv /AhP8aP7c0n/AKCll/4EJ/jRdB7OfZl6iqP9uaT/ANBSy/8AAhP8aP7c0n/oKWX/AIEJ/jRdB7Of Zl6iqP8Abmk/9BSy/wDAhP8AGj+3NJ/6Cll/4EJ/jRdB7OfZl6iqP9uaT/0FLL/wIT/Gj+3NJ/6C ll/4EJ/jRdB7OfZl6iqP9uaT/wBBSy/8CE/xo/tzSf8AoKWX/gQn+NF0Hs59mXqKjguIbqIS200c 0Z4DxsGB/EVJTIatowooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA8J/au/wCSf6P/ ANhQf+inr5Sr6t/au/5J/o//AGFB/wCinr5SoA3IvGviWC1sraHWrxIbBg1qgkOISAQCvpwSPxqO Pxbr8Wuya1Hq10upyrse6EnzsuAMZ+gH5Vj0Vh9Xo6+4tfJFc0u56f8ADaXV/iF8Q7eLXPEGprLZ 2sstvcwzYkjIK8AkHg55rU8ZaDPq/hLwzq2sa5qd/Nfan9jaOeQFI0LspKgDg4Uc1w3w48Yp4G8X x6tPatdQmJ4ZUQ4ba2ORnjPArqPGHxS0XV7PQ9O8P6Rc2lhpl8LxxOy7mIYnaoBPqeSa8DEYfExx 8XQh7itqkrLSV131bR0wlB03zPX/AIY73xJ8Jlur5Hv9e1e9s7DTpZLZppVZoZUIwoOOFIx+Vclr tnrOr/BvRtXufEeq3lzq94kD2txMDCT5jhTjGeqg1oH4+afIuuxTaXetFfsTajeuYgYghDc/3gTx 61xl18Rrd/hbovhq1tJ477TLpbj7QxBQkO7DA6/xD8q4MJhsyXIq0fhlHotFZt/ja9uprOdLXlfR nqupeC7qOLULaw8Z61J4nstLWSV5JB5UkZLYjxjgEqe5xWH4N8FXup/C/RtZ07xBq0F3byM0EEUw EcSmUpJsGMglCxqpqPx10mfTL28sdDuIfEN9ZLaSzM4MKgZ5HOTgsSOBWX4Q+MVp4Y0LQNONhdSD T/PF1sZQJVfJXb7g4PNZRwuZrDtKHvcy3UdbRd16N6L1Hz0ebf8Aq5W1qD+wf2go7W51C5vkM8UE lzdsGkZZYwhyeOgc16D8KLh4NcW1mOGudGjRx/00tZngI/752/nXivjbxZF4l8e3HiGwgkt0do3S OUjcpRQO3uK63R/irpel+LYNU+x3pgju72Vo12bjFcKrbeuMiRSfTFd2MwOIrYOEOW8uRJ7bpXt8 2Z06kY1G76XPcvE8qeHPBfiDUbc7XMclwWH99gFz/Ktq2ghu9Q07U/4o4/3Z9BJtJ/kK8M8dfG7R fE3grUNG03TtQguLtVUPME2gBgTnDE9q1dI/aD0Cy0WxtbvS9Tee3t44pHQR4LKoBIy3tXzSyfHx oxn7N83M+21l/wAE6/b0+Zq+h6Z8Tkl1Dwz4vS2RppDZtBHGoyxKoCQB9Sag+HdvNafDnQILqNop Usk3I4wV78j8a4DRv2htEmluBrdheWzPPI6TRgOGUsSNwzkNjA4yOKr+Kv2gtN/sue38K2tzJeSq UW5uFCJFn+IDqTXVjcFmOKrTpKk0pT5rvtay8tiKdSlCKlzbKxxvwl/5ON0z/r/uf/QJK+1a+Hfg Yxf44eHWYkkzykk9/wB09fcVfosVyxSPLe4UUUVQgooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAqvqP/ILuv8Ari//AKCasVX1H/kF3X/XF/8A0E0nsVH4kfFC qu0cDp6Uu1f7o/KhfuD6UpIAJJwBXz6P2Nuwm1f7o/Kjav8AdH5VoTaFq9tdWttcaXeRXF5/x7RP Awab/dHfr2qk6tHI8cgKvGxR1IwVYHBBHrmqcJLdGMa9KekZJ/NDNq/3R+VG1f7o/KtDUNC1bSIE n1XTLuyikbYj3ELIGbGcAnvgGn2Ph3W9Uthc6bpF9dwFivmwQM65HUZAo5JbWF9Zo8vNzq3qjM2r /dH5UbV/uj8qlnhltbqW2uY3hnhfZJE64ZG9COxq5qGhatpMCT6rpl3ZRSNsSS4hZFZsZwCR1o5Z dh+3pae8tdtVqZ21f7o/Kjav90flU6WtxJZz3aQSNbW5UTTBSUjLcLuPQZ7U2GGW5njgt43mllYJ HHGMs7HoAO5pWZXtYa6rTfXb1Itq/wB0flRtX+6Pyp8qPBNLDOpjlhYpJG4wyMOoI7EVd/sTVftv 2P8Asy7+0+T9o8nyW3+V/fx/d96fJLsS69KKTclZ+Zn7V/uj8qNq/wB0flQrKyhlIIPQinVJqmnq j6b+CHHwtssf895v/Rhr0GvPvgj/AMktsv8ArvP/AOjDXoNe5R/hx9D8qzL/AHyr/if5hRRRWpwB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAAeBWdZ6xb3k97 Em5PsT7JGcYGfb2rRNctoRVb7xCXQOonJKnuMHisKk3GcUut/wAiW7NHQ2d7Bf26z2kqyxE4DL3q xXM22sw2XhaLULTT1it9+0wo2NgzjNbc97HBp73h5jWPzPqMUU6sZRu30uCY681C209Fe7mWJGYK C3c1YVtwyOnY+tc3e6tBP4dtb++00SJPIpSJ2B256NmrF94gWx1U2H2WSaRog8QjPLk/w47fWp9v FO7emn4hzI3aK5+28QTjVIrHVrBrJ5/9S28MG9vrU+pa41rfJYWNq95eON3lq20IPVj2qvb0+Xmv 5f0tw5kbNFc6fEksN7b2V7p7wXU0oQrvBXB/iB7/AEqLUfFjw6m1jplk17LH98gnHvgDmk8TSirt hzo6eisW114NosmoajbtZiNipRzk59qxj43uGVriLSXNqpwZC54+pxgUpYqlBJt7ic4o7Oisuz12 yvNIbUFkKQxglw3VCOx96wJPHM0sj/YNKkmjTqSSSfyHFE8TSgk29xuSR0Goa9Y6ZeQ211IyyTfd AXIHuT2rSBzXHa5qVmuoae1/pQmmdFkBMpGzJ6HjnFaWra7d2N99lstKmu32Byy524/CojiEnLme i8mLm3udATWPpviO11PUZLKBJRJECWLrgHBxxzVTRfFA1K/Nld2rWtyBkKehx29qxvCP/I33v+7J /wCh1MsTeUPZvRuwnO7VjvKKKK7jQKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigDwn9q7/kn+j/9hQf+inr5Sr6t/au/5J/o/wD2FB/6KevlKgAq 9pGh6rr901tomnXN/Oq7jHbRF2AzjOB2yR+dUa6vwR44bwW100VgLprma2dz55jPlxSiQx8A8MQu fpQBQ/4QjxR9oe3/AOEe1Pzkt/tLJ9lfIiyRvIx0yDz7VLpvgfXdRF4fsFxB9ki3nzIH+d/l2xrg ffYOpA967a2+Od1FpsUE2kebcWwElvP9sYfvgZjvkGPnXM7ELnqBzUlr8e763ltXbRIX+z2lvBgX BXfJGQWlb5eWfbGPYIBQBwX/AAg3ir7RcW//AAjup+daxrLOn2V8xo2SGIxwDg/kai03wd4k1myS 70nQtQvLZ32LNBbs6s2cYBA9a9U0/wCL+kt4BuU1Bp49Yt7RrWxgQuxLG38kSO/RvvyNg9O2c1y+ h/FybQ9I03TotJDwWUUETAXbL5oS5Nw+QBwXJUewXvmgDk4/B/iSWGCaLQtReO5laGFhbORI65yo 45I2n8jTv+EL8Tb7hP7A1HdayrDOPsz5jdsbVPHBORx7j1rvZ/jrdSWUwi0cJeXNr5E8/wBrbAYR PGrxrj5DiV2PqxzkVoQfHqS8S30+WwGlQNfxSSXaSmUxQK8bEbdoLtiIDOeR2oA868OeB9Y8Ra9B piQNZmS3kummuEYKkKA7pOBkjKkcDk8VXk8GeJEkRRoWosJYDcxn7K43wjrIOPu8jn3rpL/4nyye ONf1y1slKahbPY2cRcotrAWXACgc/KpBHHLE1e8SfGa51nSdV0/TtLbT11LcXm+2M8iF5VklAOB8 p2qoXjCjvmgDlH8Da6PCem+IYLKW5sdQkeONoI2fYyvsAbA4LNwPXFXrD4UeN9R/1Hh67U/aRakT L5ZDlS3IOMAAZJ6cium8N/GseGtL0e2tNADS6fCltI73ZKSRh2kJVNuFcswO7n7oqW4+Ob3d9Fc3 OjS5huJpEEd8Vwj23kAH5fvLy2enJ4oA4AeCvEzeVs0HUXE28xMts5EgT7xHHIFYZBBweor1bW/j pe6n4TbRLPShYhrFLQTpcnMeAikqAo4KIRgnPzHnjFeU0AegfAr/AJLd4c/67Sf+iXr7jr4c+BX/ ACW7w5/12k/9EvX3HQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFV9R/wCQXdf9cX/9BNWKr6j/AMgu6/64v/6CaT2Kj8SPilfuD6U2b/USf7p/lTl+ 4PpSSKWidRySpArwI7o/YKmsGvJn0broTV/FHheVeZ9A1i3jbA/5ZT2uef8AgQFfPeqE/wDCZa9z /wAxOX/0aa9N0v4saDYfETWNSnt9QuNLu7OyWMJb/OJ4ARnaSOOTzXllxc/bdd1S+SJ447q8eeNZ Bg7WcsAffBr1q8o8m5+d5Th6yxV3F7Pp5M7n4320cfxHu7ufWLadJRAo0xZXMsB8ofvGTG0A46g5 5FRfDqeaO28YiOaRAvhu5dQrkANleQOx96yvH3iTTPFniSTXNN0rUba+uNiTi4njaLy1Xb8oUZzw Dkn14qroXiB9Ah1pY7T7UdU0yXT/APWbPL3kfP0OcY6cVnKpH2ylfQ76GEqvK6lJwfNfa1n9/Uwd OHmQxTOWeWVlLuzElju7k13/AMbLWOL4kX13PrNtOspgVdMWVzLAfKX52TG0A46g9xXB2UbQWsSO PmTHf0Oa1vFeuy+LPHN9r8tmtmLpI18kSb9uxAvXA64zWcakUp3Z1VcFVdTC8kNEtdNFtujd0r/k iXjv/rtY/wDodZXgH/kePDf/AF/2/wD6EKm0XxHZ6b4Z1nQtU0mfUbPVnhaQ290IHj8s5GCVPU4r N8P6ouj+JLLUvscnkWN4s0cBkBdkVshS3TOOM4ocouELPYpUascTiVyP307aaPQd4oGfiR4rB5zq k/8A6Ga9bnnki+B0vjHD/wBr/wDCP/2UGGM+T52wSfkc14xqd62q+J9a1VIHt1v7uS4jjcglQzE4 JHpXfj4haFIJ9Gngv49EbwwNLVfJ3H7QCTv2g9OevsK2hKPtZO55WMoVf7OoQ5HdN9Hoeb2UQhso 0Axxmp6raezNZRhwdyjacirNebU+Nn2+D5fq0OXay/I+m/gj/wAktsv+u8//AKMNeg1598Ef+SW2 X/Xef/0Ya9Br2aP8OPofmeZf75V/xP8AMKKKK1OAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooADXK6L/x9eI/+urfyNdSelZtro8Vo988byH7YxZ844J9Pzrnq wcpRa6X/ACJa1RmeHLRL7wStrJysqupz9azFupbvw7a6ISRctc/ZpB/sKckn8K6vS9Oj0uwS0hd3 RM4Ldearw6Baw65Jqi+Z50g+7n5Vz1IFc7w8+SKXaz9CeV2Rn+L41h0G2jQYVLiNQB6ChlB+IUeR kizOD6VrarpUWq2qQTO6KsgkBXrkUn9lRHWl1Pe/mrF5Wztj1q5UZOpzLbT8Lg4u9/QyvFQxe6Ke 4vBgjt0pNGIXxjrKTDEr7Sm7qV9vbpWtqWkxalJbPM7qbaXzF29z71U1bT9Lvr2M3F19lvUXKvHK EfH9aU6clUdRd1+Vgad7lPxHIv8AwkOhoGHmCcsVzzjIqhq+hXdlfXOq6JeINpZ3QNhk9R6H6GnN Z2jeJdNt9Pna7likM1zO77zgDgE9vpV268D2lxdyTrd3CGVy7jgg5rnlCdXmajfXva2nclpu5h6j q9zrPhMSThS8FyqyMowGBHBxW3p89qPAXzMmxbd0cf7XPb1zWta6FY2umNYJDuhf7+85Le5NYx8B WBmyLi5EZOSmR/OmqNeD5vibVnqPlktTmLNLj/hFNRdAfK8+Ld74zn+YrrPB11aLoCRrIiSox80M wBznr9K2rfSrS2037DFAv2fBUoed2euawJPANg0uY55415+QYOB6ZohhqtCUZQSdlb9RKEo2aM7x mQ3iGxKkEGNcEcj71T6hqupan4mfSdPu/sUaMV39yQOTmte88K2t7JavJNOpto1jXGOQOmabqnhK 01K9N0JJbeV/v+Xj5vf2NE6Fa8murXUHGV3Y5qyge28eQxPdNdOsmGmY8scdKteEf+Rvvf8Adk/9 DFbdr4QsbG/hu7aSZWiIO0nIY9yfep9M8OQaZqkt7FLKzy5BVsYGTmpp4WpGUW1tK+/kCg0zaooo r1zYKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igDwn9q7/kn+j/8AYUH/AKKevlKv0S1nw/o/iK2S317S7TUoY33pHdQrIqtjGQCOuCax/wDhWHgT /oT9E/8AACP/AAoA+BaK++v+FYeBP+hP0T/wAj/wo/4Vh4E/6E/RP/ACP/CgD4For76/4Vh4E/6E /RP/AAAj/wAKP+FYeBP+hP0T/wAAI/8ACgD4For76/4Vh4E/6E/RP/ACP/Cj/hWHgT/oT9E/8AI/ 8KAPgWivvr/hWHgT/oT9E/8AACP/AAo/4Vh4E/6E/RP/AAAj/wAKAPgWivvr/hWHgT/oT9E/8AI/ 8KP+FYeBP+hP0T/wAj/woA+BaK++v+FYeBP+hP0T/wAAI/8ACj/hWHgT/oT9E/8AACP/AAoA+BaK ++v+FYeBP+hP0T/wAj/wo/4Vh4E/6E/RP/ACP/CgD5F+BX/JbvDn/XaT/wBEvX3HXP6d4B8I6RqE V9pfhnSrO7hJMc8FmiOhIwcEDI4JroKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAqvqP8AyC7r/ri//oJqxUN5G01jPFHjc8bKM+pFJlR+JHxOv3B9 KWvQx8DfGoUD7PZf+BQ/wpf+FHeNf+fay/8AAof4V4nsan8rP1P+0sH/AM/Y/eeeUV6H/wAKO8a/ 8+1l/wCBQ/wo/wCFHeNf+fay/wDAof4UexqfysP7SwX/AD9j9555RXof/CjvGv8Az7WX/gUP8KP+ FHeNf+fay/8AAof4UexqfysP7SwX/P2P3o88or0P/hR3jX/n2sv/AAKH+FH/AAo7xr/z7WX/AIFD /Cj2NT+Vh/aWC/5+x+9HnlFeh/8ACjvGv/PtZf8AgUP8KP8AhR3jX/n2sv8AwKH+FHsan8rD+0sF /wA/Y/ejzyivQ/8AhR3jX/n2sv8AwKH+FH/CjvGv/PtZf+BQ/wAKPY1P5WH9pYP/AJ+x+9HnlFeh /wDCjvGv/PtZf+BQ/wAKP+FHeNf+fay/8Ch/hR7Gp/Kw/tLBf8/Y/ej1j4I/8ktsv+u8/wD6MNeg 1yXwy8PX/hfwNbaXqyRpdRyyMwjfcMM5I5+hrra9ikmqaT7H5tj5xniqkou6cn+YUUUVocYUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAH pVG90ew1Ahr20imYDAZl5A+tXqKUoqSs1cNyrZ6baafGUsreOBT12LjP19atUUUJKKsgCiiimAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRTd9G/2oAdRTd/+yaXdQAtFN3e1Lu9qAFop N3tRu9qAFopN3tRu9qAFopN3tRu9qAFopN3tRu9qAFopN3tRu9qAFopAcmloAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACg9KKDwDQB ExVVLMQoUZJPYVwF3451TX9Zk0jwLaxy+UcTX8w/dx/T1qz8V9Zm0rwY0VqxSa9kEIYdQO9WvDdl Y+CPh0Lq4AVIbc3Vy46scZrOTblyo9ClThSw/wBYmrtuyXTTdsS28MeJGxLeeLbnze6RRAIPwrWh k1bTCF1J0voOnnxptdPqvcV4to8/xM+MhuNa0rW18M6GsjJaIqnMmPpyfrXXeENU8e+EpNWtviL5 V9o+nW5nj1ZCAXA/hx3zVpWOSdWU371vuSPVIyGGQcgjNPxXhej3XxU+KFu+vaLrNr4Y0d2P2KBo t7yKDwTxW14K8feIxrWr+DfHEcSa9YWrXFtdQjC3KAfex696ZketYoxXzl4R1r4sfEbwleXena/b afFp0sgEzQ5ku2HO3jgAdPxqbwl4g+K3xT0ec6bq9pog0o+TLL5WWu5h29v5UAfQ+KMV474K+Llz /wAKt1nWPF6h9Q0GZrebyxt89hwvHqTWTpC/Gfxzpg8SWetWeh2848yzsGiB3p2ycd/egD3jFGK8 fvfif4p8L/DZrzxZoSw+ImuvsNnErfJdOf48dgKhGg/GK00o6+fFNnPeiMzPpLQDyyMZ2BvWgD2b FFeEeGfip4n/AOFJa94q1BRe6na3TRRx7MCIZxyB2FHhy/8AiJqmi2HiLw54xsfEVzKyvd6OyogR SeQD1BFAHuFxd29oga6uIoFY4BlcKCfTmpRhlBByD0I7183ftA3njaQWSX1jbQ6IL6JrR1cGQzY+ 63tnNe0fDy48Uz+GFbxra29teAgRJbtkGPAwT70AdSvWnU1etOoAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAopNxz0paACiikDc9KAFooPApAcmgBaKKjuJ47WBppmCRoMsx7 CgCSiooLmO5jEkLBlIyCDUo5oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKD0NFB6GgDzr4x2Mtx4Qgu4l3fY5w7ewPeteW2i8cfCuSy glAGoWJiDA/dfHT8xXR3lrBf2UtpdRiSGZCjqe4NebWllr3w0v5Us7WXV/D0z7wkfMkGfQVk1yz5 u56dOSxGGVC9pRba877r17HH/DP4o2fw30Q+DPiDa3GmXOnSOsM3lEpKpJPWups/Gx+MVl4i8O6P pF1BpEto0UOqzDaHcjgYroZvFXgrXY0Oq28U0ijiO7syzr7citmw1AXUKW2gWBtLRf8Alq0XloB/ sr3rS6OCVKpDSaseT+Bfivb/AA+8PR+E/iBpt9p9/pQMUbxW5dJkHQgipvCw1Px38RNX+IU2nTaf pNtpslnYLOu158qcsRXtMtha3YX7Zbw3BXoZIwxH51Y8tAmwKAuMbQOMUzM8f/Z4Vk+Et4HVlb7Z cEhlINO/Z2Vl8Na/vVl/4m8p+YEV61Ba29tGY7eGOJCclY1Cg/gKILW3tVZbaGOEMcsI1C5PrxQB 83+FvCVz4z8B/ETR7QFbp9VaWAMCod1YkD8a6Lwn8ctN8N+FrfRPGOlalZaxpkQt2gjtiwl2jAwe 1e3Q2ltbFzbwRxbzltihdx9Timy2FncTLLPawyyL0d4wSPxoA8Q8XjxR8TfhxZeJbfw7Lp9/o9+L yzs5Gy1zEO+Oxx2rTf8AaC0afw6YrTStUk154zGNO+zNkSYxyfSvYwADkVCtlarcG4W2hEx6yCMb j+NAHz18N9a1rQ/gjrepWuhDVbv+0nN1YyqRlT94474rlfFNx4IutKtdW+HCanpPiyWRP+JfaI4V XJ+YEdua+sIbW3twwt4Y4gxywRQAT6mo49NsYbgzxWcCSn/losQDfnQB4r8b4NYn+EHhu81SB5Ly 0u4Jr4RrkqdvJwPevQk8ZL9g0mTTIBd21zbo3mDPoOK66WGKaNo5kWRGGGVxkH8KjisLSGNUhtok ROVVUACn2oAljO5QemRnFPpq9adQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FMkdY1LuwVVBJJ7CgDjPiD45PhBbGO3CPPcSgurfwxDqa660u4r20hubdg0UyB0I7givDprKb4n+ NNYuRLstbOFlgOepH3R+PNdX8KPEUs/hm80i5P8ApmmBtgJ5K8/yNelWwsY0U4/Et/nt9x5VDFyl Xal8L+H5bk/jT4nvo+pnR/D9sL3UAdrtjKoT2A7muek8XfEnSY/t+o6cJLXqymEcD8ORTfg/bQah 4v1e/vQHu4iWTfyQSxya9oeNZI2R1DKwwynkEVVWVLDSVJQUrbt/oTSjWxcXV53G+yX6nNeDPG1n 4x09pIV8m6i/10BOSvuPauf8G+NtV1r4ganpN75RtYQ5jCrgrtOK5rwaiaX8bb6y0/5bYmRSo6Yx nH51L8OP+Suax9Jf/QhVyw9OPtGlpypryuRDE1Z+zTevM0/Ox7PWJ4xk8rwhqTnPywE8Vt1DdW0V 3C0FxGJIn4ZT0NeVF8sk2evNOUWkea+HbHUYbG3vtV1VtNWUAxQ9XYduK9DsbtJLcL53muBySME/ hXl03iIJ461L7eRvgl8qJGH3EHTFdGfE8UzWxjZfN81VUL1Oe1d9elObTa3PPw9aEE1fbQ7eKeOd N0ThxnGRUled33iNfD/jG7t4nLRSbWMSc7WI7Cu5027kvbGOeWFoS4zscYNcc6UoJSezO2nVjNuK 3RbooorI2CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAoPSiigBu00bTTqKAIDZ25febeEt/eKDNS7OMYGBTqKAvcbtNGDTqKAG7TRtNOooAbtNG006ig Bu00bTTqKAG7TRtNOooAbtNGDTqKAEAINLRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFcl8Sb2/svBd0NKgknnnxF+7GSoPU11tGBVwkoTUmr2M6kOeDina543oHwgubjRre6uNY ubGedN8kMYxj2PvVe28Mar4B+ImnPYCfUbS6+SSUJ2PDBv517ZRgeldn1+q2+fVPocX9nUYqPJo1 1PF/EHhzXfAnix/EHheI3FnMxZ41G7bnqpHp70+6+L+t6jaG00rQpIr2Qbd+1jtPsMV7JtHoKYtv Cj7khjVvUKAaFioSS9rBSa6/5g8HOLfsqjin0/yPO/hn4JvNGkm1vXs/2jdKdsZ5KA8kn3NcNZ3+ ueFPHWp6jZ6LNctJI6YZDggnOQRX0DgelGB6ClHGy55Smr82lhywMeSEYStyu9zzTw38RfEGq65F aah4ee3t2BLyqG+XH1Fdnq2oGPwxd30e5fLj3LuGCMGtjA9Kz9b086pot1Yq/lm4jKbsdKwnOnKa ajyo6IU6kKbTlzM821zR9B8XmLVf7RGlakUAeU/cl+o9a2PCHw/t9MmTU7nUm1KRRmAhcIp9cd6n 0j4dw6fAsl3Mt7drjaJF/dL+Heu2gQJAi7VGBjCjA/Ct6uJaj7OnJ2/r5nNRwqc/aVIpP+vkY2le FdO06+n1Bk+039w++S4l5bPoPSt0UYFFccpOTvJnfGMYq0UFFFFSUFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFNBzQA6ikznpTS2Dg9aAvbcfRTQ496XIoAWiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKOaACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKx9f16z8NaTJqGoPiNeg7sfStivJ/jilydJspF3G2WT58dAfek9Ed2X4aGKxcKU 3ZNmNdfGbXL28MWj6coUnKKRkke9Xovil4it7cnWNJMceOZoudnua5nRbM2Xgf8AtS3O2S4nEcs6 jLRp7UulWV7Ya3Hd3ero+lM2GDsCZFPbFTFs+uqYTAe9GFNe73bu7HYWPxNvrLUbQauIrjS7w7Yb uIfdPoa9ShdZYo5I23IwyD6ivnnWrEWekalDArLaT3IazRuuSf4RXu3hqOW38NafFcA+YsK7s9ap O587mWHowpxqUtLvY1qKKKZ4oUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFcX8RPEWo+H7S2k0xlVpGw26uHPxJ8R8fvIuvpXFV xtKlPkluevhcoxGKpKrTtb1PbKOa8zvvGmsW62ux4/3kQZsjvUen+N9ZuNVt4JHj2SOFbA7VxvOc Mqns9b+h405KnNwluj1AUVGZFji3uwVQMkntTLe8t7pN1rMkwHUoc4r2EUT0VBc3kFooa5nSEMcA ucZpn9oWv2hIDcRiZxlUzyw9aYFqikBzS0AFFFFABRRRQAUVBd3cFjbvcXcqxRIMszHgVW0vWrHW rcz6bOJYlbaWxjn8aANCikBzS0AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUU UUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFeefFjVf7K0e3+0QLc2dw/lyxsO3qPevQz0rlPHvhr/hJ/DEtrDg3EX7yLPrQ1dHbgJ06 eKhKr8N9TyhJVtPCRm8LXRuVjkDPaPyVXvkVj22u2txeRCHw/HNeFsqik7Q3rise3ubzw9qe/DQX MDbZEbgOO4NdfrBs9A0VdZ0wAXWrrhf+mX97FZrQ/QamHp0ZJP3nP4X/AJ/5kesa6tleR3mptHfa mmBFbR/6q2P+Ne4eHJ57rw9Y3F0cyyxBmNfOnhLw5d+JtfhggRniVw08pHHX1r6atbdLa2hhj4WJ Qoqo9z5viCFCgoUKbvJb/wCRYoooqj5UKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKO9FFAHBfFDTbrUrK1W0CEq2TuYCvOz4X1YkYSHr n/Wiu8+LRP2Cz2kg7uxrzBi/Hzt19a66XDlLHxWInNpvt5HLU40xGUT+qU6aaWuvmd1qGg6hcLZm KNGCQhSd460zTfDupRavayPEgVJASd46VoZYafY4Y/6gd6ksCf7Rgyx++O9flOMrUqWYypOLdpW3 8+x7VPL1iKKxUpayV7eup2niBtvhe/I7W7fyrzn4dSy+H9Vt7eZy1rqiZjZjwGFeka5DJc+Hb2C3 XdJJAyovqcVxdz4V1Gf4cWkMMZi1az+aIA8g1+lLY88xviFNLr2pzyROws9LdVyp4Z810kd1Yx+L NJilswZxZB/tJP3RjpVS68LahD8NxZxQ+dqNxIss4zyWzzzVyTQr6fxXp8rQEW62PkyyZ+62OlMB 8Xi7XNauZ28OaWstnBIUM0rY3kdcU/U/GWqW2vx6NZ6aJruSIPjdwD3rP0WTxD4OE2lDRjfwGUtD NG4HBPetG30zUH+I6apLbbYGtgGbP3Wx0oAbL4w1a41AaTpOnLNqEKbros3yRn0pbLx5LDHqEGuW LW99YoXMaHIkHtVWey1jwt4svdV06w/tK0vuXRGwyGksNN1a41TUPEupacA7xGOCwLZLj3NAGj4d 8Tarqyfb7q3gj0woX3o+WTHqKpp4x17VUuLzQtJWSwgYgPI3MmOuKy9I0DUbzXpZbLT5dG0+aFku IWkyrMfQVZ0uXxJ4W0+bRI9FN6u5vInRwBg+tAGf4w8R3HiLwlbzWltttzMEnDHlXB6VHqt94gsr 3RoIbCOyBYeXDEwCyn3q7d+ENUtvBaWyR+dez3QnlRTwuT0rT8Y6XqTto2o6fam6ewZTJCDgnigD sNOkuZbKN76IRXBHzoDkCrVVdNuZbyxjnuLc20jjLRMclatUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUVDd3H2Wzln2lvLQttHegDBl8Z2kPjePw48MgkePeJ8fJn0z60618YWlz4wufDxjaO4 hQOrt0f2FcZd+GtXk0I6+tzMbqK5+0rb7Rny852560rWd7qGiN4r0i1kXVUmMkcLDkg8YoA6rUvH ljp/iGfSPKeSaCDzmYdCf7v1qrF42vv7I/tS40zZbP8A6sBvmJzxmuX8U6Xe2sWl6mbSSS7uebva MlcjpUkdtaReCYUt3nlut2WhOcjmgDpE8f8A2czQanYvFdJF5qIvIdcVOPGr6hPFbaFZNdzGNZJj /DED2PvXHahBdeHmuY9Qglvf7RhU290FyY+OUPpWl4Dt5vClxPDq8TpHeIskdxjj6GgDb1jxxP4f sreXVNMl8yabyysfOwf3j7VNrHjix0XXdNsLyCTydQQMl2o+RCfU1n3Gn3HjG/1CRZZLezERij+X IkI6Hmszwtby6m40XxBaNL9khMEjyLw3PBBoBmv4q8N+Hdb1O1t9Qsg0t0uUuI+1RXnwy0SbTbe1 vZZGtrPJAJ7e9Z9jb6zofjWx0S9ikvNNUF7W96lBn7rV3+qWv23Tbm1VtjTxNGG9CRQdUcXiIJKM 3p+ByOgXwit5IfB+ioLCElBM4x5hHXFXb7xXf2t7HYxaZ5l15PnSLnhR3rP8NanJ4d8Mz6TqNtJB d2YcRELxN6EVixWmueKZgbwS2F7La/LIBjoeh+tBzSlKcuaT1OhPxDN81nFolg9xNcKWIfgJg4NT SeL9TOsjS7fTFe4VN0hLfKK4uIxahr+mW+qWM+lrYxGKYxAhWbPXPvWhJZWD+O5XupLiO0WLEUyk /MaBG9qvjTVtIu7W3uNI3NdnbGVPGfeoNS+JZ0S8NpqmlzedGqtL5XIVT3o8WwzS6n4Z+xRyywrL y3oOOTVPU7SeT4rzSNatJbPAqMxXKt6igDr77xLbW2l2uoW/+k29ywCsnYHvWfD4su9Wv5odAsfP gt+HnfhWb0Fcx4j0PVPDdzFbaNDJd6Nfz/PCOTase49q1vCt4/hmxuNI1W3eFoSWhnC8TA8/nQBf h8XXc+r/ANkLZquoRjdLGxwNvqPWusQkoCwwccivJHm/4SPSG1K+hutP8RWszC0lVcNKM/KPcV6j pTXT6TatqAxdGJfNH+1jmgC3RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQBgeKPCtt4niijupXjERyNprnG+E+l8E3c3516FijA9K6aeLr0o8kJNI4a2Aw 1eXPUgmznB4StvIhj859sKbFPqKWLwpbQzpKsrkoc10WMdKMCvFqZZhKlV1pQXM3e/merCvVhBQj KyWlhkfTGOlPoor0TAKKKKACiiigAxijFFFABiiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKRhlSMA59aWigCMKcYwMdMdqcqKgwihR6AYp1FADWQN95Qw9CM1H9niXlYI8/wC6 KmooAhaIPxJGrDtkZxSmIOgWRFYejDNS0UARqmxcRqqL6KMUCJQS2xcnuBzUlFADduTkgHHtTNhI GR3qWigCJ4UchpI1cjoWXOKds6HC5+lPooAieCNz88UbZ65UGj7PCQA0MZx0yoqWigCPyx/dXA6c dKUoCclRn1xT6KAG445GaY8KyLiVEfHTcM4qWigCLyUJVmiQleh2jipaKKACiiigAooooAKKKKAC iiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP/9k= --_002_F2971C2F9E42BE40858A18C5F62C91EE2DBB0D12SBECMX003exchad_-- From nobody Fri Jun 6 14:21:46 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E521A02A6 for ; Fri, 6 Jun 2014 14:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 OxGaUfgXHcM8 for ; Fri, 6 Jun 2014 14:21:42 -0700 (PDT) Received: from nm34.bullet.mail.gq1.yahoo.com (nm34.bullet.mail.gq1.yahoo.com [98.136.217.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D8121A0283 for ; Fri, 6 Jun 2014 14:21:42 -0700 (PDT) Received: from [127.0.0.1] by nm34.bullet.mail.gq1.yahoo.com with NNFMP; 06 Jun 2014 21:21:35 -0000 Received: from [98.137.12.62] by nm34.bullet.mail.gq1.yahoo.com with NNFMP; 06 Jun 2014 21:18:35 -0000 Received: from [98.137.12.220] by tm7.bullet.mail.gq1.yahoo.com with NNFMP; 06 Jun 2014 21:18:34 -0000 Received: from [127.0.0.1] by omp1028.mail.gq1.yahoo.com with NNFMP; 06 Jun 2014 21:18:34 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 372007.35648.bm@omp1028.mail.gq1.yahoo.com Received: (qmail 77433 invoked by uid 60001); 6 Jun 2014 21:18:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402089514; bh=H2+lKpSr3psylYk8oxnja5UxGk6rpvpPVTQvvCgGXNI=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=yW+rj6mDS3TG5MWTgjPdx8zCJuENIweDhm9GC7WeOwgWEULA5y5spvY6D5S2zXYVLFB9PXzJUdT//7LAp1nDgQ0/KA1c2hAtWHPERgAcjUBvQlDcXcn6ORTzi0mm3suIsy4vyMIQYFpBuYwyoKiNV3nrDqDKfpLKSOq+Eu37Wpw= X-YMail-OSG: OP3n2ggVM1mEOwOCfbWZS4DLJvR.d6Jgz.axTGSmCj49nVJ uIEdwN_5Zt3P2hrT4Yjt0uSLM9LuPpa0V9IT4kdjA5J08ecf64BlGVqH1hzs EgnCDfZ_I6mpcO_6SdqrqsRZjRlTL9YJuJc5_PQP17Pf9DYEO6LVJYp2_.I8 s0e4NkKd86PLX8ROWZImYtf46op4suHy7PZCOjn9DxnLIu6wO9mTDGx_mM3C Qzacb4zhHwFkXIExppla9BBLveAxT7Sk0komj1pHhBuuk5sorhtmjXcR5wRv qIyGxElkRSbup9V0pXyRqPaPS72RFv2Z5cWdOKVtNBLELqnBE.WQihHdweW5 FgcZWPLH0dM0r28SE2jaJ7RP1AbkZBarRXfkBUKXXKUJROqc5L39tavRvAfG oyBn67o5NjS3i9HuKZLRatHvhdWgD9K8IfJpZsFX4aVbWe2q3ngagIPOWXiK OKxBCjK5bTpqGIz6HUnNOAkKkCHjDGANRzOBuGZ9mx8Kpi.9RZLwerckEleO p_quZitk8y0k0PMknGkiFJxuf3XE.mAhAbfrKtV8EtnHgh4QMZy2X2MkBHR1 oYkZHdqJOLKO5xhULYvz5_2R2MrsEm8gB6RD3ZssMyg-- Received: from [79.175.112.242] by web164603.mail.gq1.yahoo.com via HTTP; Fri, 06 Jun 2014 14:18:34 PDT X-Rocket-MIMEInfo: 002.001, T24gRnJpZGF5LCBKdW5lIDYsIDIwMTQgMTA6NTYgUE0sICJUYWxhbW8sIFZpY3RvciIgPHZpY3Rvci50YWxhbW9AanBtY2hhc2UuY29tPiB3cm90ZToKCgo.IFdpdGggdGhhdCBzYWlkIGlmIHlvdSBjaGVjayB0aGUgRE1BUkMgcmVjb3JkcyBmb3IgdGhlc2UgZG9tYWlucyB0b2RheSwKPiB0aGUgdmFzdCBtYWpvcml0eSBvZiB0aGVzZSBkb21haW5zIGFyZSBETUFSQyBSRUpFQ1QgY29tcHJpc2luZyBiaWxsaW9ucwo.IG9mIGVtYWlscy4KCmJpbGxpb25zIG9mIG5vdGlmaWNhdGlvbiBlbWFpbC4gdGhhdCBiYXIBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1402042491.15608.YahooMailNeo@web164601.mail.gq1.yahoo.com> <877g4u2ws4.fsf@uwakimon.sk.tsukuba.ac.jp> <1402063755.61291.YahooMailNeo@web164602.mail.gq1.yahoo.com> <8738fi2bba.fsf@uwakimon.sk.tsukuba.ac.jp> <1402080444.6636.YahooMailNeo@web164602.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8D62B7FE@MSGRTPCCRF2WIN.DMN1.FMR.COM> <1402084248.69843.YahooMailNeo@web164606.mail.gq1.yahoo.com> Message-ID: <1402089514.72796.YahooMailNeo@web164603.mail.gq1.yahoo.com> Date: Fri, 6 Jun 2014 14:18:34 -0700 (PDT) From: Vlatko Salaj To: "Talamo, Victor" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Pa_8rDJO-Nsz81FDMpkbManEcmc Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 06 Jun 2014 21:21:44 -0000 On Friday, June 6, 2014 10:56 PM, "Talamo, Victor" wrote: > With that said if you check the DMARC records for these domains today, > the vast majority of these domains are DMARC REJECT comprising billions > of emails. billions of notification email. that barely anyone reads. and that nobody cares if gets lost. i can only hope to see real data on number of DMARC false-positives in that billions of notification email, but i'm sure that would just completely crash any trust in DMARC, so we will never see it. exactly the reason behind DMARC being an independent document on IETF. not that i care anymore. it's a waste of my time, obviously. 'nuff said. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Fri Jun 6 15:02:56 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2631A02AE for ; Fri, 6 Jun 2014 15:02: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 6QszQLTEdqMP for ; Fri, 6 Jun 2014 15:02:52 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 714631A0273 for ; Fri, 6 Jun 2014 15:02:52 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id k48so3518649wev.3 for ; Fri, 06 Jun 2014 15:02:44 -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=mrKcw2wkXQFj+SBugsfH4kWSHZpeQk3M3Ts7RyBuluw=; b=VuOFDuZwjJ6pJn7vVJWBBkhX2J/T2XGLRzaJIp1bHxMtzJqPtNk+H/sua2eB/Wx2HS Tw3a0NqOsXWL0c9FO7lztjrdY3TxR3Ed3ayug1ZmV/mQFgNrQUumib9MKY5/0iha3hTQ Hdimg8dmsRHXTahXl/wvR2/34FU+p7hbjhMHWtI1WX81NtvJvLdlhh3jxNMelp2Wqbkt 6CWNIBjYgUXwKJ0fjeyjuqEy+BuJENWkSa7/m8MVQ3JMP6u74LhIsPUQ+Kf2BIwhZXR0 kVdK/caoBc0bRAUDi3dEbAelzluXSBi156sorrD3zGahtzw1scdkxsG0CFzzBz973q2h LWkA== MIME-Version: 1.0 X-Received: by 10.194.186.178 with SMTP id fl18mr10300518wjc.83.1402092163955; Fri, 06 Jun 2014 15:02:43 -0700 (PDT) Received: by 10.180.23.104 with HTTP; Fri, 6 Jun 2014 15:02:43 -0700 (PDT) In-Reply-To: <1402081601.11792.YahooMailNeo@web164602.mail.gq1.yahoo.com> References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1402042491.15608.YahooMailNeo@web164601.mail.gq1.yahoo.com> <877g4u2ws4.fsf@uwakimon.sk.tsukuba.ac.jp> <1402063755.61291.YahooMailNeo@web164602.mail.gq1.yahoo.com> <1402081601.11792.YahooMailNeo@web164602.mail.gq1.yahoo.com> Date: Fri, 6 Jun 2014 15:02:43 -0700 Message-ID: From: "Murray S. Kucherawy" To: Vlatko Salaj Content-Type: multipart/alternative; boundary=047d7bb04dd25fffe704fb320512 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/gFvy5Tl2bMsmk2CoaefvmDG9THg Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 06 Jun 2014 22:02:54 -0000 --047d7bb04dd25fffe704fb320512 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 6, 2014 at 12:06 PM, Vlatko Salaj wrote: > >> i would rather say it's a case of "history repeating". how many > >> email policy protocols were developed in last 10y? a bunch of them. > >> all of them failed. all of them "historic" now. > > Which ones, other than ADSP? > > i'm not a search engine. but one could even argue that SPF, Sender-ID > and bunch of DKIM addons were exactly in that group. > None of them are Historic. SPF was just upgraded to Proposed Standard, and DKIM is a full standard; both are in pretty heavy use. Sender-ID is probably a failed experiment at this point though. ADSP is the only one I can think of. I'm happy to be enlightened. You'll have to suggest some search terms, because I couldn't find any other than the ones we've already listed here, except maybe VBR. > > I think the more likely explanation is that the proposals on the table > > are much too risky and costly given the benefits. > > i see no risks with me publishing a DMARC records saying exactly this: > do DMARC alignment against yahoo domain too. > > and i'm sure u can't find any, other than breaching yahoo itself, > my account, or my dns records, all of which isn't DMARC's field of > protection anyway. > > be free to make an example, i would really like to see what additional > risks and costs u r mentioning. if possible, ofc. > I did provide some examples of the cost of the current third-party systems in my previous message (the one to which you are replying). > > The status of the current document has nothing at all to do with the > quality > > of what's in it, but rather the procedural path it's taking toward > > publication. > > anyone can trust whatever they like. but considering u work for ur DMARC > bosses as a document shepard... i'll just consider u biased in evaluating > this. > Huh? I'm talking about IETF procedure. Who I work for or what I'm shepherding doesn't change that. > nobody interested to fix email would publish such a protocol as independent > RFC. more brains, better solutions, more contributions, better standard... > there have been many calls to make a working group. > I think you should probably go back and read some of the archives of this list from before you joined. There was an attempt to create a working group, and another attempt is probably appropriate. Nobody is specifically avoiding it; it's a matter of agreeing on a charter. -MSK --047d7bb04dd25fffe704fb320512 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 6, 2014 at 12:06 PM, Vlatko Salaj <vlat= ko.salaj@goodone.tk> wrote:
>> i would rather say it's a case = of "history repeating". how many
>> email policy protocols were developed in last 10y? a bunch of them= .
>> all of them failed. all of them "historic" now.
> Which ones, other than ADSP?

i'm not a search engine. but one could even argue that SPF, Sende= r-ID
and bunch of DKIM addons were exactly in that group.
<= br>
None of them are Historic.=C2=A0 SPF was just upgraded to Pro= posed Standard, and DKIM is a full standard; both are in pretty heavy use.= =C2=A0 Sender-ID is probably a failed experiment at this point though.

ADSP is the only one I can think of.=C2=A0 I'm happy to = be enlightened.=C2=A0 You'll have to suggest some search terms, because= I couldn't find any other than the ones we've already listed here,= except maybe VBR.
=C2=A0
> I think the more likely explanation is that the propos= als on the table
> are much too risky and costly given the benefits.

i see no risks with me publishing a DMARC records saying exactly this= :
do DMARC alignment against yahoo domain too.

and i'm sure u can't find any, other than breaching yahoo itself, my account, or my dns records, all of which isn't DMARC's field of<= br> protection anyway.

be free to make an example, i would really like to see what additional
risks and costs u r mentioning. if possible, ofc.

=
I did provide some examples of the cost of the current third-par= ty systems in my previous message (the one to which you are replying).
=C2=A0
> The status of the current document has nothing at all = to do with the quality
> of what's in it, but rather the procedural path it's taking to= ward
> publication.

anyone can trust whatever they like. but considering u work for ur DM= ARC
bosses as a document shepard... i'll just consider u biased in evaluati= ng
this.

Huh?=C2=A0 I'm talking about = IETF procedure.=C2=A0 Who I work for or what I'm shepherding doesn'= t change that.
=C2=A0
nobody interested to fix email would publish such a protocol as independent=
RFC. more brains, better solutions, more contributions, better standard...<= br> there have been many calls to make a working group.
I think you should probably go back and read some of the archi= ves of this list from before you joined.=C2=A0 There was an attempt to crea= te a working group, and another attempt is probably appropriate.=C2=A0 Nobo= dy is specifically avoiding it; it's a matter of agreeing on a charter.=

-MSK
--047d7bb04dd25fffe704fb320512-- From nobody Fri Jun 6 15:03:30 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24C01A02B8 for ; Fri, 6 Jun 2014 15:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.791 X-Spam-Level: X-Spam-Status: No, score=-6.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=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 axpW9gQDIc36 for ; Fri, 6 Jun 2014 15:03:26 -0700 (PDT) Received: from msginmsm06vapp.fmr.com (ltm-fwus409m-410m.fidelity.com [155.199.16.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3077F1A0273 for ; Fri, 6 Jun 2014 15:03:26 -0700 (PDT) Received: from msgrtphc04win.DMN1.FMR.COM (MSGRTPHC04WIN.dmn1.fmr.com [10.95.12.184]) by msginmsm06vapp.fmr.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.1) with ESMTP id s56M3AXO007777 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Fri, 6 Jun 2014 22:03:11 GMT X-DKIM: OpenDKIM Filter v2.1.3 msginmsm06vapp.fmr.com s56M3AXO007777 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fmr.com; s=2012-05-26; t=1402092191; bh=EooRrSrGtwraK05KMV0FfkzAR43X9aRslhSVmiTHGeM=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=BJUm7Fw2u7FYKmUDEC9MUSpIFx8dTgiVdCxs/BHHGHZ9HAVHcqnNq+QPkxgHtruNT AI4vznySwXZ38VtzGzTwqecwzPIiLaNL2mcmGAhAa4vR/85R5L+5U2daOAAQv0LjrQ w+HuCMIXow0yT8PNmUrAfbcYLgAKertEBMQheMMA= Received: from MSGRTPCCRF2WIN.DMN1.FMR.COM ([10.95.12.32]) by msgrtphc04win.DMN1.FMR.COM ([10.95.12.184]) with mapi; Fri, 6 Jun 2014 18:03:10 -0400 From: "Popowycz, Alex" To: "'Vlatko Salaj'" , "'Talamo, Victor'" Date: Fri, 6 Jun 2014 18:03:09 -0400 Thread-Topic: [dmarc-ietf] confusing 3rd party support so it remains out Thread-Index: Ac+BzVF9yJgBfKNMRJ+ghcCtuGPMSAABci7d Message-ID: <9495B91F5CA0E24C9161D71CD46E43DB011C8D48E075@MSGRTPCCRF2WIN.DMN1.FMR.COM> References: <1402089514.72796.YahooMailNeo@web164603.mail.gq1.yahoo.com> In-Reply-To: <1402089514.72796.YahooMailNeo@web164603.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9495B91F5CA0E24C9161D71CD46E43DB011C8D48E075MSGRTPCCRF2_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/538JtTF2VfjrsqeKDLwPoBBf_bU Cc: "'dmarc@ietf.org'" Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 06 Jun 2014 22:03:29 -0000 --_000_9495B91F5CA0E24C9161D71CD46E43DB011C8D48E075MSGRTPCCRF2_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VmxhdGtvDQoNCkkgc3VnZ2VzdCB5b3UgcmVtb3ZlIHRoZSB2aXRyaW9sIGZyb20geW91ciByZXNw b25zZXMuIFN0YXRpbmcgdGhlIG1lc3NhZ2VzIHRoYXQgVmljIHJlZmVycmVkIHRvIGFyZSB1bmlt cG9ydGFudCBpcyBqdXN0IHN1Y2ggYW4gZXhhbXBsZS4gVGhvc2UgbWVzc2FnZXMgYXJlIG9uZXMg dGhhdCBpbmRpdmlkdWFscyBoYXZlIG9wdGVkLWluIHRvIHJlY2VpdmUgYW5kIGFyZSBpbXBvcnRh bnQgdG8gdGhlbS4gVGhleSBtYXkgYWxzbyBiZSByZXF1aXJlZCBhcyBhIG1hdHRlciBvZiBidXNp bmVzcywgYmUgdGhleSB0cmFuc2FjdGlvbiBub3RpZmljYXRpb25zLCBmcmF1ZCBhbGVydHMgYW5k IHRoZSBsaWtlLiBJJ20gc3VyZSB0aGF0IGluZGl2aWR1YWxzIHJlY2VpdmluZyB0aG9zZSBtZXNz YWdlcyBhcmUgYmV0dGVyIHNlcnZlZCB3aXRoIHRoZSBhY3Rpb25zIHRvIHByb3RlY3QgdGhlIGVt YWlsIGRvbWFpbiB0aGF0IFZpYyBoYWQgdW5kZXJ0YWtlbi4NCg0KTGlrZSBtYW55IG90aGVycyB3 aG8gaGF2ZSBzdWNjZXNzZnVsbHkgZGVwbG95ZWQgRE1BUkMsIHRoZXkndmUgZG9uZSBzbyB3aXRo IHRoZSBpbnRlbnQgb2YgbWFpbnRhaW5pbmcgdGhlIHZpYWJpbGl0eSBhbmQgaW50ZWdyaXR5IG9m IHRoZSBjaGFubmVsIGZvciB0aGVpciBjb25zdGl0dWVudHMuDQoNCk15IHVuZGVyc3RhbmRpbmcg KGFuZCBnZW5lcmFsIGV4cGVyaWVuY2UpIGlzIHRoYXQgdGhpcyBsaXN0IGlzIHRvIG1vdmUgZm9y d2FyZCBvbiBhIGNvbnN0cnVjdGl2ZSBwYXRoLg0KDQpFbWFpbCwgYXMgeW91IHdlbGwga25vdyBo YXMgZXZvbHZlZCBpbiB3YXlzIHRoYXQgd2UgbmV2ZXIgZW52aXNpb25lZCB3aGVuIHRoZSB1bmRl cmx5aW5nIHByb3RvY29scyB3ZXJlIGRldmVsb3BlZC4gSG93ZXZlciwgdGhlIGluaGVyZW50IGxh Y2sgb2Ygc2VjdXJpdHkgaGFzIGFsbG93ZWQgZm9yIGJlaGF2aW9ycyB0aGF0IGhhdmUgYm90aCBw b3NpdGl2ZSBhbmQgdW5mb3J0dW5hdGVseSBpbmNyZWFzaW5nbHkgbmVnYXRpdmUgdXNlcyBhbmQg ZWZmZWN0cy4gTm93YWRheXMgdGhlIHZhc3QgbWFqb3JpdHkgb2Yga25vd24gbWFqb3IgYmVhY2hl cyBvcmlnaW5hdGVkIHdpdGggYSBtYWxpY2lvdXMgZW1haWwuIExpa2UgbWFueSBwcm90ZWN0aXZl IHNvbHV0aW9ucywgYm90aCB2aXJ0dWFsIGFuZCBwaHlzaWNhbCwgdGhlcmUgYXJlIG9mdGVuIHNp ZGUgZWZmZWN0cy4gVGFrZSBmb3IgZXhhbXBsZSB0aGUgYXV0b21vYmlsZSBzZWF0IGJlbHQuIE9u ZSBtYXkgZmluZCB0aGF0IGl0IGlycml0YXRlcyB0aGUgc2hvdWxkZXIgb24gbG9uZyByaWRlcywg YnV0IEkgZm9yIG9uZSBhY2NlcHQgdGhhdCBmb3IgdGhlIHByb3RlY3Rpb24gaXQgcHJvdmlkZXMu IExpa2UgdGhlIHNlYXQgYmVsdCwgSSBjYW4gY2hvb3NlIG5vdCB0byB1c2UgRE1BUkMsIGJ1dCBJ IGRvIHNvIGF0IG15IG93biBwZXJpbC4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBWbGF0a28gU2FsYWogW3ZsYXRrby5zYWxhakBnb29kb25lLnRrPG1haWx0bzp2bGF0 a28uc2FsYWpAZ29vZG9uZS50az5dDQpTZW50OiBGcmlkYXksIEp1bmUgMDYsIDIwMTQgMDU6MjEg UE0gRWFzdGVybiBTdGFuZGFyZCBUaW1lDQpUbzogVGFsYW1vLCBWaWN0b3INCkNjOiBkbWFyY0Bp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtkbWFyYy1pZXRmXSBjb25mdXNpbmcgM3JkIHBhcnR5IHN1 cHBvcnQgc28gaXQgcmVtYWlucyBvdXQNCg0KDQpPbiBGcmlkYXksIEp1bmUgNiwgMjAxNCAxMDo1 NiBQTSwgIlRhbGFtbywgVmljdG9yIiA8dmljdG9yLnRhbGFtb0BqcG1jaGFzZS5jb20+IHdyb3Rl Og0KDQoNCj4gV2l0aCB0aGF0IHNhaWQgaWYgeW91IGNoZWNrIHRoZSBETUFSQyByZWNvcmRzIGZv ciB0aGVzZSBkb21haW5zIHRvZGF5LA0KPiB0aGUgdmFzdCBtYWpvcml0eSBvZiB0aGVzZSBkb21h aW5zIGFyZSBETUFSQyBSRUpFQ1QgY29tcHJpc2luZyBiaWxsaW9ucw0KPiBvZiBlbWFpbHMuDQoN CmJpbGxpb25zIG9mIG5vdGlmaWNhdGlvbiBlbWFpbC4gdGhhdCBiYXJlbHkgYW55b25lIHJlYWRz LiBhbmQgdGhhdA0Kbm9ib2R5IGNhcmVzIGlmIGdldHMgbG9zdC4NCg0KaSBjYW4gb25seSBob3Bl IHRvIHNlZSByZWFsIGRhdGEgb24gbnVtYmVyIG9mIERNQVJDIGZhbHNlLXBvc2l0aXZlcw0KaW4g dGhhdCBiaWxsaW9ucyBvZiBub3RpZmljYXRpb24gZW1haWwsIGJ1dCBpJ20gc3VyZSB0aGF0IHdv dWxkDQpqdXN0IGNvbXBsZXRlbHkgY3Jhc2ggYW55IHRydXN0IGluIERNQVJDLCBzbyB3ZSB3aWxs IG5ldmVyIHNlZSBpdC4NCg0KZXhhY3RseSB0aGUgcmVhc29uIGJlaGluZCBETUFSQyBiZWluZyBh biBpbmRlcGVuZGVudCBkb2N1bWVudCBvbiBJRVRGLg0KDQpub3QgdGhhdCBpIGNhcmUgYW55bW9y ZS4gaXQncyBhIHdhc3RlIG9mIG15IHRpbWUsIG9idmlvdXNseS4NCg0KJ251ZmYgc2FpZC4NCg0K DQotLQ0KVmxhdGtvIFNhbGFqIGFrYSBnb29kb25lDQpodHRwOi8vZ29vZG9uZS50aw0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG1hcmMgbWFpbGlu ZyBsaXN0DQpkbWFyY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9kbWFyYw0K --_000_9495B91F5CA0E24C9161D71CD46E43DB011C8D48E075MSGRTPCCRF2_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPGh0bWw+ DQo8aGVhZD4NCjxtZXRhIG5hbWU9ImdlbmVyYXRvciIgY29udGVudD0iSFRNTCBUaWR5IGZvciBX aW5kb3dzICh2ZXJzIDI1IE1hcmNoIDIwMDkpLCBzZWUgd3d3LnczLm9yZyI+DQo8bWV0YSBodHRw LWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+ DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1TIEV4Y2hhbmdlIFNlcnZlciB2ZXJz aW9uIDA4LjAzLjAzMzAuMDAwIj4NCjx0aXRsZT5SZTogW2RtYXJjLWlldGZdIGNvbmZ1c2luZyAz cmQgcGFydHkgc3VwcG9ydCBzbyBpdCByZW1haW5zIG91dDwvdGl0bGU+DQo8L2hlYWQ+DQo8Ym9k eT4NClZsYXRrbzxicj4NCjxicj4NCkkgc3VnZ2VzdCB5b3UgcmVtb3ZlIHRoZSB2aXRyaW9sIGZy b20geW91ciByZXNwb25zZXMuIFN0YXRpbmcgdGhlIG1lc3NhZ2VzIHRoYXQgVmljIHJlZmVycmVk IHRvIGFyZSB1bmltcG9ydGFudCBpcyBqdXN0IHN1Y2ggYW4gZXhhbXBsZS4gVGhvc2UgbWVzc2Fn ZXMgYXJlIG9uZXMgdGhhdCBpbmRpdmlkdWFscyBoYXZlIG9wdGVkLWluIHRvIHJlY2VpdmUgYW5k IGFyZSBpbXBvcnRhbnQgdG8gdGhlbS4gVGhleSBtYXkgYWxzbyBiZSByZXF1aXJlZCBhcyBhIG1h dHRlciBvZiBidXNpbmVzcywgYmUgdGhleSB0cmFuc2FjdGlvbiBub3RpZmljYXRpb25zLCBmcmF1 ZCBhbGVydHMgYW5kIHRoZSBsaWtlLiBJJ20gc3VyZSB0aGF0IGluZGl2aWR1YWxzIHJlY2Vpdmlu ZyB0aG9zZSBtZXNzYWdlcyBhcmUgYmV0dGVyIHNlcnZlZCB3aXRoIHRoZSBhY3Rpb25zIHRvIHBy b3RlY3QgdGhlIGVtYWlsIGRvbWFpbiB0aGF0IFZpYyBoYWQgdW5kZXJ0YWtlbi48YnI+DQo8YnI+ DQpMaWtlIG1hbnkgb3RoZXJzIHdobyBoYXZlIHN1Y2Nlc3NmdWxseSBkZXBsb3llZCBETUFSQywg dGhleSd2ZSBkb25lIHNvIHdpdGggdGhlIGludGVudCBvZiBtYWludGFpbmluZyB0aGUgdmlhYmls aXR5IGFuZCBpbnRlZ3JpdHkgb2YgdGhlIGNoYW5uZWwgZm9yIHRoZWlyIGNvbnN0aXR1ZW50cy48 YnI+DQo8YnI+DQpNeSB1bmRlcnN0YW5kaW5nIChhbmQgZ2VuZXJhbCBleHBlcmllbmNlKSBpcyB0 aGF0IHRoaXMgbGlzdCBpcyB0byBtb3ZlIGZvcndhcmQgb24gYSBjb25zdHJ1Y3RpdmUgcGF0aC48 YnI+DQo8YnI+DQpFbWFpbCwgYXMgeW91IHdlbGwga25vdyBoYXMgZXZvbHZlZCBpbiB3YXlzIHRo YXQgd2UgbmV2ZXIgZW52aXNpb25lZCB3aGVuIHRoZSB1bmRlcmx5aW5nIHByb3RvY29scyB3ZXJl IGRldmVsb3BlZC4gSG93ZXZlciwgdGhlIGluaGVyZW50IGxhY2sgb2Ygc2VjdXJpdHkgaGFzIGFs bG93ZWQgZm9yIGJlaGF2aW9ycyB0aGF0IGhhdmUgYm90aCBwb3NpdGl2ZSBhbmQgdW5mb3J0dW5h dGVseSBpbmNyZWFzaW5nbHkgbmVnYXRpdmUgdXNlcyBhbmQgZWZmZWN0cy4gTm93YWRheXMgdGhl IHZhc3QgbWFqb3JpdHkgb2Yga25vd24gbWFqb3IgYmVhY2hlcyBvcmlnaW5hdGVkIHdpdGggYSBt YWxpY2lvdXMgZW1haWwuIExpa2UgbWFueSBwcm90ZWN0aXZlIHNvbHV0aW9ucywgYm90aCB2aXJ0 dWFsIGFuZCBwaHlzaWNhbCwgdGhlcmUgYXJlIG9mdGVuIHNpZGUgZWZmZWN0cy4gVGFrZSBmb3Ig ZXhhbXBsZSB0aGUgYXV0b21vYmlsZSBzZWF0IGJlbHQuIE9uZSBtYXkgZmluZCB0aGF0IGl0IGly cml0YXRlcyB0aGUgc2hvdWxkZXIgb24gbG9uZyByaWRlcywgYnV0IEkgZm9yIG9uZSBhY2NlcHQg dGhhdCBmb3IgdGhlIHByb3RlY3Rpb24gaXQgcHJvdmlkZXMuIExpa2UgdGhlIHNlYXQgYmVsdCwg SSBjYW4gY2hvb3NlIG5vdCB0byB1c2UgRE1BUkMsIGJ1dCBJIGRvIHNvIGF0IG15IG93biBwZXJp bC48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4N CjxiPkZyb206Jm5ic3A7PC9iPlZsYXRrbyBTYWxhaiBbPGEgaHJlZj0ibWFpbHRvOnZsYXRrby5z YWxhakBnb29kb25lLnRrIj52bGF0a28uc2FsYWpAZ29vZG9uZS50azwvYT5dPGJyPg0KPGI+U2Vu dDombmJzcDs8L2I+RnJpZGF5LCBKdW5lIDA2LCAyMDE0IDA1OjIxIFBNIEVhc3Rlcm4gU3RhbmRh cmQgVGltZTxicj4NCjxiPlRvOiZuYnNwOzwvYj5UYWxhbW8sIFZpY3Rvcjxicj4NCjxiPkNjOiZu YnNwOzwvYj5kbWFyY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6Jm5ic3A7PC9iPlJlOiBbZG1h cmMtaWV0Zl0gY29uZnVzaW5nIDNyZCBwYXJ0eSBzdXBwb3J0IHNvIGl0IHJlbWFpbnMgb3V0PGJy Pg0KPGJyPg0KPCEtLSBDb252ZXJ0ZWQgZnJvbSB0ZXh0L3BsYWluIGZvcm1hdCAtLT4NCjxwPjxm b250IHNpemU9IjIiPk9uIEZyaWRheSwgSnVuZSA2LCAyMDE0IDEwOjU2IFBNLCAiVGFsYW1vLCBW aWN0b3IiICZsdDt2aWN0b3IudGFsYW1vQGpwbWNoYXNlLmNvbSZndDsgd3JvdGU6PGJyPg0KPGJy Pg0KPGJyPg0KJmd0OyBXaXRoIHRoYXQgc2FpZCBpZiB5b3UgY2hlY2sgdGhlIERNQVJDIHJlY29y ZHMgZm9yIHRoZXNlIGRvbWFpbnMgdG9kYXksPGJyPg0KJmd0OyB0aGUgdmFzdCBtYWpvcml0eSBv ZiB0aGVzZSBkb21haW5zIGFyZSBETUFSQyBSRUpFQ1QgY29tcHJpc2luZyBiaWxsaW9uczxicj4N CiZndDsgb2YgZW1haWxzLjxicj4NCjxicj4NCmJpbGxpb25zIG9mIG5vdGlmaWNhdGlvbiBlbWFp bC4gdGhhdCBiYXJlbHkgYW55b25lIHJlYWRzLiBhbmQgdGhhdDxicj4NCm5vYm9keSBjYXJlcyBp ZiBnZXRzIGxvc3QuPGJyPg0KPGJyPg0KaSBjYW4gb25seSBob3BlIHRvIHNlZSByZWFsIGRhdGEg b24gbnVtYmVyIG9mIERNQVJDIGZhbHNlLXBvc2l0aXZlczxicj4NCmluIHRoYXQgYmlsbGlvbnMg b2Ygbm90aWZpY2F0aW9uIGVtYWlsLCBidXQgaSdtIHN1cmUgdGhhdCB3b3VsZDxicj4NCmp1c3Qg Y29tcGxldGVseSBjcmFzaCBhbnkgdHJ1c3QgaW4gRE1BUkMsIHNvIHdlIHdpbGwgbmV2ZXIgc2Vl IGl0Ljxicj4NCjxicj4NCmV4YWN0bHkgdGhlIHJlYXNvbiBiZWhpbmQgRE1BUkMgYmVpbmcgYW4g aW5kZXBlbmRlbnQgZG9jdW1lbnQgb24gSUVURi48YnI+DQo8YnI+DQpub3QgdGhhdCBpIGNhcmUg YW55bW9yZS4gaXQncyBhIHdhc3RlIG9mIG15IHRpbWUsIG9idmlvdXNseS48YnI+DQo8YnI+DQon bnVmZiBzYWlkLjxicj4NCjxicj4NCjxicj4NCi0tPGJyPg0KVmxhdGtvIFNhbGFqIGFrYSBnb29k b25lPGJyPg0KPGEgaHJlZj0iaHR0cDovL2dvb2RvbmUudGsiPmh0dHA6Ly9nb29kb25lLnRrPC9h Pjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KZG1hcmMgbWFpbGluZyBsaXN0PGJyPg0KZG1hcmNAaWV0Zi5vcmc8YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtYXJjIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtYXJjPC9hPjxicj48L2ZvbnQ+PC9wPg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_9495B91F5CA0E24C9161D71CD46E43DB011C8D48E075MSGRTPCCRF2_-- From nobody Fri Jun 6 15:10:11 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0601A028F for ; Fri, 6 Jun 2014 15:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 m7k_84LQRgPD for ; Fri, 6 Jun 2014 15:10:06 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 556A61A0273 for ; Fri, 6 Jun 2014 15:10:06 -0700 (PDT) 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, 7 Jun 2014 00:09:57 +0200 Message-ID: <3F4AD87778174F18B2C4B178D022C15F@fgsr.local> From: "J. Gomez" To: Vlatko Salaj References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> <96EA87B2959246E4B4916A0DEF9CAF4A@fgsr.local> <1402044548.59713.YahooMailNeo@web164603.mail.gq1.yahoo.com> <1402086600.16464.YahooMailNeo@web164602.mail.gq1.yahoo.com> Date: Sat, 7 Jun 2014 00:10:13 +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: http://mailarchive.ietf.org/arch/msg/dmarc/-EMesoKEJ47rVWEVtWccoDmNUnM Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 06 Jun 2014 22:10:10 -0000 On Friday, June 06, 2014 10:30 PM [GMT+1=3DCET], Vlatko Salaj wrote: > maybe some DMARC's 3rd party support supporters can replace me > here, cause i lost all my interest in participating in this > black hole called DMARC mailing list, for now. >=20 > sorry for that. You may be sorry, but you are not being excused. Regards, J.Gomez From nobody Fri Jun 6 15:15:30 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C941A02AA for ; Fri, 6 Jun 2014 15:15:28 -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 L6uf_1fXU-bK for ; Fri, 6 Jun 2014 15:15:26 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44DCD1A028F for ; Fri, 6 Jun 2014 15:15:26 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q59so3390305wes.21 for ; Fri, 06 Jun 2014 15:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=HVO0grZmGbcbXOGyIx28133Bg9Dg9AEuH0kAXlW7c9A=; b=vMsGRu1XyLf59hAtnL28D5Unoe4YjOuxVov9uEAK6cUNfKVuRjgYReN7mxkt4CNF2N XdphHMXl9wVCF/7Lzf714TkJ6am9lij9gpxw2813zvkRE4n0DzLtK+dUgEqc3BoR/9CG d5oKAxZo0jG+KJelmvR58pBoi9pxTKnfbZuVVB8/dkR78h7OCLdr5gpVI8HabWyMyXGb ZvAylF+4Hns5jxlw51IoQQkj9PHFb/HUYk9b+H81Yp670/xGSO2Doq7BB3wgndQq+lTY oX808w+oC2fQyBaJUhbCnglCrT3uWCgmwZcXlcCa70IIBM1tOgB3j7dK6Acr5Zz17G5+ nF8w== MIME-Version: 1.0 X-Received: by 10.194.161.168 with SMTP id xt8mr10846713wjb.35.1402092917381; Fri, 06 Jun 2014 15:15:17 -0700 (PDT) Received: by 10.180.23.104 with HTTP; Fri, 6 Jun 2014 15:15:17 -0700 (PDT) Date: Fri, 6 Jun 2014 15:15:17 -0700 Message-ID: From: "Murray S. Kucherawy" To: Vlatko Salaj Content-Type: multipart/alternative; boundary=089e01419c6a48602104fb32323c Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/m-CbIVPG9AD01vwxwETzEu20iD0 Cc: "dmarc@ietf.org" Subject: [dmarc-ietf] Comportment again (was Re: confusing 3rd party support so it remains out) 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, 06 Jun 2014 22:15:28 -0000 --089e01419c6a48602104fb32323c Content-Type: text/plain; charset=UTF-8 On Fri, Jun 6, 2014 at 1:14 PM, Vlatko Salaj wrote: > > i need DMARC alignment rigidity gone. and some wise ppl to accept it. > well, we may lack that, i guess. > > Mr. Salaj, I recently sent a message to the list explaining that we require the discussions on this list to be on-topic, professional, and non-abusive. Since then you also received a private warning about the tone you've used. Given the content of your several posts today, it appears this has not improved. Please curtail your abrasive tone in any future messages. We need constructive participation here, not antagonism. If you persist in being rude or otherwise abusive and non-constructive, your posting privileges will be suspended in accordance with RFC 3934. I have already been in contact with the Area Director, who has affirmed that I have this discretion. You may contact him if you wish to confirm or dispute this; you already have his email address. Thank you for your co-operation. -MSK, list co-admin --089e01419c6a48602104fb32323c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 6, 2014 at 1:14 PM, Vlatko Salaj <vlatk= o.salaj@goodone.tk> wrote:

i need DMARC alignment rigidity gone. and some wise ppl to accept it.
well, we may lack that, i guess.


Mr. Salaj,
I recently sent a message to the list explaining that we requi= re the discussions on this list to be on-topic, professional, and non-abusi= ve.=C2=A0 Since then you also received a private warning about the tone you= 've used.=C2=A0 Given the content of your several posts today, it appea= rs this has not improved.

Please curtail your abrasive tone in any future messages.=C2= =A0 We need constructive participation here, not antagonism.

<= div>If you persist in being rude or otherwise abusive and non-constructive,= your posting privileges will be suspended in accordance with RFC 3934.=C2= =A0 I have already been in contact with the Area Director, who has affirmed= that I have this discretion.=C2=A0 You may contact him if you wish to conf= irm or dispute this; you already have his email address.

Thank you for your co-operation.

-MSK, list co-admin<= br>
--089e01419c6a48602104fb32323c-- From nobody Sat Jun 7 01:51:37 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96BB91A0328 for ; Sat, 7 Jun 2014 01:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 hPkLDhkPojXn for ; Sat, 7 Jun 2014 01:51:34 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id 978AC1A0329 for ; Sat, 7 Jun 2014 01:51:34 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id EC7AA970B35; Sat, 7 Jun 2014 17:51:26 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id DAD3D1A324D; Sat, 7 Jun 2014 17:51:26 +0900 (JST) From: "Stephen J. Turnbull" To: "Popowycz, Alex" In-Reply-To: <9495B91F5CA0E24C9161D71CD46E43DB011C8D48E075@MSGRTPCCRF2WIN.DMN1.FMR.COM> References: <1402089514.72796.YahooMailNeo@web164603.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8D48E075@MSGRTPCCRF2WIN.DMN1.FMR.COM> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 07 Jun 2014 17:51:26 +0900 Message-ID: <87y4x914s1.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/A3iNiyK6y64jJUGf9q9Z3bIlRiM Cc: 'Vlatko Salaj' , DMARC Discussion , "'Talamo, Victor'" Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 07 Jun 2014 08:51:36 -0000 Popowycz, Alex writes: > Vlatko Please don't feed the trolls (including me, I'm regretting my role in this thread). There's work to be done here, and Vlatko seems uninterested in helping with it (eg, when asked for specific references, he says "I'm not a search engine"). What I gather from Vlatko's posts is that there is a use case where an entity (eg, a small business; called "ENTITY" below) wants its own domain (called "OWNDOM" below) referenced in correspondence, but prefers not to maintain a single presence (even as a VPS) on the Internet. Instead, ENTITY uses an ESP (below, "ESP" denotes aparticular ESP) to send and receive mail, and ESP provides the usual set of authentication services for its host. The need is to provide credentials and an authentication protocol for mailboxes in OWNDOM that will satisfy identity alignment, and all actors will voluntarily participate. SPF would require that ESP permit ENTITY to specify MAIL FROM.[1] Then ENTITY publishes an SPF record pointing to ESP's MXs and thus provides identity alignment for OWNDOM. However, this requires that ESP trust that ENTITY has the right to use OWNDOM, and that may be problematic. Eg, spammers could sweep the DNS looking for SPF records pointing to ESP and then specify a domain publishing such a record in MAIL FROM. Perhaps an additional protocol could be designed so that registrars can vouch for entities (OAuth2?) but that's outside the scope of this post. DKIM seems to be easy, and requires no cooperation as long as ESP passes mail through unchanged except for its own signature and trace fields. ENTITY just generates a keypair, publishes the public key through its DNS, and DKIM signs its own messages with the private key. This should be a SMOP (eg, Python has at least two packages on PyPI for handling DKIM). Identity alignment for OWNDOM will be satisfied. An alternative would be for ENTITY to trust ESP a little bit, have ESP generate the keypair, send the public key to ENTITY which publishes an appropriate DKIM resource, and then the ESP DKIM signs for ENTITY (and optionally for itself as well). If this capability isn't available at ESP, that too should be a SMOP (basically a database lookup to get the key for ENTITY). Identity alignment for OWNDOM will be satisfied. This last approach seems like a business opportunity for ESPs. Am I missing something? I don't understand why Vlatko thinks he has a problem that needs a new protocol to solve. What am I missing? Footnotes: [1] It's true that ENTITY could publish records in OWNDOM pointing to the MXs as hosts (CNAME), but then HELO would be valid for any user of ESP spoofing OWNDOM AFAICS. From nobody Sat Jun 7 03:37:46 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3042D1A0332 for ; Sat, 7 Jun 2014 03:37:44 -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 ot6J0sgdvzbZ for ; Sat, 7 Jun 2014 03:37:42 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2A161A0109 for ; Sat, 7 Jun 2014 03:37:41 -0700 (PDT) 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, 7 Jun 2014 12:37:32 +0200 Message-ID: <5A761CA08CE847BB9E1990FDB5149F39@fgsr.local> From: "J. Gomez" To: "Stephen J. Turnbull" References: <1402089514.72796.YahooMailNeo@web164603.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8D48E075@MSGRTPCCRF2WIN.DMN1.FMR.COM> <87y4x914s1.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Sat, 7 Jun 2014 12:37:47 +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: http://mailarchive.ietf.org/arch/msg/dmarc/SFCLgYD-DfLMX5YR0Sjc0NEE5mY Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 07 Jun 2014 10:37:44 -0000 On Saturday, June 07, 2014 10:51 AM [GMT+1=3DCET], Stephen J. Turnbull = wrote: > I don't understand why Vlatko thinks he has a problem that needs a > new protocol to solve. What am I missing? I'm glad I'm not alone. Regards, J.Gomez From nobody Sat Jun 7 03:45:02 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6C31A02E2 for ; Sat, 7 Jun 2014 03:45:00 -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 62QEdmhEsj6g for ; Sat, 7 Jun 2014 03:44:59 -0700 (PDT) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 155BD1A0109 for ; Sat, 7 Jun 2014 03:44:58 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id k48so3878597wev.19 for ; Sat, 07 Jun 2014 03:44: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=k2NfI7ZcsQ28+21fSpgvfxpE16irCFwZ9RBQMFQ0KLc=; b=FOfyfCxGNWmiKE3pYRbo+AaXVswRNVI8K9xvd7KBfJIxWnDABbkEqA+RLK412dP1Pj yFSPUAodglRSwrXO4H1D4HMOHNAuunJD0DUnla2CDmjVdRQ449YZ55c3azAZFvm92VX5 zlKSwSKO/MqcyR48QFriSNwwL5yvxW1n8emhA2N4LoQ42IR2cOjOWreVbmy0sNTj98Fp Wk+SwP3pYh+5OXaARIQzGRLAnJR7jXI5eVdqteVZffnSyJ7zwH4lvO9YRo7whB6qlItp mOLg7PLpq72jyEn6mP3luznZgWNlZZXpkPBGOq7LmVZkCFW1PokV61ADjaQzIE6Hnnut 6DhQ== X-Received: by 10.14.174.135 with SMTP id x7mr2063487eel.10.1402137890704; Sat, 07 Jun 2014 03:44:50 -0700 (PDT) Received: from ?IPv6:2a02:a03f:14c1:6600:e0ab:3885:4dd3:da36? ([2a02:a03f:14c1:6600:e0ab:3885:4dd3:da36]) by mx.google.com with ESMTPSA id m2sm29504189eey.36.2014.06.07.03.44.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Jun 2014 03:44:50 -0700 (PDT) Message-ID: <5392ECED.5010404@gmail.com> Date: Sat, 07 Jun 2014 12:43:57 +0200 From: Dave Crocker 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: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> In-Reply-To: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/VWAfdSaxsgpqCgdwnAX8B8zHYlc Subject: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 07 Jun 2014 10:45:01 -0000 Folks, I've been stewing on this idea for awhile and Murray pressed to get it into writing, adding his usual, significant enhancements to the original concept. We've gone a couple of rounds before releasing it, but it's still nascent enough to warrant gentle-but-firm handling. In other words, comments eagerly solicited. d/ -------- Original Message -------- Name: draft-kucherawy-dkim-delegate Revision: 00 Title: Delegating DKIM Signing Authority Document date: 2014-06-07 Group: Individual Submission Pages: 10 URL: http://www.ietf.org/internet-drafts/draft-kucherawy-dkim-delegate-00.txt Status: https://datatracker.ietf.org/doc/draft-kucherawy-dkim-delegate/ Htmlized: http://tools.ietf.org/html/draft-kucherawy-dkim-delegate-00 Abstract: DomainKeys Identified Mail (DKIM) permits a handling agent to affix a digital signature to an email message, associating a domain name with that message using cryptographic signing techniques. The digital signature typically covers most of a message's original portions, although the specific choices for content hashing are at the discretion of the signer. DKIM signatures survive simply email relaying but typically are invalidated by processing through Mediators, such as mailing lists. For such cases, the signer needs a way to indicate that a valid signature from some third party was anticipated, and constitutes an acceptable handling of the message. This enables a receiver to conclude that the content is legitimately from that original signer, even though its original signature no longer validates. This document defines a mechanism for improving the ability to assess DKIM validity for such messages. -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Jun 7 04:01:51 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7CDF1A0341 for ; Sat, 7 Jun 2014 04:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.618 X-Spam-Level: X-Spam-Status: No, score=-4.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 GpaMv-ATGCrt for ; Sat, 7 Jun 2014 04:01:47 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C061A0340 for ; Sat, 7 Jun 2014 04:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1402138900; x=1433674900; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kuNM2cKJzooXgzMvf/nBvT83RY7jQZHzjb25bxZetYg=; b=2MjQ3y6WkUz+bm7g8IiFchoanW0jdGZwvxuGHc37vuBqTlJUBJOyQ4nx wjuBmEKsgufziAIpx4zc+US2hDrWAUfhj7IptXwcz77EQKR70vunCT2M+ BjNlGEQ4dQ38+Qb7WqmIqRcNRYRY9utXmjHhNFhe3+y0kf9MI6crAn1D8 8=; X-IronPort-AV: E=Sophos;i="4.98,994,1392192000"; d="asc'?scan'208";a="126313266" Received: from ESV4-MBX03.linkedin.biz ([fe80::14ba:eaea:c913:fa88]) by ESV4-HT01.linkedin.biz ([::1]) with mapi id 14.03.0174.001; Sat, 7 Jun 2014 04:01:37 -0700 From: Franck Martin To: "Stephen J. Turnbull" Thread-Topic: [dmarc-ietf] confusing 3rd party support so it remains out Thread-Index: AQHPgJE8AJGm/ow150C/0rLKfClHLpti9olfgACCvgCAAAj6AIAAsLyAgAAaTYCAAEi4gIAAONaAgAAU4ACAAAZlgIAAC1IAgAASOgCAAAZMAIAADHWAgAC1IACAACRfAA== Date: Sat, 7 Jun 2014 11:01:37 +0000 Message-ID: <70B0B4F4-FA27-43F6-AE1E-68455EE5D194@linkedin.com> References: <1402089514.72796.YahooMailNeo@web164603.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8D48E075@MSGRTPCCRF2WIN.DMN1.FMR.COM> <87y4x914s1.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87y4x914s1.fsf@uwakimon.sk.tsukuba.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.250] Content-Type: multipart/signed; boundary="Apple-Mail=_85BDF62F-0053-450B-952C-B482D8393921"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/KFNkr_gKigmzjc5mzLGz-0FB0hc Cc: Vlatko Salaj , "Popowycz, Alex" , DMARC Discussion , "Talamo, Victor" Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 07 Jun 2014 11:01:49 -0000 --Apple-Mail=_85BDF62F-0053-450B-952C-B482D8393921 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 7, 2014, at 10:51 AM, Stephen J. Turnbull = wrote: > Popowycz, Alex writes: >> Vlatko >=20 > Please don't feed the trolls (including me, I'm regretting my role > in this thread). There's work to be done here, and Vlatko seems > uninterested in helping with it (eg, when asked for specific > references, he says "I'm not a search engine"). >=20 > What I gather from Vlatko's posts is that there is a use case where an > entity (eg, a small business; called "ENTITY" below) wants its own > domain (called "OWNDOM" below) referenced in correspondence, but > prefers not to maintain a single presence (even as a VPS) on the > Internet. Instead, ENTITY uses an ESP (below, "ESP" denotes > aparticular ESP) to send and receive mail, and ESP provides the usual > set of authentication services for its host. The need is to provide > credentials and an authentication protocol for mailboxes in OWNDOM > that will satisfy identity alignment, and all actors will voluntarily > participate. Stephen, We (people with p=3Dreject) went to all well known ESPs and asked them = to send our emails with SPF and DKIM alignment with our domain. They all = have been able to do it, tho some (especially account reps) did not know = what DMARC meant :P So I think requesting an ESP to do SPF and DKIM using your domain is not = impossible, I think the issue, is a problem of scale at the moment. Few = have =93press a button=94 solution, and it is still a manual = configuration, but I suspect, they will scale from manual to automatic = setup to support any domain DMARC policies as more customers request the = features. --Apple-Mail=_85BDF62F-0053-450B-952C-B482D8393921 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJTkvERAAoJEJHd9Bbysc+akfgH/0YA9wOBQH1nPPgjaivhSHMh qK37FYkwsyI41sKVikN4L7bMLqCDFnw8X3HIigdtte5ReNri1M9vYQBc5Wzmngk6 nKFxvPwEJgw4B/VSLufS3ZXZ6AI7KP+GZO1Ecy//W1+8VDyhep3hE4lDN6G5k+UT WUrI/zayhUz2+nIFL24MXAa26IvEMGr5Id8HeXoGY3em/YtRxZ9AFuPEgnqSEaiC a+/4IQNx5yX3dF2gZUezGL5nmhJlCO08O6RU6TKaaIB8/6MCK87QTCFOCZ1kjRfj Atqvm4SzJU1mt8Hg7edvlWq6mD087exDf/KbRhg912BojYeByjfEfrgvNipHKIQ= =HT9Z -----END PGP SIGNATURE----- --Apple-Mail=_85BDF62F-0053-450B-952C-B482D8393921-- From nobody Sat Jun 7 04:22:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FC71A0343 for ; Sat, 7 Jun 2014 04:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, 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 8XIKLY2OxhLx for ; Sat, 7 Jun 2014 04:22:48 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 531391A0341 for ; Sat, 7 Jun 2014 04:22:48 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id p10so3825968wes.6 for ; Sat, 07 Jun 2014 04:22: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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=uqcQ0uJqK/Qw2DbeKlpWK6BAib0R03XvzY+n3O5sYx4=; b=DtzPmWWI6eKIJUw1u/Tr1cZ9jecefZlEMGQSIfLDFxkkyNLr2lcj8495RDlwFysu5M CQ5b8DZa/72pva8wp3BNZu0gqjjgg5F+AmxNy8qtjxb72c8r5yc494sJFHLv3ifq4WRc eMxelo8Je53Jj0LqNyFJUWtV49ihK/IzPPaBClIJUQuKLKTy9fUfCcCh6WsIpp1xidSt 5o1caj3kz9IhoKsbm8pMSWNmSPoaSL3UFC4bJyd8QckAVq4hcX+8QauS3cxs3lxafJfq gOFzUdRdDwqylqbD8iML40nMo8sLdzPnW2xV+Wt+wfenw2QyJ4p49Ac1CFUhLBoxDUWU 5b8Q== X-Received: by 10.14.174.135 with SMTP id x7mr2087205eel.10.1402140160113; Sat, 07 Jun 2014 04:22:40 -0700 (PDT) Received: from ?IPv6:2a02:a03f:14c1:6600:e0ab:3885:4dd3:da36? ([2a02:a03f:14c1:6600:e0ab:3885:4dd3:da36]) by mx.google.com with ESMTPSA id p9sm29715521eeg.32.2014.06.07.04.22.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Jun 2014 04:22:39 -0700 (PDT) Message-ID: <5392F5CB.2050009@gmail.com> Date: Sat, 07 Jun 2014 13:21:47 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Franck Martin References: <1402089514.72796.YahooMailNeo@web164603.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8D48E075@MSGRTPCCRF2WIN.DMN1.FMR.COM> <87y4x914s1.fsf@uwakimon.sk.tsukuba.ac.jp> <70B0B4F4-FA27-43F6-AE1E-68455EE5D194@linkedin.com> In-Reply-To: <70B0B4F4-FA27-43F6-AE1E-68455EE5D194@linkedin.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ViTBDOlLbhJdMPJ2W2CwCqaEybI Cc: Vlatko Salaj , "Stephen J. Turnbull" , DMARC Discussion , "Popowycz, Alex" , "Talamo, Victor" Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 07 Jun 2014 11:22:50 -0000 On 6/7/2014 1:01 PM, Franck Martin wrote: > So I think requesting an ESP to do SPF and DKIM using your domain is not impossible, I think the issue, is a problem of scale at the moment. Few have “press a button” solution, and it is still a manual configuration, but I suspect, they will scale from manual to automatic setup to support any domain DMARC policies as more customers request the features. Perhaps I am missing something basic, but I would think that the larger barrier here is to make it easy for the domain owner to permit such signing by third-parties. To take an obvious example, small-business@yahoo.com wants to use small-ESP for sending mail to small-business' customers. How does small-business get Yahoo to readily delegate signing authority to small-ESP? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Jun 7 05:16:39 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA8B1A0340 for ; Sat, 7 Jun 2014 05:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.55 X-Spam-Level: X-Spam-Status: No, score=-4.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 o35LMtp52PjQ for ; Sat, 7 Jun 2014 05:16:36 -0700 (PDT) Received: from nm33.bullet.mail.gq1.yahoo.com (nm33.bullet.mail.gq1.yahoo.com [98.136.217.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA5971A02C1 for ; Sat, 7 Jun 2014 05:16:35 -0700 (PDT) Received: from [127.0.0.1] by nm33.bullet.mail.gq1.yahoo.com with NNFMP; 07 Jun 2014 12:16:28 -0000 Received: from [98.137.12.56] by nm33.bullet.mail.gq1.yahoo.com with NNFMP; 07 Jun 2014 12:13:41 -0000 Received: from [98.137.12.238] by tm1.bullet.mail.gq1.yahoo.com with NNFMP; 07 Jun 2014 12:13:41 -0000 Received: from [127.0.0.1] by omp1046.mail.gq1.yahoo.com with NNFMP; 07 Jun 2014 12:13:41 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 375824.26098.bm@omp1046.mail.gq1.yahoo.com Received: (qmail 84398 invoked by uid 60001); 7 Jun 2014 12:13:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402143221; bh=TGxWF9oKAc252VXAi6IBTBcTrEjWJJaSDmVe2azNEk4=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=l9Oq6j8i6icA8bKSlN8GAeFNpqy0xeGqxM4dGJOIiaUz/CaVq19kQdcYDK64iYJFn5db93EN0WGfNikkLcCuC+vJUSgQP+sp5ocwH2LZm76+IzWyrgCZDlmEdWR7FmwEw6GY3uPVKfwaQutZY/d5DVws4uNld9ZOUF+fK8npIQc= X-YMail-OSG: G100dEsVM1kdIKPNkhm1hgaNFGYx8UTJyVBjuq3nlDZswA7 2T9k1RKwAzqXvd9rGOb9Wgq8DRYmx2K1byBi2X0SuPmh8RSyLFAl2PV8E2NV uMjTc4yLMqgYGOb7b2Az0LKQmjBs2H5gDgpy9MDyRpLTr7w3eAiv.OFzDsbp T1MINxFm0wJE_QurQWlwn.dhdGGPzQ0byKUDfSvgdcoo4gJbaP9Uqz3ATGcJ rZLOTozIyXQLeAqlCij0I.F_YHvKH1cTRQLqAAod0oMBPuPJpaMgGLxRZkVW 4HxZRO6eNMJRix_uAiRQVvG3iljtnYCk5PCQu8dVuH9G8qXevU7rANcH4EXx cQDCKiZGT7HH5gmgYj9PWNUW8vRJaFHKHi3sciLQ1F51LhnhAmYyZFficv9H X.KK4DM0UYFQeuCqPvSvXdt.KWkc.MnTwrNZd0zm_dx2fyFzLOsG7eYDZ31m tPshtPN0.X7c9kjG6xTzXGp8pft6_amNmdfjsEuYt7rvqB8fVC.MV2BZBK22 n5kn18NEKlmLOWr2hSMlGV19JZAXsyFH.lNwp6MI8q0xzPgy09dJRfLe8Vnl tGN6_89Rzotd0mjsqd69MUt_2HHFcCjIGzLJ6kcCTfUFoMHlRBQ-- Received: from [79.175.112.242] by web164606.mail.gq1.yahoo.com via HTTP; Sat, 07 Jun 2014 05:13:41 PDT X-Rocket-MIMEInfo: 002.001, T24gU2F0dXJkYXksIEp1bmUgNywgMjAxNCAxMDo1MSBBTSwgU3RlcGhlbiBKLiBUdXJuYnVsbCA8c3RlcGhlbkB4ZW1hY3Mub3JnPiB3cm90ZToKCj4gUGxlYXNlIGRvbid0IGZlZWQgdGhlIHRyb2xscy4KCnllYWgsIGl0IHdhcyBhbiBpbnRlcmVzdGluZyBkYXkgeWVzdGVyZGF5LgoKaSBzaG91bGQgaGF2ZSB0cmllZCB0cmFuc21pdHRpbmcgbXkgcG9zdHMgd2l0aCBtdWNoIGJldHRlciB3b3JkaW5nLgoKaSBzaW5jZXJlbHkgYXBvbG9naXplIGZvciBhbnkgcGVyc29uYWwgaHVydCBpIGNhdXNlZC4gaSBkbyABMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <1402089514.72796.YahooMailNeo@web164603.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8D48E075@MSGRTPCCRF2WIN.DMN1.FMR.COM> <87y4x914s1.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <1402143221.49772.YahooMailNeo@web164606.mail.gq1.yahoo.com> Date: Sat, 7 Jun 2014 05:13:41 -0700 (PDT) From: Vlatko Salaj To: "Stephen J. Turnbull" In-Reply-To: <87y4x914s1.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/2rbIz1mpFdDe2BHnCwl64sqS4XI Cc: DMARC Discussion Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 07 Jun 2014 12:16:37 -0000 On Saturday, June 7, 2014 10:51 AM, Stephen J. Turnbull wrote: > Please don't feed the trolls. yeah, it was an interesting day yesterday. i should have tried transmitting my posts with much better wording. i sincerely apologize for any personal hurt i caused. i do not know any of u, so any personal feelings towards u would be pretty ungrounded, and i apologize for any i transmitted yesterday. at least everybody here knows that i'm a knowledgeable person now, and that they should thread carefully when discussing stuff with me, or some shameless things may happen [until my posting privileges get swashed away, at least, cause i'm threading on edges always, i guess - the story of my life]. btw, if u r willing to contribute on a mailing list like this, it's minimum decency to actually know what the hell u r talking about, or even better, know draft documents to letter. if a nobody like myself can do it, every list member can do it too. ...and before i start another flame war, let me move on. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Sat Jun 7 05:19:24 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F82E1A0340 for ; Sat, 7 Jun 2014 05:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=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 LAqR00DgeEfm for ; Sat, 7 Jun 2014 05:19:20 -0700 (PDT) Received: from msginmsm09vapp.fmr.com (ltm-fwus209m-210m.fidelity.com [155.199.204.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D4651A02C1 for ; Sat, 7 Jun 2014 05:19:19 -0700 (PDT) Received: from msgrtphc03win.DMN1.FMR.COM (MSGRTPHC03WIN.dmn1.fmr.com [10.95.11.183]) by msginmsm09vapp.fmr.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.1) with ESMTP id s57CJ3LM015688 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Sat, 7 Jun 2014 12:19:03 GMT X-DKIM: OpenDKIM Filter v2.1.3 msginmsm09vapp.fmr.com s57CJ3LM015688 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fmr.com; s=2012-05-26; t=1402143544; bh=C5taTKAa6fLCuWro9eTtMFyes0s5GxrD93H0hBpu0u8=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=wYl0kUtsXPPfF+c6xaRIw3xhY2hpeamWw3dLqlqbXNfX32q4cfWnVfWJ4GkVIeBX3 DPUznS3Xr5eFiWAGT7ozDWG+lJveOe2wPAo3iSthHtJ/8+8MzTdaoOhmXat/PgDl5K zd1frZzLls8AJIEJOFOOSGgpco0Y6/oCSZWF1NK8= Received: from MSGRTPCCRF2WIN.DMN1.FMR.COM ([10.95.12.32]) by msgrtphc03win.DMN1.FMR.COM ([10.95.11.183]) with mapi; Sat, 7 Jun 2014 08:19:02 -0400 From: "Popowycz, Alex" To: "'Dave Crocker'" , "'Franck Martin'" Date: Sat, 7 Jun 2014 08:19:01 -0400 Thread-Topic: [dmarc-ietf] confusing 3rd party support so it remains out Thread-Index: Ac+CQtN38bFJvFhaSEexj+wjBTXWKgAB9bGJ Message-ID: <9495B91F5CA0E24C9161D71CD46E43DB011C8D48E077@MSGRTPCCRF2WIN.DMN1.FMR.COM> References: <5392F5CB.2050009@gmail.com> In-Reply-To: <5392F5CB.2050009@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9495B91F5CA0E24C9161D71CD46E43DB011C8D48E077MSGRTPCCRF2_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/gcay4TuaBA17-X9VE4FH-nhhb3A Cc: 'Vlatko Salaj' , "'Stephen J. Turnbull'" , 'DMARC Discussion' , "'Talamo, Victor'" Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 07 Jun 2014 12:19:22 -0000 --_000_9495B91F5CA0E24C9161D71CD46E43DB011C8D48E077MSGRTPCCRF2_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBJIG1heSBub3QgYmUgdW5kZXJzdGFuZGluZyB0aGUgcHJvYmxlbS4gSW4gdGhlIHNp dHVhdGlvbiBjaXRlZCBieSBEYXZlLCBzbWFsbC1idXNpbmVzc0B5YWhvby5jb20gd2FudHMgdG8g aGF2ZSBhbiBFU1Agc2VuZCBtYWlsIG9uIGl0cyBiZWhhbGYgdXNpbmcgdGhlIHNtYWxsIGJ1c2lu ZXNzIGRvbWFpbiAoaS5lLiBGUk9NOkBzbWFsbGJ1c2luZXNzLmNvbSkuDQoNCkluIHRoYXQgc2l0 dWF0aW9uLCB3aHkgd291bGRuJ3Qgc21hbGwgYnVzaW5lc3MgZ2V0IGEgREtJTSBrZXkgYW5kIHVu aXF1ZSBzZWxlY3RvciBhbmQgcHVibGlzaCB0aGF0IGluIEROUywgZXhwYW5kaW5nIHRoZSBleGlz dGluZyBTUEYgcmVjb3JkIHRvIGluY2x1ZGUgdGhlIHJlbGV2YW50IGFkZHJlc3NlcyBvZiB0aGUg RVNQPyBJbiBteSBleHBlcmllbmNlLCBpc29sYXRpbmcgdGhhdCB0cmFmZmljIHVzaW5nIGEgc3Vi ZG9tYWluIChlLmcuIEBlc3Auc21hbGxidXNpbmVzcy5jb20pIGZvciB0aGUgZnJvbSBhZGRyZXNz IHdvdWxkIGJlIHByZWZlcnJlZCBmb3Igb3BlcmF0aW9uYWwgYW5kIGZvcmVuc2ljIHB1cnBvc2Vz LiBUaGUgb25seSByb2xlIEkgY2FuIHNlZSBZYWhvbyBwbGF5aW5nIGlzIHRha2luZyByZXNwb25z ZXMgdG8gdGhhdCB0cmFmZmljIHRoYXQgb3JpZ2luYXRlZCBmcm9tIHRoZSBFU1AgYXMgaW5kaWNh dGVkIGluIHRoZSBNWCByZWNvcmQgZm9yIHNtYWxsYnVzaW5lc3MuY29tIGlmIHRoYXQncyB3aGF0 IGlzIGRlc2lyZWQuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGF2 ZSBDcm9ja2VyIFtkY3JvY2tlckBnbWFpbC5jb208bWFpbHRvOmRjcm9ja2VyQGdtYWlsLmNvbT5d DQpTZW50OiBTYXR1cmRheSwgSnVuZSAwNywgMjAxNCAwNzoyMiBBTSBFYXN0ZXJuIFN0YW5kYXJk IFRpbWUNClRvOiBGcmFuY2sgTWFydGluDQpDYzogVmxhdGtvIFNhbGFqOyBTdGVwaGVuIEouIFR1 cm5idWxsOyBETUFSQyBEaXNjdXNzaW9uOyBQb3Bvd3ljeiwgQWxleDsgVGFsYW1vLCBWaWN0b3IN ClN1YmplY3Q6IFJlOiBbZG1hcmMtaWV0Zl0gY29uZnVzaW5nIDNyZCBwYXJ0eSBzdXBwb3J0IHNv IGl0IHJlbWFpbnMgb3V0DQoNCg0KT24gNi83LzIwMTQgMTowMSBQTSwgRnJhbmNrIE1hcnRpbiB3 cm90ZToNCj4gU28gSSB0aGluayByZXF1ZXN0aW5nIGFuIEVTUCB0byBkbyBTUEYgYW5kIERLSU0g dXNpbmcgeW91ciBkb21haW4gaXMgbm90IGltcG9zc2libGUsIEkgdGhpbmsgdGhlIGlzc3VlLCBp cyBhIHByb2JsZW0gb2Ygc2NhbGUgYXQgdGhlIG1vbWVudC4gRmV3IGhhdmUg4oCccHJlc3MgYSBi dXR0b27igJ0gc29sdXRpb24sIGFuZCBpdCBpcyBzdGlsbCBhIG1hbnVhbCBjb25maWd1cmF0aW9u LCBidXQgSSBzdXNwZWN0LCB0aGV5IHdpbGwgc2NhbGUgZnJvbSBtYW51YWwgdG8gYXV0b21hdGlj IHNldHVwIHRvIHN1cHBvcnQgYW55IGRvbWFpbiBETUFSQyBwb2xpY2llcyBhcyBtb3JlIGN1c3Rv bWVycyByZXF1ZXN0IHRoZSBmZWF0dXJlcy4NCg0KDQpQZXJoYXBzIEkgYW0gbWlzc2luZyBzb21l dGhpbmcgYmFzaWMsIGJ1dCBJIHdvdWxkIHRoaW5rIHRoYXQgdGhlIGxhcmdlcg0KYmFycmllciBo ZXJlIGlzIHRvIG1ha2UgaXQgZWFzeSBmb3IgdGhlIGRvbWFpbiBvd25lciB0byBwZXJtaXQgc3Vj aA0Kc2lnbmluZyBieSB0aGlyZC1wYXJ0aWVzLg0KDQpUbyB0YWtlIGFuIG9idmlvdXMgZXhhbXBs ZSwgc21hbGwtYnVzaW5lc3NAeWFob28uY29tIHdhbnRzIHRvIHVzZQ0Kc21hbGwtRVNQIGZvciBz ZW5kaW5nIG1haWwgdG8gc21hbGwtYnVzaW5lc3MnIGN1c3RvbWVycy4NCg0KSG93IGRvZXMgc21h bGwtYnVzaW5lc3MgZ2V0IFlhaG9vIHRvIHJlYWRpbHkgZGVsZWdhdGUgc2lnbmluZyBhdXRob3Jp dHkNCnRvIHNtYWxsLUVTUD8NCg0KZC8NCg0KLS0NCkRhdmUgQ3JvY2tlcg0KQnJhbmRlbmJ1cmcg SW50ZXJuZXRXb3JraW5nDQpiYml3Lm5ldA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KZG1hcmMgbWFpbGluZyBsaXN0DQpkbWFyY0BpZXRmLm9yZw0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbWFyYw0K --_000_9495B91F5CA0E24C9161D71CD46E43DB011C8D48E077MSGRTPCCRF2_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPGh0bWw+ DQo8aGVhZD4NCjxtZXRhIG5hbWU9ImdlbmVyYXRvciIgY29udGVudD0iSFRNTCBUaWR5IGZvciBX aW5kb3dzICh2ZXJzIDI1IE1hcmNoIDIwMDkpLCBzZWUgd3d3LnczLm9yZyI+DQo8bWV0YSBodHRw LWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+ DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1TIEV4Y2hhbmdlIFNlcnZlciB2ZXJz aW9uIDA4LjAzLjAzMzAuMDAwIj4NCjx0aXRsZT5SZTogW2RtYXJjLWlldGZdIGNvbmZ1c2luZyAz cmQgcGFydHkgc3VwcG9ydCBzbyBpdCByZW1haW5zIG91dDwvdGl0bGU+DQo8L2hlYWQ+DQo8Ym9k eT4NCkkgdGhpbmsgSSBtYXkgbm90IGJlIHVuZGVyc3RhbmRpbmcgdGhlIHByb2JsZW0uIEluIHRo ZSBzaXR1YXRpb24gY2l0ZWQgYnkgRGF2ZSwgc21hbGwtYnVzaW5lc3NAeWFob28uY29tIHdhbnRz IHRvIGhhdmUgYW4gRVNQIHNlbmQgbWFpbCBvbiBpdHMgYmVoYWxmIHVzaW5nIHRoZSBzbWFsbCBi dXNpbmVzcyBkb21haW4gKGkuZS4gRlJPTTpAc21hbGxidXNpbmVzcy5jb20pLjxicj4NCjxicj4N CkluIHRoYXQgc2l0dWF0aW9uLCB3aHkgd291bGRuJ3Qgc21hbGwgYnVzaW5lc3MgZ2V0IGEgREtJ TSBrZXkgYW5kIHVuaXF1ZSBzZWxlY3RvciBhbmQgcHVibGlzaCB0aGF0IGluIEROUywgZXhwYW5k aW5nIHRoZSBleGlzdGluZyBTUEYgcmVjb3JkIHRvIGluY2x1ZGUgdGhlIHJlbGV2YW50IGFkZHJl c3NlcyBvZiB0aGUgRVNQPyBJbiBteSBleHBlcmllbmNlLCBpc29sYXRpbmcgdGhhdCB0cmFmZmlj IHVzaW5nIGEgc3ViZG9tYWluIChlLmcuIEBlc3Auc21hbGxidXNpbmVzcy5jb20pIGZvciB0aGUg ZnJvbSBhZGRyZXNzIHdvdWxkIGJlIHByZWZlcnJlZCBmb3Igb3BlcmF0aW9uYWwgYW5kIGZvcmVu c2ljIHB1cnBvc2VzLiBUaGUgb25seSByb2xlIEkgY2FuIHNlZSBZYWhvbyBwbGF5aW5nIGlzIHRh a2luZyByZXNwb25zZXMgdG8gdGhhdCB0cmFmZmljIHRoYXQgb3JpZ2luYXRlZCBmcm9tIHRoZSBF U1AgYXMgaW5kaWNhdGVkIGluIHRoZSBNWCByZWNvcmQgZm9yIHNtYWxsYnVzaW5lc3MuY29tIGlm IHRoYXQncyB3aGF0IGlzIGRlc2lyZWQuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS08YnI+DQo8Yj5Gcm9tOiZuYnNwOzwvYj5EYXZlIENyb2NrZXIgWzxh IGhyZWY9Im1haWx0bzpkY3JvY2tlckBnbWFpbC5jb20iPmRjcm9ja2VyQGdtYWlsLmNvbTwvYT5d PGJyPg0KPGI+U2VudDombmJzcDs8L2I+U2F0dXJkYXksIEp1bmUgMDcsIDIwMTQgMDc6MjIgQU0g RWFzdGVybiBTdGFuZGFyZCBUaW1lPGJyPg0KPGI+VG86Jm5ic3A7PC9iPkZyYW5jayBNYXJ0aW48 YnI+DQo8Yj5DYzombmJzcDs8L2I+VmxhdGtvIFNhbGFqOyBTdGVwaGVuIEouIFR1cm5idWxsOyBE TUFSQyBEaXNjdXNzaW9uOyBQb3Bvd3ljeiwgQWxleDsgVGFsYW1vLCBWaWN0b3I8YnI+DQo8Yj5T dWJqZWN0OiZuYnNwOzwvYj5SZTogW2RtYXJjLWlldGZdIGNvbmZ1c2luZyAzcmQgcGFydHkgc3Vw cG9ydCBzbyBpdCByZW1haW5zIG91dDxicj4NCjxicj4NCjwhLS0gQ29udmVydGVkIGZyb20gdGV4 dC9wbGFpbiBmb3JtYXQgLS0+DQo8cD48Zm9udCBzaXplPSIyIj5PbiA2LzcvMjAxNCAxOjAxIFBN LCBGcmFuY2sgTWFydGluIHdyb3RlOjxicj4NCiZndDsgU28gSSB0aGluayByZXF1ZXN0aW5nIGFu IEVTUCB0byBkbyBTUEYgYW5kIERLSU0gdXNpbmcgeW91ciBkb21haW4gaXMgbm90IGltcG9zc2li bGUsIEkgdGhpbmsgdGhlIGlzc3VlLCBpcyBhIHByb2JsZW0gb2Ygc2NhbGUgYXQgdGhlIG1vbWVu dC4gRmV3IGhhdmUg4oCccHJlc3MgYSBidXR0b27igJ0gc29sdXRpb24sIGFuZCBpdCBpcyBzdGls bCBhIG1hbnVhbCBjb25maWd1cmF0aW9uLCBidXQgSSBzdXNwZWN0LCB0aGV5IHdpbGwgc2NhbGUg ZnJvbSBtYW51YWwgdG8gYXV0b21hdGljIHNldHVwIHRvIHN1cHBvcnQgYW55IGRvbWFpbiBETUFS QyBwb2xpY2llcyBhcyBtb3JlIGN1c3RvbWVycyByZXF1ZXN0IHRoZSBmZWF0dXJlcy48YnI+DQo8 YnI+DQo8YnI+DQpQZXJoYXBzIEkgYW0gbWlzc2luZyBzb21ldGhpbmcgYmFzaWMsIGJ1dCBJIHdv dWxkIHRoaW5rIHRoYXQgdGhlIGxhcmdlcjxicj4NCmJhcnJpZXIgaGVyZSBpcyB0byBtYWtlIGl0 IGVhc3kgZm9yIHRoZSBkb21haW4gb3duZXIgdG8gcGVybWl0IHN1Y2g8YnI+DQpzaWduaW5nIGJ5 IHRoaXJkLXBhcnRpZXMuPGJyPg0KPGJyPg0KVG8gdGFrZSBhbiBvYnZpb3VzIGV4YW1wbGUsIHNt YWxsLWJ1c2luZXNzQHlhaG9vLmNvbSB3YW50cyB0byB1c2U8YnI+DQpzbWFsbC1FU1AgZm9yIHNl bmRpbmcgbWFpbCB0byBzbWFsbC1idXNpbmVzcycgY3VzdG9tZXJzLjxicj4NCjxicj4NCkhvdyBk b2VzIHNtYWxsLWJ1c2luZXNzIGdldCBZYWhvbyB0byByZWFkaWx5IGRlbGVnYXRlIHNpZ25pbmcg YXV0aG9yaXR5PGJyPg0KdG8gc21hbGwtRVNQPzxicj4NCjxicj4NCmQvPGJyPg0KPGJyPg0KLS08 YnI+DQpEYXZlIENyb2NrZXI8YnI+DQpCcmFuZGVuYnVyZyBJbnRlcm5ldFdvcmtpbmc8YnI+DQpi Yml3Lm5ldDxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KZG1hcmMgbWFpbGluZyBsaXN0PGJyPg0KZG1hcmNAaWV0Zi5vcmc8YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtYXJjIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtYXJjPC9hPjxicj48L2ZvbnQ+ PC9wPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9495B91F5CA0E24C9161D71CD46E43DB011C8D48E077MSGRTPCCRF2_-- From nobody Sat Jun 7 05:24:15 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5919D1A0340 for ; Sat, 7 Jun 2014 05:24:14 -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_51=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 999Upl6dD-hf for ; Sat, 7 Jun 2014 05:24:12 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F5651A02C1 for ; Sat, 7 Jun 2014 05:24:12 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id f8so2249691wiw.4 for ; Sat, 07 Jun 2014 05:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=tA54iMmbdtAyT8KGpCoBrrNPnszotbywY6N2Qxo1AY0=; b=M1Xmap00pxLNEbEoIwonrqe8taJpwqCS7KbVRncv9x9tSX3WwdXWT8pa6lny8BWo+l p6FB1YEuYylCNKO+aB7l/AdPo51VhsN4IfhMx9mBsfqQaYxaUSaO8pFOSHpSKCiE4iSC DWFzzL15FRzNn4h9EsG9BnWLdcM0yj64OgpVfA6McIC22DHeFrouTXIIPf7PmJdCsD4F urpYNxBgVZt2+4ZJiShj4lAxvLSSvAlxSfriFGXs0xVVMNVKSPkXikiR+xDQGIQWsdUE Ov6EcwvLBI9XBjZETO5CO1mu6Sp+8GD7lDNm8E1kb/n7ITFLt04c8HazsXS8foLyj3n6 nj7A== X-Received: by 10.194.23.135 with SMTP id m7mr15643625wjf.2.1402143844170; Sat, 07 Jun 2014 05:24:04 -0700 (PDT) Received: from [10.128.84.219] (87-198-224-122.static.ptr.magnet.ie. [87.198.224.122]) by mx.google.com with ESMTPSA id lz11sm2983544wic.0.2014.06.07.05.23.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Jun 2014 05:24:03 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A3EBD24D-0F2F-4CD4-8ED5-713F729DBD12" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: Date: Sat, 7 Jun 2014 05:23:51 -0700 Message-Id: <9D1B33AF-A54C-4D2C-801B-2B39234E9132@gmail.com> References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1402042491.15608.YahooMailNeo@web164601.mail.gq1.yahoo.com> <877g4u2ws4.fsf@uwakimon.sk.tsukuba.ac.jp> <1402063755.61291.YahooMailNeo@web164602.mail.gq1.yahoo.com> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/_3ysa08FIjwTaQgkwD5JgDFj5EA Cc: Vlatko Salaj , "Stephen J. Turnbull" , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 07 Jun 2014 12:24:14 -0000 --Apple-Mail=_A3EBD24D-0F2F-4CD4-8ED5-713F729DBD12 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 6, 2014, at 10:50 AM, Murray S. Kucherawy = wrote: > To answer Stephen's question, I'm guessing you're referring to ATPS = (RFC 6541), use of CNAME to point to an externally-posted key, and a key = exchange where an operator give a third party a signing key. If there = are others, I'd like to know what they are. >=20 > All three would require the Yahoo!s and AOLs of the world to grant = signing keys, signing key aliases, or ATPS records to every domain that = might re-send their mail. There are some obvious issues with such = solutions: (a) users will have to register every list to which they = subscribe and wish to post; (b) they will have to automate DNS updates = because every new entry into that registry will require a new DNS entry; = and (c) if any of those third parties gets compromised, it's a big = problem for the domain trying to protect itself. If any bit of this = fails (and I suspect (a) is actually the bigger problem), they don't = work. Dear Murray, Unlike ATPS, TPA-Label does not expect users to register which lists = they use. TPA-Label avoids transparent authorization techniques such as = the exchange of private key information which ensures all involved = domains remain apparent. Publishing public keys as belonging to a = domain not controlling the corresponding private key puts that domain at = unreasonable risk.=20 Nor does TPA-Label require specific cooperation of third-party services. = Many of these third-party services are offered without renumeration. = Services involved can be obtained via DMARC feedback compared against = lists of outbound domains. ATPS created several unnecessary deployment = problems not found in TPA-Label. Updating the TPA-Label zone should be = automated to better permit abuse mitigation. For this feature, = TPA-Label allows such zone generation to be maintained as a service by a = different entity when needed. DMARC seeks cooperation of receivers to assist in protecting their = recipients by way of message rejection together with domain feedback for = alignment failures. Reject when appropriate has several advantages. It = helps retain the integrity of email delivery. It clearly signals to the = sender a message is not wanted which should escalate to a better review = when frequent. For such requests to remain honored, domains making = DMARC requests MUST offer information that ensures: 1) Legitimate and compliant use of email is not disrupted. 2) Users' private exchanges being found in DMARC feedback is minimized = to the greatest extent possible. =20 3) At least Sender header fields should be able to offer alignments, = perhaps by way of a TPA-Label specific exception. To help improve the present state of trust, = Original-Authentication-Results (OAR) will be added as an optional = authorization requirement. This option might help mend fences following = events of abuse. TPA-Label is akin to a highly extensible SPF based on validated domains = rather than IP address lists. Whether it is understood by those deploying DMARC, most mitigation of = email abuse occurs as a result of automated zone generation. TPA-Label = has a significant advantage over that of real-time block lists, it = unblocks. As such, it should be less afflicted by DDoS attack. Regards, Douglas Otis --Apple-Mail=_A3EBD24D-0F2F-4CD4-8ED5-713F729DBD12 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jun 6, 2014, at 10:50 AM, Murray S. = Kucherawy <superuser@gmail.com> = wrote:

To = answer Stephen's question, I'm guessing you're referring to ATPS (RFC = 6541), use of CNAME to point to an externally-posted key, and a key = exchange where an operator give a third party a signing key.  If = there are others, I'd like to know what they are.

All three would require the = Yahoo!s and AOLs of the world to grant signing keys, signing key = aliases, or ATPS records to every domain that might re-send their = mail.  There are some obvious issues with such solutions: (a) users = will have to register every list to which they subscribe and wish to = post; (b) they will have to automate DNS updates because every new entry = into that registry will require a new DNS entry; and (c) if any of those = third parties gets compromised, it's a big problem for the domain trying = to protect itself.  If any bit of this fails (and I suspect (a) is = actually the bigger problem), they don't = work.


Dear = Murray,

Unlike ATPS, TPA-Label does not expect = users to register which lists they use.  TPA-Label avoids = transparent authorization techniques such as the exchange of private key = information which ensures all involved domains remain apparent. =  Publishing public keys as belonging to a domain not controlling = the corresponding private key puts that domain at unreasonable = risk. 

Nor does TPA-Label require specific = cooperation of third-party services.  Many of these third-party = services are offered without renumeration.  Services involved can = be obtained via DMARC feedback compared against lists of outbound = domains.  ATPS created several unnecessary deployment problems not = found in TPA-Label.  Updating the TPA-Label zone should be = automated to better permit abuse mitigation.  For this feature, = TPA-Label allows such zone generation to be maintained as a service by a = different entity when needed.

DMARC seeks = cooperation of receivers to assist in protecting their recipients by way = of message rejection together with domain feedback for alignment = failures.  Reject when appropriate has several advantages.  It = helps retain the integrity of email delivery.  It clearly signals = to the sender a message is not wanted which should escalate to a better = review when frequent.  For such requests to remain honored, domains = making DMARC requests MUST offer information that = ensures:

1) Legitimate and compliant use of = email is not disrupted.

2) Users' private = exchanges being found in DMARC feedback is minimized to the greatest = extent possible.  

3) At least Sender = header fields should be able to offer alignments, perhaps by way of a = TPA-Label specific exception.

To help improve = the present state of trust, Original-Authentication-Results (OAR) will = be added as an optional authorization requirement.  This option = might help mend fences following events of = abuse.

TPA-Label is akin to a highly extensible = SPF based on validated domains rather than IP address = lists.

Whether it is understood by those = deploying DMARC, most mitigation of email abuse occurs as a result of = automated zone generation.  TPA-Label has a significant advantage = over that of real-time block lists, it unblocks.  As such, it = should be less afflicted by DDoS = attack.

Regards,
Douglas = Otis




= --Apple-Mail=_A3EBD24D-0F2F-4CD4-8ED5-713F729DBD12-- From nobody Sat Jun 7 05:28:08 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4811A0349 for ; Sat, 7 Jun 2014 05:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 mmkvFiZDCh-r for ; Sat, 7 Jun 2014 05:28:02 -0700 (PDT) Received: from nm33.bullet.mail.gq1.yahoo.com (nm33.bullet.mail.gq1.yahoo.com [98.136.217.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0748B1A0348 for ; Sat, 7 Jun 2014 05:28:02 -0700 (PDT) Received: from [127.0.0.1] by nm33.bullet.mail.gq1.yahoo.com with NNFMP; 07 Jun 2014 12:27:55 -0000 Received: from [98.137.12.63] by nm33.bullet.mail.gq1.yahoo.com with NNFMP; 07 Jun 2014 12:25:03 -0000 Received: from [216.39.60.198] by tm8.bullet.mail.gq1.yahoo.com with NNFMP; 07 Jun 2014 12:25:03 -0000 Received: from [127.0.0.1] by omp1085.mail.gq1.yahoo.com with NNFMP; 07 Jun 2014 12:25:03 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 337018.21441.bm@omp1085.mail.gq1.yahoo.com Received: (qmail 28049 invoked by uid 60001); 7 Jun 2014 12:25:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402143903; bh=OV7vBhbtSnT/PIyxlymSiQ6GppgLr+BKoH+2zk216pU=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=G6hjds/ouUpQ7TjCsDqh9a5bEjDan8Zq5wxFT/WrU4KUnnOYYv99EZsmCOi7nukl3YxLpGDm401ULY6FVheebY2gLIm6ae/JzJvVOpaUvDYGMEcw3DmKTp0G2ZRW7ESd0SOOPLXB1JrnnKOOWxD534nT//hzn9goyLtfEWEWjRo= X-YMail-OSG: 3SmhTjEVM1kyQjqs65amQjDkLtf.IWr7ff2lWSKICmi6bi0 hIpCLxkKMV5aiohlSB.YUbO.DYkOxP4M66qU61XH6DS6XX.6qXFWBzVwEQ4h T4T.L_SIdqkEZVOBSRUeVHJIASe9CyKhmFxi5.iwMVlT2cIx0vhFLJS39yWQ KXgkaIw_SKzoXOhRVkwq9dEnm4y5jgOksRu7DyiHiMlVKBiwa8KQXvY.wOKi CFGywBbfK9y_Gc8pd1WRNPPy20w7pbdwYGakk.GoIRWK.9oL1JnuODe8ijRf 24aIYc1Qnowa6OJwWxRxwnnG.x8Lc4Fg8iHk3wKhoJUxmKAqzBwG4yxgZUW_ dabW2hjRCZI6ht_jE30YbSsrHMLG9zH8miwmfOLfVFNp9ckAVah5XVok4Bke XZhj1sP0at7ihwQAXv_.xBREY7K0iISCTtCYmp8yM0YunvqoHVVLMbgON8SI dJ1hXpbuHvSiqr8nNSOD.8PO7cfzIWIb14LPagkuPKU8E2AvImIW285i1Zfj Y5.BnRDEBnhQ5yhhU04nEuBzf17R1II.e7y4qbpWT6O3lzOPuKmfn2Kr2P7y bQm5yscHCguWWUVecLeXkczEZSzcCDrGc_ZyKUDsIYDYyLk_zsqBc3nxHbYp _zJPHoDLBtH7AtXF78WejqaBWL0Fv_vXcJY3EkqMbQ0p3IwLwm.dQv1jerFI fXWTJOucly9PSoBfmP1RCvdOTu70- Received: from [79.175.112.242] by web164602.mail.gq1.yahoo.com via HTTP; Sat, 07 Jun 2014 05:25:03 PDT X-Rocket-MIMEInfo: 002.001, PiBXaGF0IEkgZ2F0aGVyIGZyb20gVmxhdGtvJ3MgcG9zdHMgaXMgdGhhdCB0aGVyZSBpcyBhIHVzZSBjYXNlIHdoZXJlIGFuCj4gZW50aXR5IChlZywgYSBzbWFsbCBidXNpbmVzczsgY2FsbGVkICJFTlRJVFkiIGJlbG93KSB3YW50cyBpdHMgb3duCj4gZG9tYWluIChjYWxsZWQgIk9XTkRPTSIgYmVsb3cpIHJlZmVyZW5jZWQgaW4gY29ycmVzcG9uZGVuY2UsIGJ1dAo.IHByZWZlcnMgbm90IHRvIG1haW50YWluIGEgc2luZ2xlIHByZXNlbmNlIChldmVuIGFzIGEgVlBTKSBvbiB0aGUKPiBJbnRlcm5ldC4KCm4BMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <1402089514.72796.YahooMailNeo@web164603.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8D48E075@MSGRTPCCRF2WIN.DMN1.FMR.COM> <87y4x914s1.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <1402143903.18880.YahooMailNeo@web164602.mail.gq1.yahoo.com> Date: Sat, 7 Jun 2014 05:25:03 -0700 (PDT) From: Vlatko Salaj To: "Stephen J. Turnbull" In-Reply-To: <87y4x914s1.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/a7T8LAMhme7yzagFLG-m4mwDJ_Y Cc: DMARC Discussion Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 07 Jun 2014 12:28:04 -0000 > What I gather from Vlatko's posts is that there is a use case where an > entity (eg, a small business; called "ENTITY" below) wants its own > domain (called "OWNDOM" below) referenced in correspondence, but > prefers not to maintain a single presence (even as a VPS) on the > Internet. nope. that's not what i want. i actually have a VPS for my personal domain. its MTA forwards all my email to my yahoo account, which i use to store, send, access from various places and ways and whatnow. actually, most of my IT colleagues have something like this done for themselves too. haven't we all? the point is that i choose to trust a 3rd ESP for my email, not my VPS provider. why? uhhh, many reasons, does it even matter? as i said, it is my sole right to decide who i trust to handle my email, and i want DMARC to upgrade itself to be able to respect that. anyway, what i propose is quite simple, pretty trivial and easy to implement, actually: http://www.ietf.org/mail-archive/web/dmarc/current/msg00813.html it also covers much more than just my use case; it covers use cases all falling into a group of DMARC 3rd party alignment support, at least on a small scale. actually, small scale support is what DMARC is lacking, for most part. transactional email is all great and fine, but most important email is one between real ppl, and that part gets, in many use cases, excluded from protection provided by DMARC in current alignment requirements. while u can fix MLs with all those DMARC-compatible workarounds, u still can't fix many use cases used by small domains, which is, actually, most of the internet. and my solution, being so easy, trivial, and quite simple to implement, solves all of that. also, it's easier than VBR, ATPS, TPA, TPA-Label, and moves trouble of authorizing legitimate email from receivers' error-prone, DMARC-policy-disrespecting, essential whitelisting to domain-owner's control, where it should be. and since DMARC provides reporting on domain's email flow, domain-owners have everything they need to evaluate what 3rd party domains they would like to trust. also, since DMARC 3rd party support remains specified in their own DNS records, they have an easy and quick way of dismissing any turned-malicious actor as soon as they like. what u r proposing, Stephen, instead, is not at all trivial or easy to implement, nor does it solve more than just my special use case. am i actually not advocating for it, cause it's rather a completely different ESP service from what's common practice now. is it better? maybe. however, worth implementing? doubtful. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Sat Jun 7 05:30:58 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E571A0349 for ; Sat, 7 Jun 2014 05:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, 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 kTwwgrA6aW_v for ; Sat, 7 Jun 2014 05:30:55 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1821B1A02C1 for ; Sat, 7 Jun 2014 05:30:54 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi2so22676wib.13 for ; Sat, 07 Jun 2014 05:30: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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=C6O4C9+0F1WFCkdoRIewHyk6bS013VPJXBIED3mAEQs=; b=rYOLK5TfVHK9ClTLnF5Rym6TKhbFcRf3vu2tn31L7DDX1nn3i5qJCQ/7hL90Gm+kdh d8LbhsR+X5LVgZfnAkaVaYoLmGpk/R0s6H8zevSV+Xyx2Vh5kFLTj2UJLA0BvM1i1Z5r WzT0l6XqL9mOwDtE1DLQai6Q0OWX2OJEDy1L0CVEqF+5ga/ChR2TNd+p1fFc4Ln242o2 011OOjZsJocijw8274FxAds1tWT4ON48n8omnP1e1NudmosFcFXIdYLd7eH3uklVtfZB Onskb+Y9hMfbrwJuS4MOCMowU5UwRB1pU4Mn0sW4+q5ijenqX8MSPEvJIdI0L2yOHCz7 LA3w== X-Received: by 10.15.35.72 with SMTP id f48mr2446eev.13.1402144246905; Sat, 07 Jun 2014 05:30:46 -0700 (PDT) Received: from ?IPv6:2a02:a03f:14c1:6600:e0ab:3885:4dd3:da36? ([2a02:a03f:14c1:6600:e0ab:3885:4dd3:da36]) by mx.google.com with ESMTPSA id s9sm30098444ees.33.2014.06.07.05.30.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Jun 2014 05:30:46 -0700 (PDT) Message-ID: <539305C2.6060805@gmail.com> Date: Sat, 07 Jun 2014 14:29:54 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Popowycz, Alex" References: <5392F5CB.2050009@gmail.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8D48E077@MSGRTPCCRF2WIN.DMN1.FMR.COM> In-Reply-To: <9495B91F5CA0E24C9161D71CD46E43DB011C8D48E077@MSGRTPCCRF2WIN.DMN1.FMR.COM> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ip4d81HWeNKk4J99AwqU1rtPXmA Cc: 'DMARC Discussion' Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 07 Jun 2014 12:30:56 -0000 On 6/7/2014 2:19 PM, Popowycz, Alex wrote: > I think I may not be understanding the problem. In the situation cited > by Dave, small-business@yahoo.com wants to have an ESP send mail on its > behalf using the small business domain (i.e. FROM:@smallbusiness.com). Eyes and brains are such interesting creatures. They have (minor pun) a mind of their own. What you cite is not what I specified. I said small-business@yahoo.com. That's been their email address for years. It is their online identity. These are /very/ small business folk with tiny revenues, no technical skills, and a stable business. There are quite a large number of them in the world. And they need the smallest disruption possible to the conduct of their business life. And in case anyone thinks that recommending switching to their own domain name is "the" answer, that is a very, very long way from being a small disruption for such folk. That's why I cast the challenge of the situation in the way I original did. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Jun 7 05:49:12 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75B11A0357 for ; Sat, 7 Jun 2014 05:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=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 IgyIPa_Sts2h for ; Sat, 7 Jun 2014 05:49:09 -0700 (PDT) Received: from msginmsm01vapp.fmr.com (ltm-fwus209m-210m.fidelity.com [155.199.204.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE0131A0356 for ; Sat, 7 Jun 2014 05:49:08 -0700 (PDT) Received: from msgrtphc04win.DMN1.FMR.COM (MSGRTPHC04WIN.dmn1.fmr.com [10.95.12.184]) by msginmsm01vapp.fmr.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.1) with ESMTP id s57Cmx2j022441 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Sat, 7 Jun 2014 12:49:00 GMT X-DKIM: OpenDKIM Filter v2.1.3 msginmsm01vapp.fmr.com s57Cmx2j022441 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fmr.com; s=2012-05-26; t=1402145340; bh=1TYjMoSUu86UxlqBkbXsnrfsFJlvoubNBa5+O3sSmZ0=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=v1i3sKLECvPAftBnZAO0y8jDVDaWuG2MwaI4Fh2gcvHNF2ZQ/pLREtfYDPnxngsCw /h7QHGt4xAdPXYOaTBbwSVurUqCosw27XW4gsqs8p+k/5xxUu7oDAjY6H65Xvnv+4L WkaiBkzHupG/mSjCnNHTfrhXDbWL4sJVn8HDRK5U= Received: from MSGRTPCCRF2WIN.DMN1.FMR.COM ([10.95.12.32]) by msgrtphc04win.DMN1.FMR.COM ([10.95.12.184]) with mapi; Sat, 7 Jun 2014 08:48:59 -0400 From: "Popowycz, Alex" To: "'Dave Crocker'" Date: Sat, 7 Jun 2014 08:48:58 -0400 Thread-Topic: [dmarc-ietf] confusing 3rd party support so it remains out Thread-Index: Ac+CTFKxr0ZJgRQ9QUe4vJx9z/FzZgAAob9T Message-ID: <9495B91F5CA0E24C9161D71CD46E43DB011C8D48E078@MSGRTPCCRF2WIN.DMN1.FMR.COM> References: <539305C2.6060805@gmail.com> In-Reply-To: <539305C2.6060805@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_9495B91F5CA0E24C9161D71CD46E43DB011C8D48E078MSGRTPCCRF2_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/NB0EpiNOAXq1Iss9fns1IT8vHdg Cc: 'DMARC Discussion' Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 07 Jun 2014 12:49:11 -0000 --_000_9495B91F5CA0E24C9161D71CD46E43DB011C8D48E078MSGRTPCCRF2_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWhoaCwgT0suIFNvIG5vIGRvbWFpbiBvdGhlciB0aGFuIHlhaG9vLmNvbSBpbnZvbHZlZC4gSSBk b24ndCBiZWxpZXZlIHlhaG9vLmNvbSBoYWQgc2V0IGEgc3ViZG9tYWluIHBvbGljeSBzbyBzbWFs bCBidXNpbmVzcyBjb3VsZCBoYXZlIEVTUCBzZW5kIHVzaW5nIEBzbWFsbGJ1c2luZXNzLnlhaG9v LmNvbSB3aXRoIGEgcmVwbHkgdG8gb2YgeWFob28uY29tLCBvciBzaW1wbGUgc2VuZCB1c2luZyB0 aGUgRVNQJ3Mgb3duIGRvbWFpbiB3aXRoIHRoZSBzYW1lIHJlcGx5IHRvIGFzIGFib3ZlPyBJIGtu b3cgdGhlIGZpcnN0IHNraXJ0cyB0aGUgcHJvYmxlbSB3aGlsZSB0aGUgc2Vjb25kIGRvZXNuJ3Qg YWRkcmVzcyBjdXN0b21lcnMgaGF2aW5nIHdoaXRlIGxpc3RlZCB0aGUgb3JpZ2luYWwgYWRkcmVz cy4gSSdtIGp1c3QgdGhpbmtpbmcgcHJhY3RpY2FsICJxdWljayB3aW4iIHNvbHV0aW9ucyBhbmQg aW4gbm8gd2F5IHRyeWluZyB0byBkaW1pbmlzaCBjaGFsbGVuZ2VzIHRoYXQgYSBzbWFsbCBidXNp bmVzcyBvd25lciBtaWdodCBmYWNlIGluIHRoZXNlIGNpcmN1bXN0YW5jZXMuDQoNClRoaXMgaXMg d2hhdCBoYXBwZW5zIHdoZW4gb25lIGhhcyBkb25lIGlkbGUgdGltZSB3YWl0aW5nIGluIHRoZWly IGNhciBmb3IgdGhlaXIgZGF1Z2h0ZXIgdG8gY29tcGxldGUgc29tZSBBUCB0ZXN0cy4uLg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGF2ZSBDcm9ja2VyIFtkY3JvY2tlckBn bWFpbC5jb208bWFpbHRvOmRjcm9ja2VyQGdtYWlsLmNvbT5dDQpTZW50OiBTYXR1cmRheSwgSnVu ZSAwNywgMjAxNCAwODozMCBBTSBFYXN0ZXJuIFN0YW5kYXJkIFRpbWUNClRvOiBQb3Bvd3ljeiwg QWxleA0KQ2M6ICdETUFSQyBEaXNjdXNzaW9uJw0KU3ViamVjdDogUmU6IFtkbWFyYy1pZXRmXSBj b25mdXNpbmcgM3JkIHBhcnR5IHN1cHBvcnQgc28gaXQgcmVtYWlucyBvdXQNCg0KDQpPbiA2Lzcv MjAxNCAyOjE5IFBNLCBQb3Bvd3ljeiwgQWxleCB3cm90ZToNCj4gSSB0aGluayBJIG1heSBub3Qg YmUgdW5kZXJzdGFuZGluZyB0aGUgcHJvYmxlbS4gSW4gdGhlIHNpdHVhdGlvbiBjaXRlZA0KPiBi eSBEYXZlLCBzbWFsbC1idXNpbmVzc0B5YWhvby5jb20gd2FudHMgdG8gaGF2ZSBhbiBFU1Agc2Vu ZCBtYWlsIG9uIGl0cw0KPiBiZWhhbGYgdXNpbmcgdGhlIHNtYWxsIGJ1c2luZXNzIGRvbWFpbiAo aS5lLiBGUk9NOkBzbWFsbGJ1c2luZXNzLmNvbSkuDQoNCg0KRXllcyBhbmQgYnJhaW5zIGFyZSBz dWNoIGludGVyZXN0aW5nIGNyZWF0dXJlcy4gIFRoZXkgaGF2ZSAobWlub3IgcHVuKSBhDQptaW5k IG9mIHRoZWlyIG93bi4NCg0KV2hhdCB5b3UgY2l0ZSBpcyBub3Qgd2hhdCBJIHNwZWNpZmllZC4g IEkgc2FpZCBzbWFsbC1idXNpbmVzc0B5YWhvby5jb20uDQoNClRoYXQncyBiZWVuIHRoZWlyIGVt YWlsIGFkZHJlc3MgZm9yIHllYXJzLiAgSXQgaXMgdGhlaXIgb25saW5lIGlkZW50aXR5Lg0KIFRo ZXNlIGFyZSAvdmVyeS8gc21hbGwgYnVzaW5lc3MgZm9sayB3aXRoIHRpbnkgcmV2ZW51ZXMsIG5v IHRlY2huaWNhbA0Kc2tpbGxzLCBhbmQgYSBzdGFibGUgYnVzaW5lc3MuICBUaGVyZSBhcmUgcXVp dGUgYSBsYXJnZSBudW1iZXIgb2YgdGhlbQ0KaW4gdGhlIHdvcmxkLg0KDQpBbmQgdGhleSBuZWVk IHRoZSBzbWFsbGVzdCBkaXNydXB0aW9uIHBvc3NpYmxlIHRvIHRoZSBjb25kdWN0IG9mIHRoZWly DQpidXNpbmVzcyBsaWZlLg0KDQpBbmQgaW4gY2FzZSBhbnlvbmUgdGhpbmtzIHRoYXQgcmVjb21t ZW5kaW5nIHN3aXRjaGluZyB0byB0aGVpciBvd24NCmRvbWFpbiBuYW1lIGlzICJ0aGUiIGFuc3dl ciwgdGhhdCBpcyBhIHZlcnksIHZlcnkgbG9uZyB3YXkgZnJvbSBiZWluZyBhDQpzbWFsbCBkaXNy dXB0aW9uIGZvciBzdWNoIGZvbGsuDQoNClRoYXQncyB3aHkgSSBjYXN0IHRoZSBjaGFsbGVuZ2Ug b2YgdGhlIHNpdHVhdGlvbiBpbiB0aGUgd2F5IEkgb3JpZ2luYWwgZGlkLg0KDQpkLw0KLS0NCkRh dmUgQ3JvY2tlcg0KQnJhbmRlbmJ1cmcgSW50ZXJuZXRXb3JraW5nDQpiYml3Lm5ldA0K --_000_9495B91F5CA0E24C9161D71CD46E43DB011C8D48E078MSGRTPCCRF2_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPGh0bWw+ DQo8aGVhZD4NCjxtZXRhIG5hbWU9ImdlbmVyYXRvciIgY29udGVudD0iSFRNTCBUaWR5IGZvciBX aW5kb3dzICh2ZXJzIDI1IE1hcmNoIDIwMDkpLCBzZWUgd3d3LnczLm9yZyI+DQo8bWV0YSBodHRw LWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+ DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1TIEV4Y2hhbmdlIFNlcnZlciB2ZXJz aW9uIDA4LjAzLjAzMzAuMDAwIj4NCjx0aXRsZT5SZTogW2RtYXJjLWlldGZdIGNvbmZ1c2luZyAz cmQgcGFydHkgc3VwcG9ydCBzbyBpdCByZW1haW5zIG91dDwvdGl0bGU+DQo8L2hlYWQ+DQo8Ym9k eT4NCkFoaGgsIE9LLiBTbyBubyBkb21haW4gb3RoZXIgdGhhbiB5YWhvby5jb20gaW52b2x2ZWQu IEkgZG9uJ3QgYmVsaWV2ZSB5YWhvby5jb20gaGFkIHNldCBhIHN1YmRvbWFpbiBwb2xpY3kgc28g c21hbGwgYnVzaW5lc3MgY291bGQgaGF2ZSBFU1Agc2VuZCB1c2luZyBAc21hbGxidXNpbmVzcy55 YWhvby5jb20gd2l0aCBhIHJlcGx5IHRvIG9mIHlhaG9vLmNvbSwgb3Igc2ltcGxlIHNlbmQgdXNp bmcgdGhlIEVTUCdzIG93biBkb21haW4gd2l0aCB0aGUgc2FtZSByZXBseSB0byBhcyBhYm92ZT8g SSBrbm93IHRoZSBmaXJzdCBza2lydHMgdGhlIHByb2JsZW0gd2hpbGUgdGhlIHNlY29uZCBkb2Vz bid0IGFkZHJlc3MgY3VzdG9tZXJzIGhhdmluZyB3aGl0ZSBsaXN0ZWQgdGhlIG9yaWdpbmFsIGFk ZHJlc3MuIEknbSBqdXN0IHRoaW5raW5nIHByYWN0aWNhbCAicXVpY2sgd2luIiBzb2x1dGlvbnMg YW5kIGluIG5vIHdheSB0cnlpbmcgdG8gZGltaW5pc2ggY2hhbGxlbmdlcyB0aGF0IGEgc21hbGwg YnVzaW5lc3Mgb3duZXIgbWlnaHQgZmFjZSBpbiB0aGVzZSBjaXJjdW1zdGFuY2VzLjxicj4NCjxi cj4NClRoaXMgaXMgd2hhdCBoYXBwZW5zIHdoZW4gb25lIGhhcyBkb25lIGlkbGUgdGltZSB3YWl0 aW5nIGluIHRoZWlyIGNhciBmb3IgdGhlaXIgZGF1Z2h0ZXIgdG8gY29tcGxldGUgc29tZSBBUCB0 ZXN0cy4uLjxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KPGI+RnJv bTombmJzcDs8L2I+RGF2ZSBDcm9ja2VyIFs8YSBocmVmPSJtYWlsdG86ZGNyb2NrZXJAZ21haWwu Y29tIj5kY3JvY2tlckBnbWFpbC5jb208L2E+XTxicj4NCjxiPlNlbnQ6Jm5ic3A7PC9iPlNhdHVy ZGF5LCBKdW5lIDA3LCAyMDE0IDA4OjMwIEFNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZTxicj4NCjxi PlRvOiZuYnNwOzwvYj5Qb3Bvd3ljeiwgQWxleDxicj4NCjxiPkNjOiZuYnNwOzwvYj4nRE1BUkMg RGlzY3Vzc2lvbic8YnI+DQo8Yj5TdWJqZWN0OiZuYnNwOzwvYj5SZTogW2RtYXJjLWlldGZdIGNv bmZ1c2luZyAzcmQgcGFydHkgc3VwcG9ydCBzbyBpdCByZW1haW5zIG91dDxicj4NCjxicj4NCjwh LS0gQ29udmVydGVkIGZyb20gdGV4dC9wbGFpbiBmb3JtYXQgLS0+DQo8cD48Zm9udCBzaXplPSIy Ij5PbiA2LzcvMjAxNCAyOjE5IFBNLCBQb3Bvd3ljeiwgQWxleCB3cm90ZTo8YnI+DQomZ3Q7IEkg dGhpbmsgSSBtYXkgbm90IGJlIHVuZGVyc3RhbmRpbmcgdGhlIHByb2JsZW0uIEluIHRoZSBzaXR1 YXRpb24gY2l0ZWQ8YnI+DQomZ3Q7IGJ5IERhdmUsIHNtYWxsLWJ1c2luZXNzQHlhaG9vLmNvbSB3 YW50cyB0byBoYXZlIGFuIEVTUCBzZW5kIG1haWwgb24gaXRzPGJyPg0KJmd0OyBiZWhhbGYgdXNp bmcgdGhlIHNtYWxsIGJ1c2luZXNzIGRvbWFpbiAoaS5lLiBGUk9NOkBzbWFsbGJ1c2luZXNzLmNv bSkuPGJyPg0KPGJyPg0KPGJyPg0KRXllcyBhbmQgYnJhaW5zIGFyZSBzdWNoIGludGVyZXN0aW5n IGNyZWF0dXJlcy4mbmJzcDsgVGhleSBoYXZlIChtaW5vciBwdW4pIGE8YnI+DQptaW5kIG9mIHRo ZWlyIG93bi48YnI+DQo8YnI+DQpXaGF0IHlvdSBjaXRlIGlzIG5vdCB3aGF0IEkgc3BlY2lmaWVk LiZuYnNwOyBJIHNhaWQgc21hbGwtYnVzaW5lc3NAeWFob28uY29tLjxicj4NCjxicj4NClRoYXQn cyBiZWVuIHRoZWlyIGVtYWlsIGFkZHJlc3MgZm9yIHllYXJzLiZuYnNwOyBJdCBpcyB0aGVpciBv bmxpbmUgaWRlbnRpdHkuPGJyPg0KJm5ic3A7VGhlc2UgYXJlIC92ZXJ5LyBzbWFsbCBidXNpbmVz cyBmb2xrIHdpdGggdGlueSByZXZlbnVlcywgbm8gdGVjaG5pY2FsPGJyPg0Kc2tpbGxzLCBhbmQg YSBzdGFibGUgYnVzaW5lc3MuJm5ic3A7IFRoZXJlIGFyZSBxdWl0ZSBhIGxhcmdlIG51bWJlciBv ZiB0aGVtPGJyPg0KaW4gdGhlIHdvcmxkLjxicj4NCjxicj4NCkFuZCB0aGV5IG5lZWQgdGhlIHNt YWxsZXN0IGRpc3J1cHRpb24gcG9zc2libGUgdG8gdGhlIGNvbmR1Y3Qgb2YgdGhlaXI8YnI+DQpi dXNpbmVzcyBsaWZlLjxicj4NCjxicj4NCkFuZCBpbiBjYXNlIGFueW9uZSB0aGlua3MgdGhhdCBy ZWNvbW1lbmRpbmcgc3dpdGNoaW5nIHRvIHRoZWlyIG93bjxicj4NCmRvbWFpbiBuYW1lIGlzICJ0 aGUiIGFuc3dlciwgdGhhdCBpcyBhIHZlcnksIHZlcnkgbG9uZyB3YXkgZnJvbSBiZWluZyBhPGJy Pg0Kc21hbGwgZGlzcnVwdGlvbiBmb3Igc3VjaCBmb2xrLjxicj4NCjxicj4NClRoYXQncyB3aHkg SSBjYXN0IHRoZSBjaGFsbGVuZ2Ugb2YgdGhlIHNpdHVhdGlvbiBpbiB0aGUgd2F5IEkgb3JpZ2lu YWwgZGlkLjxicj4NCjxicj4NCmQvPGJyPg0KLS08YnI+DQpEYXZlIENyb2NrZXI8YnI+DQpCcmFu ZGVuYnVyZyBJbnRlcm5ldFdvcmtpbmc8YnI+DQpiYml3Lm5ldDxicj48L2ZvbnQ+PC9wPg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_9495B91F5CA0E24C9161D71CD46E43DB011C8D48E078MSGRTPCCRF2_-- From nobody Sat Jun 7 05:55:43 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D14E1A0351 for ; Sat, 7 Jun 2014 05:55:40 -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 w_alY2JE12kZ for ; Sat, 7 Jun 2014 05:55:39 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EEE01A034E for ; Sat, 7 Jun 2014 05:55:38 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id x13so1209270wgg.3 for ; Sat, 07 Jun 2014 05:55:30 -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=2J2QqE+X/YH743/tfImIZcF8u8stGquXc//2fju4mf8=; b=oQ7430o+ignN8R4GWl77pRThZCv42qe89rvdLnu6LjaQC8k33Q9yWGWY6+7yjWR/52 SpPmkk6vtbM5IPvCdkLZF9I2vOVv+Jm0SfXXWw+A62tYLrvVliJ/uCWKQtmKhPdjZ9Z1 7hK8jfqmaNxMwfN/Q3a5JSX4Cc5deJrZJ8Te3pIFgF3ewu08X8l/3gO/wpJRyhmGlaY1 T4f4Rac1iS4WtwUasHMTnomi3D5A8ihnSM+mK8FESsU9dKV0NTN/CgnBt1HsVeqh3x0u 7WYeSW/j+JzeJGCH/H17yuE4UUVXVackNwrIRPcCsFB9tiASEVi2I3zQSsldxz5O9EQn xmRQ== X-Received: by 10.14.203.199 with SMTP id f47mr1910255eeo.3.1402145730721; Sat, 07 Jun 2014 05:55:30 -0700 (PDT) Received: from ?IPv6:2a02:a03f:14c1:6600:e0ab:3885:4dd3:da36? ([2a02:a03f:14c1:6600:e0ab:3885:4dd3:da36]) by mx.google.com with ESMTPSA id i2sm30233515eem.11.2014.06.07.05.55.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Jun 2014 05:55:30 -0700 (PDT) Message-ID: <53930B8E.20009@gmail.com> Date: Sat, 07 Jun 2014 14:54:38 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Popowycz, Alex" References: <539305C2.6060805@gmail.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8D48E078@MSGRTPCCRF2WIN.DMN1.FMR.COM> In-Reply-To: <9495B91F5CA0E24C9161D71CD46E43DB011C8D48E078@MSGRTPCCRF2WIN.DMN1.FMR.COM> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/kRH7p_4abXZV_0kCgt9cfn2HBq8 Cc: 'DMARC Discussion' Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 07 Jun 2014 12:55:40 -0000 On 6/7/2014 2:48 PM, Popowycz, Alex wrote: > Ahhh, OK. So no domain other than yahoo.com involved. I don't believe > yahoo.com had set a subdomain policy so small business could have ESP > send using @smallbusiness.yahoo.com with a reply to of yahoo.com, or > simple send using the ESP's own domain with the same reply to as above? That would be a domain name change to the small business' online identity. Having Yahoo facilitate such a change might make the change a slight bit more tolerable, but ultimately, such a change is a very big deal for a very small business. It's called "branding costs". For small business, changing brand information is extremely expensive. > I know the first skirts the problem while the second doesn't address > customers having white listed the original address. I'm just thinking > practical "quick win" solutions and in no way trying to diminish > challenges that a small business owner might face in these circumstances. There is nothing quick or easy about the costs or effort in changing one's brand. > This is what happens when one has done idle time waiting in their car > for their daughter to complete some AP tests... There's probably a question about this on her test... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Jun 7 05:56:50 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20291A02C1 for ; Sat, 7 Jun 2014 05:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 UOHZuV3wWtYd for ; Sat, 7 Jun 2014 05:56:47 -0700 (PDT) Received: from nm49.bullet.mail.ne1.yahoo.com (nm49.bullet.mail.ne1.yahoo.com [98.138.120.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DF1D1A0076 for ; Sat, 7 Jun 2014 05:56:47 -0700 (PDT) Received: from [127.0.0.1] by nm49.bullet.mail.ne1.yahoo.com with NNFMP; 07 Jun 2014 12:56:39 -0000 Received: from [98.138.226.178] by nm49.bullet.mail.ne1.yahoo.com with NNFMP; 07 Jun 2014 12:53:39 -0000 Received: from [216.39.60.183] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 07 Jun 2014 12:53:39 -0000 Received: from [98.137.12.248] by tm19.bullet.mail.gq1.yahoo.com with NNFMP; 07 Jun 2014 12:53:39 -0000 Received: from [127.0.0.1] by omp1056.mail.gq1.yahoo.com with NNFMP; 07 Jun 2014 12:53:39 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 533498.16214.bm@omp1056.mail.gq1.yahoo.com Received: (qmail 79765 invoked by uid 60001); 7 Jun 2014 12:53:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402145619; bh=zhViE47TX7+QLvyR3UtedvqcrgnVRZayDvF4bzby58s=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=httlZS3YbabWYDSa2EF8ey7pFsmvWBX/HSBOPwWPaPIxuYk/88ukyHalocRMLDnLEVBv4bbmsQKSeQ99DQI/w2u842eSHnWn/0Lr0R6dbeCTKjlJZuTHJXEl0HhZCsKJmoJqdrXHuHDJI3/U/1mpDBx0ncQKq1FlawW+GHKfpH4= X-YMail-OSG: wn2RGQsVM1mAIqTs.3lKCMhNVEp8QR6O5IMRa5e9iIr7xku iypwbY0OPn2ZpIQqWDOFp9WIkvG6RLRwBZyYNGF5t.CDrpE2.ObQLyNCnIog mpapLO74VY2FOTuIP1rkiFEBJVB8JTupYx1YXob.OIAFCiz9OVgPh9CYExDe RZSmy793xSZarsjvyjRWsHNQB8mnQNamXjzYFWMfqzpDz70GlVXuucts3Qxy VlrdDgQ.bFIfdXz1Qjvby2KtKogFa79GF.H_v3O6lc2VhtwEkSgvY0MLbkDn ytjg9IsBdYr1RnhwQMsF89S.wo.tbweNZAvPW5FQfQLW92tFRCGH5UordLug NWZhyyOd8YOyIWuEwZU6b3DYLI8URaG.6RgasaV3cIwvFsILDrHlcSFwVAAW laIQvDpRLnYJkI6PNMmumZURvOTJbAAEI1SHGQwU.SvHIdq1AIWSS9S_ByYu RTG11.ZdVqcaxFqCQldPyGZlXJCk8lu.TDPUYaKBBKiFfj4dpALewUsR45t1 VkS3L6MFcRC.0naF5ftaZlneyFHVtI7letSnI7kJY4LMvBcgWLofXf.ULpPT 1GRwkZdmJW5zIpzi7pqadocpGA5PPYhrdQaCxXyg0dUtqFCiH2aFvFeV84ti 9 Received: from [79.175.112.242] by web164605.mail.gq1.yahoo.com via HTTP; Sat, 07 Jun 2014 05:53:39 PDT X-Rocket-MIMEInfo: 002.001, ZG91Z2xhcywKCgppIGhhdmUgc2VlbiB1ciB3b3JrIG9uIFRQQS1MYWJlbCBldmVyIHNpbmNlCkFEU1AsIGFuZCBpIG11c3QgYWRtaXQsIGl0IGxvb2tlZCBjb21wbGV4CmVub3VnaCB0byBjb3ZlciBhbG1vc3QgYW55dGhpbmcuCgpidXQsIGl0cyBjb21wbGV4aXR5IGlzIG5vdCB3b3JraW5nIGZvciB1LgppdCBzZWVtcyB0byBtZSB0aGF0IG1vc3Qgb2YgcHBsIHIgaWdub3JpbmcKdXIgcG9zdHMsIGFuZCBUUEEtTGFiZWwgY29tcGxldGVseS4KCm1heWJlIGl0IHdvdWxkIGhlbHAgaWYgdSBoYWQgYSB3b3JraW4BMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1402042491.15608.YahooMailNeo@web164601.mail.gq1.yahoo.com> <877g4u2ws4.fsf@uwakimon.sk.tsukuba.ac.jp> <1402063755.61291.YahooMailNeo@web164602.mail.gq1.yahoo.com> <9D1B33AF-A54C-4D2C-801B-2B39234E9132@gmail.com> Message-ID: <1402145619.3081.YahooMailNeo@web164605.mail.gq1.yahoo.com> Date: Sat, 7 Jun 2014 05:53:39 -0700 (PDT) From: Vlatko Salaj To: Douglas Otis In-Reply-To: <9D1B33AF-A54C-4D2C-801B-2B39234E9132@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ppuSPo7QXZ9boiNeEO9NPMg-q6Q Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 07 Jun 2014 12:56:49 -0000 douglas, i have seen ur work on TPA-Label ever since ADSP, and i must admit, it looked complex enough to cover almost anything. but, its complexity is not working for u. it seems to me that most of ppl r ignoring ur posts, and TPA-Label completely. maybe it would help if u had a working example, beyond draft specs txt. especially since txt isn't easy to digest. so, maybe it would help to create some graphs on its operations, and post them here, or even a working website testing tool, like Hector did with his proposal. actually, maybe both of u should work together into building something made from both of ur proposals. since i'm interested into adding 3rd party support to DMARC, i would be willing to help u two out. truth be told, considering that majority of DMARC developers don't care about our 3rd party requirements, having three separate proposals with little support for each is worse than getting one with a better support. consolidation of our efforts may be more fruitful. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Sat Jun 7 06:31:58 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2261A034E for ; Sat, 7 Jun 2014 06:31:53 -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 Nw3yRaxMVO56 for ; Sat, 7 Jun 2014 06:31:48 -0700 (PDT) Received: from secure.winserver.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 149081A0058 for ; Sat, 7 Jun 2014 06:31:47 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4089; t=1402147896; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=cqU0S9WeiSLXXgO1knpwsLhCtG0=; b=DctTwUTN4hs6UUj3XnLc gc+UdG7Ov3j+WDA4kXmwO4OLaavYD0kbznU61KH9+UkCJAQqjkMjhOKyVyDzmFuX s5BvrpSsEzfTFWpUzd7ZzTuWiAtdHcFFcJBMg9GWMwG7B7dn/L2voEs7r6EwVmiJ TWu8jqudVq1WfuHw3i5dz5E= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 07 Jun 2014 09:31: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; Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1628022159.6036.5940; Sat, 07 Jun 2014 09:31:35 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4089; t=1402147735; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=EIbnXWx z26b0uWlW6OYN84U+J7E1YXQMZSyTvS/6ftY=; b=QJGJKSo7R2Mhw4ofjmTWi1N 3VRNVReD+PBl37XwRX1SMpjPuUlmiuc7xq+2iMxDgibpFsOBcD2YRwCc7H93kjCz vIxpFq3q0WzqioMhP4uoiX8B7jDEb8zOzK36Df2sZuoMeqsl4mgDmeQzQzgG3XLD K0hxSbVz4CmYr/he+2xI= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 07 Jun 2014 09:28: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 1644382625.9.2964; Sat, 07 Jun 2014 09:28:54 -0400 Message-ID: <5393143B.9060109@isdg.net> Date: Sat, 07 Jun 2014 09:31: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: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <5392ECED.5010404@gmail.com> In-Reply-To: <5392ECED.5010404@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/nU84AnDTCYAdmPd39A8e7xLXv9o Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 07 Jun 2014 13:31:53 -0000 This idea is repeating the same thing again. What would "DKIM-Delegate compliant" systems do when the "new information" is missing? What do you do when there are protocol faults? What are the protocol faults? Mr Crocker, you have been leading the DKIM project since day one. You have always been opposed to policy mail handling concepts that includes rejection. Either you keep missing these essential finer protocol faults points or just don't believe they are important and nothing gets resolved for the resigner market. Your perspective for the DKIM model has only been on the GOOD side of things. The honor system when things are run perfect. But the market has long been telling us there were other functionalities to this. DKIM has also been about eliminating the bad using a verifiable mechanism and thus allows us to stream the potential good where you can do a "TRUST" assessment with the signer domain. But there wasn't an IETF endorsed answer in how to filter the bad. I really wish you would finally get that "Ah Ha" so that the entire DKIM project can finally get completed. We can't keep doing this half way wasting so much time. The DKIM-delegate idea is asking for "change" again, yet the change is unwilling to except the simplest change which is to simply lookup the originating site policy. So what is the problem? The idea of a lookup? A scalability issue? A management issue? The DKIM-delegate idea appears only to try to avoid doing a lookup, but conceptually it the same idea of authorizing 3rd party resigners. At best, it can serve as an optimizer, but only if the originator is aware of the potential resigner which the receiver will need to do more additional overhead to verify anyway. You are now asking for additional receiver complex overhead when the simplest one has already been available; a straight forward query based on the Author Domain Identity (ADID) and Signer Domain Identity (SDID): YesNo = IsSignerAllowed(ADID, SDID) If you are finally telling us to begin thinking this way, well good. I support it, but I don't see how DKIM-Delegate is going to address all the key protocol faults that has always plagued the DKIM project. -- HLS On 6/7/2014 6:43 AM, Dave Crocker wrote: > Folks, > > I've been stewing on this idea for awhile and Murray pressed to get it > into writing, adding his usual, significant enhancements to the original > concept. We've gone a couple of rounds before releasing it, but it's > still nascent enough to warrant gentle-but-firm handling. In other > words, comments eagerly solicited. > > d/ > > > -------- Original Message -------- > > Name: draft-kucherawy-dkim-delegate > Revision: 00 > Title: Delegating DKIM Signing Authority > Document date: 2014-06-07 > Group: Individual Submission > Pages: 10 > URL: > http://www.ietf.org/internet-drafts/draft-kucherawy-dkim-delegate-00.txt > Status: > https://datatracker.ietf.org/doc/draft-kucherawy-dkim-delegate/ > Htmlized: http://tools.ietf.org/html/draft-kucherawy-dkim-delegate-00 > > > Abstract: > DomainKeys Identified Mail (DKIM) permits a handling agent to affix a > digital signature to an email message, associating a domain name with > that message using cryptographic signing techniques. The digital > signature typically covers most of a message's original portions, > although the specific choices for content hashing are at the > discretion of the signer. DKIM signatures survive simply email > relaying but typically are invalidated by processing through > Mediators, such as mailing lists. For such cases, the signer needs a > way to indicate that a valid signature from some third party was > anticipated, and constitutes an acceptable handling of the message. > This enables a receiver to conclude that the content is legitimately > from that original signer, even though its original signature no > longer validates. > > This document defines a mechanism for improving the ability to assess > DKIM validity for such messages. > > > -- HLS From nobody Sat Jun 7 06:53:54 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC581A00C3 for ; Sat, 7 Jun 2014 06:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 klix00cVcqAk for ; Sat, 7 Jun 2014 06:53:42 -0700 (PDT) Received: from nm35.bullet.mail.gq1.yahoo.com (nm35.bullet.mail.gq1.yahoo.com [98.136.217.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 072121A006D for ; Sat, 7 Jun 2014 06:53:41 -0700 (PDT) Received: from [127.0.0.1] by nm35.bullet.mail.gq1.yahoo.com with NNFMP; 07 Jun 2014 13:53:34 -0000 Received: from [98.137.12.62] by nm35.bullet.mail.gq1.yahoo.com with NNFMP; 07 Jun 2014 13:50:53 -0000 Received: from [98.137.12.253] by tm7.bullet.mail.gq1.yahoo.com with NNFMP; 07 Jun 2014 13:50:53 -0000 Received: from [127.0.0.1] by omp1061.mail.gq1.yahoo.com with NNFMP; 07 Jun 2014 13:50:53 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 416798.9711.bm@omp1061.mail.gq1.yahoo.com Received: (qmail 71068 invoked by uid 60001); 7 Jun 2014 13:50:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402149053; bh=aUL9rBxvoXxjLS0IDDQXeAgX//s3l+MhqtoW09PAhus=; h=Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=DZYtazaOGW7whoPUKlP8eyvPDtIQGb1vWPZV7gRp8yKQSl6K/J8Ev1+ezWnH5tGPagc7haCYHtxiTdFIYS7xaedRS/q7byf1qSgYG34aJ1XhY/Lgc0Dj/E1wVYqRZIwg3xzkjlNZ0EnpwyKzU/f94CfxfPi7uunCczmwZFPTa9U= X-YMail-OSG: DqSbZgoVM1knHCoKcyJ2YKtr.5AYCplhFFr2YFESsjITk1w 0TcbaJdrcRfGD6yS0Mg_Dlfqt0xVcHbuagdLlwIv_XU4lizKBtRlDEyoSMZg 4Hdom1UrFsmcVfT9hK.uP7qqcHhuvLom9Go5EDFeHwUhlA_._wlG5Njcp2ny G7eeUxbGloPp.jYP2qL3qQ.lSshRCTHHonqUpjzsonkO54xMAMRz7Hf_UbuD 51tFywfaTR5MkXbnBUvprZrSqurfqDlhnA_a0F.JzwmGBHCiQ_ECdvrBmGiE 1KdIAFsZUgpi91sMT48iFWarLJWOhrT8v3SZtr6VtnRhLYwLc4IbMcxHGuOM 46sz0FHYLJOxtHrOPnEOe4xN5hf7Oy_HAvdUXkLbbjo96DqVmfmEp3OK.ZbV KS7Vkci9kpMReLKNN2HB4Y8XEnoJLjuNZ3knUkRsJ3BAon1MxcHDkc3L8Yhc 0aogUIdsIqiyuTtG7X2YTKKa1lNxiEpG3CS0h0nb6Smgyfzz3dAtcnfnwfNk YRjH1ukkV759NKOzsKLYqM1G__u0qIu1w3BgHwndtEJVYHdsqzHjYSgpB3zz WOoS.xAChrNpL_wDMXhNkcVALfZkjk5rxqZNAMzNrzGGUp95NgszHSVU4v8y F Received: from [79.175.112.242] by web164601.mail.gq1.yahoo.com via HTTP; Sat, 07 Jun 2014 06:50:53 PDT X-Rocket-MIMEInfo: 002.001, PiBJIGRvbid0IHNlZSBob3cgREtJTS1EZWxlZ2F0ZSBpcyBnb2luZyB0byBhZGRyZXNzIGFsbAo.IHRoZSBrZXkgcHJvdG9jb2wgZmF1bHRzIHRoYXQgaGFzIGFsd2F5cyBwbGFndWVkIHRoZcKgREtJTSBwcm9qZWN0LgoKaXQncyBub3QuIGl0J3MgYW5vdGhlciBoYWxmLWJha2VkIERLSU0gYWRkb24sIGluIGEgc2VhIG9mIG1hbnksCmludHJvZHVjZWQgdG8gcmVzb2x2ZSBNTCBzdXBwb3J0IGZvciBETUFSQy4gYmFyZWx5LgoKCnNlZW1zIG11cnJheSBhbmQgZGF2ZSBwdXNoZWQgaXQgb3V0IGF0IHRoaXMgdmUBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 Message-ID: <1402149053.45679.YahooMailNeo@web164601.mail.gq1.yahoo.com> Date: Sat, 7 Jun 2014 06:50:53 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/m4t1bImGn3J0tMjBJb-jnAGX9b4 Subject: Re: [dmarc-ietf] New Version Notification for draft-kucherawy-dkim-delegate-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 07 Jun 2014 13:53:51 -0000 > I don't see how DKIM-Delegate is going to address all=0A> the key protoco= l faults that has always plagued the=A0DKIM project.=0A=0Ait's not. it's an= other half-baked DKIM addon, in a sea of many,=0Aintroduced to resolve ML s= upport for DMARC. barely.=0A=0A=0Aseems murray and dave pushed it out at th= is very moment=0Ato divert attention and discussion from a more fully fledg= ed=0A3rd party DMARC alignment support calls.=0A=0Aespecially since i pushe= d some ppl on edge with my yesterday's=0Aranting about it.=0A=0Ai wouldn't = support all these DKIM addons, that r trying to fix=0Astuff in a particular= ly messy ways. it's just too messy.=0A=0A=0A-- =0A=0AVlatko Salaj aka goodo= ne=0Ahttp://goodone.tk From nobody Sat Jun 7 07:37:20 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124471A0096 for ; Sat, 7 Jun 2014 07:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.618 X-Spam-Level: X-Spam-Status: No, score=-4.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 F0OIi_j1HPGT for ; Sat, 7 Jun 2014 07:37:15 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15AD61A008E for ; Sat, 7 Jun 2014 07:37:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1402151828; x=1433687828; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=N5hVi5G8y+rTjlVA53tprHRRnnSZs/dNA0YtMQVX18w=; b=x2L7L/uHaILA1xcL68Z7Ej/saUb8wEqahy4TtrPGBHGy13V+NxkafUVT gmBRs6M5p3CzZvBgoCjcc+gioFx1GLR6CzCbtdXVgQzSnYAzTOVB1d+TP JPnbVZpT4trDRcWs1QvMTSKh1YuHBPafRe4i3heDFaXdJ4LyHfI3bIutn k=; X-IronPort-AV: E=Sophos;i="4.98,994,1392192000"; d="asc'?scan'208";a="126325485" Received: from esv4-exctest.linkedin.biz (172.18.46.60) by ESV4-HT01.linkedin.biz (172.18.46.235) with Microsoft SMTP Server (TLS) id 14.3.174.1; Sat, 7 Jun 2014 07:37:07 -0700 Received: from ESV4-MBX03.linkedin.biz ([fe80::14ba:eaea:c913:fa88]) by esv4-exctest.linkedin.biz ([::1]) with mapi id 14.03.0174.001; Sat, 7 Jun 2014 07:37:07 -0700 From: Franck Martin To: "Popowycz, Alex" Thread-Topic: [dmarc-ietf] confusing 3rd party support so it remains out Thread-Index: AQHPgJE8AJGm/ow150C/0rLKfClHLpti9olfgACCvgCAAAj6AIAAsLyAgAAaTYCAAEi4gIAAONaAgAAU4ACAAAZlgIAAC1IAgAASOgCAAAZMAIAADHWAgAC1IACAACRfAIAABaOAgAAP/oCAAAMKAIAABVQAgAAeNAA= Date: Sat, 7 Jun 2014 14:37:06 +0000 Message-ID: References: <539305C2.6060805@gmail.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8D48E078@MSGRTPCCRF2WIN.DMN1.FMR.COM> In-Reply-To: <9495B91F5CA0E24C9161D71CD46E43DB011C8D48E078@MSGRTPCCRF2WIN.DMN1.FMR.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.250] Content-Type: multipart/signed; boundary="Apple-Mail=_7473E086-92EA-4574-B255-5B7918AC2CA8"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/fXISerxhBjbQrkihoo_pDOdQInU Cc: Dave Crocker , DMARC Discussion Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 07 Jun 2014 14:37:17 -0000 --Apple-Mail=_7473E086-92EA-4574-B255-5B7918AC2CA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Yahoo has been suggesting the ESPs use OAUTH, so the small business = owner, can authorize the ESP to post on its behalf via yahoo servers=85 = Not sure if it is today possible, but there is a bunch of apps that has = been granted permission to post on Facebook, or Linkedin, or Google+ https://developer.yahoo.com/oauth/ https://developer.yahoo.com/mail/ I guess there was no need for ESP to do OAUTH, till now... And yes, even for small business, it is best to have a brand, which is = not yahoo.com. I suppose they have a website with their domain, tho for = very small businesses, I would recommend just redirecting to their = Facebook page... On Jun 7, 2014, at 2:48 PM, Popowycz, Alex = wrote: > Ahhh, OK. So no domain other than yahoo.com involved. I don't believe = yahoo.com had set a subdomain policy so small business could have ESP = send using @smallbusiness.yahoo.com with a reply to of yahoo.com, or = simple send using the ESP's own domain with the same reply to as above? = I know the first skirts the problem while the second doesn't address = customers having white listed the original address. I'm just thinking = practical "quick win" solutions and in no way trying to diminish = challenges that a small business owner might face in these = circumstances. >=20 > This is what happens when one has done idle time waiting in their car = for their daughter to complete some AP tests... >=20 --Apple-Mail=_7473E086-92EA-4574-B255-5B7918AC2CA8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJTkyOSAAoJEJHd9Bbysc+aRdsH/RZnflMffkpHlFv6pexnPz28 kPI8JJK/m1eFo2SBWIm7PssWhLfeKHrsL25hW17jL9YL0nO3c78Y5AJW31X0y7UV qgTI0GpNrpssfToP7AX23k3DquRDkNZocR7CvgRjBLqQUKzJsZTnHJ3aI3IJjFa6 ne0oDGHVX8rcIzE4/xqVToUJUGISnkwB6Lz2VLoNXqlPuj7o6jxwKpTzHFky3EZg Z18ShTWYcSXoU3T56qESI60922dgpUSEZ7L3zj1QYDef6BJ+KSkTuDycEc0G204T /MqhX005wHWn/Rhcwem8KASsDUbCnv2Wr+hTp8N7hWYs3b9AhTwCLrYX8Tmc1go= =UCGy -----END PGP SIGNATURE----- --Apple-Mail=_7473E086-92EA-4574-B255-5B7918AC2CA8-- From nobody Sat Jun 7 07:44:58 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925601A00C3 for ; Sat, 7 Jun 2014 07:44:54 -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 cJ-h0LgKimyB for ; Sat, 7 Jun 2014 07:44:48 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE7971A0074 for ; Sat, 7 Jun 2014 07:44:47 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id q59so4013648wes.38 for ; Sat, 07 Jun 2014 07:44:39 -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=UBLsLJsIEQqEH6CNLIr8CvPHCEmIhnSGog+6pjv5muc=; b=f65MgIzOjxNhjyrasuOsJ1rAsZ1mlODCAokYocI4eYxl8OFSyXclQxITSfF7A+j9tQ cUjZgH08C0++waew4lu2ZzAB5Mk/+z+0/4CQTBtbyxuqSQntNDdKfc1/cdBpxD577dRT 7KYKterYkuu4bueYcCexNNyCIWv7fXbvR3YkD8XOaccq4Mr2l9E06m0mPRSk1gMzO0oi rkMRHOoTi4LlL8IHVPmbvZYJy+3yOY/Xzt2/fgOSlyiZDCSmaLW9uMLmX2jpDb4NQAWU buakOH5QHmZjnbfFzF9a4VjyQKG7P6FdUjmWbO0h0i9VyTcQ94+gVCbapd5eq8rE0hpd x/Cw== X-Received: by 10.15.22.131 with SMTP id f3mr13659eeu.29.1402152279408; Sat, 07 Jun 2014 07:44:39 -0700 (PDT) Received: from ?IPv6:2a02:a03f:14c1:6600:e0ab:3885:4dd3:da36? ([2a02:a03f:14c1:6600:e0ab:3885:4dd3:da36]) by mx.google.com with ESMTPSA id 4sm30825488eeu.16.2014.06.07.07.44.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Jun 2014 07:44:38 -0700 (PDT) Message-ID: <53932523.4040004@gmail.com> Date: Sat, 07 Jun 2014 16:43:47 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Franck Martin , "Popowycz, Alex" References: <539305C2.6060805@gmail.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8D48E078@MSGRTPCCRF2WIN.DMN1.FMR.COM> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/3tUwd991-8yRO8DP08dMUoE7LV8 Cc: DMARC Discussion Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 07 Jun 2014 14:44:54 -0000 On 6/7/2014 4:37 PM, Franck Martin wrote: > Yahoo has been suggesting the ESPs use OAUTH, so the small business owner, can authorize the ESP to post on its behalf via yahoo servers… Not sure if it is today possible, but there is a bunch of apps that has been granted permission to post on Facebook, or Linkedin, or Google+ > > https://developer.yahoo.com/oauth/ > https://developer.yahoo.com/mail/ > > I guess there was no need for ESP to do OAUTH, till now... That might be an interesting line of capability to explore. > And yes, even for small business, it is best to have a brand, which is not yahoo.com. I suppose they have a website with their domain, tho for very small businesses, I would recommend just redirecting to their Facebook page... None of this helps the large and very installed base of on-going small businesses. And telling other businesses how to spend their scarce resources is probably not our job. On the average, things would always be better, if we did things in the distant past that anticipated unexpected changes in the distant future. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Jun 7 08:05:21 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8BC1A00E8 for ; Sat, 7 Jun 2014 08:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 Z4tE65ZoMm-4 for ; Sat, 7 Jun 2014 08:05:17 -0700 (PDT) Received: from nm32.bullet.mail.gq1.yahoo.com (nm32.bullet.mail.gq1.yahoo.com [98.136.217.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08D801A00D7 for ; Sat, 7 Jun 2014 08:05:17 -0700 (PDT) Received: from [127.0.0.1] by nm32.bullet.mail.gq1.yahoo.com with NNFMP; 07 Jun 2014 15:05:10 -0000 Received: from [98.137.12.188] by nm32.bullet.mail.gq1.yahoo.com with NNFMP; 07 Jun 2014 15:02:09 -0000 Received: from [98.137.12.193] by tm9.bullet.mail.gq1.yahoo.com with NNFMP; 07 Jun 2014 15:02:08 -0000 Received: from [127.0.0.1] by omp1001.mail.gq1.yahoo.com with NNFMP; 07 Jun 2014 15:02:08 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 839410.52263.bm@omp1001.mail.gq1.yahoo.com Received: (qmail 54248 invoked by uid 60001); 7 Jun 2014 15:02:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402153328; bh=JLLT9OR8ijqT38jsroQfAAtJD0S+gZMVVSiyM+S1+l0=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5FtlB1mnGFqKq42S9QA42u9dYGCHKN3PtpI7391woCrqCEDIO3Zr2H286IyRuO3wasnWCFHHJ+5jx+AJ51d4R/89EaPxb4U90hnBN9mF8ri09VIl5/OCeoycZOdgAgiyjM+MVyluq5VfGiQ1d0x3dBE/mkTARxG3sPdUeZ7N+Jg= X-YMail-OSG: txgslQcVM1lFmpd.KUr5l9QeIjo9vCPK9G6WMGX2DjHok7x ZYpCk4Omh7nm3if7t3ShjsNST5Z4qJTD0RRjOG578vM94CKnTAzTJJ3fRilp 8OL18T7lZk4UNzcC.UkkYduNiUKBIEhBfOICjSPvdvfi.3HBemVyfQsVHKQN zrLNq_ICZFNoExBM_kUyvRLU_26qw2gLzSxTioF_MKe0od5sbExQ.p6JsIJP R6Uxo4CzW87opiovq9rEE48b3geaMAntFzUO00ujBzXLnrkU.dHz5DPtZnf1 0hPCwBWbRO8KCdfj0Im85QHQCq6L.RdxIooUcyJdnQAZpMZ9g3FhyD3GgFCw O.q0g8Wgnk1fpHhq6rP66xsENQZP5.EH9aUH7vY6fq1tAcqBt4p8AzVo_MLi wPm6Seg9Gzb2NLnWv3KsjPP7BaRU7tezXkPBKaIDi4JWlH2aGe04p9EhpbrJ Spf2tnUEqjSEbda5AS5il0ZiZZTp5LrVjmhveqCCkIzOTR2FGIefHQjCvpFK D4nIBYbL5Q21xn_h9rQhxm5zTp7hUbXHAI3fzQpnuE4uHfh04kpxIL8IJWoj lp23RdBJats6cKqXupttqTF_.fZ4Gc2rnByPhYD3.ZqfWzdqc_hZAZ6gkWND z74f1CYLi4ieSYBiMirubypJXHSIH8RfMPGGtPEx1IIaqRm9L8dzRu2vapMn oFmeQMsy6PeC0NWjO7.wR7bOsKc0F58cZrTWwrskasj1Q7jHmmRPTf6EE3p9 CHYnudtJDv_G1eIW_7cUYYjxfdtySuORJ1bEbxakEJAg5zusrDjMU0d2FzvC bfxhWrsdDhaZdh4_5SD2c0oS8ZazvceS9dJgOaX2pu9VcGm5oxNXjMliQ3F3 7Jz7bK_o1juPp0rDi4E4- Received: from [79.175.112.242] by web164603.mail.gq1.yahoo.com via HTTP; Sat, 07 Jun 2014 08:02:08 PDT X-Rocket-MIMEInfo: 002.001, T24gU2F0dXJkYXksIEp1bmUgNywgMjAxNCAyOjI1IFBNLCBWbGF0a28gU2FsYWogPHZsYXRrby5zYWxhakBnb29kb25lLnRrPiB3cm90ZToKCgo.IGFueXdheSwgd2hhdCBpIHByb3Bvc2UgaXMgcXVpdGUgc2ltcGxlLCBwcmV0dHkgdHJpdmlhbAo.IGFuZCBlYXN5IHRvIGltcGxlbWVudCwgYWN0dWFsbHk6Cj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2RtYXJjL2N1cnJlbnQvbXNnMDA4MTMuaHRtbAoKCmNvbnNpZGVyIHRoaXMgZXhhbXBsZSBvZiBETUFSQyBETlMgcmVjb3JkIHRhZ3MBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <1402089514.72796.YahooMailNeo@web164603.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8D48E075@MSGRTPCCRF2WIN.DMN1.FMR.COM> <87y4x914s1.fsf@uwakimon.sk.tsukuba.ac.jp> <1402143903.18880.YahooMailNeo@web164602.mail.gq1.yahoo.com> <87vbsc24p8.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <1402153328.28071.YahooMailNeo@web164603.mail.gq1.yahoo.com> Date: Sat, 7 Jun 2014 08:02:08 -0700 (PDT) From: Vlatko Salaj To: "Stephen J. Turnbull" In-Reply-To: <87vbsc24p8.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/hWPBe4jlob0MMQTN6gN-mRUodq4 Cc: DMARC Discussion Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 07 Jun 2014 15:05:19 -0000 On Saturday, June 7, 2014 2:25 PM, Vlatko Salaj w= rote:=0A=0A=0A> anyway, what i propose is quite simple, pretty trivial=0A> = and easy to implement, actually:=0A> http://www.ietf.org/mail-archive/web/d= marc/current/msg00813.html=0A=0A=0Aconsider this example of DMARC DNS recor= d tags:=0A=0Aadkim=3Ds:author-domain,s:yahoo.com,n:gmail.com=0Aaspf=3Dr:aut= hor-domain,r:yahoo.com,n:gmail.com=0A=0A=0Aso, what i am proposing is chang= ing adkim and aspf DMARC tags so=0Athey become:=0A=0Aa comma-separated list= of "alignment-strength:domain" pairs, in which=0A=0A1. domains in colon pa= irs r 1st/3rd party domains author-domain=0Awants to align to or not,=0A=0A= 2. default is "r:author-domain", similar to way it is now [relaxed],=0Aand = can be left out completely, or partly, on any colon side,=0A=0A3. alignment= -strength can be n, r or s [none, relaxed or strict],=0Awhich beside the us= ual relaxed and strict alignment policy, adds=0Apossibility [n=3Dnone] to w= ithheld alignment from a domain=0A[as a countermeasure against a newly disc= overed abuse].=0A=0A=0Athe above example would read:=0A=0A1. request strict= dkim alignment for author-domain,=0A=0A2. request strict dkim alignment fo= r yahoo.com dkim signatures,=0A=0A3. request dkim alignment failure for gma= il.com dkim signature=0A[not rly needed if gmail.com isn't used for autor-d= omain's email,=0Abut a useful thing to combat new abuse and remove trust fr= om=0Apreviously trusted domain],=0A=0A4. request relaxed spf alignment for = author-domain and yahoo.com,=0A=0A5. and finally, request spf alignment fai= lure for gmail.com.=0A[same as 3.]=0A=0A=0Aalso, since relaxed and author-d= omain r defaults, we could do:=0Aaspf=3Dyahoo.com,n:gmail.com=0Ainstead of = previous example, with same results.=0A=0Aeven things like=0Aadkim=3Dyahoo.= com,ymail.com,gmail.com,mybrosdomain.com=0Awould be legitimate and would sp= ecify relaxed alignment policy=0Afor all listed domains.=0A=0A=0Aalso, sinc= e i'm proposing a change on DMARCv1 tags, any such=0Achange would essential= ly require DMARC advancing to v2,=0Abut i consider this appropriate action,= since it introduces=0Aprincipal differences in how basic operations [align= ment]=0Awork in DMARC.=0A=0A=0AOn Saturday, June 7, 2014 4:08 PM, Stephen J= . Turnbull wrote:=0A=0A> Unfortunately there's = no protocol in there, you leave it implicit. :-(=0A=0Alook up.=0A=0A=0A> Un= fortunately, AFAICS it doesn't address my needs (ie, MLMs), so I=0A> doubt = I will be able to find time to work through it and figure out=0A> what you'= re suggesting in concrete terms.=0A=0Aon small scales, like 1-15 ML-domains= , it can address those needs too.=0Abe free to spend ur time on it, if u fi= nd it interesting enough,=0Aand forget our hostility from yesterday. :D=0A= =0Asure, it won't fix yahoo's "p=3Dreject", since yahoo will not publish=0A= hundreds of ML-domains in their DMARC DNS record alignment list, but=0Ait w= ill fix other, smaller domains that use "p=3Dreject".=0A=0A=0A>> to domain-= owner's control, where it should be.=0A> I disagree with "where it should b= e".=A0 The receiver has ultimate say=0A> on what messages it will accept, w= hether for relay to third parties or=0A> local delivery (or even "silent di= scard").=0A=0Ain respect to DMARC policy, author-domain should have control= =0Aover who posts email on its behalf. that was my point. receivers=0Ashoul= d have nothing to do with that, no guesswork, in respect=0Ato DMARC, but th= ey r forced to do it now, going even as far to process=0A"p=3Dreject" as "p= =3Dquarantine".=0A=0Ai'm not talking about receivers' anti-spam and other p= olicies,=0Awe r not in that mailing list. however, i do see DMARC used in= =0Aanti-spam filters too, in the future... with troubling results.=0A=0A=0A= >> what u r proposing, Stephen, instead, is not at all trivial or easy=0A>>= to implement,=0A> Define "trivial" and "easy." Asking the ESP to handle al= l=0A> of SPF, DKIM, and DMARC for mail purporting to be from your=0A> domai= n is an obvious solution=0A=0Ayeah, well i don't define trivial and easy li= ke that. and i doubt=0Aany ESP will introduce something like that. it essen= tially changes=0Athe way they work now. i see no incentives for them to ada= pt to=0Athese requests.=0A=0Asure, i support them, be free to add my name t= o ur petition, but=0Ai'm sure it's a waste of our efforts.=0A=0A=0A>> nor d= oes it solve more than just my special use case.=0A> So what?=0A=0Aso, solu= tion fragmentation. there r better solutions that cover=0Amore stuff at onc= e, without any 3rd party involvement, which is=0Apreferential. it is also m= y principal viewpoint on life.=0A=0A=0A-- =0AVlatko Salaj aka goodone=0Ahtt= p://goodone.tk=0A From nobody Sat Jun 7 08:20:49 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA001A0125 for ; Sat, 7 Jun 2014 08:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 8MyE8uK7T3ai for ; Sat, 7 Jun 2014 08:20:45 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id 67CC71A011C for ; Sat, 7 Jun 2014 08:20:44 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 80EDC970B1E; Sun, 8 Jun 2014 00:20:37 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 94A991A3B83; Sun, 8 Jun 2014 00:20:35 +0900 (JST) From: "Stephen J. Turnbull" To: Vlatko Salaj In-Reply-To: <1402143903.18880.YahooMailNeo@web164602.mail.gq1.yahoo.com> References: <1402089514.72796.YahooMailNeo@web164603.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8D48E075@MSGRTPCCRF2WIN.DMN1.FMR.COM> <87y4x914s1.fsf@uwakimon.sk.tsukuba.ac.jp> <1402143903.18880.YahooMailNeo@web164602.mail.gq1.yahoo.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Sun, 08 Jun 2014 00:20:33 +0900 Message-ID: <87tx7w21by.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/TC-sS-Ebtj9mRUdADjDJcAyixbQ Cc: DMARC Discussion Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 07 Jun 2014 15:20:47 -0000 Vlatko Salaj writes: > > What I [== stephen] gather from Vlatko's posts is that there is a > > use case where an entity (eg, a small business; called "ENTITY" > > below) wants its own domain (called "OWNDOM" below) referenced in > > correspondence, but prefers not to maintain a single presence > > (even as a VPS) on the Internet. > > nope. OK, so it's not. The solutions I propose still work if you have a physical presence but *choose* not to use it to send mail, and Franck Martin says that ESPs are open to cooperation as required by a subset of those solutions. The only difference is that there *may* be issues of spoofing or losing mail that happens to be delivered directly from your personal MTA. I didn't want to make the effort to be *sure* so I chose a setting where it wasn't an issue. > i want DMARC to upgrade itself to be able to respect that. Please stop writing things like that. It's either a semantic null or a troll. Somebody has to do the work, RFCs don't write themselves. If you can't write a whole draft, at least write an outline of the parts of the protocol your idea requires. > http://www.ietf.org/mail-archive/web/dmarc/current/msg00813.html Now that's more like it! Unfortunately there's no protocol in there, you leave it implicit. :-( And you must have some new (undefined) forms of "alignment", as mail "From: vlatko.salaj@goodone.tk" can never satisfy DMARC identity alignment with yahoo.com credentials. Eg, what is being aligned" in (2)? Your "example" isn't a conforming DMARC record, in fact it even usurps existing protocol (that's a no-no, even if a spec is only at draft stage; it's not that hard to choose a new name, and adjust nomenclature whan publishing a new draft). Finally, the post is full of minor inaccuracies, like writing "Sender-ID instead of SPF" when Sender-ID depends on SPF. Unfortunately, AFAICS it doesn't address my needs (ie, MLMs), so I doubt I will be able to find time to work through it and figure out what you're suggesting in concrete terms. > also, it's easier than VBR, ATPS, TPA, TPA-Label, and moves > trouble of authorizing legitimate email from receivers' > error-prone, DMARC-policy-disrespecting, essential > whitelisting to domain-owner's control, where it should be. I disagree with "where it should be". The receiver has ultimate say on what messages it will accept, whether for relay to third parties or local delivery (or even "silent discard"). > what u r proposing, Stephen, instead, is not at all trivial or easy > to implement, Huh? Define "trivial" and "easy." Technically speaking, AFAICS DKIM signing in the MUA is a SMOP (and in fact it can easily be done outside of the MUA but on the same host as the MUA by a separate application), many users with a personal domain can handle setting DMARC and DKIM resources, and I see no reason why ESPs would alter the signed portion of a message. If the user *can't* handle setting those resources or your preferred ESP insists on corrupting your messages, asking the ESP to handle all of SPF, DKIM, and DMARC for mail purporting to be from your domain is an obvious solution, and if the ESP goes rogue or has a security breach compromising your private keys, you delete the authorizing resources from your DNS. > nor does it solve more than just my special use case. So what? It's easy to implement and solves a use case that must be fairly common out there. Get real, man -- you're bitching *because* it solves your use case?! From nobody Sat Jun 7 08:59:39 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767C11A034A; Sat, 7 Jun 2014 05:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 vTh4qiZv9Kw9; Sat, 7 Jun 2014 05:40:59 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 299251A0349; Sat, 7 Jun 2014 05:40:59 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id p10so1903780wes.37 for ; Sat, 07 Jun 2014 05:40:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=vmCfXqRpTCWvYsiVjLKK4liizIAMDyL9xnIDoiNri58=; b=ll6P0H8177Gw0SHxzKmkQmjrJWV8iAAtxTWbxW32qXAPeUfG/Gizgecb07SdIxEr5v s+OTBy7uzswyg39FDBbpKkzqSS8S4NpXQ7D+Njy9m5++1dZh/FYfnOz92VQjjsXG90K+ Lqg8gPzAJCPtLxCvAe4/bn8sHzVcnMbh1aygsJIX76xqwDJ6ENs0ltvmyAGF1/VaUW4t PvmtTmW3S2aR9nRwe587ssu1d1WI6oQXindX4WmrGW4S5Ms2BKcuh1B2gNeIYHnVw8qP Zq8WaEv7R55qh1GP05cizoD1S6DxzsnkRlRNyYyZmMmL9MZ2IEoZO6+AobEo4pqTIHA/ TLGw== MIME-Version: 1.0 X-Received: by 10.194.24.36 with SMTP id r4mr15619732wjf.39.1402144850866; Sat, 07 Jun 2014 05:40:50 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.79.136 with HTTP; Sat, 7 Jun 2014 05:40:50 -0700 (PDT) Date: Sat, 7 Jun 2014 08:40:50 -0400 X-Google-Sender-Auth: pbYUnUZyAVHRU6iilUhvmSG255g Message-ID: From: Phillip Hallam-Baker To: Hector Santos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/beoK4I5pcqz-swAq1IITRZbj5_w X-Mailman-Approved-At: Sat, 07 Jun 2014 08:59:38 -0700 Cc: "dmarc@ietf.org" , IETF , Dave Crocker , "Fred Baker \(fred\)" Subject: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 07 Jun 2014 12:41:00 -0000 On Sat, May 3, 2014 at 2:08 PM, Hector Santos wrote: > Let me ask, what if a fedex.com employee use this email domain for > subscribing to the IETF list? Any subsequent problems are irrelevant unless FedEx, the owner of fedex.com considers them to be relevant. That is what folk complaining don't get: you don't have the right to use your employers email or a public email provider's email any way you want. The domain name owner makes the rules. As Craster insists: My domain, my rules. If you want to make the rules then get your own domain. I think that is something most IETF participants know how to do. In the medium term, lets kill the stupidity of mailing lists with a protocol that works. NNTP was originally designed to replace mailing lists. It actually works quite well at that. The only problem was the IT-Dictator mindset that underlies it: newsgroups have to be approved by the Commune! The idea that newsgroups work by the mail client PULLING a list of unread messages and then PULLING those that are to be read is the best architecture for newsgroups. I am currently using 8Gb of my primary Gmail account space, 80% of that is my mailing list mail. Google and Yahoo could both save tens of millions of dollars worth of hard drives a year with a better protocol, thats incentive to invest. The only points that need to change are the mailing list programs need to offer a very simple network API and the clients need to accept it. The second is not so difficult to deploy for the 90% of webmail users. From nobody Sat Jun 7 09:15:36 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FCF1A0360 for ; Sat, 7 Jun 2014 09:15:19 -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 Jl0t8X9NyORw for ; Sat, 7 Jun 2014 09:15:13 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.93]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7CFF1A0152 for ; Sat, 7 Jun 2014 09:15:12 -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.0.974.2; Sat, 7 Jun 2014 15:59:44 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.234]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.234]) with mapi id 15.00.0974.002; Sat, 7 Jun 2014 15:59:44 +0000 From: Terry Zink To: DMARC Discussion Thread-Topic: [dmarc-ietf] confusing 3rd party support so it remains out Thread-Index: AQHPgJE6rlU6oPjaZ0S7HmZV2XZY+5ti9o5jgAANYACAAAj7AIAAsLuAgAAaTYCAAEi4gIAAONeAgAAU4ACAAAZlgIAAC1EAgAASOgCAAAZMAIAADHWAgAC1IQCAACRfgIAAUZGi Date: Sat, 7 Jun 2014 15:55:31 +0000 Message-ID: <1402156561426.74028@exchange.microsoft.com> References: <1402089514.72796.YahooMailNeo@web164603.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8D48E075@MSGRTPCCRF2WIN.DMN1.FMR.COM> <87y4x914s1.fsf@uwakimon.sk.tsukuba.ac.jp>, <70B0B4F4-FA27-43F6-AE1E-68455EE5D194@linkedin.com> In-Reply-To: <70B0B4F4-FA27-43F6-AE1E-68455EE5D194@linkedin.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.172.11.235] x-exchange-antispam-report-test: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0235CBE7D0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(189002)(199002)(24454002)(377454003)(51704005)(79102001)(97336001)(74502001)(77982001)(95666003)(21056001)(31966008)(101416001)(74662001)(64706001)(49866002)(47446003)(94316002)(54356002)(94946001)(92726001)(85306002)(97186001)(53806002)(50986002)(54316003)(81342001)(93516002)(69226001)(92566001)(74706001)(80022001)(76796001)(66066001)(74876001)(81816001)(76482001)(46102001)(81686001)(51856002)(65816002)(77096001)(76786001)(83072002)(74366001)(4396001)(99396002)(85852003)(87936001)(2656002)(47976003)(87266001)(47736002)(63696004)(83322001)(93886002)(19580395003)(98676001)(19580405001)(93136001)(20776003)(81542001)(56776002)(56816006)(59766002)(95416001)(90146001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2SR01MB605; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/4l2deE1SlQtXqemh9Bb2nkUJu5Y Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 07 Jun 2014 16:15:20 -0000 > We (people with p=3Dreject) went to all well known ESPs =0A= > and asked them to send our emails with SPF and DKIM =0A= > alignment with our domain.=0A= =0A= I did the same thing with microsoft.com (not every domain or brand at Micro= soft, just microsoft.com). It took me six months. I'm going to be giving a = talk about this at the Virus Bulletin conference in Seattle this September.= =0A= =0A= -- Terry=0A= =0A= ________________________________________=0A= From: dmarc on behalf of Franck Martin =0A= Sent: Saturday, June 07, 2014 4:01 AM=0A= To: Stephen J. Turnbull=0A= Cc: Vlatko Salaj; Popowycz, Alex; DMARC Discussion; Talamo, Victor=0A= Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out=0A= =0A= On Jun 7, 2014, at 10:51 AM, Stephen J. Turnbull wrote= :=0A= =0A= > Popowycz, Alex writes:=0A= >> Vlatko=0A= >=0A= > Please don't feed the trolls (including me, I'm regretting my role=0A= > in this thread). There's work to be done here, and Vlatko seems=0A= > uninterested in helping with it (eg, when asked for specific=0A= > references, he says "I'm not a search engine").=0A= >=0A= > What I gather from Vlatko's posts is that there is a use case where an=0A= > entity (eg, a small business; called "ENTITY" below) wants its own=0A= > domain (called "OWNDOM" below) referenced in correspondence, but=0A= > prefers not to maintain a single presence (even as a VPS) on the=0A= > Internet. Instead, ENTITY uses an ESP (below, "ESP" denotes=0A= > aparticular ESP) to send and receive mail, and ESP provides the usual=0A= > set of authentication services for its host. The need is to provide=0A= > credentials and an authentication protocol for mailboxes in OWNDOM=0A= > that will satisfy identity alignment, and all actors will voluntarily=0A= > participate.=0A= =0A= Stephen,=0A= =0A= We (people with p=3Dreject) went to all well known ESPs and asked them to s= end our emails with SPF and DKIM alignment with our domain. They all have b= een able to do it, tho some (especially account reps) did not know what DMA= RC meant :P=0A= =0A= So I think requesting an ESP to do SPF and DKIM using your domain is not im= possible, I think the issue, is a problem of scale at the moment. Few have = =93press a button=94 solution, and it is still a manual configuration, but = I suspect, they will scale from manual to automatic setup to support any do= main DMARC policies as more customers request the features.= From nobody Sat Jun 7 09:39:13 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D431A007E for ; Sat, 7 Jun 2014 09:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 lprajzHrhUIX for ; Sat, 7 Jun 2014 09:39:08 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA921A0081 for ; Sat, 7 Jun 2014 09:39:07 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 957C9970B37; Sun, 8 Jun 2014 01:39:00 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id B0D471A3B83; Sun, 8 Jun 2014 01:38:58 +0900 (JST) From: "Stephen J. Turnbull" To: Phillip Hallam-Baker In-Reply-To: References: X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Sun, 08 Jun 2014 01:38:56 +0900 Message-ID: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/zc5AujFkBbhWUDWTkEFQUzCC26w Cc: "dmarc@ietf.org" Subject: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 07 Jun 2014 16:39:09 -0000 I'm not sure what the long list of addressees was about, but I'm not comfortable with them. Feel free to repost my message if you wish. Phillip Hallam-Baker writes: > In the medium term, lets kill the stupidity of mailing lists with a > protocol that works. NNTP was originally designed to replace mailing > lists. GNU Mailman is thinking about this for Mailman 3. Of course we've long had a mostly functional mail-to-news bidrectional gateway, but Mailman 3 is considering adding NNTP capability directly to the bundled archiver, or perhaps a separate facility resembling an archiver as far as Mailman core is concerned.[1] I don't think this has gone anywhere yet, though. > It actually works quite well at that. The only problem was the > IT-Dictator mindset that underlies it: newsgroups have to be > approved by the Commune! Nonsense. I don't know what the problem that prevented netnews from obsoleting mailing lists is, but the alt hierarchy has always been available, and GMane proves that you can run a whole alternative NNTP network without trouble and with a reasonable amount of resources. So it's not the Cabal's fault (by the way, there is no cabal, in case you haven't heard). > I am currently using 8Gb of my primary Gmail account space, 80% of > that is my mailing list mail. Google and Yahoo could both save tens of > millions of dollars worth of hard drives a year with a better > protocol, thats incentive to invest. I suspect that's part of the reason for *groups. Regards, Footnotes: [1] Not in the core, because it doesn't have and shouldn't grow a message store beyond the in-process queues. From nobody Sat Jun 7 09:48:59 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3732F1A0084 for ; Sat, 7 Jun 2014 09:48:58 -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 mybvHchL-b-C for ; Sat, 7 Jun 2014 09:48:56 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9182B1A0081 for ; Sat, 7 Jun 2014 09:48:56 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id m15so4035424wgh.8 for ; Sat, 07 Jun 2014 09:48:48 -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=ALvx8ZzxT22030t1Rw+BnSCwry+D1NgzmUcdaEJtHmA=; b=Gqx9T/lW5g+paPIGQHjE76DJ5BPH9+qC44+MOSbRAD2jyYwCM731rWffjvBsd5XV5Q SdJpAQDEoZMbv1lqwqMzlnuCepRhGanhAD6qJCHgbCjNzvsuafkKhnT2PCvg2+LHCuiH Mx5oJeHJRE18dsKbtaguzZmnW1pB6jBzfBaNLufplnf4wzv4Cflq0WP92IkUx5V8ZNqT W5JSiu+21DY3C6aDz2G3KWdjCqePZOTh7lpsbadfZzP2z8pjnWI/lXZBg8jTKaC+2Mk4 I53UtI+DLpd/x+pJI5sky15K7dH1cCuwJeweUJeytVyUZQl7Iy2NFhDNMapk3erdv1md pAUQ== X-Received: by 10.14.194.136 with SMTP id m8mr596320een.4.1402159728358; Sat, 07 Jun 2014 09:48:48 -0700 (PDT) Received: from ?IPv6:2a02:a03f:14c1:6600:e0ab:3885:4dd3:da36? ([2a02:a03f:14c1:6600:e0ab:3885:4dd3:da36]) by mx.google.com with ESMTPSA id a1sm31484758eep.3.2014.06.07.09.48.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Jun 2014 09:48:47 -0700 (PDT) Message-ID: <5393423A.2000806@gmail.com> Date: Sat, 07 Jun 2014 18:47:54 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Stephen J. Turnbull" References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/TQSyUMgs44M8p9dE2oUQs8qs74E Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 07 Jun 2014 16:48:58 -0000 On 6/7/2014 6:38 PM, Stephen J. Turnbull wrote: > I don't know what the problem that prevented netnews from > obsoleting mailing lists is At base, netnews and mailing lists are entirely different kinds of human communication services. The critical construct that highlights the difference is: subscriptions. Really, the participation and scaling characteristic differences between bulletin boards -- which are essentially broadcast -- versus mailing lists -- which are multicast, are huge. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Jun 7 09:55:47 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFEA21A0103 for ; Sat, 7 Jun 2014 09:55:45 -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 RugLredd3Lg1 for ; Sat, 7 Jun 2014 09:55:43 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58A31A00DD for ; Sat, 7 Jun 2014 09:55:42 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id x48so1367302wes.11 for ; Sat, 07 Jun 2014 09:55:34 -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=qtcPfm3uG+6hfuq3WWCDZxYsXE4Qo+mAkIdbq84H5+c=; b=YRNoeovU7DBSHgXGdpJE9EGFcRMFJyud5ZEtLAB6evFl7R3pqqvB/Y51u4JsJMdXbx hfHwpLnVKk4Y+INMPRFVd+82OCXh2sN+f1vX45rUR/4IzkmhA6l8EeghGYg7fX4aKvEV S53SA0lzAI58cVIORNy/sEBmkAxqbQC0gegyLgDi63nhF2EXuJyI3adE/Sie60x0n4NO Wx4d8EN/1Iy/xyWlASR1DkZ8QNRUWQnwr1Br0awGu81xcZTn4t9PYcDyjjg5+0T+snq9 ahv0LoQkp0fa39Zz7+f07sNtywjDSD8meU+7LS4wlYVVzzez0Aho/LjwEDk63uWl3d5X K9bw== MIME-Version: 1.0 X-Received: by 10.194.161.168 with SMTP id xt8mr17108298wjb.35.1402160134613; Sat, 07 Jun 2014 09:55:34 -0700 (PDT) Received: by 10.180.23.104 with HTTP; Sat, 7 Jun 2014 09:55:34 -0700 (PDT) In-Reply-To: <1402145619.3081.YahooMailNeo@web164605.mail.gq1.yahoo.com> References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1402042491.15608.YahooMailNeo@web164601.mail.gq1.yahoo.com> <877g4u2ws4.fsf@uwakimon.sk.tsukuba.ac.jp> <1402063755.61291.YahooMailNeo@web164602.mail.gq1.yahoo.com> <9D1B33AF-A54C-4D2C-801B-2B39234E9132@gmail.com> <1402145619.3081.YahooMailNeo@web164605.mail.gq1.yahoo.com> Date: Sat, 7 Jun 2014 09:55:34 -0700 Message-ID: From: "Murray S. Kucherawy" To: Vlatko Salaj Content-Type: multipart/alternative; boundary=089e01419c6abdf2f904fb41d858 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/zfkjvcF9pbDCSK2tsWszSGN0-js Cc: "dmarc@ietf.org" , Douglas Otis Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 07 Jun 2014 16:55:46 -0000 --089e01419c6abdf2f904fb41d858 Content-Type: text/plain; charset=UTF-8 On Sat, Jun 7, 2014 at 5:53 AM, Vlatko Salaj wrote: > > truth be told, considering that majority of > DMARC developers don't care about our > 3rd party requirements, having three separate > proposals with little support for each is > worse than getting one with a better support. > > I can't speak for anyone other than myself, but I'd bet that a third party mechanism that scales and is relatively painless to add on would get proper consideration. So far none of the ones that have been proposed, including my own, have gotten the necessary traction; that could be because they're flawed, or they're not being communicated or demonstrated well, or a combination of those. That's not the same as "don't care", which I think is an unfair and untrue claim. > consolidation of our efforts may be more > fruitful. > I fully agree that's worth trying. -MSK --089e01419c6abdf2f904fb41d858 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Jun 7, 2014 at 5:53 AM, Vlatko Salaj <vlatk= o.salaj@goodone.tk> wrote:

truth be told, considering that majority of
DMARC developers don't care about our
3rd party requirements, having three separate
proposals with little support for each is
worse than getting one with a better support.


I can't speak for anyone other tha= n myself, but I'd bet that a third party mechanism that scales and is r= elatively painless to add on would get proper consideration.=C2=A0 So far n= one of the ones that have been proposed, including my own, have gotten the = necessary traction; that could be because they're flawed, or they'r= e not being communicated or demonstrated well, or a combination of those.= =C2=A0 That's not the same as "don't care", which I think= is an unfair and untrue claim.
=C2=A0
consolidation of our efforts may be more
fruitful.

I fully agree that's wort= h trying.

-MSK
--089e01419c6abdf2f904fb41d858-- From nobody Sat Jun 7 10:01:21 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91A31A00B0 for ; Sat, 7 Jun 2014 10:01:18 -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 BJe4uUbda4iP for ; Sat, 7 Jun 2014 10:01:17 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52FD31A00A2 for ; Sat, 7 Jun 2014 10:01:17 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id k48so4199430wev.3 for ; Sat, 07 Jun 2014 10:01: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=H+sb4l97ITIuxpOLC9WihCi7h5nobL8B+Q9fJ+h+enI=; b=WpUoKzGbYoTBMArCevkHD0hzq+tlpNND/p1QJ/0Tk7NCRCZ0n83tnjyj+IGo0q62nq K7PT3uRnxKaUBPw99NA2mu15vkeOEfwDVgkL9D5/vw81AkMgNAo4mnuF4ay5AjKmxe7o gGCPbqBUTDmqJrJPxvD7p08OvSkyTM7Jlu3X8qjzHT6Zn3SbhuPPDzdHotZVc+WRRIxc S0ocSVzhGJ3xlUYdVVxDfrjj7/V88h+zq6QHbwvvoh/HTCQCq04REfoUfAZnAOcacD2J OvaeAQqJcookOATISTdBYR/PEhz2RpCb3zqdWA4grBR3TvGZOPOBd6Z9XOQRDMmnLdpI POwg== MIME-Version: 1.0 X-Received: by 10.194.89.168 with SMTP id bp8mr17008593wjb.73.1402160469277; Sat, 07 Jun 2014 10:01:09 -0700 (PDT) Received: by 10.180.23.104 with HTTP; Sat, 7 Jun 2014 10:01:09 -0700 (PDT) In-Reply-To: <1402149053.45679.YahooMailNeo@web164601.mail.gq1.yahoo.com> References: <1402149053.45679.YahooMailNeo@web164601.mail.gq1.yahoo.com> Date: Sat, 7 Jun 2014 10:01:09 -0700 Message-ID: From: "Murray S. Kucherawy" To: Vlatko Salaj Content-Type: multipart/alternative; boundary=047d7bf10a1cb0851804fb41eca9 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/kHQqf6H9YLnwsJggYyR0IzLF9X4 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] New Version Notification for draft-kucherawy-dkim-delegate-00.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, 07 Jun 2014 17:01:19 -0000 --047d7bf10a1cb0851804fb41eca9 Content-Type: text/plain; charset=UTF-8 On Sat, Jun 7, 2014 at 6:50 AM, Vlatko Salaj wrote: > > seems murray and dave pushed it out at this very moment > to divert attention and discussion from a more fully fledged > 3rd party DMARC alignment support calls. > > We're all brainstorming about solutions here. There's nothing wrong with proposing another one when the ones we have so far have failed to gain traction. What's in this draft was proposed elsewhere. I just took the time to put it into draft form so people could see the whole proposal in a more formal way rather than a bunch of separate mailing list posts. And finally, I would appreciate it if the accusations of personal agendas stopped. That's the second one today in this thread. -MSK --047d7bf10a1cb0851804fb41eca9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Jun 7, 2014 at 6:50 AM, Vlatko Salaj <vlatk= o.salaj@goodone.tk> wrote:

seems murray and dave pushed it out at this very moment
to divert attention and discussion from a more fully fledged
3rd party DMARC alignment support calls.


We're all brainstorming about solu= tions here.=C2=A0 There's nothing wrong with proposing another one when= the ones we have so far have failed to gain traction.

Wh= at's in this draft was proposed elsewhere.=C2=A0 I just took the time t= o put it into draft form so people could see the whole proposal in a more f= ormal way rather than a bunch of separate mailing list posts.

And finally, I would appreciate it if the accusat= ions of personal agendas stopped.=C2=A0 That's the second one today in = this thread.

-MSK
--047d7bf10a1cb0851804fb41eca9-- From nobody Sat Jun 7 10:17:24 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85BDE1A00F2 for ; Sat, 7 Jun 2014 10:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 StHcZDBXj4Lh for ; Sat, 7 Jun 2014 10:17:22 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id A0C641A00A2 for ; Sat, 7 Jun 2014 10:17:21 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id D9FA6970B37; Sun, 8 Jun 2014 02:17:13 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id CC2321A3B83; Sun, 8 Jun 2014 02:17:12 +0900 (JST) From: "Stephen J. Turnbull" To: Vlatko Salaj In-Reply-To: <1402153328.28071.YahooMailNeo@web164603.mail.gq1.yahoo.com> References: <1402089514.72796.YahooMailNeo@web164603.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8D48E075@MSGRTPCCRF2WIN.DMN1.FMR.COM> <87y4x914s1.fsf@uwakimon.sk.tsukuba.ac.jp> <1402143903.18880.YahooMailNeo@web164602.mail.gq1.yahoo.com> <87vbsc24p8.fsf@uwakimon.sk.tsukuba.ac.jp> <1402153328.28071.YahooMailNeo@web164603.mail.gq1.yahoo.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Sun, 08 Jun 2014 02:17:10 +0900 Message-ID: <87r4301vxl.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/eVBelcuyYs0bei0HtFQs2uP6Y50 Cc: DMARC Discussion Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 07 Jun 2014 17:17:23 -0000 Vlatko Salaj writes: > so, what i am proposing is changing adkim and aspf DMARC tags so > they become: > > a comma-separated list of "alignment-strength:domain" pairs, in which OK, I understand now. This probably doesn't solve the mailing list problem, especially since you'll run into the UDP size limit real fast (your protocol will use a *lot* of octets for domain names), and I doubt domains with a lot of wear and tear on their nameservers will be happy about using TCP (my employer's nameservers don't accept TCP queries from me, at least). > > Unfortunately, AFAICS it doesn't address my needs (ie, MLMs), so I > > doubt I will be able to find time to work through it and figure out > > what you're suggesting in concrete terms. > > on small scales, like 1-15 ML-domains, it can address those needs > too. 1-15 MLs? I subscribe to about 30. I think this is only going to be useful for personal domains with 1-3 users, and even then there will be many the way overtretch the practical bounds. > in respect to DMARC policy, author-domain should have control > over who posts email on its behalf. that was my point. But in reality it does not and never will. It can't stop posting from hosts outside of its control at all. It can ask other domains to help enforce its policy when they receive such messages, but they may not. For a benign example, consider a honeypot feeding data about mail abuse to a research project or a machine learning algorithm. > receivers should have nothing to do with that, no guesswork, in > respect to DMARC, but they r forced to do it now, going even as far > to process "p=reject" as "p=quarantine". Nobody is *forced* to do any such thing. Eg, Gmail *chooses* to treat "p=reject" as advisory, we know that *some* messages that should be rejected according to DMARC do get through to the recipient (at least to the spam folder). They do this not because they hate Yahoo!, but because they think that is what will please their users without doing Gmail any hard. *This is as it should be.* Other domains silently discard (my personal domain, which no longer has any yahoo users among senders it wants to hear from), and I know a few ML operators who have seriously considered doing the same even though they do have posters from Yahoo! or AOL. > yeah, well i don't define trivial and easy like that. and i doubt > any ESP will introduce something like that. Once again, you are not paying attention. Franck Martin testifies that he knows of many ESPs willing to make necessary adjustments, and who are already doing so. From nobody Sat Jun 7 10:27:28 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C991A00B2 for ; Sat, 7 Jun 2014 10:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.618 X-Spam-Level: X-Spam-Status: No, score=-4.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 hLmmphDqxruO for ; Sat, 7 Jun 2014 10:27:23 -0700 (PDT) Received: from esv4-mav04.corp.linkedin.com (esv4-mav04.corp.linkedin.com [69.28.149.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFAD71A00A2 for ; Sat, 7 Jun 2014 10:27:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1402162037; x=1433698037; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fM+cFU5+cfOYWK7W+bxZ7oByi8y2LhgczvMLI3odX/E=; b=05co9NrWtG511wleFj6OHjtQA/7bR5HzZl/Cr3alaAoH64AkqrqHeQEN cbIjn58csxCL8CZinM1yhmTVYo8HQbgnk3YMGRDUIef2XceyquVA49Dc1 jBhPoG/t0Ser5XGMcaXMpMcwR/br+v7YFlSacKTJ4+uoYT7ADxqsODtiV A=; X-IronPort-AV: E=Sophos;i="4.98,995,1392192000"; d="asc'?scan'208";a="126334755" Received: from ESV4-MBX03.linkedin.biz ([fe80::14ba:eaea:c913:fa88]) by ESV4-HT01.linkedin.biz ([::1]) with mapi id 14.03.0174.001; Sat, 7 Jun 2014 10:27:16 -0700 From: Franck Martin To: Dave Crocker Thread-Topic: [dmarc-ietf] confusing 3rd party support so it remains out Thread-Index: AQHPgJE8AJGm/ow150C/0rLKfClHLpti9olfgACCvgCAAAj6AIAAsLyAgAAaTYCAAEi4gIAAONaAgAAU4ACAAAZlgIAAC1IAgAASOgCAAAZMAIAADHWAgAC1IACAACRfAIAABaOAgAAP/oCAAAMKAIAABVQAgAAeNACAAAHggIAALasA Date: Sat, 7 Jun 2014 17:27:16 +0000 Message-ID: <594B88A3-E8A5-487A-8698-3D08AF8B758B@linkedin.com> References: <539305C2.6060805@gmail.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8D48E078@MSGRTPCCRF2WIN.DMN1.FMR.COM> <53932523.4040004@gmail.com> In-Reply-To: <53932523.4040004@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.251] Content-Type: multipart/signed; boundary="Apple-Mail=_3F629DDA-E545-46E1-952B-BF64BD5E9C28"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/1jA3GO6hhNEc-_GbfEQbAIeQY8M Cc: "Popowycz, Alex" , DMARC Discussion Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 07 Jun 2014 17:27:25 -0000 --Apple-Mail=_3F629DDA-E545-46E1-952B-BF64BD5E9C28 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jun 7, 2014, at 4:43 PM, Dave Crocker wrote: > On 6/7/2014 4:37 PM, Franck Martin wrote: >> Yahoo has been suggesting the ESPs use OAUTH, so the small business = owner, can authorize the ESP to post on its behalf via yahoo servers=85 = Not sure if it is today possible, but there is a bunch of apps that has = been granted permission to post on Facebook, or Linkedin, or Google+ >>=20 >> https://developer.yahoo.com/oauth/ >> https://developer.yahoo.com/mail/ >>=20 >> I guess there was no need for ESP to do OAUTH, till now... >=20 > That might be an interesting line of capability to explore. Waiting for the first ESP that thinks it has a business case here. >=20 >> And yes, even for small business, it is best to have a brand, which = is not yahoo.com. I suppose they have a website with their domain, tho = for very small businesses, I would recommend just redirecting to their = Facebook page... >=20 > None of this helps the large and very installed base of on-going small > businesses. And telling other businesses how to spend their scarce > resources is probably not our job. Well it is. the DMARC.org has a FAQ and the IETF (WG?) is writing a BCP.=20= However I like to provide options. Solutions that work today, and = solutions that work tomorrow. Seriously getting a domain and getting yahoo to host it is not that = expensive, I think USD10-35 a year=85 https://smallbusiness.yahoo.com/email It is just, nobody has written what exactly works in that path, and = small businesses do not like to experiment. Anybody could provide some = guidance here? A step by step transition guide? >=20 > On the average, things would always be better, if we did things in the > distant past that anticipated unexpected changes in the distant = future. >=20 Did you just watch X-Man: Days of future past? --Apple-Mail=_3F629DDA-E545-46E1-952B-BF64BD5E9C28 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJTk0tzAAoJEJHd9Bbysc+aW+AIAIcf7N3ENyPZMe7Hc210fpIk eFGp/sj0TvTxQ3Ardzw7xQdd16PpXf026jwSB0I68i13PlfrcYWTzycifSlQV0LU VbYpQWO9EGpq6ekM1K8ifpmNK9SkG42LA7yjcZ2M3F2uEmY0lxf8cDdYxUjhXGcF WUKGSOlesysEd1691t6KKSDk8tXChtiGSVDPhi2EafxeF3SBP2oRLxb3i3n+rLHe bye8NxMt4J3qPgFiQ1jkr0ESB25Tl4++Lx2/6tZVf4mvVHG3q3F+o1hs8NekCqEa mEdurK2cvR/EZNnm3/Pg+OO3xNopL8cbCKliQiVhmfCF5mmCuVPPLtmZ1M/vXoc= =1ACH -----END PGP SIGNATURE----- --Apple-Mail=_3F629DDA-E545-46E1-952B-BF64BD5E9C28-- From nobody Sat Jun 7 10:35:38 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184911A0104 for ; Sat, 7 Jun 2014 10:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.48 X-Spam-Level: X-Spam-Status: No, score=-100.48 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_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 DvMZiVMCFTqt for ; Sat, 7 Jun 2014 10:35:32 -0700 (PDT) Received: from mail.catinthebox.net (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 516FC1A00F2 for ; Sat, 7 Jun 2014 10:35:32 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=9853; t=1402162521; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=QjvgfiH0hMpFpkNXv2sxizSvJeE=; b=licaSlXq70AaQFKt9WTz R+JZBjWz2LyM79iVz5OjYrV3J3VW99BIJi1R6l5HF/e7ZAGLt/3/QvDt/hWsvZLQ 9JI2LgrapU3+h/DltwMnJVzkdoEWXLnPuJgIT3JhxfbGvLkPa7GMY5/MJae3P9Cv AiSoGEIDhPSEMvGum1zSYK4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 07 Jun 2014 13:35: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; Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1642647596.6036.3972; Sat, 07 Jun 2014 13:35:21 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=9853; t=1402162362; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=mmP4Ml+ a+4RPz/0e9MLeVyz+LwVXGyc9kFvNqZQWEQQ=; b=wvOHkRTJI6z9ZJjjdBuXbiw T1eN7/ZMO7QOMTzd1cc46Ts+byLzfFkuKETRnkbJqFU0QmMzdUfX4GkFoIwF6Lev Zj7wsRAbgcVytfnV3F7LAChhXf8TT5lD5o9eYBIJOFRLdHnY6ylEqIsuNsl3D8aY O1l7orwN+UayzPK8hDuE= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 07 Jun 2014 13:32:41 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1659008187.9.3472; Sat, 07 Jun 2014 13:32:40 -0400 Message-ID: <53934D5D.1030903@isdg.net> Date: Sat, 07 Jun 2014 13:35:25 -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: "Stephen J. Turnbull" , Vlatko Salaj References: <1402089514.72796.YahooMailNeo@web164603.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8D48E075@MSGRTPCCRF2WIN.DMN1.FMR.COM> <87y4x914s1.fsf@uwakimon.sk.tsukuba.ac.jp> <1402143903.18880.YahooMailNeo@web164602.mail.gq1.yahoo.com> <87tx7w21by.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87tx7w21by.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/z3yP8QNcwW8A16UJw8HxbUlU7VQ Cc: DMARC Discussion Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 07 Jun 2014 17:35:35 -0000 Stephen, I hope the DMARC List moderators/chairs recognized your antagonistic "first strike" responses to concerned comments here. It isn't helpful. This is a long time issue and I have been there since day one, since MARID when all these integrated design concepts and issues began. I don't recall your early participation in this but there is deep history in all this. But thats ok. Welcome to the problem!! :) Generally people get involve when they begin to see something effect them. It did with me in 2003 when the SORBIG infamous dual blitz (DoS RBL sites, Accept/Bounce attack the receivers) came and SMTP developers saw we finally needed to add something into our software to help operators. Do you know what our first support answer was? To enable their existing but optional SMTP feature: [_] Validate Local Recipient You see, when people switched from UUCP/SLIP/UUCICO hosting methods to SMTP transports, the early versions do not have a RCPT TO validation process. So all mail was accepted and it was your existing internal import gateway that did the user delivery check. If not there, the mail gateway created a bounce to be sent out. So the first support fix for very concern SORBIG suffering ESPs, ISPS, and all domains, was to tell them to enable the local user validate checks. By doing this check at RCPT TO, you can potentially save 40% to 60% DNS overhead, wasted processing of all new DNS-based email security protocols. I have 11 years of consistent and persistent automated daily statistics recorded here: http://www.winserver.com/SpamStats This has always been a basic client/server negotiated protocol engineer "lookup" discovery problem. For DKIM, the solution was outlined in 9+ years of IETF work which does covers ALL client/servers situations. That was the goal. The feasibility of this was a concern and it depended on who it was applicable to. But overall, it was about the dealing with the BAD, the GOOD and the UGLY. Many administrators and list operators only wish to do deal with the good. There is a long traditional to be "fail-safe", i.e accept all mail and let the user decide. Thats been long understood but it only serves one part of the market needs. Increasingly, the need for deterministic methods at the system level, not at the user level was becoming more apparent. Again, as a SOFTWARE DEVELOPER, you have to cater to all market needs. The IETF has to address two fundamental protocol engineering issues: LAYER #1: DKIM signature authorization protocol, and LAYER #2: DKIM signature trust/reputation protocol. This was done in all the R&D, RFC work done. The threats, the optimizations, the expected short term overheads and redundancy issues were all considered. In the short term, you should expect a high waste, high redundancy and network latency, performance issues with higher NXDOMAIN lookup results and early migration recommended paths of using relaxed Policies. But in the long term with higher expected adoption, there would be some greater payoffs, efficacy, efficiency realized, especially as the domains migrated and got their network in order and began to switch over stronger policies. This was ALL expected and it didn't begin with DKIM, it began with SPF. It also had the same issues of scalability, network performance, nxdomain, relaxed vs strong policies design concerns. But as expected and it took years for domains, but many did finally switch their SPF policy to the hardfail -ALL policy. As it was predicted, we have the same dilemma with DKIM now. It is yet another philosophical, wasteful discussion on the merits having strong signature policies. This concept has long been resolved by the market. It is a highly desirable feature and idea to be able to take control of your domain again. As it was done with SPF, over time, the private domains, the higher value domains, began to use SPF -ALL policies, even the IETF is telling the world only their machines send out @ietf.org related mail: "v=spf1 ip4:12.22.58.0/24 ip6:2001:1890:123a::/56 ip4:64.170.98.0/24 ip6:2001:1890:126c::/56 ip4:4.31.198.32/27 ip6:2001:1900:3001:0011::0/64 ip4:209.208.19.192/27 ip6:2607:f170:8000:1500::0/64 ip4:72.167.123.204 -all" As you can understand, you technically do not need DMARC to process this SPF parameter and is highly inefficient with a high payload overhead if DMARC told implementators not to process SPF or wait until the DATA state is reaches in order to receive the 5322 payload overhead to get the Author Domain DMARC policy first to only to see if, for sure, the domain has a "p=reject." Do you understand why the SUBMITTER protocol was invented for SENDER-ID? Well, all these ideas apply because they all dealt with the same kind of 5321 vs 5322 implementation issues. DMARC can have a similar optimizer for SPF: C: MAIL FROM: dmarc=(p=reject; ruf=dmarc-ruf); This could tell the OPTIMIZED RECEIVER thats ok to reject before DATA is reached, even though the SPF -ALL already tells you its ok. The "DMARC friendly" integrated difference is that it can tell the receiver to collect and send reports. Etc, etc, etc. The whole point, the IETF has long lost time in the entire DKIM+POLICY framework and its about time it gets serious about it (again). Only with IETF endorsement will it begin to get wider adoption within the market. The IETF job's is to enable it. Let them the implementations and deployments learn how to manage the DNS records and eventually come back and write a BCP for it or come up with a better DNS query concept. Where do you end up with all this? When do you actually begin to explore the proposed solutions that are technically sound? There is software change cost. But the framework is sound. Have you tried ADSP/ATPS or DMARC with ATPS updated for DMARC instead? -- HLS On 6/7/2014 11:20 AM, Stephen J. Turnbull wrote: > Vlatko Salaj writes: > > > > What I [== stephen] gather from Vlatko's posts is that there is a > > > use case where an entity (eg, a small business; called "ENTITY" > > > below) wants its own domain (called "OWNDOM" below) referenced in > > > correspondence, but prefers not to maintain a single presence > > > (even as a VPS) on the Internet. > > > > nope. > > OK, so it's not. The solutions I propose still work if you have a > physical presence but *choose* not to use it to send mail, and Franck > Martin says that ESPs are open to cooperation as required by a subset > of those solutions. > > The only difference is that there *may* be issues of spoofing or > losing mail that happens to be delivered directly from your personal > MTA. I didn't want to make the effort to be *sure* so I chose a > setting where it wasn't an issue. > > > i want DMARC to upgrade itself to be able to respect that. > > Please stop writing things like that. It's either a semantic null or > a troll. Somebody has to do the work, RFCs don't write themselves. > If you can't write a whole draft, at least write an outline of the > parts of the protocol your idea requires. > > > http://www.ietf.org/mail-archive/web/dmarc/current/msg00813.html > > Now that's more like it! > > Unfortunately there's no protocol in there, you leave it implicit. :-( > And you must have some new (undefined) forms of "alignment", as mail > "From: vlatko.salaj@goodone.tk" can never satisfy DMARC identity > alignment with yahoo.com credentials. Eg, what is being aligned" in > (2)? Your "example" isn't a conforming DMARC record, in fact it even > usurps existing protocol (that's a no-no, even if a spec is only at > draft stage; it's not that hard to choose a new name, and adjust > nomenclature whan publishing a new draft). Finally, the post is full > of minor inaccuracies, like writing "Sender-ID instead of SPF" when > Sender-ID depends on SPF. > > Unfortunately, AFAICS it doesn't address my needs (ie, MLMs), so I > doubt I will be able to find time to work through it and figure out > what you're suggesting in concrete terms. > > > also, it's easier than VBR, ATPS, TPA, TPA-Label, and moves > > trouble of authorizing legitimate email from receivers' > > error-prone, DMARC-policy-disrespecting, essential > > whitelisting to domain-owner's control, where it should be. > > I disagree with "where it should be". The receiver has ultimate say > on what messages it will accept, whether for relay to third parties or > local delivery (or even "silent discard"). > > > what u r proposing, Stephen, instead, is not at all trivial or easy > > to implement, > > Huh? Define "trivial" and "easy." Technically speaking, AFAICS DKIM > signing in the MUA is a SMOP (and in fact it can easily be done > outside of the MUA but on the same host as the MUA by a separate > application), many users with a personal domain can handle setting > DMARC and DKIM resources, and I see no reason why ESPs would alter the > signed portion of a message. > > If the user *can't* handle setting those resources or your preferred > ESP insists on corrupting your messages, asking the ESP to handle all > of SPF, DKIM, and DMARC for mail purporting to be from your domain is > an obvious solution, and if the ESP goes rogue or has a security > breach compromising your private keys, you delete the authorizing > resources from your DNS. > > > nor does it solve more than just my special use case. > > So what? It's easy to implement and solves a use case that must be > fairly common out there. Get real, man -- you're bitching *because* > it solves your use case?! > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > -- HLS From nobody Sat Jun 7 11:08:41 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06F11A016E for ; Sat, 7 Jun 2014 11:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 Xf7SAkS--BOF for ; Sat, 7 Jun 2014 11:08:38 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id E32081A014D for ; Sat, 7 Jun 2014 11:08:37 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 3DCF4970B1E; Sun, 8 Jun 2014 03:08:30 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 490B21A3B83; Sun, 8 Jun 2014 03:08:28 +0900 (JST) From: "Stephen J. Turnbull" To: Dave Crocker In-Reply-To: <5392ECED.5010404@gmail.com> References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <5392ECED.5010404@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Sun, 08 Jun 2014 03:08:26 +0900 Message-ID: <87ppik1tk5.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/EBQr9uk4Stx78Vhe5CjVd0OcXYY Cc: "dmarc@ietf.org" Subject: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 07 Jun 2014 18:08:39 -0000 Dave Crocker writes: > URL: > http://www.ietf.org/internet-drafts/draft-kucherawy-dkim-delegate-00.txt Merry Christmas for mailing lists! Mailman at least already recommends that sites hosting lists DKIM sign, so we have nothing new to do! Two nits to pick. First, I'd like a whole (sub)section (containing approximately one sentence :-) for Mediator responsibilities, even if it's redundant with step 4 of the specification. Maybe a subsection of section 5 (Discussion)? Second, from the draft: The expiration time on the Secondary signature needs to be long enough to permit evaluation by receivers of the re-submitted message, yet short enough to limit the potential for unauthorized replay attacks. A good choice is a small number of days or even hours. Due to greylisting (I've seen a message that got greylisted twice, once at the mailing list and once at the recipient), I'd recommend that the absolute minimum for expiration time be 12 hours, and that at least 24 hours be recommended. From nobody Sat Jun 7 12:09:43 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E061A01C8 for ; Sat, 7 Jun 2014 12:09:42 -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 22LbwwMpGKCM for ; Sat, 7 Jun 2014 12:09:40 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9E551A01BD for ; Sat, 7 Jun 2014 12:09:39 -0700 (PDT) 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, 7 Jun 2014 21:09:30 +0200 Message-ID: <9529BCDA5AC34DC694173FD43EB7E71F@fgsr.local> From: "J. Gomez" To: Dave Crocker References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <5392ECED.5010404@gmail.com> Date: Sat, 7 Jun 2014 21:09:45 +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: http://mailarchive.ietf.org/arch/msg/dmarc/qaT-WM-06vbA-eBdv5-GDgwvXQo Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Fwd: New Version Notification fordraft-kucherawy-dkim-delegate-00.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, 07 Jun 2014 19:09:42 -0000 On Saturday, June 07, 2014 12:43 PM [GMT+1=3DCET], Dave Crocker wrote: > Folks, >=20 > I've been stewing on this idea for awhile and Murray pressed to get it > into writing, adding his usual, significant enhancements to the > original concept. We've gone a couple of rounds before releasing it, > but it's still nascent enough to warrant gentle-but-firm handling.=20 > In other=20 > words, comments eagerly solicited. Hello, I have this comment: What do you think are the probabilities that = YAHOO/AOL, etc, would go through the trouble of identifying and = declaring the many third parties needed to be allowed to DKIM re-sign = their messages, so that YAHOO/AOL users could painlessly post to mailing = lists in a world where DMARC happened to be widely deployed? Regards, J.Gomez From nobody Sat Jun 7 12:15:36 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4EB1A01C8 for ; Sat, 7 Jun 2014 12:15:34 -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 bxJcrG-bBmZM for ; Sat, 7 Jun 2014 12:15:33 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D6BA1A01BD for ; Sat, 7 Jun 2014 12:15:33 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id bs8so2495325wib.6 for ; Sat, 07 Jun 2014 12:15:25 -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=du8crPuRrqFk80lOHkXK3wOjJhLpyEnmDfGiNGRJnkc=; b=sK5NKhap0gif2R4mNWNEvgzJXpHGfBSlE9n2puUF1w8ciCXxad1HBG36ZlLSgFgt4b JX2GxTpOjl+KR4rQRJC6cXUfgre8pdn1C1IAILGF84jnGzF9jrcw4ueuNX3GvCeXK+LO P/Mlty2ih1JzZaFp3gKxg/O0B9vvHd9vGSegFWLWN7TiruYGOVY59aCgDbGejr3Qnmo/ 3unrhTT6U1Yig5dfOyP420gnN/lbNljmz2wqzQube1Dw3Qr3PxmW4PhtI0gEDytbQYwf D98Thhnv3DUZpU9ffGlBx7Kp6Y+3Wu6oADr9EZWFfQkJV6j7pFOSIQ+dfqBAPid3SDz0 fEVQ== X-Received: by 10.14.113.136 with SMTP id a8mr2384901eeh.0.1402168525097; Sat, 07 Jun 2014 12:15:25 -0700 (PDT) Received: from ?IPv6:2a02:a03f:14c1:6600:e0ab:3885:4dd3:da36? ([2a02:a03f:14c1:6600:e0ab:3885:4dd3:da36]) by mx.google.com with ESMTPSA id y8sm10636985eef.5.2014.06.07.12.15.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Jun 2014 12:15:24 -0700 (PDT) Message-ID: <53936498.6030505@gmail.com> Date: Sat, 07 Jun 2014 21:14:32 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "J. Gomez" References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <5392ECED.5010404@gmail.com> <9529BCDA5AC34DC694173FD43EB7E71F@fgsr.local> In-Reply-To: <9529BCDA5AC34DC694173FD43EB7E71F@fgsr.local> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/9QdUAvQdVS4pWSySr6b5bpTcClQ Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Fwd: New Version Notification fordraft-kucherawy-dkim-delegate-00.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, 07 Jun 2014 19:15:34 -0000 On 6/7/2014 9:09 PM, J. Gomez wrote: > Hello, I have this comment: What do you think are the probabilities that YAHOO/AOL, etc, would go through the trouble of identifying and declaring the many third parties needed to be allowed to DKIM re-sign their messages, so that YAHOO/AOL users could painlessly post to mailing lists in a world where DMARC happened to be widely deployed? The spec imposes no such requirement. So I've no idea how your comment applies to the document. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Jun 7 13:58:47 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313831A01DD for ; Sat, 7 Jun 2014 13:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.009 X-Spam-Level: ** X-Spam-Status: No, score=2.009 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 ttRfezPJZVlq for ; Sat, 7 Jun 2014 13:58:44 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id B41A11A01DC for ; Sat, 7 Jun 2014 13:58:43 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 12D4B970B2A; Sun, 8 Jun 2014 05:58:36 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 5FA2F11F87D; Sun, 8 Jun 2014 05:58:35 +0900 (JST) From: "Stephen J. Turnbull" To: Hector Santos In-Reply-To: <53934D5D.1030903@isdg.net> References: <1402089514.72796.YahooMailNeo@web164603.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8D48E075@MSGRTPCCRF2WIN.DMN1.FMR.COM> <87y4x914s1.fsf@uwakimon.sk.tsukuba.ac.jp> <1402143903.18880.YahooMailNeo@web164602.mail.gq1.yahoo.com> <87tx7w21by.fsf@uwakimon.sk.tsukuba.ac.jp> <53934D5D.1030903@isdg.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Sun, 08 Jun 2014 05:58:33 +0900 Message-ID: <87oay41lom.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/EckA3WaDMqlbGWl5a-eXlyIIbW0 Cc: Vlatko Salaj , DMARC Discussion Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 07 Jun 2014 20:58:46 -0000 Hector Santos writes: > This is a long time issue and I have been there since day one, I haven't participated in IETF discussions before. But my personal site was abused as an open relay in 1995 because Smail 100.something advertised a no-relay config option but didn't implement it (so I had to, while apologizing to a large number of pissed-off postmasters), and I have a Zumabot T-Shirt. > Again, as a SOFTWARE DEVELOPER, you have to cater to all market > needs. I disagree. Software developers cater to the needs they want to, including both pure good will and for-profit reasons for wanting to. In this venue, many of us *want* to see protocols that work for everybody all the time. Me too. However, as a MLM developer, I have to say that in practice, the 9+ years of IETF engineering work has dismally failed to achieve universal inclusion. Both SPF and DKIM marginalize mailing lists because they relegate them to world of unauthenticatable traffic. In practice, too, software developers regularly fail to satisfy some of the market's needs. Does that mean y'all owe us a pony? It does not. In today's Internet, much as I hate to admit it, Mailman-style lists are a bit marginal. On the other hand, the Kucherawy-Crocker dkim-delegate draft looks like a way forward for mailing lists, and I don't understand why you and Vlatko feel the need to deprecate it in such strong terms. > As it was predicted, we have the same dilemma with DKIM now. It is > yet another philosophical, wasteful discussion on the merits having > strong signature policies. I don't have a problem with strong signatures. I do have a problem with the way existing protocols marginalize mailing lists. I do have a problem with the way DMARC "p=reject" can be abused and interfere with mailing list traffic among other classes of email. I think there are valid reasons for worrying about the potential negative effects of strong policies especially if they try to mandate rejecting mail before the DATA transaction, and I disagree that: > This concept has long been resolved by the market. It is a highly > desirable feature and idea to be able to take control of your > domain again. in the sense that as desirable as it may be, for the vast majority of mailboxes, it probably cannot be implemented without losing a lot of mail and perhaps having other unfortunate effects (eg, the thousands of mailing list subscriptions that were disabled or even terminated due to Yahoo! bounces). And I doubt the average Yahoo! user would be pleased to understand the full meaning of "control" as implied by that domain's "p=reject" policy. So AFAICS these "strong policies" remain as controversial as ever, and progress is going to have to be made in small steps. DMARC, IMHO, was a remarkably big step by this criterion (but then, it has built on a lot of experience of failed or marginal proposals). > As it was done with SPF, over time, the private domains, the higher > value domains, began to use SPF -ALL policies, even the IETF is > telling the world only their machines send out @ietf.org related > mail: > > "v=spf1 ip4:12.22.58.0/24 ip6:2001:1890:123a::/56 > ip4:64.170.98.0/24 ip6:2001:1890:126c::/56 > ip4:4.31.198.32/27 ip6:2001:1900:3001:0011::0/64 > ip4:209.208.19.192/27 ip6:2607:f170:8000:1500::0/64 > ip4:72.167.123.204 -all" Sure. I can't imagine why (except for fear of Murphy) anybody would publish anything else. (Well, actually I can, but I don't think that discussion is particularly useful.) What I don't agree with is using *only* the information about source IP and SPF policy as a spam filter in a store and forward architecture with mediators. And I think this idea has been completely rejected by the market (as opposed to blacklisting known spam source IPs, and using SPF policy and source IP as one datum among several for assessing abusiveness of a message). Are there really sites out there that reject on the basis of SPF -ALL without waiting for DATA? I for one could not use such a host. > This could tell the OPTIMIZED RECEIVER thats ok to reject before DATA > is reached, even though the SPF -ALL already tells you its ok. Well, no, in the real world SPF -ALL *doesn't* tell you that. It tells you that you can trust those hosts for traffic claiming to be from the corresponding domain. But you risk throwing away legitimate messages if you reject just on the basis of that SPF record. Even in the bank case: I get a notice from my bank at home, but that account is automatically resent (.forward) to my cellphone. If my cellphone provider bounces it because of SPF, I would be quite annoyed. (DMARC is a big improvement here, because it won't bounce due to DKIM identity alignment.) The fact is, with the exception of blacklisting truly evil hosts, making a decision to reject based on the client's IP address and the domain(s) in HELO and MAIL FROM is just a recipe for throwing away a lot of legitimate mail and users in most domains will not stand for it. > Only with IETF endorsement will it begin to get wider adoption > within the market. DMARC proves that wrong. What DMARC shows, AFAICS, is that what is needed to get adoption in the market is a protocol that does what it is designed to do *and* satisfies real needs. Not to mention that in IETF tradition this whole sequence of anti-mail-abuse standards is somewhat unseemly, as quite clearly many were hopeful stabs in the dark based on a lot of theory and a little bit of urgency, rather than codification of successful practice.[1] > Have you tried ADSP/ATPS or DMARC with ATPS updated for DMARC > instead? Uh, no. I'm interested in this discussion because I administer mailing lists and develop MLM software, not MTAs. So implementing those protocols has not been a possible experiment for me. I'm working on getting control of the MTA for some of the public mailing lists I administer, at which point I may experiment with it. It's not clear that the experiment would be very meaningful, though, as those lists have very few Yahoo!/AOL subscribers, and none who have posted from those domains in years. In any case, ADSP is now historic, and it would appear to be superseded by DMARC; I'm not sure what the point of trying ADSP is. Footnotes: [1] Granted, it's not just mail security standards that have moved to adoption on the basis of theory, the whole IETF process is doing it. From nobody Sat Jun 7 14:06:30 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05D31A0218 for ; Sat, 7 Jun 2014 14:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 pYOnNBeR9stJ for ; Sat, 7 Jun 2014 14:06:25 -0700 (PDT) Received: from nm35.bullet.mail.gq1.yahoo.com (nm35.bullet.mail.gq1.yahoo.com [98.136.217.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9CD71A01FA for ; Sat, 7 Jun 2014 14:06:25 -0700 (PDT) Received: from [127.0.0.1] by nm35.bullet.mail.gq1.yahoo.com with NNFMP; 07 Jun 2014 21:06:18 -0000 Received: from [98.137.12.61] by nm35.bullet.mail.gq1.yahoo.com with NNFMP; 07 Jun 2014 21:03:34 -0000 Received: from [98.137.12.212] by tm6.bullet.mail.gq1.yahoo.com with NNFMP; 07 Jun 2014 21:03:34 -0000 Received: from [127.0.0.1] by omp1020.mail.gq1.yahoo.com with NNFMP; 07 Jun 2014 21:03:34 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 555458.470.bm@omp1020.mail.gq1.yahoo.com Received: (qmail 22394 invoked by uid 60001); 7 Jun 2014 21:03:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402175014; bh=K5brAkWZTajM4Aq25j+7YLRcpX1G+ryNqrYwURlQN6Q=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=R9ZMd9E6cdEyA9aICDHds2AmAQG2RAmaIabmP7bzFtCgv19jXuSws0ILXOflu6PDTG0Jjv5mg0P0VJJKoV3CfXSlORqFuYH089hEGI/B4Rbh7mgjayACK6d3wHu/qInAfJNg+OoMAEAu8RGDMODxSsOAZ4zBgIJJqrrWAfdkuis= X-YMail-OSG: b_XwRVUVM1lBnsCrivQbeSvFpVrPya2L_wsbPSXn5tW4Feq WHQlFYW2WJ5BlrVPnDOfw8yXmV0gDdcpEEq8jzzImHWt6EOYFh.JTIeZH.Sx osDiKnywFDKIrq4mC0PPx4U33pchTt7uFoqbciFu_2c_R9kR.1TmEUjqVqI1 1fxeJsF91.viFr9s6rtq6Hbo3ArndIHJlqVzLC37msWHCHY.OFs9MXCjxNCX p1bLyA_bx3o9aQOGQZibE6B4yywr_NqnQC8Q9cJa_MZ_udhMz57EOTmhS2Yl a94cKVufZbTgWXH18bnaUUweBN_.JMc6PvtkCbTLsSA4ReltiAKuTmR45avX CBEPeegxkVnhejHoaZHgmw7EcFr0l7BxdXoJdGCqG_TXBkusdYVSepPIjG4m 167Dg3f6WWyn38x99Wnbx2v9EUWiPEjdf8wt.elaYYd9guXjqfQomAhlSOYZ KuUcKyRLU2bH1VWqo4OA23GJh.3HqMe3XabKC_cAhTyvCEJUd28mVtLiY_qJ YuSiehKgZPtwaLKcLpz1r_75tMBl0qIqX.y4jKx5soGxS3RmJ1DkwIxnimRO wVseUsM3c7ufjQr1Qe5dEpR7nim5rhwahnNohkFsVNiLO9tbHlg-- Received: from [79.175.112.242] by web164601.mail.gq1.yahoo.com via HTTP; Sat, 07 Jun 2014 14:03:34 PDT X-Rocket-MIMEInfo: 002.001, T24gU2F0dXJkYXksIEp1bmUgNywgMjAxNCA3OjE3IFBNLCBTdGVwaGVuIEouIFR1cm5idWxsIDxzdGVwaGVuQHhlbWFjcy5vcmc.IHdyb3RlOgoKCj4.IHNvLCB3aGF0IGkgYW0gcHJvcG9zaW5nIGlzIGNoYW5naW5nIGFka2ltIGFuZCBhc3BmIERNQVJDIHRhZ3Mgc28KPj4gdGhleSBiZWNvbWU6Cj4.IGEgY29tbWEtc2VwYXJhdGVkIGxpc3Qgb2YgImFsaWdubWVudC1zdHJlbmd0aDpkb21haW4iIHBhaXJzLCBpbiB3aGljaAo.IFRoaXMgcHJvYmFibHkgZG9lc24ndCBzb2x2ZSB0aGUgbWFpbGluZyBsaXN0IHABMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <1402089514.72796.YahooMailNeo@web164603.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8D48E075@MSGRTPCCRF2WIN.DMN1.FMR.COM> <87y4x914s1.fsf@uwakimon.sk.tsukuba.ac.jp> <1402143903.18880.YahooMailNeo@web164602.mail.gq1.yahoo.com> <87vbsc24p8.fsf@uwakimon.sk.tsukuba.ac.jp> <1402153328.28071.YahooMailNeo@web164603.mail.gq1.yahoo.com> <87r4301vxl.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <1402175014.3312.YahooMailNeo@web164601.mail.gq1.yahoo.com> Date: Sat, 7 Jun 2014 14:03:34 -0700 (PDT) From: Vlatko Salaj To: "Stephen J. Turnbull" In-Reply-To: <87r4301vxl.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/kHHyi4jXX6dzg_qdE0B0-wJ2Tck Cc: DMARC Discussion Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 07 Jun 2014 21:06:29 -0000 On Saturday, June 7, 2014 7:17 PM, Stephen J. Turnbull = wrote:=0A=0A=0A>> so, what i am proposing is changing adkim and aspf DMARC= tags so=0A>> they become:=0A>> a comma-separated list of "alignment-streng= th:domain" pairs, in which=0A> This probably doesn't solve the mailing list= problem,=0A=0Asure, it doesn't scale well to support more than a dozen dom= ains, which=0Aisn't a complete solution for mailing lists, but it can be us= ed=0Ain special cases when u have mailing lists that can't/won't adapt=0Ato= DMARC in any other possible or suggested way, and u can't=0Ause any other = developed workaround.=0A=0Aalso, this whitelisting solution does fix quite = a few other=0Ause cases that DMARC without any 3rd party support simply=0Ah= as to exclude. and most of those, if not all, r small scale=0Ause cases, ma= jority of worldwide scenarios.=0A=0A=0Aactually, any proposed 3rd party ali= gnment upgrade to DMARC would=0Ado, imo.=0A=0Awhat we need to agree upon is= which is best overall. my proposal=0Amay be quick, trivial, and simple... = but Hector's proposal=0Ais much more developed and opens wider support, and= Douglas'=0ATPA-Label is rly complex but could fix almost anything and=0Aev= erything.=0A=0Aand i may be missing some other proposal too.=0A=0A=0Aalso, = there r DKIM-based upgrades to help workaround DMARC=0Adeficiencies, howeve= r, imo, i would rather skip those, cause:=0A=0A1. they don't fix SPF 3rd pa= rty alignment,=0A2. won't provide 3rd party alignment support out of box,= =0Ain case DMARC gets expanded to include another underlying protocol,=0Abe= side the SPF and DKIM,=0A3. r quite messy and seem unnatural.=0A=0A=0A>> re= ceivers should have nothing to do with that, no guesswork, in=0A>> respect = to DMARC, but they r forced to do it now, going even as far=0A>> to process= "p=3Dreject" as "p=3Dquarantine".=0A> Nobody is *forced* to do any such th= ing.=0A=0Athey r "forced" by circumstances of DMARC having too much=0Afalse= -positives with "p=3Dreject". nobody wants unhappy users over=0Alost import= ant email.=0A=0Ahowever, such practice essentially dismantles any strength = DMARC has,=0Acause once services start treating reject as anything-but-not-= reject,=0Ait will become a common practice, and puff... away goes strong ph= ishing=0Aprotection.=0A=0Aand then, it won't take long for phishers to unde= rstand what exactly=0Aneeds to be done to email to look like it should be t= reated as non-reject=0Aby protocols at any receivers using such false-posit= ives precautions.=0A=0A=0Athat's where 3rd party support comes in. allowing= domain-owner to=0Asay: "trust here there like this and that, and don't tru= st anything=0Aelse", would dramatically ease upon any workarounds receivers= need=0Ato perform to keep DMARC false-positives as low as possible.=0A=0Aw= hy? cause it will enable domain-owner to specify services it=0Aconsiders mo= re or less, but, trustworthy enough, to deliver its=0Amail.=0A=0A=0A>> yeah= , well i don't define trivial and easy like that. and i doubt=0A>> any ESP = will introduce something like that.=0A> Once again, you are not paying atte= ntion.=A0 Franck Martin testifies=0A> that he knows of many ESPs willing to= make necessary adjustments, and=0A> who are already doing so.=0A=0AFranck = isn't a representative of an ESP. i have full respect for=0AFranck ofc, but= until i actually see an ESP publicly committing=0Ato such a thing, it's al= l rumors.=0A=0Aand even if an ESP does such a thing, it doesn't mean it wil= l=0Abecome a new common standard for all of them.=0A=0Aand even if it does = become a new standard, it still doesn't preclude=0Aactual 3rd party alignme= nt support upgrade to DMARC, merely cause=0A3rd party support covers much m= ore ground.=0A=0A=0A-- =0AVlatko Salaj aka goodone=0Ahttp://goodone.tk From nobody Sat Jun 7 14:35:20 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C321A01FA for ; Sat, 7 Jun 2014 14:35:17 -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 HoL4QLwtzrfZ for ; Sat, 7 Jun 2014 14:35:15 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 645821A01F3 for ; Sat, 7 Jun 2014 14:35:15 -0700 (PDT) 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, 7 Jun 2014 23:35:06 +0200 Message-ID: <2CB7182D523F431A99683E757C7FCD7B@fgsr.local> From: "J. Gomez" To: "Stephen J. Turnbull" References: <1402089514.72796.YahooMailNeo@web164603.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8D48E075@MSGRTPCCRF2WIN.DMN1.FMR.COM> <87y4x914s1.fsf@uwakimon.sk.tsukuba.ac.jp> <1402143903.18880.YahooMailNeo@web164602.mail.gq1.yahoo.com> <87tx7w21by.fsf@uwakimon.sk.tsukuba.ac.jp> <53934D5D.1030903@isdg.net> <87oay41lom.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Sat, 7 Jun 2014 23:35:20 +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: http://mailarchive.ietf.org/arch/msg/dmarc/MjRNEX1HztlssPE0ihzvqqMKygs Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 07 Jun 2014 21:35:18 -0000 On Saturday, June 07, 2014 10:58 PM [GMT+1=3DCET], Stephen J. Turnbull = wrote: > Are there really sites out there > that reject on the basis of SPF -ALL without waiting for DATA? I for > one could not use such a host. Yes, there are. =20 Rejecting on the basis of SPF -ALL without waiting for DATA is cheap in = resources, obeys the published policy of the sending domain owner, and = affords the Recipient the benefit of off-loading the blame for the = rejection onto the Sender. =20 Also, rejecting on the basis of SPF -ALL does not inconvenience at all = mailing list traffic, as mailing list traffic usually takes ownership of = the Return Path (envelope MAIL FROM), so if the mailing list host has an = SPF record, its traffic will pass an SPF check without waiting for DATA. Regards, J.Gomez From nobody Sat Jun 7 14:57:35 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E9F1A0225 for ; Sat, 7 Jun 2014 14:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 U2JpP1vu_GjY for ; Sat, 7 Jun 2014 14:57:32 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id 2449C1A01FA for ; Sat, 7 Jun 2014 14:57:32 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 54D89970B1E; Sun, 8 Jun 2014 06:57:24 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 457931A2744; Sun, 8 Jun 2014 06:57:24 +0900 (JST) From: "Stephen J. Turnbull" To: "J. Gomez" In-Reply-To: <9529BCDA5AC34DC694173FD43EB7E71F@fgsr.local> References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <5392ECED.5010404@gmail.com> <9529BCDA5AC34DC694173FD43EB7E71F@fgsr.local> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Sun, 08 Jun 2014 06:57:24 +0900 Message-ID: <87lht81iyj.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/GOfNEWlVg62Umz7JbalyghSpjOA Cc: Dave Crocker , dmarc@ietf.org Subject: Re: [dmarc-ietf] Fwd: New Version Notification fordraft-kucherawy-dkim-delegate-00.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, 07 Jun 2014 21:57:34 -0000 J. Gomez writes: > Hello, I have this comment: What do you think are the probabilities > that YAHOO/AOL, etc, would go through the trouble of identifying > and declaring the many third parties needed to be allowed to DKIM > re-sign their messages, so that YAHOO/AOL users could painlessly > post to mailing lists in a world where DMARC happened to be widely > deployed? First, in the usual case the mailing list is explicitly mentioned in the addressee list at the time it reaches the destination domain, so it automatically becomes a delegate. So there would be no need to specify "t=" in those cases. Nor do I see a serious risk of exploitation, since the implicit list is restricted to the explicit (non-bcc) addressees. DKIM sign To and Cc and replay attacks become quite difficult, I should think. I guess these considerations are what Dave meant by "the protocol doesn't require that", but you'd have to ask him. Do you have a specific reason to think explicit delegate lists would commonly be needed? For your actual question, I can't speak to probability, but I think that it would be reasonably easy to delegate the identification task to the users. Just as many webmail services allow you to "whitelist" senders such as your bank, they could have a separate "delegate" list (probably labeled "mailing lists"). Then the MUA module would generate the "t=" parameter of the DKIM-Delegate header based on the user's whitelist and the addressee fields. I don't see a problem with this from the mailbox provider's point of view, and it would be greatly appreciated by many mailbox users. From nobody Sat Jun 7 14:59:09 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFBD81A0232 for ; Sat, 7 Jun 2014 14:59: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=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 6ADheSnj5bbX for ; Sat, 7 Jun 2014 14:59:05 -0700 (PDT) Received: from listserv.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C548F1A01FA for ; Sat, 7 Jun 2014 14:59:04 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=223; t=1402178333; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=9lBL6XYC/gWNr3CY4f32LXUwl6E=; b=ZS9pEQyoXzQcDFdv6cgP i4qiGjQHMIeIBGaJVKw21sdyxqd/eEruTH8mfDlzo7OSSLcH6WNaO5KZU2ZikG0D oZNQ/wQTqWhZWZqIWEB17iSJEmH576PXNixj5nZeoZd6+dK6JF4nydqUFc/c6X3d 6DbrxzIdyU8zA/vlNUTWLJQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 07 Jun 2014 17:58:53 -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; Received: from opensite.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1658458547.6036.5264; Sat, 07 Jun 2014 17:58:52 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=223; t=1402178169; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=RQs2G3D rg6ugPocZBqLnCqj54j0poVc7Z8RwaZojdpE=; b=Tr1ZAm9R5iSahqXA4hjrvSQ AbincxQWDSdxsog+JW3A8EaIvbvob21x7xD6fzt8cVAkGHGZZqDmkc4UGVaHnSTD vkgRXDWiztnYK/wvIk4U9bv2XBDLEKD8BLLiVulTUb4T/Drq04tTDEzYbVx87L4s tazdep2cEavvbdoRl/vY= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 07 Jun 2014 17:56: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 1674816656.9.5448; Sat, 07 Jun 2014 17:56:08 -0400 Message-ID: <53938B1E.2020002@isdg.net> Date: Sat, 07 Jun 2014 17:58: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, IETF General Discussion Mailing List Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/eU8qpYITgsrQpezvC5IOElnRzvI Subject: [dmarc-ietf] Next IETF Meeting DMARC Related Talks 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, 07 Jun 2014 21:59:07 -0000 I might be interested in remote participation at the next IETF 90 meeting if there are any DKIM/DMARC related meetings scheduled. I have not seen any announcements for any such DKIM/DMARC related activity. -- HLS From nobody Sat Jun 7 15:23:17 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8691A0228 for ; Sat, 7 Jun 2014 15:23: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_40=-0.001, 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 iMn8Ia1sGLx3 for ; Sat, 7 Jun 2014 15:23:14 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [192.254.77.197]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA9B1A021E for ; Sat, 7 Jun 2014 15:23:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id CE19CA04A6 for ; Sat, 7 Jun 2014 17:23:06 -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 bi3tCVN_AFSW for ; Sat, 7 Jun 2014 17:23:06 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id AE734A04CE for ; Sat, 7 Jun 2014 17:23:06 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 9875FA04A8 for ; Sat, 7 Jun 2014 17:23:06 -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 tUey7VtqvO8b for ; Sat, 7 Jun 2014 17:23:06 -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 7D170A04A6 for ; Sat, 7 Jun 2014 17:23:06 -0500 (CDT) Date: Sat, 7 Jun 2014 17:23:05 -0500 (CDT) From: Franck Martin To: "dmarc@ietf.org" Message-ID: <1322530073.150717.1402179785354.JavaMail.zimbra@peachymango.org> In-Reply-To: <1479173289.150583.1402179226077.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_150716_40142775.1402179785354" X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF29 (Mac)/8.0.5_GA_5839) Thread-Topic: Advice to MUA Thread-Index: QzkwqgflzJ92otGiqWewc6uwis78xA== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/GQ9m3rc8vp0oxKbymZPGiqACiOs Subject: [dmarc-ietf] Advice to MUA 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, 07 Jun 2014 22:23:16 -0000 ------=_Part_150716_40142775.1402179785354 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I think we need to give advice to MUAs, while letting MUA developers some liberty on how to interpret it. I'm proposing the following text to be added to the DMARC spec "MUAs SHOULD display to the end user, in UTF8 (and punycode), in a non ambiguous font, the domain used for the assertion of the DMARC policy, as well as the result of this assertion. A non ambiguous font is a font where the graphical representation of a chararcter is not identical to the graphical representation of another chararcter in the same font" If we know what a non ambiguous font is, then may be we could specifiy the font name. ------=_Part_150716_40142775.1402179785354 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
I think we need to give advice to MUAs, while letting MUA developers some liberty on how to interpret it.

I'm proposing the following text to be added to the DMARC spec

"MUAs SHOULD display to the end user, in UTF8 (and punycode), in a non ambiguous font, the domain used for the assertion of the DMARC policy, as well as the result of this assertion. A non ambiguous font is a font where the graphical representation of a chararcter is not identical to the graphical representation of another chararcter in the same font"

If we know what a non ambiguous font is, then may be we could specifiy the font name.
------=_Part_150716_40142775.1402179785354-- From nobody Sat Jun 7 16:16:00 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385841A0259 for ; Sat, 7 Jun 2014 16:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 soqzKPE4WtEs for ; Sat, 7 Jun 2014 16:15:57 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id 84EC21A024F for ; Sat, 7 Jun 2014 16:15:57 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id BD031970B1E; Sun, 8 Jun 2014 08:15:49 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id A947A1A2744; Sun, 8 Jun 2014 08:15:49 +0900 (JST) From: "Stephen J. Turnbull" To: Vlatko Salaj In-Reply-To: <1402175014.3312.YahooMailNeo@web164601.mail.gq1.yahoo.com> References: <1402089514.72796.YahooMailNeo@web164603.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8D48E075@MSGRTPCCRF2WIN.DMN1.FMR.COM> <87y4x914s1.fsf@uwakimon.sk.tsukuba.ac.jp> <1402143903.18880.YahooMailNeo@web164602.mail.gq1.yahoo.com> <87vbsc24p8.fsf@uwakimon.sk.tsukuba.ac.jp> <1402153328.28071.YahooMailNeo@web164603.mail.gq1.yahoo.com> <87r4301vxl.fsf@uwakimon.sk.tsukuba.ac.jp> <1402175014.3312.YahooMailNeo@web164601.mail.gq1.yahoo.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Sun, 08 Jun 2014 08:15:49 +0900 Message-ID: <87k38s1fbu.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/KnhDMvT61WuCJSLhfmS4n_NtOGc Cc: DMARC Discussion Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 07 Jun 2014 23:15:59 -0000 Vlatko Salaj writes: > sure, [my proposal] doesn't scale well to support more than a dozen > domains, which isn't a complete solution for mailing lists, but it > can be used in special cases when u have mailing lists that > can't/won't adapt to DMARC in any other possible or suggested way, > and u can't use any other developed workaround. > > also, this whitelisting solution does fix quite a few other > use cases that DMARC without any 3rd party support simply > has to exclude. and most of those, if not all, r small scale > use cases, majority of worldwide scenarios. OK, I guess I'll have to take a closer look at the idea. > however, such practice essentially dismantles any strength DMARC > has, cause once services start treating reject as > anything-but-not-reject, it will become a common practice, and > puff... away goes strong phishing protection. I think you dramatically underestimate the intelligence that will be applied to this by the big mailbox providers. First, the most vulnerable domains and users (banks and their clients) are reasonably easy to identify, and reject will continue to be treated as reject for those Author Domains. Second, use of "p=reject" by public mailbox providers has so far been associated with security issues, and other public mailbox providers (eg, Comcast) have made a point of dissociating themselves from "p=reject". It will be difficult for them to adopt it -- unless they find themselves in a desperate security situation like AOL and Yahoo! did. > why? cause it will enable domain-owner to specify services it > considers more or less, but, trustworthy enough, to deliver its > mail. I don't think it's that easy -- the domains that matter most are the big public providers and ISPs. The domain-based 3rd-party auth schemes have a severe scaling problem in those cases. I think the dkim-delegate scheme actually is likely to scale better, and adapt better to individual user needs. From nobody Sat Jun 7 16:52:31 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5334E1A026C for ; Sat, 7 Jun 2014 16:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-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 g0EqZ7tkQD0c for ; Sat, 7 Jun 2014 16:52:28 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 044571A0212 for ; Sat, 7 Jun 2014 16:52:28 -0700 (PDT) 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; Sun, 8 Jun 2014 01:52:19 +0200 Message-ID: <43FBB724BB014305AF92AE07C2FD4A01@fgsr.local> From: "J. Gomez" To: Franck Martin References: <1322530073.150717.1402179785354.JavaMail.zimbra@peachymango.org> Date: Sun, 8 Jun 2014 01:52:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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: http://mailarchive.ietf.org/arch/msg/dmarc/4p98zW2oOAIluNmdUk7Tqbu0hHY Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Advice to MUA 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, 07 Jun 2014 23:52:30 -0000 Franck Martin wrote: > "MUAs SHOULD display to the end user, in UTF8 (and punycode), in a > non ambiguous font, the domain used for the assertion of the DMARC > policy, as well as the result of this assertion. A non ambiguous font > is a font where the graphical representation of a chararcter is not > identical to the graphical representation of another chararcter in > the same font" =20 >=20 > If we know what a non ambiguous font is, then may be we could > specifiy the font name.=20 I very much would like that to be included in the DMARC spec. And what about an additional recommendation in the spec (less than = SHOULD) for MUAs to "green bar" the Header-From when the DMARC check = passed *and* the domain is found to be accesible at = https://_dmarc.example.com *and* found to have an EV SSL certificate? So that only MUAs complying with that could be branded "DMARC-compliant" = or "DMARC-secured"... As long as Certification Authorities managed to = keep EV SSL certificates trustworthy, that would go a long way securing = email communications and averting phishing scams, I think. At any rate, MUA involvement for a successful DMARC is definitely = required. Regards, J.Gomez From nobody Sat Jun 7 16:57:08 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7221A026C for ; Sat, 7 Jun 2014 16:57:07 -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 2B6lujyUjQim for ; Sat, 7 Jun 2014 16:57:05 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7247D1A0212 for ; Sat, 7 Jun 2014 16:57:05 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id l18so4370673wgh.14 for ; Sat, 07 Jun 2014 16:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=i2KorM8arwe21glaPFoVnuKjF94WZDbdYMApRZC7nfs=; b=nF5y5zLZ0DQ6XsBQjwsuKAcHUsOa+FHGPWoT5/P9KpMJmv4Mi2by02rUoqqyqzt7/2 TdtY2ti0EM/+bJ7CMFzhovRPtMWBygRycW7mnDJeb8a0rITTyZuFoXkuW8zSKaB8HmJa m37rKiqO2ZGVsZA8nQI6iBa2tFJkNBAQ4qGcqb6SB/mmX5rjjDM45Yk+bZ9hnt5pub4I IDqNvb5WMgzIcDb3ZjzC4KbYEzdTaapW6WntWLn+WHpyHPUviXA1Er7CVLVdHGdRli47 UGoc0JogJUD+Udf7Crp0EuHQbfNmtHV3SY7xsl9vPKl8MCM1eEoqhN3AY/wFQ81Ezs63 BpMA== X-Received: by 10.180.14.168 with SMTP id q8mr19313832wic.47.1402185417005; Sat, 07 Jun 2014 16:56:57 -0700 (PDT) Received: from [10.128.84.219] (87-198-224-122.static.ptr.magnet.ie. [87.198.224.122]) by mx.google.com with ESMTPSA id ej4sm5696498wib.4.2014.06.07.16.56.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Jun 2014 16:56:55 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_8FA22764-5058-4F76-B542-635D08278353" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: <87k38s1fbu.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Sun, 8 Jun 2014 00:56:47 +0100 Message-Id: References: <1402089514.72796.YahooMailNeo@web164603.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8D48E075@MSGRTPCCRF2WIN.DMN1.FMR.COM> <87y4x914s1.fsf@uwakimon.sk.tsukuba.ac.jp> <1402143903.18880.YahooMailNeo@web164602.mail.gq1.yahoo.com> <87vbsc24p8.fsf@uwakimon.sk.tsukuba.ac.jp> <1402153328.28071.YahooMailNeo@web164603.mail.gq1.yahoo.com> <87r4301vxl.fsf@uwakimon.sk.tsukuba.ac.jp> <1402175014.3312.YahooMailNeo@web164601.mail.gq1.yahoo.com> <87k38s1fbu.fsf@uwakimon.sk.tsukuba.ac.jp> To: "Stephen J. Turnbull" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/21NOJlF8RLc4YeHR4QkTEzoUqYE Cc: Vlatko Salaj , DMARC Discussion Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 07 Jun 2014 23:57:07 -0000 --Apple-Mail=_8FA22764-5058-4F76-B542-635D08278353 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 8, 2014, at 12:15 AM, Stephen J. Turnbull = wrote: > I don't think it's that easy -- the domains that matter most are the > big public providers and ISPs. The domain-based 3rd-party auth > schemes have a severe scaling problem in those cases. I think the > dkim-delegate scheme actually is likely to scale better, and adapt > better to individual user needs. Dear Stephen, Considered how weak signing schemes can be abused, especially for small = messages. Short expiry offers little protection nor will capturing To: = or Cc: headers or including BCC domains in the 'D' list. This solves a = parochial interest and overlooks other serious issues.=20 Email is only protected by assessing validated source domains. Once a = source is validated, a TPA-Label should allow the DMARC domain to grant = needed alignment exceptions AND retract them when abused. That is a = feature missing in a DKIM delegation scheme that also seems likely to = imperil safe use of BCC. Frankly, DMARC already exposes those even = merely receiving messages. Nor will this scheme satisfy uses = exemplified by services offered by Intuit. It seems the greater good is to adopt a scheme able to handle any = eventual abuse and encompasses all the issues. If it is worth doing, it = is worth doing right. Regards, Douglas Otis =20 =20 --Apple-Mail=_8FA22764-5058-4F76-B542-635D08278353 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jun 8, 2014, at 12:15 AM, Stephen = J. Turnbull <stephen@xemacs.org> = wrote:

I don't think it's that easy -- the = domains that matter most are the
big public providers and ISPs.  The domain-based = 3rd-party auth
schemes have a severe scaling problem in = those cases.  I think the
dkim-delegate scheme actually is likely to scale better, = and adapt
better to individual user needs.

Dear = Stephen,

Considered how weak signing schemes = can be abused, especially for small messages.  Short expiry offers = little protection nor will capturing To: or Cc: headers or including BCC = domains in the 'D' list. This solves a parochial interest and overlooks = other serious issues. 

Email is only = protected by assessing validated source domains.  Once a source is = validated, a TPA-Label should allow the DMARC domain to grant needed = alignment exceptions AND retract them when abused.  That is a = feature missing in a DKIM delegation scheme that also seems likely to = imperil safe use of BCC.  Frankly, DMARC already exposes those even = merely receiving messages.  Nor will this scheme satisfy uses = exemplified by services offered by Intuit.

It = seems the greater good is to adopt a scheme able to handle any eventual = abuse and encompasses all the issues.  If it is worth doing, it is = worth doing right.

Regards,
Douglas = Otis =  

  

= --Apple-Mail=_8FA22764-5058-4F76-B542-635D08278353-- From nobody Sat Jun 7 17:22:34 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0079A1A026E for ; Sat, 7 Jun 2014 17:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 jl56m3bn03mZ for ; Sat, 7 Jun 2014 17:22:30 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id 614CB1A026C for ; Sat, 7 Jun 2014 17:22:30 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 96E7F970B2D; Sun, 8 Jun 2014 09:22:22 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 86F631A2744; Sun, 8 Jun 2014 09:22:22 +0900 (JST) From: "Stephen J. Turnbull" To: Franck Martin In-Reply-To: <1322530073.150717.1402179785354.JavaMail.zimbra@peachymango.org> References: <1479173289.150583.1402179226077.JavaMail.zimbra@peachymango.org> <1322530073.150717.1402179785354.JavaMail.zimbra@peachymango.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Sun, 08 Jun 2014 09:22:22 +0900 Message-ID: <87ha3w1c8x.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/4Sn02KfX_5rLrdqsEzrcTnzpLyQ Cc: "dmarc@ietf.org" Subject: [dmarc-ietf] Advice to MUA 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, 08 Jun 2014 00:22:32 -0000 Franck Martin writes: > I think we need to give advice to MUAs, while letting MUA > developers some liberty on how to interpret it. > > I'm proposing the following text to be added to the DMARC spec > > "MUAs SHOULD display to the end user, in UTF8 (and punycode), in a > non ambiguous font, the domain used for the assertion of the DMARC Isn't the "domain used for assertion" normally called the Author Domain? > policy, as well as the result of this assertion. A non ambiguous > font is a font where the graphical representation of a chararcter > is not identical to the graphical representation of another > chararcter in the same font" > > If we know what a non ambiguous font is, then may be we could > specifiy the font name. Unfortunately, there is no such thing. For example, the glyph that represents "A" is very likely to be used for the corresponding character in all of the Latin, Greek, and Cyrillic scripts. Even if the glyphs for such confusable characters are clearly distinct in each script, it would require a very carefully designed font to ensure that most users would be able to reliably decide which glyph represents the character from which script. I would suggest MUAs SHOULD indicate the domain used for the assertion of the DMARC policy, and SHOULD also display internationalized domain names [IDNA = RFC 3490] as Punycode [PUNYCODE = RFC 3492]. MUAs MAY highlight a confusable character [UTS #39] if its script differs from the surrounding characters, or otherwise indicate different scripts in the domain name. I'm not wedded to that language, and the part about highlighting confusables needs refinement. I wonder if it might not be a better idea to say that in the case of identity alignment *failure*, the MUA should clearly indicate this fact, as well as the Author Domain? From nobody Sat Jun 7 18:02:59 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720C11A020B for ; Sat, 7 Jun 2014 18:02:58 -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 JTQWAEl4y6mQ for ; Sat, 7 Jun 2014 18:02:56 -0700 (PDT) Received: from ntbbs.santronics.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9491A024A for ; Sat, 7 Jun 2014 18:02:56 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=510; t=1402189359; h=Received:Received: Message-Id:From:Subject:Date:To:Organization:List-ID; bh=zIPFsy4 WcgLEmgmlbOANGVlhVbU=; b=SzJGDH/fmN37ITJwPLHStDu+Sd+JW2Us9pr/yZC Rn3S1IpTbS2D+ATf9qVA5yFs4OfVmMC2O22JGUODJ7Btj8K07ZtnWKSHxwYxLnZR xZeS4K5tnJMInEPUrByxSPMXSj9Hfhoi7CUgaSgbxyy6aQAgnv3O3duuByEslDBD p9lQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 07 Jun 2014 21:02:39 -0400 Received: from [192.168.1.221] (99-72-160-212.lightspeed.miamfl.sbcglobal.net [99.72.160.212]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1669485150.6036.2356; Sat, 07 Jun 2014 21:02:39 -0400 References: <1322530073.150717.1402179785354.JavaMail.zimbra@peachymango.org> <43FBB724BB014305AF92AE07C2FD4A01@fgsr.local> Mime-Version: 1.0 (1.0) In-Reply-To: <43FBB724BB014305AF92AE07C2FD4A01@fgsr.local> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (11B651) From: Hector Santos Date: Sat, 7 Jun 2014 21:02:38 -0400 To: "J. Gomez" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/HnWlH2p8uVVpESd5Q1k6TJWmDu4 Cc: "dmarc@ietf.org" , Franck Martin Subject: Re: [dmarc-ietf] Advice to MUA 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, 08 Jun 2014 01:02:58 -0000 > On Jun 7, 2014, at 7:52 PM, "J. Gomez" wrote: >=20 > At any rate, MUA involvement for a successful DMARC is definitely required= . All security considerations tell you otherwise. You need control of the MUA= and that's only possible with online-based MUAs or hybrid MUAs. You have no= control over offline RFC-based store and forward MUAs. The only control you= have is what the backend provides via the 5322 format. -- Hector Santos http ://www.santronics.com= From nobody Sat Jun 7 19:41:05 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325A91A0286 for ; Sat, 7 Jun 2014 19:41:04 -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 E6Y78zF9iHml for ; Sat, 7 Jun 2014 19:41:02 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E864F1A0264 for ; Sat, 7 Jun 2014 19:41:01 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 0E264D045CC; Sat, 7 Jun 2014 22:40:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1402195254; bh=SsrabJ1b06ljos8UhzRleDX/yNos0Hok+regm0j+eUE=; h=In-Reply-To:References:Subject:From:Date:To:From; b=p3TFww90Vmmrg3M1KZZ3vdO01oqo/n3I5aqKkxGN1hrj7F7V9ilRl70qMpEU9bjt4 EiYRvNrhpElt5PCudzi4NY9ZLYoH5G0kcY4k4VrckHfVnFPnyCPEqiAmG1k4RhIQrQ FccdSuAYGF0N94hsM7XDmewO69/aP9jb24xOttc8= Received: from [192.168.111.2] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id B02D5D043DB; Sat, 7 Jun 2014 22:40:53 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <2CB7182D523F431A99683E757C7FCD7B@fgsr.local> References: <1402089514.72796.YahooMailNeo@web164603.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8D48E075@MSGRTPCCRF2WIN.DMN1.FMR.COM> <87y4x914s1.fsf@uwakimon.sk.tsukuba.ac.jp> <1402143903.18880.YahooMailNeo@web164602.mail.gq1.yahoo.com> <87tx7w21by.fsf@uwakimon.sk.tsukuba.ac.jp> <53934D5D.1030903@isdg.net> <87oay41lom.fsf@uwakimon.sk.tsukuba.ac.jp> <2CB7182D523F431A99683E757C7FCD7B@fgsr.local> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Sat, 07 Jun 2014 22:40:49 -0400 To: dmarc@ietf.org Message-ID: X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/tu2rKZ2hId-MW-bYf-oI0KzNke4 Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 08 Jun 2014 02:41:04 -0000 On June 7, 2014 5:35:20 PM EDT, "J. Gomez" wrote: >On Saturday, June 07, 2014 10:58 PM [GMT+1=CET], Stephen J. Turnbull >wrote: > >> Are there really sites out there >> that reject on the basis of SPF -ALL without waiting for DATA? I for >> one could not use such a host. > >Yes, there are. > >Rejecting on the basis of SPF -ALL without waiting for DATA is cheap in >resources, obeys the published policy of the sending domain owner, and >affords the Recipient the benefit of off-loading the blame for the >rejection onto the Sender. > >Also, rejecting on the basis of SPF -ALL does not inconvenience at all >mailing list traffic, as mailing list traffic usually takes ownership >of the Return Path (envelope MAIL FROM), so if the mailing list host >has an SPF record, its traffic will pass an SPF check without waiting >for DATA. I maintain a reasonably popular Postfix plugin for SPF checking that defaults to rejecting mail with an SPF fail result. I think I've been doing it since 2007 and I don't recall ever having a complaint about this default (plenty of complaints and requests about other things). I've published a -all SPF record since 2004. I do occasionally have mail rejected due to forwarding. In my experience it's mostly smaller domains that reject on -all. Personally, I prefer rejection over spam scoring. When it's rejected due to forwarding, the reject message always has the address I should send to directly in it. If mail gets spamfoldered and the recipient never sees it, I never find out. No, it's not what the big guys do, but it's definitely done. Scott K From nobody Sat Jun 7 21:33:42 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B55B31A02C7 for ; Sat, 7 Jun 2014 21:33: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 GAfj2wX20Bqy for ; Sat, 7 Jun 2014 21:33:37 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A131A02BE for ; Sat, 7 Jun 2014 21:33:37 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id y10so473810wgg.17 for ; Sat, 07 Jun 2014 21:33:29 -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=kg4IRuTTyIKJJ8OvG7ImbFtNRGdJfEGmR/vJnULPlhE=; b=KkLFIsOcKDkJQdp3kAQhvwCAwUpC8uEVIl+Vuz/ySyYYQfEgEmhCgxGI3Gp10VDM7s sbLpX6ngGhSSZ9R1qj8YdANPT+I82DRBS9T3w7uuDLRXWx0wmLmfajauT49tfsLffxhz InT8pmAT3pXRAsSN2rnQocrhEBl2KIWLLcAvpx9G9mTYIf4CX/JYNxQuX4dwZ8UF7Kwk xXVbL+kUyho8sukbch0+yycY0sL2Cw8cZIZdYW4QZqMN2afIyjqv1HJPzCHpFzMxzqdm dIBfAt/W5+XL1TKy3y1Z+0ElWY/QguNsoEFNlzjcDTZkh8GyTMbKlayDW1zFcRvQycTT 4uSQ== MIME-Version: 1.0 X-Received: by 10.194.61.193 with SMTP id s1mr20259984wjr.36.1402202008988; Sat, 07 Jun 2014 21:33:28 -0700 (PDT) Received: by 10.180.23.104 with HTTP; Sat, 7 Jun 2014 21:33:28 -0700 (PDT) In-Reply-To: <43FBB724BB014305AF92AE07C2FD4A01@fgsr.local> References: <1322530073.150717.1402179785354.JavaMail.zimbra@peachymango.org> <43FBB724BB014305AF92AE07C2FD4A01@fgsr.local> Date: Sat, 7 Jun 2014 21:33:28 -0700 Message-ID: From: "Murray S. Kucherawy" To: "J. Gomez" Content-Type: multipart/alternative; boundary=047d7b86cdc2a633b304fb4b98e2 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/BVl8y3wL6hc46ciHzGZ1CRVvpWI Cc: "dmarc@ietf.org" , Franck Martin Subject: Re: [dmarc-ietf] Advice to MUA 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, 08 Jun 2014 04:33:39 -0000 --047d7b86cdc2a633b304fb4b98e2 Content-Type: text/plain; charset=UTF-8 On Sat, Jun 7, 2014 at 4:52 PM, J. Gomez wrote: > > "MUAs SHOULD display to the end user, in UTF8 (and punycode), in a > > non ambiguous font, the domain used for the assertion of the DMARC > > policy, as well as the result of this assertion. A non ambiguous font > > is a font where the graphical representation of a chararcter is not > > identical to the graphical representation of another chararcter in > > the same font" > > > > If we know what a non ambiguous font is, then may be we could > > specifiy the font name. > > I very much would like that to be included in the DMARC spec. > I would very much include such advice in documents if I thought there was any hope they would be followed. MUA developers rarely if ever participate at the level of IETF work and often do things we don't expect, which has led us to our current pattern of punting on using any kind of normative language describing user interface stuff. That is, they are consumers of things like IMAP and SMTP, but they're completely free to decide how to render the user side of those things. Moreover, at the levels the IETF deals with, we as a community would be kidding ourselves to think we understand what user interface choices work or don't, so it would be silly for us to write things into RFCs that purport otherwise. Still, I've asked this before in other contexts, and I'll ask again: Does anyone have contacts in MUA space that we might reach out to, and what chances are there of them actually engaging? I may have one with Thunderbird that I'll try to reach out to in the coming week. -MSK --047d7b86cdc2a633b304fb4b98e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Jun 7, 2014 at 4:52 PM, J. Gomez <jgomez@seryri= ch.com> wrote:
> "MUAs SHOULD displ= ay to the end user, in UTF8 (and punycode), in a
> non ambiguous font, the domain used for the assertion of the DMARC
> policy, as well as the result of this assertion. A non ambiguous font<= br> > is a font where the graphical representation of a chararcter is not > identical to the graphical representation of another chararcter in
> the same font"
>
> If we know what a non ambiguous font is, then may be we could
> specifiy the font name.

I very much would like that to be included in the DMARC spec.

I would very much include such advice in docum= ents if I thought there was any hope they would be followed.=C2=A0 MUA deve= lopers rarely if ever participate at the level of IETF work and often do th= ings we don't expect, which has led us to our current pattern of puntin= g on using any kind of normative language describing user interface stuff.= =C2=A0 That is, they are consumers of things like IMAP and SMTP, but they&#= 39;re completely free to decide how to render the user side of those things= .

Moreover, at the levels the IETF deals with, we as a community would be= kidding ourselves to think we understand what user interface choices work = or don't, so it would be silly for us to write things into RFCs that pu= rport otherwise.

Still, I've asked this before in other contex= ts, and I'll ask again: Does anyone have contacts in MUA space that we = might reach out to, and what chances are there of them actually engaging?= =C2=A0 I may have one with Thunderbird that I'll try to reach out to in= the coming week.

-MSK
--047d7b86cdc2a633b304fb4b98e2-- From nobody Sat Jun 7 21:35:02 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D769C1A02C9; Sat, 7 Jun 2014 21:34:59 -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 pwROepnTSg04; Sat, 7 Jun 2014 21:34:58 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E876B1A02C7; Sat, 7 Jun 2014 21:34:57 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hi2so513724wib.4 for ; Sat, 07 Jun 2014 21:34: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=tbS2RalzHAHtO5iFd9yoNK9Ksxu15YuG4+IlBSWJRDg=; b=acRhyCi/AGNvGfBhNCt+0x9wZeEyICNZnTBkm4CLgAZp4MlwpMP4lmCXCpOl7um//N cZ4FUnbOYu30LCaZbyVGOJI54ZRx6hTKbn+bOTqqTKjtDhPyT0xBC437DV/+yk5PV+Jc q9QkBrgLgcy5KrECdyNOhU2yvJ067M+83AI+PUzM6iSzeTwKkVkD9tmvNbUzNeXTvf6x 3dpEE/m5Bw7u386GMliG8NmJ1KoTzRPkQ+AXTybCE5OHaCGjffV/fLaH/O/X4Q2SVDeN rNtuDDx3Pq0PVNvzLqyVjlnzReT1ZJjDvPtwkP2+K1sR9jKXhaELcv8dJmiwRRglRSB1 9egQ== MIME-Version: 1.0 X-Received: by 10.194.190.42 with SMTP id gn10mr20162661wjc.9.1402202089533; Sat, 07 Jun 2014 21:34:49 -0700 (PDT) Received: by 10.180.23.104 with HTTP; Sat, 7 Jun 2014 21:34:49 -0700 (PDT) In-Reply-To: <53938B1E.2020002@isdg.net> References: <53938B1E.2020002@isdg.net> Date: Sat, 7 Jun 2014 21:34:49 -0700 Message-ID: From: "Murray S. Kucherawy" To: Hector Santos Content-Type: multipart/alternative; boundary=047d7bb708827335c404fb4b9d05 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Wrj4A-lcf3rwsggeveUloZT6m2A Cc: "dmarc@ietf.org" , IETF General Discussion Mailing List Subject: Re: [dmarc-ietf] Next IETF Meeting DMARC Related Talks 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, 08 Jun 2014 04:35:00 -0000 --047d7bb708827335c404fb4b9d05 Content-Type: text/plain; charset=UTF-8 On Sat, Jun 7, 2014 at 2:58 PM, Hector Santos wrote: > I might be interested in remote participation at the next IETF 90 meeting > if there are any DKIM/DMARC related meetings scheduled. > > I have not seen any announcements for any such DKIM/DMARC related activity. None are presently scheduled; there isn't a DMARC working group, no BoF session has been requested (that I know of), and no related work is going on in other working groups (that I know of). Of course, all of that could change, so "watch this space". -MSK --047d7bb708827335c404fb4b9d05 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Jun 7, 2014 at 2:58 PM, Hector Santos <hsantos@isd= g.net> wrote:
I might be interested in remote participatio= n at the next IETF 90 meeting if there are any DKIM/DMARC related meetings = scheduled.

I have not seen any announcements for any such DKIM/DMARC related activity.=
<= div>
None are presently scheduled; there isn't a DMARC wo= rking group, no BoF session has been requested (that I know of), and no rel= ated work is going on in other working groups (that I know of).=C2=A0 Of co= urse, all of that could change, so "watch this space".

-MSK
--047d7bb708827335c404fb4b9d05-- From nobody Sat Jun 7 21:54:04 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD641A02CB for ; Sat, 7 Jun 2014 21:54:03 -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 JFnK6Io873Vv for ; Sat, 7 Jun 2014 21:54:01 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BF681A02C7 for ; Sat, 7 Jun 2014 21:54:01 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id p10so4347519wes.6 for ; Sat, 07 Jun 2014 21:53: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=XTUOBuy0MSreTLOR228PctD9p+cvovri0qAIjUqScQo=; b=j7xQ9+JxgBYrwimkaM/9R/DUQoeX97fVwlstYQyF8/dhamz//AOe73HKm0JEqpncWw 1x75xaxU+oguGbnUZAIhu9ziqp6/R41d/htEHCegdNzLD4wuRg5H3ZO/jEdxPZds0EVe RBm+AMYivz1W34XcaChNy78S1zm2K4xT+83TeJ6sloHJoRBqjWF77aOoNMvA8aD1k+jT DfZ9zCdE7Kaq5It7giiFpfPruD3xWvJE2PgYwGUPV5QO5+qbUJAwbbE3y6mnvwJhClJW uM5vubrcojXmQnAleVjwmD7hkE/YECiIyvqux3w3s49OrEIQjvsc219niraRVn0VsMZb jcLw== X-Received: by 10.14.4.199 with SMTP id 47mr2373342eej.9.1402203232916; Sat, 07 Jun 2014 21:53:52 -0700 (PDT) Received: from ?IPv6:2a02:a03f:14c1:6600:5def:16e2:9df4:bc92? ([2a02:a03f:14c1:6600:5def:16e2:9df4:bc92]) by mx.google.com with ESMTPSA id y5sm35110661eee.1.2014.06.07.21.53.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Jun 2014 21:53:52 -0700 (PDT) Message-ID: <5393EC2B.6080501@gmail.com> Date: Sun, 08 Jun 2014 06:52:59 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Franck Martin , "dmarc@ietf.org" References: <1322530073.150717.1402179785354.JavaMail.zimbra@peachymango.org> In-Reply-To: <1322530073.150717.1402179785354.JavaMail.zimbra@peachymango.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/iG9utnjg8q8XdrG3uHtFanm94fo Subject: Re: [dmarc-ietf] Advice to MUA 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, 08 Jun 2014 04:54:03 -0000 On 6/8/2014 12:23 AM, Franck Martin wrote: > I think we need to give advice to MUAs, while letting MUA developers > some liberty on how to interpret it. > > I'm proposing the following text to be added to the DMARC spec Directives encased in standards that concern UI/UX design are appropriate when there are empirical data to support them. On the average, efforts in IETF-related discussions at making UI/UX design assertions lack that empirical basis and often even run counter to existing empirical data. Often they represent using the speaker as the user exemplar or cognitive models along the lines of "more information presented to the user is better". The former is bad methodology and the latter is known to be wrong. Think bell curve... UI/UX design is a specialty. Few of us have the necessary training or experience. A hallmark of those who do have that training and experience is knowing that world-class expertise only produces a useful /starting/ point in design, but that the /finishing/ point is rarely the same. What is required to reach that finishing point is testing of the design. I've been making that above, two-sentence summary for many years, but finally tested with a group of real UI/YX experts at the SOUPs conference last year and they nodded yes. (It's the per-eminent 'usable security' conference. Last year was England; this year is Menlo Park, CA.) > "MUAs SHOULD display to the end user, in UTF8 (and punycode), in a non > ambiguous font, the domain used for the assertion of the DMARC policy, > as well as the result of this assertion. A non ambiguous font is a font > where the graphical representation of a character is not identical to > the graphical representation of another character in the same font" This is an example of a directive for a design choice that has demonstrated very poor utility. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Jun 7 22:46:53 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553581A02F4 for ; Sat, 7 Jun 2014 22:46:51 -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 XCfmtjMvh1lk for ; Sat, 7 Jun 2014 22:46:48 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.91]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 668901A02F1 for ; Sat, 7 Jun 2014 22:46:48 -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.0.974.2; Sun, 8 Jun 2014 05:46:38 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.234]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.234]) with mapi id 15.00.0974.002; Sun, 8 Jun 2014 05:46:38 +0000 From: Terry Zink To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Advice to MUA Thread-Index: QzkwqgflJeuqeTTZKkGz/xpoaKHf4KykAwmOgABOfQCAABNj4g== Date: Sun, 8 Jun 2014 05:46:37 +0000 Message-ID: <1402206427235.99831@exchange.microsoft.com> References: <1322530073.150717.1402179785354.JavaMail.zimbra@peachymango.org> <43FBB724BB014305AF92AE07C2FD4A01@fgsr.local>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.172.11.235] x-exchange-antispam-report-test: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0236114672 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(51704005)(24454002)(199002)(189002)(377454003)(19625215002)(561944003)(81542001)(85852003)(83072002)(98676001)(81342001)(99396002)(50986002)(54316003)(49866002)(54356002)(56816006)(59766002)(56776002)(47736002)(47446003)(47976003)(65816002)(63696004)(51856002)(53806002)(16236675004)(90146001)(4396001)(94946001)(76482001)(19580395003)(46102001)(92726001)(101416001)(95416001)(20776003)(81816001)(21056001)(83322001)(95666003)(74706001)(93136001)(80022001)(92566001)(19580405001)(69226001)(97186001)(87266001)(87936001)(97336001)(64706001)(74366001)(94316002)(85306002)(2656002)(77096001)(77982001)(93516002)(76786001)(76796001)(66066001)(74502001)(74876001)(31966008)(74662001)(81686001)(79102001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2SR01MB605; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_140220642723599831exchangemicrosoftcom_" MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/jlClt-tGq-6GCTJAt0_m8cF4REI Subject: Re: [dmarc-ietf] Advice to MUA 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, 08 Jun 2014 05:46:51 -0000 --_000_140220642723599831exchangemicrosoftcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Does anyone have contacts in MUA space that we might > reach out to, and what chances are there of them actually > engaging? I'm currently working with the Outlook Web Access (OWA) team to do some UX = work for email we (Exchange Online) detect as phishing, and am similarly wo= rking with the Outlook team. Eventually Hotmail/outlook.com will move to ha= ve a similar interface as OWA. Getting UX teams to pick up the work is not easy, though. In terms of engag= ing, it depends on how much uniformity there is across the industry. There = has to be a concrete proposal in place that has either wide adoption or wid= e support. -- Terry ________________________________ From: dmarc on behalf of Murray S. Kucherawy Sent: Saturday, June 07, 2014 9:33 PM To: J. Gomez Cc: dmarc@ietf.org; Franck Martin Subject: Re: [dmarc-ietf] Advice to MUA On Sat, Jun 7, 2014 at 4:52 PM, J. Gomez > wrote: > "MUAs SHOULD display to the end user, in UTF8 (and punycode), in a > non ambiguous font, the domain used for the assertion of the DMARC > policy, as well as the result of this assertion. A non ambiguous font > is a font where the graphical representation of a chararcter is not > identical to the graphical representation of another chararcter in > the same font" > > If we know what a non ambiguous font is, then may be we could > specifiy the font name. I very much would like that to be included in the DMARC spec. I would very much include such advice in documents if I thought there was a= ny hope they would be followed. MUA developers rarely if ever participate = at the level of IETF work and often do things we don't expect, which has le= d us to our current pattern of punting on using any kind of normative langu= age describing user interface stuff. That is, they are consumers of things= like IMAP and SMTP, but they're completely free to decide how to render th= e user side of those things. Moreover, at the levels the IETF deals with, we as a community would be kid= ding ourselves to think we understand what user interface choices work or d= on't, so it would be silly for us to write things into RFCs that purport ot= herwise. Still, I've asked this before in other contexts, and I'll ask again: Does a= nyone have contacts in MUA space that we might reach out to, and what chanc= es are there of them actually engaging? I may have one with Thunderbird th= at I'll try to reach out to in the coming week. -MSK --_000_140220642723599831exchangemicrosoftcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

= > Does anyone have contacts in MUA space that we might =

= > reach out to, and what chances are there of them actually 

= > engaging?


I'm currently working with the Outlook Web Access (OWA) team to do some = UX work for email we (Exchange Online) detect as phishing, and am simi= larly working with the Outlook team. Eventually Hotmail/outlook.com will mo= ve to have a similar interface as OWA.


Getting UX teams to pick up the work is not easy, though. In terms of en= gaging, it depends on how much uniformity there is across the industry.&nbs= p;There has to be a concrete proposal in place that has either wide adoption or wi= de support.


-- Terry


From: dmarc <dmarc-bounc= es@ietf.org> on behalf of Murray S. Kucherawy <superuser@gmail.com>= ;
Sent: Saturday, June 07, 2014 9:33 PM
To: J. Gomez
Cc: dmarc@ietf.org; Franck Martin
Subject: Re: [dmarc-ietf] Advice to MUA
 
On Sat, Jun 7, 2014 at 4:52 PM, J. Gomez <jgomez@seryri= ch.com> wrote:
> "MUAs SHOULD display to the end user, in UTF8 (an= d punycode), in a
> non ambiguous font, the domain used for the assertion of the DMARC
> policy, as well as the result of this assertion. A non ambiguous font<= br> > is a font where the graphical representation of a chararcter is not > identical to the graphical representation of another chararcter in
> the same font"
>
> If we know what a non ambiguous font is, then may be we could
> specifiy the font name.

I very much would like that to be included in the DMARC spec.

I would very much include such advice in documents if I thought there = was any hope they would be followed.  MUA developers rarely if ever pa= rticipate at the level of IETF work and often do things we don't expect, wh= ich has led us to our current pattern of punting on using any kind of normative language describing user interfa= ce stuff.  That is, they are consumers of things like IMAP and SMTP, b= ut they're completely free to decide how to render the user side of those t= hings.

Moreover, at the levels the IETF deals with, we as a community would be kid= ding ourselves to think we understand what user interface choices work or d= on't, so it would be silly for us to write things into RFCs that purport ot= herwise.

Still, I've asked this before in other contexts, and I'll ask again: D= oes anyone have contacts in MUA space that we might reach out to, and what = chances are there of them actually engaging?  I may have one with Thun= derbird that I'll try to reach out to in the coming week.

-MSK
--_000_140220642723599831exchangemicrosoftcom_-- From nobody Sun Jun 8 00:29:13 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98311A0247 for ; Sun, 8 Jun 2014 00:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 xfyG88bcu97y for ; Sun, 8 Jun 2014 00:28:02 -0700 (PDT) Received: from nm48.bullet.mail.ne1.yahoo.com (nm48.bullet.mail.ne1.yahoo.com [98.138.120.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8FAC1A0384 for ; Sun, 8 Jun 2014 00:27:59 -0700 (PDT) Received: from [127.0.0.1] by nm48.bullet.mail.ne1.yahoo.com with NNFMP; 08 Jun 2014 07:27:52 -0000 Received: from [98.138.101.128] by nm48.bullet.mail.ne1.yahoo.com with NNFMP; 08 Jun 2014 07:25:10 -0000 Received: from [98.137.12.175] by tm16.bullet.mail.ne1.yahoo.com with NNFMP; 08 Jun 2014 07:25:10 -0000 Received: from [98.137.12.249] by tm14.bullet.mail.gq1.yahoo.com with NNFMP; 08 Jun 2014 07:25:10 -0000 Received: from [127.0.0.1] by omp1057.mail.gq1.yahoo.com with NNFMP; 08 Jun 2014 07:25:10 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 246212.891.bm@omp1057.mail.gq1.yahoo.com Received: (qmail 98702 invoked by uid 60001); 8 Jun 2014 07:25:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402212310; bh=8s9ASi2u8xfHtCcGSUNGHLrVr/fw6GAeyvuU9yQ0ft4=; h=Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=MlU9IHE2lVKy0wszZuFkTKQ+42bsrY5gFG4hjxuHJXvhC65j+vLrHigrqPS1xsueIARNEjb2j5ALEaQwU3TfM9ddto2FIzKg5E5XQrgqMh9U+c1dnjbCUMb3qMrTJ9ascc2vPkCsF+dwP5RUapwWecsYmp0FLJL+7clzgfj7AHw= X-YMail-OSG: LZnmUP8VM1k7lKLpPIyfngDcQ4.7T6xW.VQxPHMsHn6YWDh FjAf0EAOOunVCAPdCJll_oCFEGzsLyGpUKDXXqutXUgvRGWVJymCXQsjQKOo 5W7.4ViiqakhnaY.wYghfQCOMpF1VSNd42Ac.5PE4G3m7ccqFFsK1lnE2Psn gdpsI7GxeNAtwFmM42yP55nHU7A9oh82182CgIOOqQXfLiM7lLceN9dHe2D_ VyHJuddgGSRKqPkV5BHa3jQ8ZQxlgP9n7xj_4GYQib9MGn3.8AW.0JDVEhti 5EzG5wpd3ecfpUchN4oc1tZSU86BznlF2.NXjre0CpaYpHebAA.GggxM4NQt nifSuJt6zDeR8TqxqkkisqyeQfz4lLoNLIKzSCTYZx0rWxGLt07HJKaY6YL1 wDt6ob4fdPkR5KZK47XKD9r2pw2r9x2o2sgbEfVZAtZVqmyHPq5DuzCFJ9BO TmTSVmYI9hjvpaFdLOsyUk3iTtwIlHzDEk7KvfEDjKdBxk3e2vQzaF98FEox EZu8wQkyOSiwK8ACSLbLBcusMY3MpSMy.iwVQx_vy.mvsHe76smu2mCeoOZX Lv026hcSVMjqio9ADy.esw5ji.qj4.0Nq7N5o07pps8qFvV40AhGPgsdPG9k f Received: from [79.175.112.242] by web164605.mail.gq1.yahoo.com via HTTP; Sun, 08 Jun 2014 00:25:10 PDT X-Rocket-MIMEInfo: 002.001, aW1vLCB3aGF0IGFsbCBjdXJyZW50IERNQVJDIGRlcGxveW1lbnRzIGxhY2sgaXMgbm90aWNlIHRvCmVuZCByZWNlaXZlciBtYWlsYm94IGFib3V0IGFueSBETUFSQyB2YWxpZGF0aW9uIGRvbmUgb24gYQpwYXJ0aWN1bGFyIG1lc3NhZ2UsIGFuZCBob3cgaXQgdmFsaWRhdGVkLgoKdGh1cywgc2ltaWxhcmx5IHRvIEZyYW5jaydzIEFkdmljZSB0byBNVUFzLCBpIHdvdWxkIHByb3Bvc2UKYWRkaW5nIHRoaXMga2luZCBvZiB0eHQgdG8gRE1BUkMgZHJhZnQ6CgoKIkRNQVJDIHBhcnRpY2lwYXRpbmcgTVRBcyBTSE8BMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 Message-ID: <1402212310.40987.YahooMailNeo@web164605.mail.gq1.yahoo.com> Date: Sun, 8 Jun 2014 00:25:10 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/gVb76Vb0G8WIBqFa37ucpq_bPsc Subject: [dmarc-ietf] advice to MTAs X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 08 Jun 2014 07:28:11 -0000 imo, what all current DMARC deployments lack is notice to=0Aend receiver ma= ilbox about any DMARC validation done on a=0Aparticular message, and how it= validated.=0A=0Athus, similarly to Franck's Advice to MUAs, i would propos= e=0Aadding this kind of txt to DMARC draft:=0A=0A=0A"DMARC participating MT= As SHOULD include Authentication Results=0Afor all underlying protocols (SP= F/DKIM), as well as such results=0Afor DMARC validation itself, among heade= rs of original messages,=0Aduring DMARC processing, so they are delivered t= o end user's=0Amailbox with the message.=0A=0AIf a participating MTA decide= s to uphold this advisory, it MUST=0Aat least display:=0A1. IP address used= for SPF validation,=0A2. domain used for DKIM validation,=0A3. domain used= for DMARC alignment validation,=0A4. strings used to perform these validat= ions against:=0A=A0 a. MAIL-FROM and HELO/EHLO in case of SPF,=0A=A0 b. DKI= M signature domain,=0A=A0 c. Domain-Owner's "asfp", "adkim", "p=3D" and "sp= " DMARC tags,=0A=A0=A0=A0=A0 in case of DMARC validation,=0A5. results of e= ach validation and human readable version of it,=0Aif provided by correspon= ding protocol and if possible, including=0Aany policy overrides.=0A"=0A=0A= =0Abe free to take my txt and fix it, i know it needs refinement.=0Abut i h= ope the general idea is understood and considered valid=0Aand useful.=0A=0A= this requirement may be more realistic to happen than MUA=0Adesign change, = imo.=0A=0A=0A-- =0AVlatko Salaj aka goodone=0Ahttp://goodone.tk From nobody Sun Jun 8 02:16:19 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683191A02F3 for ; Sun, 8 Jun 2014 02:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 Ok-SJ9ZGHAg7 for ; Sun, 8 Jun 2014 02:16:16 -0700 (PDT) Received: from nm31.bullet.mail.ne1.yahoo.com (nm31.bullet.mail.ne1.yahoo.com [98.138.229.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF1F21A02D0 for ; Sun, 8 Jun 2014 02:16:16 -0700 (PDT) Received: from [127.0.0.1] by nm31.bullet.mail.ne1.yahoo.com with NNFMP; 08 Jun 2014 09:16:09 -0000 Received: from [98.138.100.116] by nm31.bullet.mail.ne1.yahoo.com with NNFMP; 08 Jun 2014 09:13:09 -0000 Received: from [98.137.12.175] by tm107.bullet.mail.ne1.yahoo.com with NNFMP; 08 Jun 2014 09:13:09 -0000 Received: from [98.137.12.224] by tm14.bullet.mail.gq1.yahoo.com with NNFMP; 08 Jun 2014 09:13:09 -0000 Received: from [127.0.0.1] by omp1032.mail.gq1.yahoo.com with NNFMP; 08 Jun 2014 09:13:09 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 612920.74503.bm@omp1032.mail.gq1.yahoo.com Received: (qmail 2652 invoked by uid 60001); 8 Jun 2014 09:13:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402218789; bh=Nbf+vRKy3AymNDJztuzMTJSyik/CmuABrN1GGK4ccq8=; h=Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=QbhwsNGxhMQp1NHFJb7XfU06sqYsI8XsjDBcv+hSwVBI4mhpgIpSqEAr6FUraTjI4dLjRCh9rEJSNRyr81IeW0Bu2AUzDLx/Km1AsXMA6djtIjnTSCiZad3eD5pLgXLtdLZolavAIo2nxhQqIpPBd35xaMZbYEMRkJMUaKwZETk= X-YMail-OSG: K5UeyxYVM1kio.ltJ6_LyIqc6JZPLFzkPbaOxoevXROLB4l iKBQC9p6C7TpUCI4QI0DJqT7uv3owV1V2ejNFBkF9d0sW.Gtx7TbOJeGq6y9 w9Xh478_VFWkYEMG3H8nRiDhSTEMnR2jZDszpOuAW49_w.4lzH2JAGWuuFSt _nwge7JcSlw0u4aiTQ.MTr8QNti897irCFe7uT4R5ABVzRkNvaNhp.OFcnAw _oPFiwfRwdi9HpoiYIymQk.wWWd3k_BweUPz6knNcmNe0zuAMu.wyGMVUcga FAhw9INEjmDqHft_m41t0L4M_lKLNkkT2H6dTZQ.DvKmum3tRNas4oB3b4Sh VZtJ_JxofZ6qdC8.47VtBkp_.5mE.hkeW3ySE63250p_Dy3eynjBvv0ePJjG zxvwzyQAy2m2s5yeeYQ_ag.G8OOSp_dhMxJr7MS_JMnp5M0WzTk4ZNr913hH OVAozNT7TOwNddR9ILhsbLEL0hXLfR7sy9SV7hPwpKml6ByKs.hWYks3QeZY UqPC4lq9PSlLDGtYUp4Tw7rRpR8h8_nr.95xJ6Cn_tLaEbUeNXI8qw4DjV6m BoB94oNmPcAAsim6PsLRGi_Vqra3L.WPumoXvnC5eTIQvi310T6Hd9rIj.WU I5qHNsp8Ub5v4izV6cT6NpAnUmJoKYhIJg7oP1L5B4ExSYo7uCY2s2AGDzm3 wUt1aZYaFJcIP222C9658vzA8 Received: from [79.175.112.242] by web164602.mail.gq1.yahoo.com via HTTP; Sun, 08 Jun 2014 02:13:09 PDT X-Rocket-MIMEInfo: 002.001, aSBjb25zaWRlciBteSAzcmQgcGFydHkgYWxpZ25tZW50IHN1cHBvcnQgZm9yIERNQVJDCmVhc3kgdG8gdW5kZXJzdGFuZCwgdHJpdmlhbCBlbm91Z2ggdG8gZGVwbG95IGFuZAp1c2VmdWwgZW5vdWdoIHRvIGNvdmVyIG1hbnkgdXNlIGNhc2VzLCBzbyBpIHdvdWxkCmxpa2UgdG8gbW92ZSBpdCB0byBJRVRGIGFzIGEsIHByb2JhYmx5LCBpbmRlcGVuZGVudApSRkMuCgpkb2VzIGFueWJvZHkgaGVyZSBzZWUgaW50ZXJlc3QgaW4gaGVscGluZyBtZSBvdXQKd2l0aCB0aGlzIHByb2NlZHVyZT8gdSBzaG91bGQgaGEBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 Message-ID: <1402218789.64411.YahooMailNeo@web164602.mail.gq1.yahoo.com> Date: Sun, 8 Jun 2014 02:13:09 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/InhZHSWxkkxCSZYkR7b2xsrabIw Subject: [dmarc-ietf] 3rd party alignment DMARC upgrade moving to RFC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 08 Jun 2014 09:16:18 -0000 i consider my 3rd party alignment support for DMARC easy to understand, trivial enough to deploy and useful enough to cover many use cases, so i would like to move it to IETF as a, probably, independent RFC. does anybody here see interest in helping me out with this procedure? u should have good english skills, and at least some xp with RFCs. be free to contact me if u do. btw, mr. Hector, would u be so kind to include my version of the proposal on ur test-page at: http://www.winserver.com/public/wcDMARC/default.wct my proposal is quite similar to what u call ASL and if we agree to merge our two proposals together to at least some degree, i may actually adopt ASL as a name for new version, but rename it to Aligned Sender List. since ur ASL logic and my ASL logic r similar enough to merge, it could be beneficial to both proposals, adding some traction to other, more, advanced 3rd party support, for cases where ASL is insufficient. also, that may be a start of a working cooperation for a true, full-fledged 3rd party DMARC standard, assimilating* ASL or in addition to ASL. [*] borg anybody? :D -- Vlatko Salaj aka goodone http://goodone.tk From nobody Sun Jun 8 02:19:50 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32641A02F3 for ; Sun, 8 Jun 2014 02:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 ZanIOL3lmzDZ for ; Sun, 8 Jun 2014 02:19:48 -0700 (PDT) Received: from nm36.bullet.mail.ne1.yahoo.com (nm36.bullet.mail.ne1.yahoo.com [98.138.229.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 646091A02D0 for ; Sun, 8 Jun 2014 02:19:48 -0700 (PDT) Received: from [127.0.0.1] by nm36.bullet.mail.ne1.yahoo.com with NNFMP; 08 Jun 2014 09:19:40 -0000 Received: from [98.138.226.176] by nm36.bullet.mail.ne1.yahoo.com with NNFMP; 08 Jun 2014 09:16:40 -0000 Received: from [98.137.12.174] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 08 Jun 2014 09:16:35 -0000 Received: from [216.39.60.198] by tm13.bullet.mail.gq1.yahoo.com with NNFMP; 08 Jun 2014 09:16:35 -0000 Received: from [127.0.0.1] by omp1085.mail.gq1.yahoo.com with NNFMP; 08 Jun 2014 09:16:35 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 522006.48417.bm@omp1085.mail.gq1.yahoo.com Received: (qmail 71528 invoked by uid 60001); 8 Jun 2014 09:16:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402218995; bh=jxtVIMGG/eaevljQq313Bm0UzNWTFpzd/m7HmRr0XrM=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Mf0tr7cjc6FZrcplqnGj38i1kN/msWIE98yUPZB+mF5YZ2As4iy1o/z/EI+hqTJFIdav8iub5fY3vr0GR+3o0dlMnglOwbhKUjFnBXF0Ulodz8/Mhp9y8UsYShqjfMha/e+EYhMUD4J16TFckqOMXZtgysPy7gc59h2xeTpu/Mc= X-YMail-OSG: GpnQif4VM1luVV_QNytwo8RmP.kgm3n.rbmbMfyxu1qme8L JYk4_31qZWncbfIOYLkXK2Cpnn8sgS86HqvJ1BFW87C0QUuk2Q2izNbpTp6t uGKN_zd4TaxMafzAj9eF.wpdRz2eLqY2jwfzngw9.LAkbpOznXwQumSx9U99 9FIvmv0VcBbOMvTbgtHPXTxmOQfAwvExFLFdlLzHdrO.HUyazniqrStwmiAh Yf98sb9ztKOfJAUCqzQ5an80QjnDTF6bX1kQQxkBGcSiAXrx9w3wd2qL85CV lhPO.r_ibwVFkraD0iRhVdfLGXfYwLXHiHmpfU54ljd01r7UznRUfLUPV.g4 r.va0YEZZC8GZm05aXhLTANMAzovou0OLSyd7_WJZ74EUt8vCvBf1ysryv5. NhT9Gf0lk3.2KJfcxtvHCOTVnQAfVlc4qGcQT9bdlPMQT8ILoAlA0vfpElrf _LTL4qjbdDzbxLkGD8OZikDHJauNrqJ4gFyzAyAzRXi9J2x4C6gdY8OR78b_ 4ZhjTGxY2H2R1Lt_s0wzJQaPplA5GFXGL0f_V62eXiJAIdEoefphIG1ej9Ua uhLNkhZKz2AE7_.UVz5.45HBM0iK04D.CU3zmG5gD7VwwBSe4xgNhW8lydO3 dZgf13mLXMZIow6Wrb64UPdMoRddrfBhf54KRBrhWwu.l2sbXDBs50rlMLnQ kNj5cKep1pnykBHpRdpXCfSNWNw-- Received: from [79.175.112.242] by web164606.mail.gq1.yahoo.com via HTTP; Sun, 08 Jun 2014 02:16:35 PDT X-Rocket-MIMEInfo: 002.001, T24gU3VuZGF5LCBKdW5lIDgsIDIwMTQgMTE6MTMgQU0sIFZsYXRrbyBTYWxhaiA8dmxhdGtvLnNhbGFqQGdvb2RvbmUudGs.IHdyb3RlOgoKPiBpIGNvbnNpZGVyIG15IDNyZCBwYXJ0eSBhbGlnbm1lbnQgc3VwcG9ydCBmb3IgRE1BUkMKCj4gZWFzeSB0byB1bmRlcnN0YW5kLCB0cml2aWFsIGVub3VnaCB0byBkZXBsb3kgYW5kCj4gdXNlZnVsIGVub3VnaCB0byBjb3ZlciBtYW55IHVzZSBjYXNlcywgc28gaSB3b3VsZAo.IGxpa2UgdG8gbW92ZSBpdCB0byBJRVRGIGFzIGEsIHByb2JhYmx5LCBpbmRlcGVuZGUBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <1402218789.64411.YahooMailNeo@web164602.mail.gq1.yahoo.com> Message-ID: <1402218995.6919.YahooMailNeo@web164606.mail.gq1.yahoo.com> Date: Sun, 8 Jun 2014 02:16:35 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" In-Reply-To: <1402218789.64411.YahooMailNeo@web164602.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/5BdbCFD-KplGbl0JMG45lwK5-No Subject: Re: [dmarc-ietf] 3rd party alignment DMARC upgrade moving to RFC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 08 Jun 2014 09:19:50 -0000 On Sunday, June 8, 2014 11:13 AM, Vlatko Salaj wrote: > i consider my 3rd party alignment support for DMARC > easy to understand, trivial enough to deploy and > useful enough to cover many use cases, so i would > like to move it to IETF as a, probably, independent > RFC. if u missed it, it's here, more or less, defined: http://www.ietf.org/mail-archive/web/dmarc/current/msg01079.html -- Vlatko Salaj aka goodone http://goodone.tk From nobody Sun Jun 8 03:27:38 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE91C1A0395 for ; Sun, 8 Jun 2014 03:27:35 -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 Iz0s-zfUJUxM for ; Sun, 8 Jun 2014 03:27:34 -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 54DA71A0394 for ; Sun, 8 Jun 2014 03:27:33 -0700 (PDT) Received: (qmail 52339 invoked from network); 8 Jun 2014 10:27:25 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 8 Jun 2014 10:27: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:mime-version:content-type:content-transfer-encoding; s=a43.53943a8e.k1406; i=johnl@user.iecc.com; bh=0PJYr+20WnGqwQ4RQ82hBKVzVA+9jVPyI6MHDiHdR7Y=; b=Vz93AGjSvpyjstTbHVjxI9In/cUU9nP8feyRvMIBcX+MkGUb9F2oV7N9gustVS69jjDIvCpmWXeDdWc2GtrQqTSH3shI5+FNZYi6t+bbgIC2X/BYmHgHQ0Vu6YWC39XNrhhVLWkAx7iLdVxS5WKifD7cEDqVnPw80DzM5eWPOOZvvZo1VIvpnU3Z/cYvNhza6INnHAV/+FgAaF0WsrwiCOtkQ5I/VDvDlkwKaL+K4NP4sA+jpM256u6o8jZQxbNK DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=a43.53943a8e.k1406; olt=johnl@user.iecc.com; bh=0PJYr+20WnGqwQ4RQ82hBKVzVA+9jVPyI6MHDiHdR7Y=; b=xaaPGVJBwHofp1zK7PkKLDvzgrShzR7f2u2TTqZrKfbTvCkJM6FTl5mUrPQnhkgvkRLyIjWa7RIzOOe0ABoLYJAcok62yx1Clm3CnKGMPX/THmmlMrYhHYnpfRZwOFonydp72uJDYbqf1epn8dqhV31naJzP7P2YUqIXGfYR245dLkXxF1aS1g+IFipZ9EQDdjGDHqhGJpqeX5vt1OlTTdqaEXJ7pIScWbfv6I6yO0I1EYoaWY42BaHQ7IKPE1Vt Date: 8 Jun 2014 10:27:03 -0000 Message-ID: <20140608102703.2626.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <53932523.4040004@gmail.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/IJ7MvgRyXAJdBntw-x8Vad0OAtI Cc: dcrocker@gmail.com Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 08 Jun 2014 10:27:36 -0000 Dave Crocker wrote: >On 6/7/2014 4:37 PM, Franck Martin wrote: >> Yahoo has been suggesting the ESPs use OAUTH, so the small business owner, can authorize >the ESP to post on its behalf via yahoo servers… Not sure if it is today possible, but there >is a bunch of apps that has been granted permission to post on Facebook, or Linkedin, or >Google+ >> >> https://developer.yahoo.com/oauth/ >> https://developer.yahoo.com/mail/ >> >> I guess there was no need for ESP to do OAUTH, till now... > >That might be an interesting line of capability to explore. I doubt that Yahoo would be thrilled if ESPs used the Yahoo API to send bulk mail. I suppose the ESP could take the message, use the API to send one copy of the message to itself so it gets Yahoo's DKIM signature, then remail that message to all the subscribers through the ESP's outgoing mail, sort of a virtuous replay attack. This could probably work but it feels overclever, and doesn't scale since no two mail providers have the same API. From nobody Sun Jun 8 03:38:51 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89411A0337 for ; Sun, 8 Jun 2014 03:38:49 -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 Nz5abuBubrZ9 for ; Sun, 8 Jun 2014 03:38:49 -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 DF71D1A032C for ; Sun, 8 Jun 2014 03:38:48 -0700 (PDT) Received: (qmail 53881 invoked from network); 8 Jun 2014 10:38:41 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 8 Jun 2014 10:38:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=a70.53943d32.k1406; i=johnl@user.iecc.com; bh=zZ9Fkumvm3JguEKAE6cQqERBtzqYDPhYx/WbvFpfIeA=; b=ZMNitsCgtSUK+ddVMmqAc9fc41dOLDl7RqiHYTvJHwukciuRG0LfiK5EGVR+hh77PBedNu4xHJ2Ik3pope1lxUMnks/w6Yu19ll85FP9MzlCI//YQQ2Zb5lV/MwbDf3yTg0iTvAwf8pO/AWunyDgyLowpsBbzDQkbu13RpYJJRuytwDEgYVl0DJ9m2MKT2GLLT+nZ/2RJnx2bqveFnPIjVOHZRm4WW5bJjHcXZOfyd/yyighaa0FaHjpyUaMRhll DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=a70.53943d32.k1406; olt=johnl@user.iecc.com; bh=zZ9Fkumvm3JguEKAE6cQqERBtzqYDPhYx/WbvFpfIeA=; b=Ql8x8FK1USMqO5nHVA+axXs1WCQJOl1YU737igNha8XajuxexeVWDj7qwkh4fAii2fGU2oy3nro3PgY7UMlKTbzqSKaMNOWpwdft8YlaqQQz2bolUX7iAQdo1H5/OglSJp7To+tbiWW+lZomBuvxbgMmSryhr2ssNxo+UlncRmPbYxc2P0r4KrowLOVeqmErG0jPqpciBAiOF/XrcaD5fGi2Pmsl051e8bcjZAzYnftAM6Vb/ZRU1BnzOfVKzHev Date: 8 Jun 2014 10:38:19 -0000 Message-ID: <20140608103819.2671.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <5393423A.2000806@gmail.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/GlKD8-ssq5LQjjjZpeuZZP-nRWo Cc: dcrocker@gmail.com Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 08 Jun 2014 10:38:50 -0000 In article <5393423A.2000806@gmail.com> you write: >On 6/7/2014 6:38 PM, Stephen J. Turnbull wrote: >> I don't know what the problem that prevented netnews from >> obsoleting mailing lists is > >At base, netnews and mailing lists are entirely different kinds of human >communication services. The critical construct that highlights the >difference is: subscriptions. Netnews has subscriptions. On the client side you can say which newsgroups you want to read, and on the server side you can say which users are allowed to read which groups. >Really, the participation and scaling characteristic differences between >bulletin boards -- which are essentially broadcast -- versus mailing >lists -- which are multicast, are huge. Huh? Usenet is multicast, with each server sending messages to other servers it knows. I suppose it's broadcast in the sense that everything goes everywhere with no overall control. That led to vast amounts of spam. Even worse, as spammers started scraping addresses off usenet messages (which as far as I can tell they no longer do, but it's too late now) people used fake addresses, leading to no accountability. One of the reasons mailing lists are useful is that there are list managers who can control who gets to post to the list and eject trolls. Moderated newsgroups sort of do that, although they have other issues. R's, John From nobody Sun Jun 8 03:51:04 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF85B1A0394 for ; Sun, 8 Jun 2014 03:51: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 ghGCNN4oNmZI for ; Sun, 8 Jun 2014 03:51:01 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D46B1A0337 for ; Sun, 8 Jun 2014 03:51:00 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id r20so2958993wiv.15 for ; Sun, 08 Jun 2014 03:50:51 -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=//UqvG4YVXjZQU4s8WcUapZbP1r9Vn5kC8CAIrsLSWU=; b=XvnosjrIJelQ/9mH0PKOOphcXuiHfAB4MU1W7sr9Hwhe6BZHloDruGcPloyi+tfUxT 7j1ZEGklvEXvHf9gHhNNBrkf5xDF4SMqHKOPYHUJ/wZZhsFdgUzg2p01oNLc+2IbXBMg 5++vobbrLoiBCz1EE5+383h1zb2/9tfb6dMowej7Z/lmOArLn6A7yxxn54ZHJ4YRXdPw HCK7fh/jRM9tYk2bZPe5pvQukQZWKl/mig52LmjuvXm0lvZrKYFWbJfz6iW5VAudVoqm c/7SmKQi39b9bvIrtXGsudMLpgqQiyUR8Ztfgcm9n3OdoPrmq9Bg0lm3lCW6LESGLE2v Aolg== X-Received: by 10.14.194.136 with SMTP id m8mr1019218een.4.1402224651411; Sun, 08 Jun 2014 03:50:51 -0700 (PDT) Received: from ?IPv6:2a02:a03f:14c1:6600:d9f6:f774:e6a2:d1dd? ([2a02:a03f:14c1:6600:d9f6:f774:e6a2:d1dd]) by mx.google.com with ESMTPSA id m2sm36934995eey.36.2014.06.08.03.50.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 08 Jun 2014 03:50:50 -0700 (PDT) Message-ID: <53943FD3.5010509@gmail.com> Date: Sun, 08 Jun 2014 12:49:55 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Levine , dmarc@ietf.org References: <20140608103819.2671.qmail@joyce.lan> In-Reply-To: <20140608103819.2671.qmail@joyce.lan> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/fwiJL9zF16TONgXOR6YDj4FIq9U Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 08 Jun 2014 10:51:02 -0000 On 6/8/2014 12:38 PM, John Levine wrote: > In article <5393423A.2000806@gmail.com> you write: >> On 6/7/2014 6:38 PM, Stephen J. Turnbull wrote: >>> I don't know what the problem that prevented netnews from >>> obsoleting mailing lists is >> >> At base, netnews and mailing lists are entirely different kinds of human >> communication services. The critical construct that highlights the >> difference is: subscriptions. > > Netnews has subscriptions. On the client side you can say which > newsgroups you want to read, and on the server side you can say > which users are allowed to read which groups. Different concept of subscription. You are describing local distribution controls. Since netnews is a global process with no concept of global access control, it is fundamentally different than the sort of centralized control embodied in a mailing list subscription. The mailing list distribution model is central control, with multicast to subscribees. The netnews distribution model is flooding distribution to whoever participates. That local distribution controls might happen in addition is just that: local policy. >> Really, the participation and scaling characteristic differences between >> bulletin boards -- which are essentially broadcast -- versus mailing >> lists -- which are multicast, are huge. > > Huh? Usenet is multicast, with each server sending messages to other > servers it knows. It uses a flooding algorithm, to make sure that a message from any server gets to all the others. Mailing lists have no built-in concept of feeding other servers. It's an entirely centralized model. > I suppose it's broadcast in the sense that > everything goes everywhere with no overall control. Yeah, that's kinda what broadcast means. > One of the reasons mailing lists are useful is that there are list > managers who can control who gets to post to the list and eject > trolls. Moderated newsgroups sort of do that, although they have > other issues. Exactly. As I said, fundamental differences. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Jun 8 07:03:27 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A401A03D2 for ; Sun, 8 Jun 2014 07:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.937 X-Spam-Level: X-Spam-Status: No, score=-99.937 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_35=0.6, J_CHICKENPOX_55=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 IInl9Vhra0OD for ; Sun, 8 Jun 2014 07:03:23 -0700 (PDT) Received: from dkim.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id CDD981A03CD for ; Sun, 8 Jun 2014 07:03:22 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=6130; t=1402236189; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=BFoLf2/TSCNFXlKtysY6wW0FEe8=; b=niPmYTGzc7rimnQpoU/8 8K6G9MKBivNXrxmKDKoN/7G540cAhnCNYgnBIaL5QDHkhWzrmu/+/aXpJV5zDgRw KXKHIi/YrqYJUmecv9sMEtVcRX2aAt1ARf56LogInP182QqDnnCV26wcjZuQoKnh 7ia/B0YYV1hZDL1EnDproeQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 08 Jun 2014 10:03:09 -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; Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1716314404.8093.3628; Sun, 08 Jun 2014 10:03:08 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=6130; t=1402236024; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=MDJs7cC BFZHSHN66WzQLKhX9R1pW6jpxg0dWs0xB418=; b=G8sqR80P5tVysn7Ex8Z4dRr p/W7WPni0c/umSSKO8jt9/3sp2Rm+xF2EZe70xPioyD4G18qYtsNLv1AEGrqu42g ydr9BrSHcX9TCxYV1BGructQ5lH/GRtFWkPKbYagcUGMPVNIFPXUnSTIl+5jB3J0 5MaE8l8YuPFJRNYy9HSw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 08 Jun 2014 10:00: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 1732671031.9.5980; Sun, 08 Jun 2014 10:00:23 -0400 Message-ID: <53946D15.5090103@isdg.net> Date: Sun, 08 Jun 2014 10:03:01 -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: Vlatko Salaj , "dmarc@ietf.org" References: <1402218789.64411.YahooMailNeo@web164602.mail.gq1.yahoo.com> In-Reply-To: <1402218789.64411.YahooMailNeo@web164602.mail.gq1.yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/6BNhNKc7FWmRmKw6oT2TT96flyY Subject: Re: [dmarc-ietf] 3rd party alignment DMARC upgrade moving to RFC 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, 08 Jun 2014 14:03:26 -0000 On 6/8/2014 5:13 AM, Vlatko Salaj wrote: > i consider my 3rd party alignment support for DMARC > easy to understand, trivial enough to deploy and > useful enough to cover many use cases, so i would > like to move it to IETF as a, probably, independent > RFC. > > does anybody here see interest in helping me out > with this procedure? u should have good english skills, > and at least some xp with RFCs. > > be free to contact me if u do. > > > btw, mr. Hector, would u be so kind to include my > version of the proposal on ur test-page at: > http://www.winserver.com/public/wcDMARC/default.wct > > my proposal is quite similar to what u call ASL and > if we agree to merge our two proposals together to at > least some degree, i may actually adopt ASL as a > name for new version, but rename it to > Aligned Sender List. > > since ur ASL logic and my ASL logic r similar enough > to merge, it could be beneficial to both proposals, > adding some traction to other, more, advanced 3rd > party support, for cases where ASL is insufficient. > > also, that may be a start of a working cooperation > for a true, full-fledged 3rd party DMARC standard, > assimilating* ASL or in addition to ASL. Hi Vlatko, Overall, the problem is backward compatibility. When we try to extend an existing protocol, we need to consider the basic implementation "ignorance" of any new extended logic. This is why "asl=" and the "atps=" tags are separate from existing tags. With the proposed idea to extend "adkim=" and "aspf=", it (the syntax parsing) can fail with existing systems. Such situations are suppose to be ok for such protocols language; unknown tags are to be ignored, not a failure, otherwise the whole extension concept allowed by the specification is a wash. Won't work well at all. But this is different from attempting to use a syntax error as an extended logic. Doing a quick search for "unknown" in the dmarc draft rev4... 5.2 General Record Format DMARC records follow the extensible "tag-value" syntax for DNS-based key records defined in DKIM [DKIM]]. Section 16 creates a registry for known DMARC tags and registers the initial set defined in this memo. Only tags defined in this memo or in later extensions, and thus added to that registry, are to be processed; unknown tags MUST be ignored. ... A DMARC policy record MUST comply with the formal specification found in Section 5.3 in that the "v" and "p" tags MUST be present and MUST appear in that order. Unknown tags MUST be ignored. Syntax errors in the remainder of the record SHOULD be discarded in favor of default values (if any) or ignored outright. So in DMARC protocol theory: o unknown tags MUST be skipped, ignored, o syntax errors SHOULD be ignored in favor of its defaults. This is ok software logic, but you have to watch the latter one. In practice, syntax errors can be a problem. It also has security implications, i.e. DoS-like attacks, overwhelming you with invalid syntax processing overhead that the operator is forced to turn off the DMARC processor. But extending an existing tag is almost guaranteed to be a parsing problem to be expected at some processor. It depends on the sophistication of the implementation, can't assume everyone is using the same "DMARC library." Generally for an extension of an existing tag=value, this is where you would change the v=DMARC1 version number to something else, i.e. v=dmarc1.1, v=dmarc2, etc. To provide an example, here is a general outline for simple token base parser for something like this: string rec = GetDMARCRecord(Author.Domain) do while rec has something string value = GetNextTag(rec,";") // rec has remaining string string tag = Split(value,"=") // value has remaining string case lowercase(tag) of "v" : process_v(value) // check version "adkim" : process_adkim(value) "aspf" : process_aspf(value) "fo" : process_fo(value) "rua" : process_ruf(value) "ruf" : process_ruf(value) "pct" : process_pct(value) "p" : process_p(value) .... end case end do The process_adkim(value) logic will MOST LIKELY only have the logic that has been specified in the DMARC draft which is check a value of: "r" "s" and nothing more. If DMARC developers had envisioned such extended value needs, it would allowed for such things as your idea. But in general, its not typical to see this for many reasons, and within the IETF, it will be pointed out that simple string parsing is better. On the other hand, one may also suggest that since we are doing this more and more with this format for many new DNS based single line command tag-based language applications, maybe we should have a formal IETF language syntax for such protocols so intelligent advanced tag-based parsers can be written. But it would be more complex and since the same functionality can be accomplished with the advanced reader required anyway, you might was well just propose a new tag, like: "adkimx=" Finally, you would need to do feasibility test to make sure there is no compatibility problem. I have not seen a problem with the various domains using "atps=y" or "asl=y" yet but who knows if there are some DMARC sites with software parsers that see the unknown tags and well, skip the entire record, do nothing in the name of avoid the possible "DoS" overhead processing attacks. It would be a 'violation' of the spec but there still needs to be a feasibility test because if most of the sites are violating the spec in this regard, then we have a protocol specification implementation "bug" and generally, in cases like this, we begin to consider "codifying" the actual industry behavior in the updated DMARC draft to whats actually seen. - SHOULD|MAY ignore unknown tags - MAY throw an exception (abort processor) Then we will get into debates on what it means to throw an exception and do we need to control it, limit it, track it, report it, block abusers, etc. Can we use a different tag for your proposal? -- HLS From nobody Sun Jun 8 08:24:56 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FA71A02FE; Sat, 7 Jun 2014 23:51:53 -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 4Cb9DScFgIah; Sat, 7 Jun 2014 23:51:52 -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 3E6BD1A01D1; Sat, 7 Jun 2014 23:51:52 -0700 (PDT) Received: from [192.168.1.45] (205.195-136-217.adsl-dyn.isp.belgacom.be [217.136.195.205]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s586pdhR025772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 7 Jun 2014 23:51:44 -0700 Message-ID: <539407C6.1070604@dcrocker.net> Date: Sun, 08 Jun 2014 08:50:46 +0200 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John C Klensin References: <53938B1E.2020002@isdg.net> <5F14A8207940865BA1BB5186@JcK-HP8200.jck.com> In-Reply-To: <5F14A8207940865BA1BB5186@JcK-HP8200.jck.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sat, 07 Jun 2014 23:51:45 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/-VSnYq7Dl2-vCWf8F66ceMASZ8Q X-Mailman-Approved-At: Sun, 08 Jun 2014 08:24:54 -0700 Cc: dmarc@ietf.org, IETF General Discussion Mailing List Subject: Re: [dmarc-ietf] Next IETF Meeting DMARC Related Talks 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: Sun, 08 Jun 2014 06:51:53 -0000 On 6/8/2014 8:32 AM, John C Klensin wrote: > Murray, you didn't mention whether there is any ongoing > discussion in dmarc.org and, if so, how Hector can participate > there. That's because Hector is already active in the IETF's DMARC discussion list, which was an addressee of your note, as it is of this one... > If there are no further discussions there and dmarc.org > is turning change control over to the IETF, it might be helpful > for people here to know that. Discussions continue. To my non-expert eyes, the IPR statements in the base I-D spec: https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ is standard IETF boilerplate and already shows the IETF Trust as holding copyright... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Jun 8 08:25:02 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E97331A0342; Sat, 7 Jun 2014 23:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 J39gGdCNBuSa; Sat, 7 Jun 2014 23:33:04 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E43E31A026B; Sat, 7 Jun 2014 23:33:03 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WtWdO-0002V3-D3; Sun, 08 Jun 2014 02:31:14 -0400 Date: Sun, 08 Jun 2014 02:32:45 -0400 From: John C Klensin To: "Murray S. Kucherawy" , Hector Santos Message-ID: <5F14A8207940865BA1BB5186@JcK-HP8200.jck.com> In-Reply-To: References: <53938B1E.2020002@isdg.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/wZQpO3EDbLKa7B_TNAzGZKCmsqU X-Mailman-Approved-At: Sun, 08 Jun 2014 08:24:59 -0700 Cc: dmarc@ietf.org, IETF General Discussion Mailing List Subject: Re: [dmarc-ietf] Next IETF Meeting DMARC Related Talks 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, 08 Jun 2014 06:33:06 -0000 --On Saturday, June 07, 2014 21:34 -0700 "Murray S. Kucherawy" wrote: > On Sat, Jun 7, 2014 at 2:58 PM, Hector Santos > wrote: > >> I might be interested in remote participation at the next >> IETF 90 meeting if there are any DKIM/DMARC related meetings >> scheduled. >> >> I have not seen any announcements for any such DKIM/DMARC >> related activity. > > > None are presently scheduled; there isn't a DMARC working > group, no BoF session has been requested (that I know of), and > no related work is going on in other working groups (that I > know of). Of course, all of that could change, so "watch this > space". Murray, you didn't mention whether there is any ongoing discussion in dmarc.org and, if so, how Hector can participate there. If there are no further discussions there and dmarc.org is turning change control over to the IETF, it might be helpful for people here to know that. Conversely, if discussions on the IETF dmarc list (or the IETF list) are simply taken as input to a change control and decision process that is not described on the dmarc.org web pages or in any other obvious place, it would be good to be explicit about that. regards, john From nobody Sun Jun 8 08:25:37 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503C41A03C1 for ; Sun, 8 Jun 2014 05:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 cxfWf5_ulwKy for ; Sun, 8 Jun 2014 05:46:09 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A0971A03BD for ; Sun, 8 Jun 2014 05:46:09 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi2so802484wib.7 for ; Sun, 08 Jun 2014 05:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=D5wrjhr+AOHXNMDv7leZQyrWkSlMlGbc4RnoReODM7E=; b=VzUI0EuxaMbxiRSh8KUx/N1LF8x5NzUdmtKeb5eqlKJkCXxRjlDmoWNUdNZMyeAJhI DuS/393h/oZ7rx/AeMSSyvFIH5LNTPGMOK0Ce3pmlXlL7e2TlddYSRZE8nQLzIvQL4nd 9Pg8bHa0Rn2ijfHWkc8ft+3aRd63gufVacLOGYnB/xmuddZyvaGygWuISMFkmhbomgke 5sZDYWRAtU+r3rN51Z0TjFBN/xxOJ+mMfHTF134XvHJOkXFIobTQMaIDAa6TCwjVGH/l jnNyscff+aBQSGv5QuwcrcVvcwQ9F5sW1lwuBLBLiTd5zp9ZxYdxy1A4jCvDqbjkdb4T ctAg== MIME-Version: 1.0 X-Received: by 10.194.24.36 with SMTP id r4mr23036913wjf.39.1402231560585; Sun, 08 Jun 2014 05:46:00 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.79.136 with HTTP; Sun, 8 Jun 2014 05:46:00 -0700 (PDT) In-Reply-To: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Sun, 8 Jun 2014 08:46:00 -0400 X-Google-Sender-Auth: YuH-upsz-4Z2oKoeulKVKMj2miU Message-ID: From: Phillip Hallam-Baker To: "Stephen J. Turnbull" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/-8MSi1LopVezSw3_Z0Iw6K_Z2ns X-Mailman-Approved-At: Sun, 08 Jun 2014 08:25:36 -0700 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 08 Jun 2014 12:46:11 -0000 On Sat, Jun 7, 2014 at 12:38 PM, Stephen J. Turnbull wrote: > I'm not sure what the long list of addressees was about, but I'm not > comfortable with them. Feel free to repost my message if you wish. > > Phillip Hallam-Baker writes: > > > In the medium term, lets kill the stupidity of mailing lists with a > > protocol that works. NNTP was originally designed to replace mailing > > lists. > > GNU Mailman is thinking about this for Mailman 3. Of course we've > long had a mostly functional mail-to-news bidrectional gateway, but > Mailman 3 is considering adding NNTP capability directly to the > bundled archiver, or perhaps a separate facility resembling an > archiver as far as Mailman core is concerned.[1] I don't think this > has gone anywhere yet, though. NNTP was designed 30 years ago. We should consider moving on. The modern protocol world is JSON/REST > > It actually works quite well at that. The only problem was the > > IT-Dictator mindset that underlies it: newsgroups have to be > > approved by the Commune! > > Nonsense. I don't know what the problem that prevented netnews from > obsoleting mailing lists is, but the alt hierarchy has always been > available, and GMane proves that you can run a whole alternative NNTP > network without trouble and with a reasonable amount of resources. So > it's not the Cabal's fault (by the way, there is no cabal, in case you > haven't heard). Well you don't get the difference between the Web and the Internet then. We built the web on a model where the individual was empowered. Having to get a proposal for a newsgroup approved by an amorphous collective isn't empowering. The lack of clear control does not mean that there isn't any. It just means that the control is exercised without accountability. NNTP was built to save bandwidth, hence the need to manage what data went where. But we could certainly drop the server-server copy functions and just declare the mailing lists as site local. The problem with that approach is that we then have to have accounts and the single log in problem grows unless we interface to one of the single log in schemes, all of which have problems. From nobody Sun Jun 8 08:38:38 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6E01A00D4 for ; Sun, 8 Jun 2014 08:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[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 vCZK1L007SXX for ; Sun, 8 Jun 2014 08:38:08 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A498B1A00D2 for ; Sun, 8 Jun 2014 08:38:07 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id x48so1978502wes.25 for ; Sun, 08 Jun 2014 08:38: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=spycuDnkQH2nctabZr2bVfZJmPudJTPrsBteCgifSQs=; b=N/jKddYN//GjhNh1sHFs3DznzrdT530jGGiT/7Q3skY/dsx0a5U/csXb+FUCsFUuhZ GlxxFvQIzp2HVjFowuwx/YW16hiF4ZNLA+g+ZF2X2VAZO9+7Qvrd7dUeF7KhqgpfFZrW WF24iNabvdwyZgOYGKmEIIm+RAvptGmfTnsghzKy1EVZZprMVlcBreb+0fmTgUq9M8x4 u/E3TJyePPvKJ+R8TW55vPcWubLGCItF6ddBb/2ly876eYZTf/nafY5DIdMZYUK7Jx3g Xks0JskckUzX6OxbDen6gc04/Av7z8waaozFq1w0BtmBw5fbw+gPbtTdgk/HKld9uZbi lvuQ== MIME-Version: 1.0 X-Received: by 10.194.161.168 with SMTP id xt8mr24058309wjb.35.1402241433367; Sun, 08 Jun 2014 08:30:33 -0700 (PDT) Received: by 10.180.23.104 with HTTP; Sun, 8 Jun 2014 08:30:33 -0700 (PDT) In-Reply-To: <1402212310.40987.YahooMailNeo@web164605.mail.gq1.yahoo.com> References: <1402212310.40987.YahooMailNeo@web164605.mail.gq1.yahoo.com> Date: Sun, 8 Jun 2014 08:30:33 -0700 Message-ID: From: "Murray S. Kucherawy" To: Vlatko Salaj Content-Type: multipart/alternative; boundary=089e01419c6a867c1a04fb54c6e3 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/LfZsEJR3LrdlaLY8X_8LZOtNoCE Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] advice to MTAs 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, 08 Jun 2014 15:38:18 -0000 --089e01419c6a867c1a04fb54c6e3 Content-Type: text/plain; charset=UTF-8 On Sun, Jun 8, 2014 at 12:25 AM, Vlatko Salaj wrote: > imo, what all current DMARC deployments lack is notice to > end receiver mailbox about any DMARC validation done on a > particular message, and how it validated. > > thus, similarly to Franck's Advice to MUAs, i would propose > adding this kind of txt to DMARC draft: > > > "DMARC participating MTAs SHOULD include Authentication Results > for all underlying protocols (SPF/DKIM), as well as such results > for DMARC validation itself, among headers of original messages, > during DMARC processing, so they are delivered to end user's > mailbox with the message. > [...] > That's interesting. I imagine I assumed they were all (or would all be) doing that already, so it wasn't made explicit. I'm not so sure about the SHOULD because the only interoperability A-R enables is stuff between the verifiers and the MUAs and humans, really. It certainly wouldn't be a bad idea for us to highlight how useful it would be though. It is mentioned in Section 6, but the mention there doesn't even say that it's the DMARC result that's supposed to be recorded. That bit at least needs to be fixed. Anyone else have a comment? -MSK --089e01419c6a867c1a04fb54c6e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Jun 8, 2014 at 12:25 AM, Vlatko Salaj <vlat= ko.salaj@goodone.tk> wrote:
imo, what all current DMARC deployments lack= is notice to
end receiver mailbox about any DMARC validation done on a
particular message, and how it validated.

thus, similarly to Franck's Advice to MUAs, i would propose
adding this kind of txt to DMARC draft:


"DMARC participating MTAs SHOULD include Authentication Results
for all underlying protocols (SPF/DKIM), as well as such results
for DMARC validation itself, among headers of original messages,
during DMARC processing, so they are delivered to end user's
mailbox with the message.
[...]

That= 's interesting.=C2=A0 I imagine I assumed they were all (or would all b= e) doing that already, so it wasn't made explicit.

I&= #39;m not so sure about the SHOULD because the only interoperability A-R en= ables is stuff between the verifiers and the MUAs and humans, really.=C2=A0= It certainly wouldn't be a bad idea for us to highlight how useful it = would be though.

It is mentioned in Section 6, but the mention there doesn= 9;t even say that it's the DMARC result that's supposed to be recor= ded.=C2=A0 That bit at least needs to be fixed.

Anyone el= se have a comment?

-MSK
--089e01419c6a867c1a04fb54c6e3-- From nobody Sun Jun 8 08:42:14 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D99F1A0357; Sun, 8 Jun 2014 08:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[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 46kLvwCpJp5L; Sun, 8 Jun 2014 08:41:54 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CBCB1A0089; Sun, 8 Jun 2014 08:41:54 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi2so911857wib.1 for ; Sun, 08 Jun 2014 08:41: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=zhETK1y6+/hJTcxAlneHnRtDel7z89x/XP7EOTgHnZ0=; b=OTLGGIckX7Im+IAARBQJmHtmDwQptspx3ys57JEDTm9s2z/pvCgRqkBrDGlLTVmxFq IdYirvf4P7IEzP4EOgHtVvEJEvpkOBChaN2CDe/lWlgPeYFtKN3XF+CjSP6A+iVJjMio 2hplYrDDc9ucDQnK1zN8zKoiFzSwUrp5nYXle+axmyanIVN038wR+Ks7h+bRkB9FcB9d tF4G1lLzF9i8RILV755BXEeHhqG8AYJmz/qBHixKwmgwaCbicQZPD1mKwJfcHoq9jemI v6dswU3o9qibeo7f4hgufPrExfZZgIpdzyfJl/IwCHR755BXUX1JoZWEifyqJMZJ7sdT wg5w== MIME-Version: 1.0 X-Received: by 10.180.212.77 with SMTP id ni13mr23802260wic.5.1402242112975; Sun, 08 Jun 2014 08:41:52 -0700 (PDT) Received: by 10.180.23.104 with HTTP; Sun, 8 Jun 2014 08:41:52 -0700 (PDT) In-Reply-To: <5F14A8207940865BA1BB5186@JcK-HP8200.jck.com> References: <53938B1E.2020002@isdg.net> <5F14A8207940865BA1BB5186@JcK-HP8200.jck.com> Date: Sun, 8 Jun 2014 08:41:52 -0700 Message-ID: From: "Murray S. Kucherawy" To: John C Klensin Content-Type: multipart/alternative; boundary=001a11c23e5a0879f904fb54efe7 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/suT0ILnLhs6_Jpym-y01oScanPU Cc: "dmarc@ietf.org" , Hector Santos , IETF General Discussion Mailing List Subject: Re: [dmarc-ietf] Next IETF Meeting DMARC Related Talks 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, 08 Jun 2014 15:41:59 -0000 --001a11c23e5a0879f904fb54efe7 Content-Type: text/plain; charset=UTF-8 On Sat, Jun 7, 2014 at 11:32 PM, John C Klensin wrote: > Murray, you didn't mention whether there is any ongoing > discussion in dmarc.org and, if so, how Hector can participate > there. If there are no further discussions there and dmarc.org > is turning change control over to the IETF, it might be helpful > for people here to know that. Conversely, if discussions on the > IETF dmarc list (or the IETF list) are simply taken as input to > a change control and decision process that is not described on > the dmarc.org web pages or in any other obvious place, it would > be good to be explicit about that. > Hi John, There are two active venues for discussion about DMARC. This one is the primary one. There is a legacy list operated at dmarc.org that has more casual conversation not geared to specification development and advancement. We are still discussing the change control transfer, but I can say that do so was always the end goal. It has been submitted to the ISE, but it's always possible to make important changes while it's pending in that queue. -MSK --001a11c23e5a0879f904fb54efe7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Jun 7, 2014 at 11:32 PM, John C Klensin <john-ie= tf@jck.com> wrote:
Murray, you didn't mention whether there= is any ongoing
discussion in dmarc.org = and, if so, how Hector can participate
there. =C2=A0If there are no further discussions there and dmarc.org
is turning change control over to the IETF, it might be helpful
for people here to know that. =C2=A0Conversely, if discussions on the
IETF dmarc list (or the IETF list) are simply taken as input to
a change control and decision process that is not described on
the dmarc.org web pages = or in any other obvious place, it would
be good to be explicit about that.

Hi J= ohn,

There are two active venues for discussion about DMA= RC.=C2=A0 This one is the primary one.=C2=A0 There is a legacy list operate= d at dmarc.org that has more casual conver= sation not geared to specification development and advancement.

We are still discussing the change control transfer, but I c= an say that do so was always the end goal.=C2=A0 It has been submitted to t= he ISE, but it's always possible to make important changes while it'= ;s pending in that queue.

-MSK
--001a11c23e5a0879f904fb54efe7-- From nobody Sun Jun 8 09:33:18 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC5F1A007C for ; Sun, 8 Jun 2014 09:33:17 -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=[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 rpWQtL47g8um for ; Sun, 8 Jun 2014 09:33:14 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [192.254.77.197]) by ietfa.amsl.com (Postfix) with ESMTP id A5F441A006B for ; Sun, 8 Jun 2014 09:33:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 322CDA04BC; Sun, 8 Jun 2014 11:33:14 -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 yrdK97hikJaV; Sun, 8 Jun 2014 11:33:14 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 11B47A04B4; Sun, 8 Jun 2014 11:33:14 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id EF95CA04BC; Sun, 8 Jun 2014 11:33:13 -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 W_QnKAcjcN5l; Sun, 8 Jun 2014 11:33:13 -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 D3F9BA04B4; Sun, 8 Jun 2014 11:33:13 -0500 (CDT) Date: Sun, 8 Jun 2014 11:33:13 -0500 (CDT) From: Franck Martin To: "Murray S. Kucherawy" Message-ID: <1322124542.1687.1402245193573.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <1402212310.40987.YahooMailNeo@web164605.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1686_1996789973.1402245193572" X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF29 (Mac)/8.0.5_GA_5839) Thread-Topic: advice to MTAs Thread-Index: dH9NhDI1mUu9g4tSSXgoXXo53RgapQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/_3CkZUzZaU2bJ_iWPYsw_ZFeYP0 Cc: Vlatko Salaj , dmarc@ietf.org Subject: Re: [dmarc-ietf] advice to MTAs 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, 08 Jun 2014 16:33:17 -0000 ------=_Part_1686_1996789973.1402245193572 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Murray S. Kucherawy" > To: "Vlatko Salaj" > Cc: dmarc@ietf.org > Sent: Sunday, June 8, 2014 5:30:33 PM > Subject: Re: [dmarc-ietf] advice to MTAs > On Sun, Jun 8, 2014 at 12:25 AM, Vlatko Salaj < vlatko.salaj@goodone.tk > > wrote: > > imo, what all current DMARC deployments lack is notice to > > > end receiver mailbox about any DMARC validation done on a > > > particular message, and how it validated. > > > thus, similarly to Franck's Advice to MUAs, i would propose > > > adding this kind of txt to DMARC draft: > > > "DMARC participating MTAs SHOULD include Authentication Results > > > for all underlying protocols (SPF/DKIM), as well as such results > > > for DMARC validation itself, among headers of original messages, > > > during DMARC processing, so they are delivered to end user's > > > mailbox with the message. > > > [...] > > That's interesting. I imagine I assumed they were all (or would all be) doing > that already, so it wasn't made explicit. > I'm not so sure about the SHOULD because the only interoperability A-R > enables is stuff between the verifiers and the MUAs and humans, really. It > certainly wouldn't be a bad idea for us to highlight how useful it would be > though. > It is mentioned in Section 6, but the mention there doesn't even say that > it's the DMARC result that's supposed to be recorded. That bit at least > needs to be fixed. > Anyone else have a comment? We based DMARC spec on the From header because it is visible to the end user. I understand it is hard to indicate a UI design specification, but we should advice MUA that this header and especially the domain name(s) found there are important, and they should remain visible and easily readable (in a non confusing way) to the end user. So I'm happy with advice to MTA, and I still think we should do an advice to the MUA, by telling what is important to us. ------=_Part_1686_1996789973.1402245193572 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
From: "Murray S. Kucherawy" <superuser@= gmail.com>
To: "Vlatko Salaj" <vlatko.salaj@goodone.tk><= br>Cc: dmarc@ietf.org
Sent: Sunday, June 8, 2014 5:30:33 P= M
Subject: Re: [dmarc-ietf] advice to MTAs

On Sun, Jun 8, 2014 at 12:25 AM, Vlatko Salaj <vlatko.s= alaj@goodone.tk> wrote:
imo, what all current DM= ARC deployments lack is notice to
end receiver mailbox about any DMARC validation done on a
particular message, and how it validated.

thus, similarly to Franck's Advice to MUAs, i would propose
adding this kind of txt to DMARC draft:


"DMARC participating MTAs SHOULD include Authentication Results
for all underlying protocols (SPF/DKIM), as well as such results
for DMARC validation itself, among headers of original messages,
during DMARC processing, so they are delivered to end user's
mailbox with the message.
[...]

That= 's interesting.  I imagine I assumed they were all (or would all be) d= oing that already, so it wasn't made explicit.

I'm not so sure about the SHOULD because the only interoperability A-R ena= bles is stuff between the verifiers and the MUAs and humans, really.  = It certainly wouldn't be a bad idea for us to highlight how useful it would= be though.

It is mentioned in Section 6, but the mention= there doesn't even say that it's the DMARC result that's supposed to be re= corded.  That bit at least needs to be fixed.

Anyone= else have a comment?
We based= DMARC spec on the From header because it is visible to the end user. I und= erstand it is hard to indicate a UI design specification, but we should adv= ice MUA that this header and especially the domain name(s) found there are = important, and they should remain visible and easily readable (in a non con= fusing way) to the end user.

So I'm happy with= advice to MTA, and I still think we should do an advice to the MUA, by tel= ling what is important to us.
------=_Part_1686_1996789973.1402245193572-- From nobody Sun Jun 8 09:51:38 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022561A0089; Sun, 8 Jun 2014 08:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.351 X-Spam-Level: X-Spam-Status: No, score=-1.351 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] 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 T---Ox2yjdDb; Sun, 8 Jun 2014 08:40:13 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6F0A1A00D2; Sun, 8 Jun 2014 08:40:12 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WtfB0-0003JT-S5; Sun, 08 Jun 2014 11:38:30 -0400 Date: Sun, 08 Jun 2014 11:40:03 -0400 From: John C Klensin To: dcrocker@bbiw.net Message-ID: <4465008835DE6369E27DA302@JcK-HP8200.jck.com> In-Reply-To: <539407C6.1070604@dcrocker.net> References: <53938B1E.2020002@isdg.net> <5F14A8207940865BA1BB5186@JcK-HP8200.jck.com> <539407C6.1070604@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ePacz3zmYwo6DWR2Ftk3Ljudnok X-Mailman-Approved-At: Sun, 08 Jun 2014 09:51:36 -0700 Cc: dmarc@ietf.org, IETF General Discussion Mailing List Subject: Re: [dmarc-ietf] Next IETF Meeting DMARC Related Talks 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, 08 Jun 2014 15:40:18 -0000 --On Sunday, June 08, 2014 08:50 +0200 Dave Crocker wrote: > On 6/8/2014 8:32 AM, John C Klensin wrote: >> Murray, you didn't mention whether there is any ongoing >> discussion in dmarc.org and, if so, how Hector can participate >> there. > > That's because Hector is already active in the IETF's DMARC > discussion list, which was an addressee of your note, as it is > of this one... And, because I'm still confused about change control and decision processes (see below), I deliberately asked about dmarc.org, not about the IETF's DMARC discussion list. >> If there are no further discussions there and dmarc.org >> is turning change control over to the IETF, it might be >> helpful for people here to know that. > > Discussions continue. > > To my non-expert eyes, the IPR statements in the base I-D spec: > > https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/ > > is standard IETF boilerplate and already shows the IETF Trust > as holding copyright... To my non-expert eyes, informed by many years of IETF IPR discussions and a recent rereading of the IETF Trust policies, the copyright is important if someone wants to reproduce the document (not at issue here, AFICT) or if the IETF decides create a WG that intended to use the work as a starting point, possibly forking it. As far as I know, no one has suggested the latter. The copyright would be equally irrelevant if the IETF decided to ignore DMARC (except as a learning experience) and adopt some other technology. I asked about voluntary handoff of change control; I don't see want your response about copyright has to do with that. I hope we are not heading into another round in which the IETF is asked to adopt another technology and standardize it but told that it can't make substantive changes in that technology because it has already been discussed, adopted, and deployed elsewhere but that possibility is precisely why the question of change control is relevant. Copyright in a document not produced in the IETF does not appear to be. best, john From nobody Sun Jun 8 10:00:43 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3A81A01D4 for ; Sun, 8 Jun 2014 10:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.509 X-Spam-Level: ** X-Spam-Status: No, score=2.509 tagged_above=-999 required=5 tests=[HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 xkjAgVqIG3S0 for ; Sun, 8 Jun 2014 10:00:39 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4481A0092 for ; Sun, 8 Jun 2014 10:00:38 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 9A4E2970B37; Mon, 9 Jun 2014 02:00:37 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 878F61A2744; Mon, 9 Jun 2014 02:00:37 +0900 (JST) From: "Stephen J. Turnbull" To: Phillip Hallam-Baker In-Reply-To: References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Mon, 09 Jun 2014 02:00:37 +0900 Message-ID: <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/LaL0pDjA0YYzY6lK7YJ6ajiFCRw Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 08 Jun 2014 17:00:40 -0000 Phillip Hallam-Baker writes: > NNTP was designed 30 years ago. We should consider moving on. > The modern protocol world is JSON/REST That's off-topic for this list, IMO, and I don't intend to discuss it unless the moderator(s) make clear that it is on-topic. What I believe is on-topic is that several people participating in development of DMARC-related standards have expressed concern about the impact on mailing lists. There's no question that "p=reject" is a knife at our throats, because much of the value-added of Mailman-style lists to end users is in the "decoration" added to posts, and I have yet to see anyone (except Franck Martin) say on the Mailman channels that From-corruption is completely acceptable. All mitigations proposed so far are deeply unpopular with our users (list operators), as well as with the developers. Nor is it clear that any standard for third party authentication will be approved at all, let alone adopted widely by Author Domains in good time. The mention of Usenet suggested a completely "out of the box" way to sidestep DMARC impact by avoiding SMTP entirely, using NNTP as an alternative transport. I merely wanted to make it clear that GNU Mailman is *technically* prepared to think about that kind of thing, if better mitigations for the SMTP transport aren't developed. (Development of a new "modern" transport is completely out of the question for us; we have neither the skills nor the resources.) Both the security ramifications of NNTP and the social ramifications of changing from a push protocol to a pull protocol for transport are entirely unclear to me, however. And of course I don't speak for any other MLM development communities. From nobody Sun Jun 8 10:09:19 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38EAF1A0139 for ; Sun, 8 Jun 2014 10:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 oi1kkfjujx2a for ; Sun, 8 Jun 2014 10:09:15 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id 97CDE1A0114 for ; Sun, 8 Jun 2014 10:09:15 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 998E4970B37; Mon, 9 Jun 2014 02:09:14 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 87E121A2744; Mon, 9 Jun 2014 02:09:14 +0900 (JST) From: "Stephen J. Turnbull" To: Franck Martin In-Reply-To: <1322124542.1687.1402245193573.JavaMail.zimbra@peachymango.org> References: <1402212310.40987.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1322124542.1687.1402245193573.JavaMail.zimbra@peachymango.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Mon, 09 Jun 2014 02:09:14 +0900 Message-ID: <878up71g79.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/m6U_hwkq3ByQ-CrnEdtxA7RM6sg Cc: Vlatko Salaj , dmarc@ietf.org, "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] advice to MTAs 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, 08 Jun 2014 17:09:16 -0000 Franck Martin writes: > So I'm happy with advice to MTA, and I still think we should do an > advice to the MUA, by telling what is important to us. I think the BCP is the appropriate place for recommendations to the MUA. SPF, DKIM, and DMARC are a couple of protocol layers lower than what MUA developers are interested in; they aren't going to read the technical spec for DMARC. The A-R field is another matter: see my reply to Murray. Steve From nobody Sun Jun 8 10:19:00 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB241A0352 for ; Sun, 8 Jun 2014 10:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 eTZa1MvgY3oM for ; Sun, 8 Jun 2014 10:18:53 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id 146D21A0245 for ; Sun, 8 Jun 2014 10:18:52 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 4D09E970B2E; Mon, 9 Jun 2014 02:18:52 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 3BB091A2744; Mon, 9 Jun 2014 02:18:52 +0900 (JST) From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: <1402212310.40987.YahooMailNeo@web164605.mail.gq1.yahoo.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Mon, 09 Jun 2014 02:18:52 +0900 Message-ID: <877g4r1fr7.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/SGWep-Ihh6mXg64bZW-tY-GegNU Cc: Vlatko Salaj , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] advice to MTAs 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, 08 Jun 2014 17:18:54 -0000 Murray S. Kucherawy writes: > I'm not so sure about the SHOULD because the only interoperability > A-R enables is stuff between the verifiers and the MUAs and humans, > really. It certainly wouldn't be a bad idea for us to highlight > how useful it would be though. I'm in strong agreement with the "SHOULD" (at least). If we want to ask the MUA developers to do something to inform the end user about authentication results, we sure as shooting should put our protocol where our mouth is by putting in a requirement that MTAs give them that information. I have no opinion about the specifics of Vlatko's list, and I also suspect that it might want to be "SHOULD provide these A-R data *by default*," with the nuance that MTAs can provide a configuration option to reduce the chatter. (They're presumably logging all this information, right? A-R is a convenience for MUAs, sysadmins can use the logs although they too might find an A-R field very convenient.) From nobody Sun Jun 8 11:08:10 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC301A0102 for ; Sun, 8 Jun 2014 11:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 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, RP_MATCHES_RCVD=-0.651, 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 QCwSD5v1z5vw for ; Sun, 8 Jun 2014 11:08:07 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C7AC1A00F8 for ; Sun, 8 Jun 2014 11:08:07 -0700 (PDT) Received: from [10.10.20.3] (c-50-136-244-117.hsd1.ca.comcast.net [50.136.244.117]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id s58I82gX028099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 8 Jun 2014 11:08:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1402250884; bh=sPLuDftQr3mrCW1mJ12QsRo0R424QhqLIJzI81R41L8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=LoQ+p0unRiftCmG85w2JE5SPuUeS8750FYJpdogDgRDqMWslc/BAaKy5v7UgchNO/ A7hku1nmrCa4WiMa5A4PSj6izJ+fHLzKOpUS5ilio7MplM2wRgPfqpJNYhOn0cUbk9 ba5u3IFg31lbkdoGYIwA4UG47dqPUJIKjF0WP+E0= Message-ID: <5394A681.1040301@bluepopcorn.net> Date: Sun, 08 Jun 2014 11:08:01 -0700 From: Jim Fenton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , John C Klensin References: <53938B1E.2020002@isdg.net> <5F14A8207940865BA1BB5186@JcK-HP8200.jck.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------080707030907070409070602" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/NJtOp1hlvmZGszvDb_n7TXl9LCg Cc: "dmarc@ietf.org" , Hector Santos Subject: Re: [dmarc-ietf] Next IETF Meeting DMARC Related Talks 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, 08 Jun 2014 18:08:08 -0000 This is a multi-part message in MIME format. --------------080707030907070409070602 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 06/08/2014 08:41 AM, Murray S. Kucherawy wrote: > On Sat, Jun 7, 2014 at 11:32 PM, John C Klensin > wrote: > > Murray, you didn't mention whether there is any ongoing > discussion in dmarc.org and, if so, how Hector > can participate > there. If there are no further discussions there and dmarc.org > > is turning change control over to the IETF, it might be helpful > for people here to know that. Conversely, if discussions on the > IETF dmarc list (or the IETF list) are simply taken as input to > a change control and decision process that is not described on > the dmarc.org web pages or in any other obvious > place, it would > be good to be explicit about that. > > > Hi John, > > There are two active venues for discussion about DMARC. This one is > the primary one. There is a legacy list operated at dmarc.org > that has more casual conversation not geared to > specification development and advancement. Given that on this list there was no discussion of or response to the detailed review of the -04 draft that I sent on April 16, I came to the conclusion that specification development, if any is going on, is happening somewhere else. -Jim --------------080707030907070409070602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 06/08/2014 08:41 AM, Murray S. Kucherawy wrote:
On Sat, Jun 7, 2014 at 11:32 PM, John C Klensin <john-ietf@jck.com> wrote:
Murray, you didn't mention whether there is any ongoing
discussion in dmarc.org and, if so, how Hector can participate
there.  If there are no further discussions there and dmarc.org
is turning change control over to the IETF, it might be helpful
for people here to know that.  Conversely, if discussions on the
IETF dmarc list (or the IETF list) are simply taken as input to
a change control and decision process that is not described on
the dmarc.org web pages or in any other obvious place, it would
be good to be explicit about that.

Hi John,

There are two active venues for discussion about DMARC.  This one is the primary one.  There is a legacy list operated at dmarc.org that has more casual conversation not geared to specification development and advancement.

Given that on this list there was no discussion of or response to the detailed review of the -04 draft that I sent on April 16, I came to the conclusion that specification development, if any is going on, is happening somewhere else.

-Jim
--------------080707030907070409070602-- From nobody Sun Jun 8 13:25:12 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBAEB1A0403 for ; Sun, 8 Jun 2014 13:25: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 Nw406KNepcbt for ; Sun, 8 Jun 2014 13:25:10 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DD831A0175 for ; Sun, 8 Jun 2014 13:25:09 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id u56so548409wes.7 for ; Sun, 08 Jun 2014 13:25: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=uK7ukdUJErdV+sihtqX75vMZDbSy9rjvZeeh+Dxalw0=; b=Pci0Lc77Mk2HiHC0R4DbOrf8UlpD+EGmD4t7Jr6nivV14v+hqhFyrK2LNqD4VOZi+k qZc8Aao+rwtO97SpW2G2cK3arwbMRmoUi0kyI5cjvzNJuRARE8JjoC6v3vZt1+VolYVF YHmMrsn55e9rSYJAArl3HQZeJeTJ87X4HwtFa+UHblfm5L+fxgI1S0sVj+bncOwkx+vp rruLG17otAeI0VM41AT6GjGpJjHTJC39gx6ftAqx+craHa3Q52qmcqYhGwz3T/FU/yyK 44WeePxrxWlzYkYz65ruqiVOiLw2VnXlmtKWxueV5yR4i4TitK56gMcO4OhNvRxDodz9 vYPA== X-Received: by 10.14.99.67 with SMTP id w43mr2859657eef.11.1402259108283; Sun, 08 Jun 2014 13:25:08 -0700 (PDT) Received: from ?IPv6:2a02:a03f:1405:ee00:9511:2252:d394:851a? ([2a02:a03f:1405:ee00:9511:2252:d394:851a]) by mx.google.com with ESMTPSA id v45sm39916447eeg.29.2014.06.08.13.25.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 08 Jun 2014 13:25:07 -0700 (PDT) Message-ID: <5394C66C.9010401@gmail.com> Date: Sun, 08 Jun 2014 22:24:12 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Stephen J. Turnbull" References: <1402212310.40987.YahooMailNeo@web164605.mail.gq1.yahoo.com> <877g4r1fr7.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <877g4r1fr7.fsf@uwakimon.sk.tsukuba.ac.jp> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/4-DTGJlC50VZtKWMq4-pAKEQkmA Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] advice to MTAs 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, 08 Jun 2014 20:25:12 -0000 On 6/8/2014 7:18 PM, Stephen J. Turnbull wrote: > If we want to > ask the MUA developers to do something to inform the end user about > authentication results, we sure as shooting should put our protocol > where our mouth is by putting in a requirement that MTAs give them > that information. Having a requirement that specific information be made available to the UI is one thing. Having a requirement that anything be presented to users is quite another. For the latter, relevant empirical justification is required. Absent that, it's just guesswork about utility -- or worse, runs counter to what is known -- and that has no place in a formal standard. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Jun 8 13:27:12 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E311D1A01EE for ; Sun, 8 Jun 2014 13:27: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 phJ9Fl_msxW7 for ; Sun, 8 Jun 2014 13:27:09 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A6E11A0175 for ; Sun, 8 Jun 2014 13:27:09 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id y10so1020571wgg.29 for ; Sun, 08 Jun 2014 13:27:07 -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=bflsjXAXbAN0FbvwdKDfhIRW56eIUBSd+kR6zBwdmak=; b=hug6pgegh18ZTuEpgHmGwx36+vYjBagAc9+vUGbGBGMujuKhkUqk2eePWCM2A1OMIr Y+RebVFHf8gGZuPF+3jWLrchWtTHUD+BI3h1fWyDDvBXFaLZmznS+7/eGrPoeXwcSBlZ B8wXouCmeb6UEkFtlXLcKoHVQq+SaxxVjCcMHbYte2cnv3hdd5oangXS9j+FAbfhVO0o CMlytHy6k+hOow6qfi5BIQmVbF6NKkItoQG4alSAZtd9DN7UPGv7e7J0qOorMCIKy0sl AZSYGHSWzCVCvthE9313VmsVtCRGNLaw10Lodz+bOq6JB/IxvNW7JYbnK/DElUnZCTE5 1gJQ== X-Received: by 10.14.194.136 with SMTP id m8mr1305833een.4.1402259227936; Sun, 08 Jun 2014 13:27:07 -0700 (PDT) Received: from ?IPv6:2a02:a03f:1405:ee00:9511:2252:d394:851a? ([2a02:a03f:1405:ee00:9511:2252:d394:851a]) by mx.google.com with ESMTPSA id g8sm39922118eep.0.2014.06.08.13.27.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 08 Jun 2014 13:27:07 -0700 (PDT) Message-ID: <5394C6E4.4030904@gmail.com> Date: Sun, 08 Jun 2014 22:26:12 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Stephen J. Turnbull" References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/DJ_bRQPh-QpLZS_j8hPuFNZsjO0 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 08 Jun 2014 20:27:11 -0000 On 6/8/2014 7:00 PM, Stephen J. Turnbull wrote: > The mention of Usenet suggested a completely "out of the box" way to > sidestep DMARC impact by avoiding SMTP entirely, using NNTP as an > alternative transport. I merely wanted to make it clear that GNU > Mailman is *technically* prepared to think about that kind of thing, > if better mitigations for the SMTP transport aren't developed. > (Development of a new "modern" transport is completely out of the > question for us; we have neither the skills nor the resources.) Both > the security ramifications of NNTP and the social ramifications of > changing from a push protocol to a pull protocol for transport are > entirely unclear to me, however. So that certainly could be an interesting discussion, although it's not nearly as promising as one might think at first blush. The semantic difference in the models of MLs vs. Usenet, and the challenge of adapting the latter to the form, as well as adapting all of the security and support infrastructure, are likely to be daunting. But it might force a refreshing discussion about the nature of MLs and what is needed to support them properly. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Jun 8 13:29:01 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCB11A01EE for ; Sun, 8 Jun 2014 13:29:00 -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 pV0AYLeZ2z_a for ; Sun, 8 Jun 2014 13:28:59 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B21C01A0175 for ; Sun, 8 Jun 2014 13:28:58 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id w61so5026239wes.12 for ; Sun, 08 Jun 2014 13:28: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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=X4zxy1+KVyedGyNGOoCORz2b9S8CIDTqR3wp3DQZFGk=; b=R6WthSPQ6C4sZ/00zPRk41pPCH9YSx88faOWBKB/SnElMuV8hw/QUC7kRasTdFVukd NZCjVRA4Fq8BrsIvF7n2QfzCoZDIXG5ptrYQxFaYX0EkL/AwYR6olIv/ZoSQncdsldQs i/QADFbDXHpDGdXgKNWmZwxB1KP0bSxVkhVh7OaWjfY7GTR6b+4daVM6QifUxd+G0g+J ZdfzLuB+kmY86x6jSQk8Wbghke+yevTkq98VHmz/AEqkoK6BFOLYARz9AgahMCSOqyAX vr4jWZEYgYuXVTcdIzVXwFinOvOxeXzm87z1Jpq/tHaRuj4I+2dRL3yUgFlWh9rPu0eo 5bGg== X-Received: by 10.14.204.73 with SMTP id g49mr3087336eeo.2.1402259337368; Sun, 08 Jun 2014 13:28:57 -0700 (PDT) Received: from ?IPv6:2a02:a03f:1405:ee00:9511:2252:d394:851a? ([2a02:a03f:1405:ee00:9511:2252:d394:851a]) by mx.google.com with ESMTPSA id l41sm39932574eew.8.2014.06.08.13.28.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 08 Jun 2014 13:28:56 -0700 (PDT) Message-ID: <5394C751.6050003@gmail.com> Date: Sun, 08 Jun 2014 22:28:01 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Phillip Hallam-Baker , "Stephen J. Turnbull" References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/HWQd_ghkPVJEwCNi7-JptreQAm8 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 08 Jun 2014 20:29:00 -0000 On 6/8/2014 2:46 PM, Phillip Hallam-Baker wrote: > NNTP was built to save bandwidth, Flooding protocols do not do a very good job of saving bandwidth. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Jun 8 13:38:30 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51BC21A03EB for ; Sun, 8 Jun 2014 13:38: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 0o6RgtKtp7QM for ; Sun, 8 Jun 2014 13:38:26 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB2141A0175 for ; Sun, 8 Jun 2014 13:38:25 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi2so1095682wib.1 for ; Sun, 08 Jun 2014 13:38:24 -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=L4BerC83yYG0NQCC2nRm04+LPRtUszOFSlWL/tz4wug=; b=b3rQylYoKukIDlncPxCOXA1PPccuSSvPO9rcyJDB4mDpPXi8WcrPA+uaww4oSpa5D5 9lf75ptlgkOyzzn9rS21VF+QFCy1e+7D6WCXADetDBQjcqlEUO9Cuti+8/nTFwfYBil/ PqSsJI+ZFYleZWdQYzq+3bAPG+olbOKE6/8bHdzvO9LrH302FS5RhUajldBi9RL57RUu u+fmXToItndHN3ETs/fEWMIbciYKELF02a1zhcGNc8h2tqy5Ac7p/PInnjAza7BSOc+0 58BSvgmGZHk6aY6GFBvB5RH4UFe3GOoRo0MhHP6JkPt25BIQx+C12tWPT2aQ8hdLBpXW pcRQ== X-Received: by 10.15.53.1 with SMTP id q1mr2752701eew.7.1402259904611; Sun, 08 Jun 2014 13:38:24 -0700 (PDT) Received: from [192.168.1.45] ([109.128.169.101]) by mx.google.com with ESMTPSA id h49sm39983951eeg.21.2014.06.08.13.38.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 08 Jun 2014 13:38:23 -0700 (PDT) Message-ID: <5394C988.7040608@gmail.com> Date: Sun, 08 Jun 2014 22:37:28 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Stephen J. Turnbull" References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <5392ECED.5010404@gmail.com> <87ppik1tk5.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87ppik1tk5.fsf@uwakimon.sk.tsukuba.ac.jp> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ZNFd2QdctoAQioZ_L2dHpVtazD4 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Sun, 08 Jun 2014 20:38:27 -0000 Stephen, Thanks for the comments... On 6/7/2014 8:08 PM, Stephen J. Turnbull wrote: > Two nits to pick. First, I'd like a whole (sub)section (containing > approximately one sentence :-) for Mediator responsibilities, even if > it's redundant with step 4 of the specification. Maybe a subsection > of section 5 (Discussion)? Uhh... why? > Second, from the draft: > > The expiration time on the Secondary signature needs to be long > enough to permit evaluation by receivers of the re-submitted > message, yet short enough to limit the potential for unauthorized > replay attacks. A good choice is a small number of days or even > hours. > > Due to greylisting (I've seen a message that got greylisted twice, > once at the mailing list and once at the recipient), I'd recommend > that the absolute minimum for expiration time be 12 hours, and that at > least 24 hours be recommended. Long ago, the usual email minimum timer was 72 hours, to deal with a long weekend... I'll suggest that rather than using precise number, perhaps the spec should indicate what the functional requirement or goal is, to guide the choice of actual timer value(s). Text suggesting how to accomplish this in the draft would not be met with hostility... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sun Jun 8 13:46:03 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F771A03FC for ; Sun, 8 Jun 2014 13:46:02 -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 LGLXjIPiaoFt for ; Sun, 8 Jun 2014 13:45:59 -0700 (PDT) Received: from catinthebox.net (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id EF5B11A03EB for ; Sun, 8 Jun 2014 13:45:58 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1300; t=1402260351; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=wYpbXhHoZgnOdWqsXJmVmEWzeUQ=; b=fZS7baEVnsMimo7UbZUp 2dwZ21zFjvMcOYJEEp2O/2Y1ki5kXj2AghlRTg8r3dTGJb7paWLXbEwB1hYSlBbj rV/tZ+S7KGlhzNn/i0hzOW3LRLtYMPojfdllZ9aYuZ/0zXjc5r2gLr8kVxRINI5q JcS9ctG5LyCWthwbMVYpZoY= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 08 Jun 2014 16:45: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; Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1740474981.8093.5492; Sun, 08 Jun 2014 16:45:49 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1300; t=1402260186; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=GiL64t1 WprozWf2iqCEQ1YL0OSSf/NkIB17hCFQj+as=; b=cxqaxWSC0CkIwl5tC61uGyE JNb6yQwHEp5galP7HUKmE6l1CQ8bUKdgJlMYYAf03G/0A4kANzvbTrqR5bM9wh9h M8KfgAXu7oKa/6LrMAnkFbzITB5nSWCeAwyXzkJdDcwhXzBl1NOwAtx7ZndKqfrQ oSB1IyydL3QDWZvOmoZw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 08 Jun 2014 16:43: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 1756833593.9.4396; Sun, 08 Jun 2014 16:43:05 -0400 Message-ID: <5394CB79.3010908@isdg.net> Date: Sun, 08 Jun 2014 16:45:45 -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" , Vlatko Salaj References: <1402212310.40987.YahooMailNeo@web164605.mail.gq1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/p7WDm2u1pyDfT-SifkqmDVpdZCs Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] advice to MTAs 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, 08 Jun 2014 20:46:02 -0000 On 6/8/2014 11:30 AM, Murray S. Kucherawy wrote: > On Sun, Jun 8, 2014 at 12:25 AM, Vlatko Salaj > "DMARC participating MTAs SHOULD include Authentication Results > for all underlying protocols (SPF/DKIM), as well as such results > for DMARC validation itself, among headers of original messages, > during DMARC processing, so they are delivered to end user's > mailbox with the message. > [...] > > > That's interesting. I imagine I assumed they were all (or would all > be) doing that already, so it wasn't made explicit. > > I'm not so sure about the SHOULD because the only interoperability A-R > enables is stuff between the verifiers and the MUAs and humans, > really. It certainly wouldn't be a bad idea for us to highlight how > useful it would be though. > > It is mentioned in Section 6, but the mention there doesn't even say > that it's the DMARC result that's supposed to be recorded. That bit > at least needs to be fixed. > > Anyone else have a comment? > Only that it goes back to the similar SPF thing regarding dynamic rejections. So to be consistent for DMARC: DMARC POLICY A-R Trace Guideline REJECT --> N/A see 55x reply codes. QUARANTINE --> SHOULD record with A-R. NONE --> SHOULD record with A-R. -- HLS From nobody Sun Jun 8 15:00:42 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004371A04AE for ; Sun, 8 Jun 2014 15:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 xDTTRqar8vWi for ; Sun, 8 Jun 2014 15:00:36 -0700 (PDT) Received: from nm31.bullet.mail.gq1.yahoo.com (nm31.bullet.mail.gq1.yahoo.com [98.136.217.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE9BE1A03E3 for ; Sun, 8 Jun 2014 15:00:36 -0700 (PDT) Received: from [127.0.0.1] by nm31.bullet.mail.gq1.yahoo.com with NNFMP; 08 Jun 2014 22:00:36 -0000 Received: from [98.137.12.61] by nm31.bullet.mail.gq1.yahoo.com with NNFMP; 08 Jun 2014 21:57:40 -0000 Received: from [98.137.12.251] by tm6.bullet.mail.gq1.yahoo.com with NNFMP; 08 Jun 2014 21:57:39 -0000 Received: from [127.0.0.1] by omp1059.mail.gq1.yahoo.com with NNFMP; 08 Jun 2014 21:57:39 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 840986.68794.bm@omp1059.mail.gq1.yahoo.com Received: (qmail 20817 invoked by uid 60001); 8 Jun 2014 21:57:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402264659; bh=70SD51z8Pzr7FdykBXMn+0sjalJU7pa1iQhXJyl/0Nw=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=XsjOA4MVPTA2gOXQUavL0s6VrOig+m11HqH8e8tc9gUoTmAKGcz2Wp3zkSi3WIYsS64+8i01k6SS8u02IzlbioNSnfFV2ZGKqMkZ3waKHMOSk3ph1E+DXf+eWqW55dMrB1SuJmOHtXfm7UMDevcgg+OtQiBenh60y1NJpRbBFbY= X-YMail-OSG: OJSAvuQVM1n.P6cpRY89d5aooaNHyQ01vXN62Mo0cwztb7Z jKsPXj_5YqFD77gcRz.GA0JjLeHn.S2tTIMCgHJEqRqJFjE16J1eAvZ7bfVK ZO.Fm0nJGEwZYXvd9YLO5INNRywgh3tWwNr1AH6KWUJsMp9qZ.jD9LeFiiSM Ov4c21rU0d8XDoxL_NBLlBqzF4KTi1XnQOeRyCLa1Xdbpj5Tbgv4D5yBjk7H UO_Dl4joXTcTClAeb_6kYktoIr74w7PfPmZGEii.3WO4vbZtNFRC6hPV9F1G ljNSQeWIyrIyWiSwcf1mS_N2DxMDt66EYWYmZ9WvcgfjFj3STxyu3Mkr33_r hAnnyjeYx3Aqu8Cx4b2y_C_aSx8y39CXMLsUDUnkR98zV7EAxnHdn9wcZm_e _52UOkPG1OIItRkQwkSBtA3iHnC5efHCBWnnJjuTvjQ2AgKSGnzEvVE8DIrj sD0WM0Tr4x7aWpaWOpGC8AZb4clwPArHtrh2DS32lXOEdmTdxAWgGClahda1 0PBOnOUrRPG_IKRIj4g6W_DpkbpK8r5pYLeJJNm3A2XTIm3d7jtS9vanm1rx kITfGgFc.494tS7dTOQAn.EiRmiQtWAfMRkb0R4yiIme2oYvdww-- Received: from [79.175.112.242] by web164605.mail.gq1.yahoo.com via HTTP; Sun, 08 Jun 2014 14:57:39 PDT X-Rocket-MIMEInfo: 002.001, T24gU3VuZGF5LCBKdW5lIDgsIDIwMTQgNTozMCBQTSwgTXVycmF5IFMuIEt1Y2hlcmF3eSA8c3VwZXJ1c2VyQGdtYWlsLmNvbT4gd3JvdGU6CgoKPiBJJ20gbm90IHNvIHN1cmUgYWJvdXQgdGhlIFNIT1VMRAoKaSB3b3VsZCBzdGF5IHdpdGggU0hPVUxEL01VU1QgY29tYm8uIGkgd291bGQsIGFjdHVhbGx5LCBldmVuCnN1Z2dlc3QgaXQgdG8gYmUgTVVTVC9NVVNUIGNvbWJvLCBidXQgaSBsZWF2ZSB0aGF0IHRvIGdlbmVyYWwKY29uc2Vuc3VzLCBhcyB0aGVyZSBtYXkgYmUgcmVhc29ucyBub3QgdG8gZ28gc28BMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <1402212310.40987.YahooMailNeo@web164605.mail.gq1.yahoo.com> Message-ID: <1402264659.98830.YahooMailNeo@web164605.mail.gq1.yahoo.com> Date: Sun, 8 Jun 2014 14:57:39 -0700 (PDT) From: Vlatko Salaj To: "Murray S. Kucherawy" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/YdZUNCwzmD9qml9XoEF5SBdivGA Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] advice to MTAs X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 08 Jun 2014 22:00:40 -0000 On Sunday, June 8, 2014 5:30 PM, Murray S. Kucherawy wrote: > I'm not so sure about the SHOULD i would stay with SHOULD/MUST combo. i would, actually, even suggest it to be MUST/MUST combo, but i leave that to general consensus, as there may be reasons not to go so strong, which i'm not currently aware of. however, 1st paragraph should b stronger than RECOMMENDED, imo, cause i believe such information is quite helpful and very informative in number of ways to end users in case of issues, and especially to various levels of support and administration. also, it is a fact most current MTAs include A-R for SPF/DKIM, and ASAICS such practice is rather a common standard now, so i would go with a SHOULD, simply to be in line with what seems to be usual for MTAs today. when it comes to 2nd paragraph's MUST, if there r any operational objections or reasons why would any particular implementation have to lower these requirements in its use case, i'm perfectly fine to switch it to SHOULD SHOULD combo. however, if there aren't any, SHOULD MUST is preferred by me. anyway, i do suggest we review the list of items in 2nd paragraph, as i may have left something important out, or listed something irrelevantly redundant. i'm not sure how to process "pct" tag exactly, in sense of DMARC A-R info, to make it obvious, but minimalistic, but that's something we may want to include also. ofc, my txt needs RFC tags where appropriate, but i'm sure Murray will include them as a matter of good document writeup, which does seem to be one of his talents, as i didn't have any issues reading any spec he authored before. > It is mentioned in Section 6 yes, it was my original idea to add advice to MTAa to s6, with some adequate transformation of the original txt, but i leave that to u, as the document author, to handle, since u would do it better than me, or we can cooperate on wording, if u prefer. imo, the same section, in addition to advice to MTAs, would do good to include some wording of advice to MUAs from Franck's suggestion. i do think, however, that any design proposals should be as minimalistic as possible, since that's a whole other area of expertise, problems and requirements we cannot possibly hope to evaluate adequately, and, ofc, we need to leave creative freedom in hands of designers. so, i do support to RECOMMEND MUAs to make prominence of a validated FROM domain in their implementations, or, at least to mention it as MAY. if DMARC succeeds in its premise to validate authorised email, domain validation information could become quite useful to design choices in MUAs, making some distinction between DMARC-validated and regular email. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Sun Jun 8 15:03:54 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D581A04AE for ; Sun, 8 Jun 2014 15:03:52 -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 yOHW6Em_UQKl for ; Sun, 8 Jun 2014 15:03:50 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.92]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C960D1A03E3 for ; Sun, 8 Jun 2014 15:03:49 -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.0.974.2; Sun, 8 Jun 2014 21:31:31 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.234]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.234]) with mapi id 15.00.0974.002; Sun, 8 Jun 2014 21:31:30 +0000 From: Terry Zink To: Hector Santos , "Murray S. Kucherawy" , Vlatko Salaj Thread-Topic: [dmarc-ietf] advice to MTAs Thread-Index: AQHPguwL/jJB/F9560KwCvBs5fZmtZtnV1SAgABYEYCAAAtodA== Date: Sun, 8 Jun 2014 21:31:30 +0000 Message-ID: <1402263120639.86327@exchange.microsoft.com> References: <1402212310.40987.YahooMailNeo@web164605.mail.gq1.yahoo.com> , <5394CB79.3010908@isdg.net> In-Reply-To: <5394CB79.3010908@isdg.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [75.172.11.235] x-exchange-antispam-report-test: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0236114672 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(51704005)(199002)(189002)(24454002)(74366001)(50986002)(92726001)(93516002)(69226001)(66066001)(99396002)(92566001)(53806002)(80022001)(49866002)(47736002)(51856002)(47446003)(98676001)(21056001)(97336001)(54316003)(81342001)(56816006)(56776002)(59766002)(47976003)(64706001)(54356002)(63696004)(20776003)(65816002)(97186001)(77982001)(81542001)(79102001)(76796001)(76786001)(81816001)(95666003)(93136001)(19580395003)(19580405001)(94316002)(83322001)(94946001)(90146001)(77096001)(81686001)(74706001)(4396001)(76482001)(101416001)(95416001)(31966008)(74502001)(74662001)(46102001)(87936001)(85306002)(87266001)(2656002)(74876001)(85852003)(83072002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2SR01MB604; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/AUPz07NvzpQPTS1YRzlmKRig5hA Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] advice to MTAs 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, 08 Jun 2014 22:03:52 -0000 > Hector Santos wrote:=0A= >=0A= >> It is mentioned in Section 6, but the mention there doesn't even say=0A= >> that it's the DMARC result that's supposed to be recorded. That bit=0A= >> at least needs to be fixed.=0A= >>=0A= >> Anyone else have a comment?=0A= >=0A= =0A= > Only that it goes back to the similar SPF thing regarding dynamic=0A= > rejections. So to be consistent for DMARC:=0A= >=0A= > DMARC POLICY A-R Trace Guideline=0A= >=0A= > REJECT --> N/A see 55x reply codes.=0A= > QUARANTINE --> SHOULD record with A-R.=0A= > NONE --> SHOULD record with A-R.=0A= =0A= In our implementation, we also plan to indicate the following scenarios:=0A= =0A= 1. DMARC fails but the pct value indicated not to take action (i.e., pct=3D= 80, this message failed but is in the 20% of cases not to take action) at w= hich point we would stamp "dmarc=3Dfail action=3Dpct.quarantine"=0A= =0A= 2. DMARC fails and the action is reject but we overrode the requested actio= n (i.e., for a mailing list) at which point we would stamp "dmarc=3Dfail ac= tion=3Do.reject"=0A= =0A= Others may feel that this is not necessary (of think this syntax is not cle= ar enough) but we do it for troubleshooting -- "This domain's DMARC action = is reject. Why is it in my junk folder?"=0A= =0A= --Terry= From nobody Sun Jun 8 15:39:49 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583371A041D for ; Sun, 8 Jun 2014 15:39:47 -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 kRQth6TEsYVQ for ; Sun, 8 Jun 2014 15:39:44 -0700 (PDT) Received: from mail.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 397771ACAD6 for ; Sun, 8 Jun 2014 15:39:44 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4468; t=1402267175; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=WcifNaHXO64I4D1Sj8jFUfea7Jk=; b=C76MitVmsy44YocuOxLE XXGRg4iXV03xGTRvgPI9qLzm18sq9Zfd2kCh0IJwBqf2NrfSm7OLDN3xo3RFVcFh j6kdyyLWd7dsLdRwhghz8Ue+Vkoz/XzgrEW+hfazekN46EkrarOiap7cCaPfByOm sb+fjJA/WsMm5uopwlC0Dts= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 08 Jun 2014 18:39: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; Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1747300399.8093.1168; Sun, 08 Jun 2014 18:39:35 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4468; t=1402267010; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=qdhaYY+ qJkoT2aEGQB8lE2pHlC4JRnclrS+KV9ta80I=; b=KZ1smNV533w+OoMbLkmVZMr vxCuOufbPtryAiLSz4kHo2W6lEG9/qV88DArxk/sxpP3CYqesV9PNKuaZZhQMZj6 FgP9fvmje7hx6I95++ETcXrER+myQeFAw9/UqDG5DAXwqxLPgFmOSH9Y63G4kJSf auMv1wymsoSvuYaa8pOc= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 08 Jun 2014 18:36:50 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1763657546.9.5916; Sun, 08 Jun 2014 18:36:49 -0400 Message-ID: <5394E621.2050705@isdg.net> Date: Sun, 08 Jun 2014 18:39: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: "Stephen J. Turnbull" , Phillip Hallam-Baker References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/EohQM6APYUPMQ_EosqGlb5g9cy4 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 08 Jun 2014 22:39:47 -0000 On 6/8/2014 1:00 PM, Stephen J. Turnbull wrote: > Phillip Hallam-Baker writes: > > > NNTP was designed 30 years ago. We should consider moving on. > > The modern protocol world is JSON/REST > > That's off-topic for this list, IMO, and I don't intend to discuss it > unless the moderator(s) make clear that it is on-topic. > What I believe is on-topic is that several people participating in > development of DMARC-related standards have expressed concern about > the impact on mailing lists. Stephen, Phillip is spreading synergism. For example, it wouldn't be off-topic if someone proposed a DMARC callout mechanism based on JSON/REST (API) wire. It will be viewed as a technological competitive alternative to using a DNS-based mechanism directly. It might access a different backend database or just as API wrapper on top of a DNS API already and serves as a tool for web-based client development. The IETF DNS community do consider to things, especially with the growth of DNS TXT-based applications. There are many network and system level design considerations. In this vain, Phillip was 100% on-communications-par. > There's no question that "p=reject" is a > knife at our throats, because much of the value-added of Mailman-style > lists to end users is in the "decoration" added to posts, and I have > yet to see anyone (except Franck Martin) say on the Mailman channels > that From-corruption is completely acceptable. To express how strong I feel about this.... If there is a charter for a new DMARC WG work, you can bet I will request that any form of 5322.From-Corruption concept be considered OFF TOPIC and OUT OF SCOPE in the new WG charter except to be aware of intentional From-Corruption is to be considered a new security exploit and threat to be mitigated. And for the record, I will also appeal any IETF work that begins to suggest From-Corruption concepts as a means to bypass security protocols. I will appeal it. If the idea includes getting permission, thats less damaging, but still bad. Not as a solution to the problem that comes about by not even doing a lookup. See below. > All mitigations > proposed so far are deeply unpopular with our users (list operators), > as well as with the developers. Nor is it clear that any standard for > third party authentication will be approved at all, let alone adopted > widely by Author Domains in good time. Thats a different problem and your frustration is well understood. But the proposals were not the problem. Forget 3rd party concepts for the moment, you gotta accept the idea that you even want to do a LOOKUP. Are you ready to do a LOOKUP? There are two basic ML implementations problems here: 1) Doing a LOOKUP, 2) Honoring the Lookup record protocol semantics. For the ML, it hasn't even gotten to the idea of a lookup and it really doesn't have to do it directly, but whatever is receiving our mail has to do the lookup. We can make it work for our MLS and MDA because our MLS will create an acceptable list addresses text file. So we can add a script at the MDA to check this list and do any restriction checks. Does your setup allow for scripting at the MDA level? > The mention of Usenet suggested a completely "out of the box" way to > sidestep DMARC impact by avoiding SMTP entirely, using NNTP as an > alternative transport. No, as an existing Client Portal with an offline mail reader or browser with a web-view of mail conferences. The network transport is still SMTP. Again, Synergy!! Our NNTP server allows you to gate a mailing list. news://publicnews.winserver.com/ietf-drafts or the mailing list for SPF: news://publicnews.winserver.com/spf.-.sender.policy.framework.discussion news://publicnews.winserver.com:119/spf.-.sender.policy.framework.help I don't remember if the above actually allows anonymous news readers. Synergy. I could, if wanted to to satisfy Frank's MUA change proposal, show a NNTP backend generated text change to any of the 5322 display headers or even the body. > (Development of a new "modern" transport is completely out of the > question for us; we have neither the skills nor the resources.) Good point, so its only off-topic for GNU Mailman. It doesn't make it off-topic for others. I am not suggesting NNTP or JSON/REST as part of the solution. We are still at baby steps here of just doing a lookup. -- HLS From nobody Sun Jun 8 19:27:03 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0944C1B27A7 for ; Sun, 8 Jun 2014 19:27:02 -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 NXpBapWamid0 for ; Sun, 8 Jun 2014 19:27:00 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B6DF1A036E for ; Sun, 8 Jun 2014 19:26:59 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id u57so5169394wes.18 for ; Sun, 08 Jun 2014 19:26:58 -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=0+/44X7LzASsFBBh5mnObcRnBzDV+KaroblSFifKGG4=; b=HEXH9jUw+Na7LVmXHm1/ZBVhPAV8z8twBlKDHlEsxWnWRV8LWtZofrXXGP2B3NJ0eK ZMBQbjReHFvgDfU33TYQjBar0oZHCKvpSiOixZWrbPZNHJu3s/TISnnjyrLuOTuVZbbe daiPVQXqKBoxnp8qpsQKgFP7HCEkvs0aaVWMn1V3dMfsadFp8JTiNJ5lwIiA0yAlIbR/ 5F1+YzkDhueTY1VT7M1q7lkhC6633KahapAKK9KuK+hqoJPhk8WSAQYbRtzAFBaUsl0h 1YOwpI0r8NJ6bVfh5e5JXUZRisplXGEC1g3IJnFEPIvNdHqHJX7VI59LyEEL0xSEtxu3 nZZg== MIME-Version: 1.0 X-Received: by 10.194.161.168 with SMTP id xt8mr27354082wjb.35.1402280818467; Sun, 08 Jun 2014 19:26:58 -0700 (PDT) Received: by 10.180.23.104 with HTTP; Sun, 8 Jun 2014 19:26:58 -0700 (PDT) In-Reply-To: <5394E621.2050705@isdg.net> References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> Date: Sun, 8 Jun 2014 19:26:58 -0700 Message-ID: From: "Murray S. Kucherawy" To: Hector Santos Content-Type: multipart/alternative; boundary=089e01419c6a0f6af004fb5df2f3 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/AfdCceZl8F23mhpAfc99bD3qrBk Cc: "dmarc@ietf.org" , "Stephen J. Turnbull" , Phillip Hallam-Baker Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 09 Jun 2014 02:27:02 -0000 --089e01419c6a0f6af004fb5df2f3 Content-Type: text/plain; charset=UTF-8 On Sun, Jun 8, 2014 at 3:39 PM, Hector Santos wrote: > On 6/8/2014 1:00 PM, Stephen J. Turnbull wrote: > >> Phillip Hallam-Baker writes: >> >> > NNTP was designed 30 years ago. We should consider moving on. >> > The modern protocol world is JSON/REST >> >> That's off-topic for this list, IMO, and I don't intend to discuss it >> unless the moderator(s) make clear that it is on-topic. >> > > What I believe is on-topic is that several people participating in >> development of DMARC-related standards have expressed concern about >> the impact on mailing lists. >> > As this isn't a list associated with a working group, it doesn't have a formal charter as such other than the idea that we probably should stick to the one-paragraph description we gave to the IESG to create the list, which says: "Discussion related to the development, clarification, and implementation of the DMARC protocol, and operational uses of it." Since mailing lists are obviously a major consideration for DMARC, paying them due attention is certainly valid here as long as it's in the context of DMARC. The more abstract conversation about "mailing lists redux" should probably get its own list, or maybe take place on ietf-822, at least until there's actual work before the IETF such as a draft. However, again on the informal point, I don't think there's a need to make a declaration about something being off-topic until it's clearly become a distraction from the above. If there is a charter for a new DMARC WG work, you can bet I will request > that any form of 5322.From-Corruption concept be considered OFF TOPIC and > OUT OF SCOPE in the new WG charter except to be aware of intentional > From-Corruption is to be considered a new security exploit and threat to be > mitigated. And for the record, I will also appeal any IETF work that begins > to suggest From-Corruption concepts as a means to bypass security > protocols. I will appeal it. > Setting aside for the moment how premature this threat is given that there's not even a skeleton charter under proposal right now, I suggest you read Section 6.5 of RFC2026 to figure out what the official basis would be for such an appeal. -MSK --089e01419c6a0f6af004fb5df2f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Jun 8, 2014 at 3:39 PM, Hector Santos <hsantos@isd= g.net> wrote:
On 6/8/20= 14 1:00 PM, Stephen J. Turnbull wrote:
Phillip Hallam-Baker writes:

=C2=A0 > NNTP was designed 30 years ago. We should consider moving on. =C2=A0 > The modern protocol world is JSON/REST

That's off-topic for this list, IMO, and I don't intend to discuss = it
unless the moderator(s) make clear that it is on-topic.

What I believe is on-topic is that several people participating in
development of DMARC-related standards have expressed concern about
the impact on mailing lists.

As this isn't a list associated with a working group, it doesn= 't have a formal charter as such other than the idea that we probably s= hould stick to the one-paragraph description we gave to the IESG to create = the list, which says:

"Discussion related to the development, clarification, and impleme= ntation of the DMARC protocol, and operational uses of it."

Since mailing lists are obviously a major consideration for DMARC, = paying them due attention is certainly valid here as long as it's in th= e context of DMARC.=C2=A0 The more abstract conversation about "mailin= g lists redux" should probably get its own list, or maybe take place o= n ietf-822, at least until there's actual work before the IETF such as = a draft.

However, again on the informal point, I don't think ther= e's a need to make a declaration about something being off-topic until = it's clearly become a distraction from the above.

If there is a charter for a new DMARC WG work, you can bet I w= ill request that any form of 5322.From-Corruption concept be considered OFF= TOPIC and OUT OF SCOPE in the new WG charter except to be aware of intenti= onal From-Corruption is to be considered a new security exploit and threat = to be mitigated. And for the record, I will also appeal any IETF work that = begins to suggest From-Corruption concepts as a means to bypass security pr= otocols. I will appeal it.

Setting aside for the moment how pre= mature this threat is given that there's not even a skeleton charter un= der proposal right now, I suggest you read Section 6.5 of RFC2026 to figure= out what the official basis would be for such an appeal.

-MSK
--089e01419c6a0f6af004fb5df2f3-- From nobody Sun Jun 8 21:06:42 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1531A0653 for ; Sun, 8 Jun 2014 21:06:40 -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 fs0kXJ4LtnKX for ; Sun, 8 Jun 2014 21:06:37 -0700 (PDT) Received: from ntbbs.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5B40D1A0220 for ; Sun, 8 Jun 2014 21:06:36 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2052; t=1402286792; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=eFfjq8lKPe8U0Xr0ZA3+f1vJqro=; b=GT5IhtQIFwj2Ee4K3Es/ LXZMuCH3WckKu1G5S2ej27w4+HESK6aThP0emTg0e26LAwq1EoyRdJDSsDPhIyLk zVentIaFkYRvMKN9+/Jer/BfEvggQhpM7dlxpQ27wjHt0vy4RKPyBMauJ8pWkJ+F 9LOg83AEFpdIPR3NEc0qlyI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 09 Jun 2014 00:06: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; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1766915933.8093.5416; Mon, 09 Jun 2014 00:06:30 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2052; t=1402286627; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=GpxcDU2 qDk40WabL5OfuoMj71Zq6xHpGeUfsrI4Tp7E=; b=CV9xfA0by8MNqjs81nZv1ud 5/ZEFWQpzzeOu93x1E4LfonKXBQHXMkZF0bZuKCmcwnNYggzY00X3dNeZF6tia4K 6L2PwYbtUl0SBjBbk12slthETIl5O+5LANgKrCWEro6EP5V39zru37RaeOe70Iot s8LUFb+HXjQ3ZRNXBFPc= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 09 Jun 2014 00:03:47 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1783273890.9.184; Mon, 09 Jun 2014 00:03:46 -0400 Message-ID: <539532C2.9030406@isdg.net> Date: Mon, 09 Jun 2014 00:06:26 -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" References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/O370D1KVhNI_IgWevmN2c8RjlmE Cc: "dmarc@ietf.org" , "Stephen J. Turnbull" , Phillip Hallam-Baker Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 09 Jun 2014 04:06:40 -0000 On 6/8/2014 10:26 PM, Murray S. Kucherawy wrote: > > To express how strong I feel about this.... > > If there is a charter for a new DMARC WG work, you can bet I will > request that any form of 5322.From-Corruption concept be > considered OFF TOPIC and OUT OF SCOPE in the new WG charter except > to be aware of intentional From-Corruption is to be considered a > new security exploit and threat to be mitigated. And for the > record, I will also appeal any IETF work that begins to suggest > From-Corruption concepts as a means to bypass security protocols. > I will appeal it. > > Setting aside for the moment how premature this threat is given that > there's not even a skeleton charter under proposal right now, Its better to get this bud nipped now. >I > suggest you read Section 6.5 of RFC2026 to figure out what the > official basis would be for such an appeal. Murray, Fundamentally, any From-Corruption (good term to use) concept is bad. 30 years of mail software/product/hosting development across multiple networks tells me so, it ethically burns inside me as wrong and I have strong confidence the IETF/IESG wise ones will agree. I hope you agree too. You will need to add security information to your DMARC document as this From-Corruption concept would be a security exploit that can potentially get by RFC5322 validation checks that can hurt DMARC publishers and create bad PR for the DMARC protocol itself. DMARC receivers will need to be warned. You will need to provide guidelines for mitigating it, not for allowing it unless there is an explicit policy defining language authorizing it, and even then, that can be cracking open a loophole. You may want to make it a boundary layer check thing. The exploit will need to be described just like it was done for DKIM's Double From situation with RFC5322 validation checks done at receivers. Consider it a "to-do" note for when the anticipated official DMARC WG begins. Thanks -- Hector Santos, CTO http://www.santronics.com From nobody Sun Jun 8 22:32:17 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDCF1B27E2 for ; Sun, 8 Jun 2014 22:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 TUPHw_daaOxq for ; Sun, 8 Jun 2014 22:32:15 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34AFA1B27E6 for ; Sun, 8 Jun 2014 22:32:15 -0700 (PDT) Received: by mail-ig0-f173.google.com with SMTP id r2so1492233igi.12 for ; Sun, 08 Jun 2014 22:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ERMI+n8MIDsNtBo1D+UstGDBnio1THqsY+irP2M92pY=; b=gv5HLtRRVpBk5r6akekMYTgbJT+6TU0O6IjmfI8JU9YJGsaPrLKn2DjhM35rtP/ada crAqqy17v8iE6UbmZwkrm+GaMu//QHbiIMJRDBJL9ZTbV9q2DhEBrXubpDwtdM3y5baT Cro0ehoSDX2PoRPGnqZKcaBCMkLMC9IBLZDrj20Z95WEoQIHcp1jYY0yje8xpKSXFiGA bEF8NnhHWLDf+lNEsMvNGhyJ/DvRuGG+J9nrjA0tvIAHMA264X8Mc1lRc43oIFmQvHTl q1gnY9ExUw5xhM45rUZTFZrzvYY4+eAPc++nwYg+X2n5WNkn8C2TpIaHQ84r6uym7fuQ IMiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ERMI+n8MIDsNtBo1D+UstGDBnio1THqsY+irP2M92pY=; b=bq3YqUcR9LnslhEib/iu3AbcHjCXCDbU/AsLLwaj6YA3JYuEhNFmpgUYSXTA4YiX62 fddiyr0VJM4JDmir31OMeoSco3bgW407T+qIEt2ASgCfFF4g3Q46T1uS0mZLM8lorRoe 5pehhUWtIxDcjKb1iQ8hlYE3EprY8pAOLIMRo4aLOYyafOupBl9N2swcCH3ohZA9IVkD Z5Dcy0q7gzTMcNBgXCvrfKZq/qOo240AE3nO9Eldjiw3UTxGNubP22cntuecgbH5ijBC I+zp1zo4M1Rh34YYO8ppNeywHsq8Ec+LSZlXdSwLnviNlmtLvv0lzccA9euCD/Ri9Sof Svxg== X-Gm-Message-State: ALoCoQni+Lu7JFngrOG+6rraCYnPgwv6KwPuYn1UiY2bACV7yXMz1k2oDDZhdI2EcnbyvcpnCm9P MIME-Version: 1.0 X-Received: by 10.50.43.202 with SMTP id y10mr34029925igl.23.1402291934534; Sun, 08 Jun 2014 22:32:14 -0700 (PDT) Received: by 10.64.136.202 with HTTP; Sun, 8 Jun 2014 22:32:14 -0700 (PDT) Received: by 10.64.136.202 with HTTP; Sun, 8 Jun 2014 22:32:14 -0700 (PDT) In-Reply-To: <539532C2.9030406@isdg.net> References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> Date: Sun, 8 Jun 2014 22:32:14 -0700 Message-ID: From: Brandon Long To: Hector Santos Content-Type: multipart/alternative; boundary=089e011604baa14bc404fb60882e Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/kI-V7bgrP0LuXdLEBXieIDsd0SI Cc: "dmarc@ietf.org" , "Stephen J. Turnbull" , Phillip Hallam-Baker , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 09 Jun 2014 05:32:17 -0000 --089e011604baa14bc404fb60882e Content-Type: text/plain; charset=UTF-8 I fundamentally disagree with your assertions on this matter and completely fail to see the how ethics are even involved. The message is already corrupted, or there wouldn't be a problem to be solved. I also fail to see how this is a security issue. Afaik, dmarc is designed to prevent potentially false messages from reaching inboxes if they contain the domain in the from. Munging the from domain meets that requirement, and is the suggested mlm mitigation strategy on the dmarc.org website. We're not ascribing words to random people, nor to list owners. There are certainly examples of systems that munge from headers, there are also systems which assign non specific from headers to folks (FB/G+/Twitter comments and status messages, forum software post notifications, customer support portals). Brandon On Jun 8, 2014 9:06 PM, "Hector Santos" wrote: > On 6/8/2014 10:26 PM, Murray S. Kucherawy wrote: > >> >> To express how strong I feel about this.... >> >> If there is a charter for a new DMARC WG work, you can bet I will >> request that any form of 5322.From-Corruption concept be >> considered OFF TOPIC and OUT OF SCOPE in the new WG charter except >> to be aware of intentional From-Corruption is to be considered a >> new security exploit and threat to be mitigated. And for the >> record, I will also appeal any IETF work that begins to suggest >> From-Corruption concepts as a means to bypass security protocols. >> I will appeal it. >> >> Setting aside for the moment how premature this threat is given that >> there's not even a skeleton charter under proposal right now, >> > > Its better to get this bud nipped now. > > I >> suggest you read Section 6.5 of RFC2026 to figure out what the >> official basis would be for such an appeal. >> > > Murray, > > Fundamentally, any From-Corruption (good term to use) concept is bad. 30 > years of mail software/product/hosting development across multiple networks > tells me so, it ethically burns inside me as wrong and I have strong > confidence the IETF/IESG wise ones will agree. I hope you agree too. > > You will need to add security information to your DMARC document as this > From-Corruption concept would be a security exploit that can potentially > get by RFC5322 validation checks that can hurt DMARC publishers and create > bad PR for the DMARC protocol itself. DMARC receivers will need to be > warned. > > You will need to provide guidelines for mitigating it, not for allowing it > unless there is an explicit policy defining language authorizing it, and > even then, that can be cracking open a loophole. > > You may want to make it a boundary layer check thing. The exploit will > need to be described just like it was done for DKIM's Double From situation > with RFC5322 validation checks done at receivers. > > Consider it a "to-do" note for when the anticipated official DMARC WG > begins. > > Thanks > > -- > Hector Santos, CTO > http://www.santronics.com > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > --089e011604baa14bc404fb60882e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I fundamentally disagree with your assertions on this matter= and completely fail to see the how ethics are even involved.

The message is already corrupted, or there wouldn't be a= problem to be solved.

I also fail to see how this is a security issue.=C2=A0 Afaik= , dmarc is designed to prevent potentially false messages from reaching inb= oxes if they contain the domain in the from.=C2=A0 Munging the from domain = meets that requirement, and is the suggested mlm mitigation strategy on the= dmarc.org website.

We're not ascribing words to random people, nor to list = owners.=C2=A0 There are certainly examples of systems that munge from heade= rs, there are also systems which assign non specific from headers to folks = (FB/G+/Twitter comments and status messages, forum software post notificati= ons, customer support portals).

Brandon

On Jun 8, 2014 9:06 PM, "Hector Santos"= ; <hsantos@isdg.net> wrote:
On 6/8/2014 10:26 PM, Murray S. Kucherawy wrote:

=C2=A0 =C2=A0 To express how strong I feel about this....

=C2=A0 =C2=A0 If there is a charter for a new DMARC WG work, you can bet I = will
=C2=A0 =C2=A0 request that any form of 5322.From-Corruption concept be
=C2=A0 =C2=A0 considered OFF TOPIC and OUT OF SCOPE in the new WG charter e= xcept
=C2=A0 =C2=A0 to be aware of intentional From-Corruption is to be considere= d a
=C2=A0 =C2=A0 new security exploit and threat to be mitigated. And for the<= br> =C2=A0 =C2=A0 record, I will also appeal any IETF work that begins to sugge= st
=C2=A0 =C2=A0 From-Corruption concepts as a means to bypass security protoc= ols.
=C2=A0 =C2=A0 I will appeal it.

Setting aside for the moment how premature this threat is given that
there's not even a skeleton charter under proposal right now,

Its better to get this bud nipped now.

I
suggest you read Section 6.5 of RFC2026 to figure out what the
official basis would be for such an appeal.

Murray,

Fundamentally, any From-Corruption (good term to use) concept is bad. 30 ye= ars of mail software/product/hosting development across multiple networks t= ells me so, it ethically burns inside me as wrong and I have strong confide= nce the IETF/IESG wise ones will agree. I hope you agree too.

You will need to add security information to your DMARC document as this Fr= om-Corruption concept would be a security exploit that can potentially get = by RFC5322 validation checks that can hurt DMARC publishers and create bad = PR for the DMARC protocol itself. =C2=A0DMARC receivers will need to be war= ned.

You will need to provide guidelines for mitigating it, not for allowing it = unless there is an explicit policy defining language authorizing it, and ev= en then, that can be cracking open a loophole.

You may want to make it a boundary layer check thing. The exploit will need= to be described just like it was done for DKIM's Double From situation= with RFC5322 validation checks done at receivers.

Consider it a "to-do" note for when the anticipated official DMAR= C WG begins.

Thanks

--
Hector Santos, CTO
http://www.santronics.com


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
--089e011604baa14bc404fb60882e-- From nobody Sun Jun 8 23:02:13 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6561B27E5 for ; Sun, 8 Jun 2014 23:02:11 -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 suXxOut6DMjH for ; Sun, 8 Jun 2014 23:02:09 -0700 (PDT) Received: from mail.theartfarm.com (mail.theartfarm.com [66.128.51.165]) by ietfa.amsl.com (Postfix) with SMTP id 757441A02DB for ; Sun, 8 Jun 2014 23:02:09 -0700 (PDT) Received: (qmail 52216 invoked by uid 89); 9 Jun 2014 06:02:08 -0000 Received: from unknown (HELO mail.theartfarm.com) (127.0.0.30) by mail.theartfarm.com with SMTP; 9 Jun 2014 06:02:08 -0000 Received-SPF: Pass (mail.theartfarm.com: domain of tnpi.net designates 50.159.99.59 as permitted sender) receiver=mail.theartfarm.com; identity=mailfrom; client-ip=50.159.99.59; helo=[10.0.1.141]; envelope-from= Received: from [10.0.1.141] (c-50-159-99-59.hsd1.wa.comcast.net [50.159.99.59]) by mail.theartfarm.com (Haraka/2.5.0-toaster) with ESMTPSA id ADDF6EA2-9882-49D5-93BC-A2353E434417.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=AES128-SHA verify=FAIL); Mon, 09 Jun 2014 02:02:08 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Matt Simerson In-Reply-To: Date: Sun, 8 Jun 2014 23:01:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> To: "dmarc@ietf.org" X-Mailer: Apple Mail (2.1878.2) X-Haraka-p0f: os="MacOS X 10.9 or newer (sometimes iPhone " link_type="Ethernet or modem" distance=11 total_conn=12 shared_ip=N X-Haraka-GeoIP: US, WA, Seattle, 2699km X-Haraka-GeoIP-Received: X-Haraka-ASN: 7922 50.128.0.0/9 X-Haraka-ASN-MONKEY: asn=7922 net=50.128.0.0/9 org=Comcast Cable Communications, Inc. date=1997-02-14 country=US X-Haraka-FCrDNS: c-50-159-99-59.hsd1.wa.comcast.net X-Spam-ASN: X-Spam-DCC: x.dcc-servers: spamassassin.tnpi.net 104; Body=1 Fuz1=1 Fuz2=1 X-Spam-SNF-Result: 0 (Standard White Rules) X-Spam-MessageSniffer-Scan-Result: 0 X-MessageSniffer-Rules: 0-0-0-3157-c X-MessageSniffer-Clean: Yes X-Spam-MessageSniffer-Rules: 0-0-0-3157-c X-MessageSniffer-Clean: Yes X-Spam-GBUdb-Analysis: 0, 10.0.1.141, Ugly c=0.25607 p=-1 Source Normal X-MessageSniffer-Scan-Result: 0 X-MessageSniffer-Rules: 0-0-0-3157-c X-MessageSniffer-Clean: Yes X-Haraka-Karma: connect: 4, history: 387, total_connects: 418, neighbors: -5378, pass:fcrdns.fcrdns, relaying, auth_user, fail:fcrdns.fail, neighbors, dnsbl.fail, helo.checks.fail, helo.checks.fail, skip:penalty DKIM-Signature: v=1; a=rsa-sha256; bh=6K47LBOpbn7+u6+lOueVtf/rOEZq6gUEWGpRr1S2T6A=; c=relaxed/simple; d=tnpi.net; h=from:subject:date:message-id:to:mime-version; s=mar2013; b=GPq28aIUKNJxkbjmv58ZetuwrkXWR78/nhY7RuFA/kITDDMZLbTn4cHpccuVxGyZwyB0QoJ87EdAIdRzB8sT0tqgrKIwm63nt3u4vCJsTgUDM2Q9kRMi2IpvL/P9ZLEjbcN3OvfJIm2hKTaPAFJJX79EBKLyMXBbeUaFl79iFVIltUDsPD3HkWM2xVQXumBjHl1dbZOQ/8o0goCWdK/j55b9wksflCQUs57qo0hBaJC7ATk1Wnjrl8ah/LJemFdVbZ45ua1Jv03I0A7Odrj8YXPacRYRl81a0vY0wZwq59pyR3WFYqXmH9oA4TPrn89rVm14wUc+kBMBmUg5FTdK3w== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/-Gf6LbZZcvdrycq5yPvrVTPs-6E Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 09 Jun 2014 06:02:11 -0000 On Jun 8, 2014, at 10:32 PM, Brandon Long wrote: > The message is already corrupted, or there wouldn't be a problem to be = solved. When the message arrives at the list, it's unlikely that it's already = corrupted. What has been described is corrupting the =46rom header by = the same entity that is about to break the DKIM signature by altering = the the message. This should be called the "break it worse" method. > I also fail to see how this is a security issue. Agreed. It's *really* easy to filter and block delivery for non-existent = domains. Matt From nobody Sun Jun 8 23:23:08 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A67D1B27DB for ; Sun, 8 Jun 2014 23:23:07 -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 UN2dVm6nv_X9 for ; Sun, 8 Jun 2014 23:23:05 -0700 (PDT) Received: from secure.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id BF4F31B27D8 for ; Sun, 8 Jun 2014 23:23:04 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=547; t=1402294982; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=kCdABHD53x5CPHNF+LeFVMU3aY8=; b=HLfeNkZ5o7YhNJgdTsmw yQEjHEdh3DsqN+1JiyqE1VAP6sywejGhV7jyCWDTqaF6QL32+ASHOy+veExpkH15 WpT3jLIhOzb5ijXuDBlzNXreADOl0bk7qWhSrqTXpLXUd+HnlJ60iIh3iI/uwJtt qryop8xhB0CIWXh6/y0RtfI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 09 Jun 2014 02:23:02 -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; Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1775106220.10081.4172; Mon, 09 Jun 2014 02:23:01 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=547; t=1402294816; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=/j2AavO STcQvuzffz/J2BqwFaOG82MRhMlXJHN0Oui4=; b=1l8Oo4lhe75DRdHeq+swImA /sA4Iz8gpTT4+988/oLcFMn97+FJb995GWusunE1rF7u5TKMwuiUoeeG0vKDimkh SQyFXlCcFGsS5DaCS4I5/T/M7W/7wa8LroBBsx9Q6ZoMYv+yXQb1hGtlmiPCBSE2 OxoAWmf5tv1zU9DBZqx8= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 09 Jun 2014 02:20: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 1791463234.9.6036; Mon, 09 Jun 2014 02:20:15 -0400 Message-ID: <539552C0.8020600@isdg.net> Date: Mon, 09 Jun 2014 02:22:56 -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: Matt Simerson , "dmarc@ietf.org" References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> In-Reply-To: <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/MpZ8YzW56IqaFyVP2jwyvYWPyrE Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 09 Jun 2014 06:23:07 -0000 On 6/9/2014 2:01 AM, Matt Simerson wrote: >> >> I also fail to see how this is a security issue. > > Agreed. It's *really* easy to filter and block delivery >for non-existent domains. > That is exactly what will be required to mitigate and close this new security hole. if mail.from.tld is ".invalid" then reject it, or accept and discard, or accept and quarantine Then it won't be a potential security problem any more. We went through this same issue with DKIM and its Multiple From headers security hole. -- HLS From nobody Sun Jun 8 23:33:56 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722E01B27E1 for ; Sun, 8 Jun 2014 23:33: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 N-IVeIQJ4fHp for ; Sun, 8 Jun 2014 23:33:52 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F501B27DB for ; Sun, 8 Jun 2014 23:33:52 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id x13so2542389wgg.3 for ; Sun, 08 Jun 2014 23:33: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=44MSbN5QfyikNsdYJJw85BAnJH4zrizQUKblFTjQSgc=; b=UWm+G38v34rF1tMu+TBrTsMBYd5tONKixgacR2mrE0Dhf8mZisch01xFJjYvRqL52H ayhzCEW2V82oaJmz5Zx06kaTH3Fe32kI23ubWVHlr4vk08+4hZTUJ4MJdBjrH1xtsz/n aoyhIuO2JL88J8N3V/zUvZ0e5Pjly8BTY/YqMvpJ4n90E+BgNEE65Dg4UM27kXp01kh1 oqJZD8JmlQSDVI4zL1UfNHYznmMRvz63w3NecibOMwDN2M/aE1iO3jYlR90OEnMVe/Pk GAul5pp5ewDgUtuEwk4XsseHu5vk0h9mjGNjglc9c5co2hXHFrSEWtcj6fjAtMpY8A90 eXPg== MIME-Version: 1.0 X-Received: by 10.180.228.39 with SMTP id sf7mr23969013wic.26.1402295630960; Sun, 08 Jun 2014 23:33:50 -0700 (PDT) Received: by 10.180.23.104 with HTTP; Sun, 8 Jun 2014 23:33:50 -0700 (PDT) In-Reply-To: <539532C2.9030406@isdg.net> References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> Date: Sun, 8 Jun 2014 23:33:50 -0700 Message-ID: From: "Murray S. Kucherawy" To: Hector Santos Content-Type: multipart/alternative; boundary=001a1134d18af41f5504fb61647c Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/P0VO12iG6Z6OHI_kDZQBAXr1OGU Cc: "dmarc@ietf.org" , "Stephen J. Turnbull" , Phillip Hallam-Baker Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 09 Jun 2014 06:33:54 -0000 --001a1134d18af41f5504fb61647c Content-Type: text/plain; charset=UTF-8 On Sun, Jun 8, 2014 at 9:06 PM, Hector Santos wrote: > Fundamentally, any From-Corruption (good term to use) concept is bad. 30 > years of mail software/product/hosting development across multiple networks > tells me so, it ethically burns inside me as wrong and I have strong > confidence the IETF/IESG wise ones will agree. I hope you agree too. > I understand that this is your opinion and that you're passionate about it. I have no idea where consensus falls, and I don't think I've given it enough thought to have my own opinion yet. > You will need to add security information to your DMARC document as this > From-Corruption concept would be a security exploit that can potentially > get by RFC5322 validation checks that can hurt DMARC publishers and create > bad PR for the DMARC protocol itself. DMARC receivers will need to be > warned. > The base document doesn't advocate changing From as a method of solving anything. It only lays out the alignment requirement; compliance is an exercise for the reader (or for some other document). As far as I know, nobody's even suggested adding that to the base document, so I have no idea why you're threatening an appeal about it, or on what RFC2026 basis you might do so. Now, if someone were to write a draft that actually tries to codify this practice, then I agree, the security implications of doing so would need to be well documented. But that has yet to materialize, so I don't see what all the hubbub is about. -MSK --001a1134d18af41f5504fb61647c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Jun 8, 2014 at 9:06 PM, Hector Santos <hsantos@isd= g.net> wrote:
Fundamentally, any From-Corruption (good ter= m to use) concept is bad. 30 years of mail software/product/hosting develop= ment across multiple networks tells me so, it ethically burns inside me as = wrong and I have strong confidence the IETF/IESG wise ones will agree. I ho= pe you agree too.

I understand that this is your opinion and= that you're passionate about it.=C2=A0 I have no idea where consensus = falls, and I don't think I've given it enough thought to have my ow= n opinion yet.
=C2=A0
You will need to add security information to your DMARC document as this Fr= om-Corruption concept would be a security exploit that can potentially get = by RFC5322 validation checks that can hurt DMARC publishers and create bad = PR for the DMARC protocol itself. =C2=A0DMARC receivers will need to be war= ned.

The base document doesn't advocate cha= nging From as a method of solving anything.=C2=A0 It only lays out the alig= nment requirement; compliance is an exercise for the reader (or for some ot= her document).=C2=A0 As far as I know, nobody's even suggested adding t= hat to the base document, so I have no idea why you're threatening an a= ppeal about it, or on what RFC2026 basis you might do so.

Now, if someone were to write a draft that actually tries to codify thi= s practice, then I agree, the security implications of doing so would need = to be well documented.=C2=A0 But that has yet to materialize, so I don'= t see what all the hubbub is about.

-MSK
--001a1134d18af41f5504fb61647c-- From nobody Sun Jun 8 23:50:23 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4D91B27F0 for ; Sun, 8 Jun 2014 23:50:07 -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 hDgpqG4ePblT for ; Sun, 8 Jun 2014 23:50: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 430A91B27EA for ; Sun, 8 Jun 2014 23:50:06 -0700 (PDT) Received: (qmail 54998 invoked from network); 9 Jun 2014 06:49:38 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 9 Jun 2014 06:49:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=15de.53955903.k1406; i=johnl@user.iecc.com; bh=RZ4DbQxzj38C2gbTWibyOwCC04s3kaHXp8UH07ITX74=; b=ByiviK9c6N3Mjs5kJo7f70WKI4VE6AbX9N/nw6kAESU88/9yB9vfY0gSRcp3OcygXhT3DQhYWIjXk7342wPwwIq7r9ocP6boeyoTX9ChabdRUfmdQrk4OpLa+8100bTjQK75YyDAB5iEZrxOtSxl2GtCQKWUuRMbgr1boOR3ppX+ObFjh050CrPrGm2ANZW/+lClLWRax9/jnirG14DKbawgOHBjLjAa800qZqFz/uIZi6WE2Jjb91C9LCjWlTTP DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=15de.53955903.k1406; olt=johnl@user.iecc.com; bh=RZ4DbQxzj38C2gbTWibyOwCC04s3kaHXp8UH07ITX74=; b=G3m3GUpbS6UxASEF2A+TOr2C7EcsIpXv1VhB2mPsYAC1p+WbCG2/SPEdCtgyDXJmC/V9wKyDU9pcbEVvsS+FJDXyrUTa6yeCZtKHAITfkIYDeIYyIQLcA2I4azL5E5cWSnfc3j0CmtJagkEsr7WAeVCd+LZ9aaPOf+ASsLlwbiomSjo7AzimCq6lgkdDGAPPXd79zt7HNkATqKouRdo/BAu55uKft7obvF8u6eUhvTAawrpPfKeWjvP3+fmPV/Nz Date: 9 Jun 2014 06:49:16 -0000 Message-ID: <20140609064916.5597.qmail@joyce.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: http://mailarchive.ietf.org/arch/msg/dmarc/7biyU1rMlHhE5kb_W-bE479-B3s Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] advice to MTAs 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, 09 Jun 2014 06:50:07 -0000 >It is mentioned in Section 6, but the mention there doesn't even say that >it's the DMARC result that's supposed to be recorded. That bit at least >needs to be fixed. > >Anyone else have a comment? Recording stuff in A-R is fine. Advice about how MUAs should display them is not. Considering the dismal history of browser warnings about bad SSL certs, I would expect any user interface advice we give to be counterproductive. R's, John From nobody Mon Jun 9 01:07:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623BB1A0019 for ; Mon, 9 Jun 2014 01:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 LBvSambB-vM9 for ; Mon, 9 Jun 2014 01:07:46 -0700 (PDT) Received: from nm32.bullet.mail.gq1.yahoo.com (nm32.bullet.mail.gq1.yahoo.com [98.136.217.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BFC81A0012 for ; Mon, 9 Jun 2014 01:07:44 -0700 (PDT) Received: from [127.0.0.1] by nm32.bullet.mail.gq1.yahoo.com with NNFMP; 09 Jun 2014 08:07:44 -0000 Received: from [98.137.12.61] by nm32.bullet.mail.gq1.yahoo.com with NNFMP; 09 Jun 2014 08:04:44 -0000 Received: from [216.39.60.215] by tm6.bullet.mail.gq1.yahoo.com with NNFMP; 09 Jun 2014 08:04:44 -0000 Received: from [127.0.0.1] by omp1102.mail.gq1.yahoo.com with NNFMP; 09 Jun 2014 08:04:44 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 201170.36381.bm@omp1102.mail.gq1.yahoo.com Received: (qmail 59669 invoked by uid 60001); 9 Jun 2014 08:04:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402301084; bh=PK9nOjb0mem99hTazlbOGARBO9/HU0CX5AuBFUiNLKY=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=eaznCWyV/FYgNwf933nJGlfO3LfKy/h8sFATSyWGOm5fzpKtaq9mxTie+pEVcVR/7x1p7Wc+eW5tmYAlf3ayuk4RHGm+SHiBwRzw6Ve+a5BaSZWnyn6kQOrZwGGiIiMsWYlf4pKL9WjLX9wPI/kQrBB6mo52TdNURv8QHPLj/30= X-YMail-OSG: 9ETs6hMVM1m3B7gYTSzzN69sBNfU0fGisFd02vh.FCfQiRN XtxzoGiYAfNAl6pZs5h4bQ60HCzpKewihSthL52w7T9.gCNsNQS6JjcYig96 uuj53NH1ryEeN2jE3vEtbjJKgnbOQsgCM2I_HRpcdW1p6uzk3IRso8T.bvr1 hQNGyJQBnpC71XEa_yEpW4vMqJWzW86eSge4gqttHOKDbP9R5gseXWcOMGPc yXhPYzsvKSkmotEGFK94WGHJrkN_FJv3y28a4bQtTbKSKC3A5LD5EKNYqlA6 28L8V.RrYo1222qdTjDKdcsjh_YLYTGfyeHw6w9_6oNLtmPNsxIkQu1PEsMM ez5yhLg7XTi8XMKPmOGy7hFZck2JM49h6EadauEdCz_hyu6ykK6Ajb4dXVwp 2.nBpRtvYaw2Brsj5LfH1OvSZ.p0Zx621JmaTZQvpSeKBQ5eT6Y59QuWJE.x FcpYfMcVuItgTc.X4gQIZEzCOoGflzW1KW78oCsNc5hbkhpsnAaBlGStcbab 2rgGciyP4WVc2knPUqxy825xjMMm.Q6YCAApXfUW0aaOvKJr1gE1jpcs9QpQ c0wYiW8eJK3gnaq7jargZjlu7GC.77UoQyMutPBNAIhhbwxtCNbYkWrTRvvp c3GGPiHU2YjvuuP96gSybMgLngLmHOVB3rCzkia22t59c4sst Received: from [79.175.112.242] by web164602.mail.gq1.yahoo.com via HTTP; Mon, 09 Jun 2014 01:04:44 PDT X-Rocket-MIMEInfo: 002.001, T24gU3VuZGF5LCBKdW5lIDgsIDIwMTQgNDowMyBQTSwgSGVjdG9yIFNhbnRvcyA8aHNhbnRvc0Bpc2RnLm5ldD4gd3JvdGU6CgoKPiBDYW4gd2UgdXNlIGEgZGlmZmVyZW50IHRhZyBmb3IgeW91ciBwcm9wb3NhbD8KCkhlY3RvciwgaSdsbCBnaXZlIHUgb25lIHRoaW5nIGZvciBzdXJlOiB1IGRvIGxpa2UgdG8KbWFrZSB1ciByZXBsaWVzIGFzIGRldGFpbGVkIGFzIHBvc3NpYmxlLgoKaSBkbyByZXNwZWN0IHRoYXQgYWN0dWFsbHksIGNhdXNlIGl0IHNob3dzIHRoYXQgdQpnaXZlIGEgZGFtbiwgYW5kIHRoYXQBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <1402218789.64411.YahooMailNeo@web164602.mail.gq1.yahoo.com> <53946D15.5090103@isdg.net> Message-ID: <1402301084.4746.YahooMailNeo@web164602.mail.gq1.yahoo.com> Date: Mon, 9 Jun 2014 01:04:44 -0700 (PDT) From: Vlatko Salaj To: Hector Santos , "dmarc@ietf.org" , Douglas Otis In-Reply-To: <53946D15.5090103@isdg.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/a8ZSeEYm6ghi5KNGh819_ap7SxI Subject: Re: [dmarc-ietf] 3rd party alignment DMARC upgrade moving to RFC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 09 Jun 2014 08:07:49 -0000 On Sunday, June 8, 2014 4:03 PM, Hector Santos wrote:=0A= =0A=0A> Can we use a different tag for your proposal?=0A=0AHector, i'll giv= e u one thing for sure: u do like to=0Amake ur replies as detailed as possi= ble.=0A=0Ai do respect that actually, cause it shows that u=0Agive a damn, = and that u r a perfectionist, both=0Atraits that r actually somewhat of a r= equirement=0Ain development of things such a standards.=0A=0Abut u may, esp= ecially if u r pressed with time,=0Amake it as shirt as much u like, and ho= pe my brain=0Ais developed enough to fill all the blanks on its own.=0A=0Aa= nd i'll do my best to surprise u.=0A=0Athat said, i understand all the tech= nical burden=0Aof possible incompatibility, which u were kind enough=0Ato c= over in ur reply. but i hope DMARC implementers=0Afollowed DMARCv1 specs an= d r making version checks=0Abefore they actually process aspf and adkim tag= s,=0Athe way spec requires them to.=0A=0Ai do not want to lower my ambition= s cause of fear of=0Abad DMARC implementation out there. bugs r to be=0Aadd= ressed by their developers.=0A=0A=0Aso, the question, imo, is what is bette= r:=0A=0A1. to be as much compatible as possible with v1,=0A=A0=A0 essential= ly making as little disruption as possible,=0A=A0=A0 but risking to be igno= red on long run, and=0A=0A2. to be blunt and request a version replacement,= =0A=A0=A0 hoping for overall approval, thus moving v1 to=0A=A0=A0 legacy.= =0A=0A=0Aimo, changing the way alignment works, ESSENTIALLY=0Achanges the b= asic logic, based on a SINGLE domain=0Avirtue.=0A=0Aby extending it to cove= r whatever domain-owner wants=0Acovering, alignment now becomes a TRUST log= ic, and,=0Aimo, that is a sufficient reason to actually go=0Abluntly forwar= d and make space for DMARCv2,=0Apossibly as a 1st step for any future IETF = WG to base=0Aits work on.=0A=0A=0Ayeah, i know this is ambitious. and may a= s well be=0Aignored as SPF2 was. but i hope we learned from=0Apast mistakes= , and instead i choose to be positivist=0Aabout it and hope ppl will find D= MARCv2 an upgrade=0Ain right direction.=0A=0A=0Abeside those clearly politi= cal motives, imo, there=0Ar technical ones:=0A1. adding "none" to alignment= logic requires changes=0A=A0=A0 in aspf/adkim tags, and i think "none" is = valued=0A=A0=A0 enough to warrant it for domain-owner too,=0A=A0=A0 not jus= t 3rd party,=0A2. there's a need to treat ASL domains separately for=0A=A0= =A0 SPF and DKIM, cause some domains may need something=0A=A0=A0 like "aspf= =3Dn:urdomain.com adkim=3Ds:urdomain.com",=0A3. adding new tags is less opt= imized than using old tags,=0A=A0=A0 essentially cause it uses more charact= ers, in a limited=0A=A0=A0 DNS record space.=0A=0A=0Aall that being said, w= e can do both:=0A=0A1. make a DMARC version 1.1, which would use=0A=A0=A0 a= spfx and adkimx, and won't introduce "none" for=0A=A0=A0 domain-owner; mere= ly to have a test online, and=0A=A0=A0 to see if there's something we miss = in the concept space,=0A=A0=A0 but also as a fallback if v2 is completely d= ismissed=0A=A0=A0 by community,=0A=0A2. make a DMARC version 2 draft, which= would go my=0A=A0=A0 original proposal for aspf and adkim, and which=0A=A0= =A0 we would advertise as a more optimized, stable=0A=A0=A0 solution, worki= ng towards inclusion of a more complex=0A=A0=A0 and scalable 3rd party supp= ort [i'm considering TPA-Label],=0A=A0=A0 in addition to ASL, thus adding m= ore weight to=0A=A0=A0 the proposed version upgrade.=0A=0A=0Abe free to rep= ly as detailed as u like. i'm happy we r=0Amoving on this, anyhow.=0A=0A=0A= -- =0AVlatko Salaj aka goodone=0Ahttp://goodone.tk From nobody Mon Jun 9 01:54:47 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4021A0025 for ; Mon, 9 Jun 2014 01:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.508 X-Spam-Level: X-Spam-Status: No, score=0.508 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, GB_I_INVITATION=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 qja5qVsrC9yF for ; Mon, 9 Jun 2014 01:54:45 -0700 (PDT) Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id EFD4A1A0023 for ; Mon, 9 Jun 2014 01:54:44 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 15DCE970B37; Mon, 9 Jun 2014 17:54:44 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 8CF8B157EEA; Mon, 9 Jun 2014 17:54:43 +0900 (JST) From: "Stephen J. Turnbull" To: "John Levine" In-Reply-To: <20140609064916.5597.qmail@joyce.lan> References: <20140609064916.5597.qmail@joyce.lan> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) Date: Mon, 09 Jun 2014 17:54:41 +0900 Message-ID: <8761ka1mzy.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/zIyXIJVrm4Nx-0dqNoxldk4yCjs Cc: dmarc@ietf.org, superuser@gmail.com Subject: Re: [dmarc-ietf] advice to MTAs 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, 09 Jun 2014 08:54:46 -0000 John Levine writes: > Recording stuff in A-R is fine. Advice about how MUAs should display > them is not. Considering the dismal history of browser warnings about > bad SSL certs, I would expect any user interface advice we give to be > counterproductive. Agreed. However, in case of "p=quarantine", IWBNI MUAs told the reader that there's a reason Aunt Sally's birthday greeting is in the spam folder, and it's more than just the that fact that she emailed you 27 invitations to join her Amway downline last month. Similarly in case of bypassing DMARC by wrapping the message, or a length limit on the DKIM signature, IWBNI the unauthenticated parts of the message were given a "nice UX" treatment semantically equivalent to displaying it in grey45 on grey50, adding a big warning in red explaining that From: header can't be trusted and clicking on links is not advised, and a button to make it readable (and make the annoying warning go away). I understand the reservations you and Dave are posting about trying to make concrete suggestions about UI/UX in RFCs. Still, unless we get closer to the end-user wetware than simply adding an invisible Authentication-Results field, the phishers are just going mimic our workarounds or create their own. Best would be direct coordination with the major MUA teams, but we should also document the semantics we'd like to convey. From nobody Mon Jun 9 06:19:38 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1F7A1A016B for ; Mon, 9 Jun 2014 06:19:35 -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_40=-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 azkapA5-MYrT for ; Mon, 9 Jun 2014 06:19:31 -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 5FE091A0164 for ; Mon, 9 Jun 2014 06:19:30 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES533.agna.amgreetings.com ([::1]) with mapi id 14.03.0158.001; Mon, 9 Jun 2014 09:19:30 -0400 From: "MH Michael Hammer (5304)" To: "Talamo, Victor" , Vlatko Salaj , "Popowycz, Alex" Thread-Topic: [dmarc-ietf] confusing 3rd party support so it remains out Thread-Index: AQHPgJE48Ol4iNEVL0Gsq8oF29G/u5ti9ojWgABQdQCAAAj6AIAAsLuAgAAaTYCAAEi4gIAAONeAgAAU4ACAAAZlgIAAC1IAgAASOQCAA/O2QA== Date: Mon, 9 Jun 2014 13:19:29 +0000 Message-ID: References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1402042491.15608.YahooMailNeo@web164601.mail.gq1.yahoo.com> <877g4u2ws4.fsf@uwakimon.sk.tsukuba.ac.jp> <1402063755.61291.YahooMailNeo@web164602.mail.gq1.yahoo.com> <8738fi2bba.fsf@uwakimon.sk.tsukuba.ac.jp> <1402080444.6636.YahooMailNeo@web164602.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8D62B7FE@MSGRTPCCRF2WIN.DMN1.FMR.COM> <1402084248.69843.YahooMailNeo@web164606.mail.gq1.yahoo.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.220] 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: http://mailarchive.ietf.org/arch/msg/dmarc/bC8MNm1QW7I0w3zn4Sr6GuTod9g Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 09 Jun 2014 13:19:36 -0000 > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Talamo, Victor > Sent: Friday, June 06, 2014 4:56 PM > To: Vlatko Salaj; Popowycz, Alex > Cc: dmarc@ietf.org > Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out >=20 > I concur with Alex. Attached is very dated list of DMARC adopters from > sometime last year and it is in no way comprehensive. The list is simply = a > sample to identify dmarc adopters, and included a mix of senders and > receivers adopting DMARC. With that said if you check the DMARC records > for these domains today, the vast majority of these domains are DMARC > REJECT comprising billions of emails. Enough said. >=20 We implemented the essence of DMARC (the publishing of records in DNS didn'= t exist so I communicated to mailbox providers through the DKIM-ops list as= well as directly) in late 2007, so my personal experience representing sen= ding domains spans 6+ years and billions of emails. Mike From nobody Mon Jun 9 06:27:56 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D651A0162 for ; Mon, 9 Jun 2014 06:27:55 -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 XwkAw16WajVk for ; Mon, 9 Jun 2014 06:27:50 -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 BDB521A0158 for ; Mon, 9 Jun 2014 06:27:49 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES532.agna.amgreetings.com ([::1]) with mapi id 14.03.0158.001; Mon, 9 Jun 2014 09:27:48 -0400 From: "MH Michael Hammer (5304)" To: Vlatko Salaj , "Talamo, Victor" Thread-Topic: [dmarc-ietf] confusing 3rd party support so it remains out Thread-Index: AQHPgJE48Ol4iNEVL0Gsq8oF29G/u5ti9ojWgABQdQCAAAj6AIAAsLuAgAAaTYCAAEi4gIAAONeAgAAU4ACAAAZlgIAAC1IAgAASOQCAAAZMAIAD7jCg Date: Mon, 9 Jun 2014 13:27:48 +0000 Message-ID: References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1402042491.15608.YahooMailNeo@web164601.mail.gq1.yahoo.com> <877g4u2ws4.fsf@uwakimon.sk.tsukuba.ac.jp> <1402063755.61291.YahooMailNeo@web164602.mail.gq1.yahoo.com> <8738fi2bba.fsf@uwakimon.sk.tsukuba.ac.jp> <1402080444.6636.YahooMailNeo@web164602.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8D62B7FE@MSGRTPCCRF2WIN.DMN1.FMR.COM> <1402084248.69843.YahooMailNeo@web164606.mail.gq1.yahoo.com> <1402089514.72796.YahooMailNeo@web164603.mail.gq1.yahoo.com> In-Reply-To: <1402089514.72796.YahooMailNeo@web164603.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.220] 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: http://mailarchive.ietf.org/arch/msg/dmarc/SlhuHjdwHYC5tqi6i7h7uk5OPa4 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 09 Jun 2014 13:27:55 -0000 > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Vlatko Salaj > Sent: Friday, June 06, 2014 5:19 PM > To: Talamo, Victor > Cc: dmarc@ietf.org > Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out >=20 > On Friday, June 6, 2014 10:56 PM, "Talamo, Victor" > wrote: >=20 >=20 > > With that said if you check the DMARC records for these domains today, > > the vast majority of these domains are DMARC REJECT comprising > > billions of emails. >=20 > billions of notification email. that barely anyone reads. and that nobody= cares > if gets lost. >=20 > i can only hope to see real data on number of DMARC false-positives in th= at > billions of notification email, but i'm sure that would just completely c= rash > any trust in DMARC, so we will never see it. >=20 Our analysis of DMARC reporting (AUF and RUF) plus private channel reportin= g for our domains indicates FP rates ranging from .17% to .3% (that is, le= ss than a fifth of a percent to a third of a percent). I'm not sure why you= claim that reporting of FP rates would "completely crash any trust in DMAR= C, so we will never see it"? > exactly the reason behind DMARC being an independent document on IETF. >=20 Not really. While people who in the process (Attempt to bring DMARC under I= ETF auspices other than as an independent document) from both the IETF and = DMARC sides may disagree on some things, I think all who were "in the room"= would agree that the failure to do so was not a function of false positive= rates. > not that i care anymore. it's a waste of my time, obviously. >=20 > 'nuff said. >=20 >=20 > -- > Vlatko Salaj aka goodone > http://goodone.tk >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Mon Jun 9 07:01:20 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 318221A017C for ; Mon, 9 Jun 2014 07:01:18 -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 AbPWW3Gr50gY for ; Mon, 9 Jun 2014 07:01:12 -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 2AE7A1A017A for ; Mon, 9 Jun 2014 07:01:12 -0700 (PDT) Received: (qmail 21231 invoked from network); 9 Jun 2014 14:01:09 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 9 Jun 2014 14:01:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=18a6.5395be25.k1406; i=johnl@user.iecc.com; bh=SIw2WVlIozOqdCO+0zhD2EyC5edGl2tRKqRO+ztUIEs=; b=ydxmHdqiFGT36bkXNeoyc5OV/jSJT2ppuxEeo0jmKgF80ehmWFZAn1SSRCp3JGpVkw01MVH/3WnUiKuVhZ21NXEUor+nd1L8bvqbAKmn/s/OHYyC8pmOD08u1a8YqEDM4gR1KMT9Ju3BCERt0pyxo8YQBSn8ZjGV49wU/pwGEFdhbM3DtWhSdRHGcHsaFSrhgBJ1qHV45Wa+zSm5Q+n5ztj+QOVvF22Bd7Xt2Ahse7CLGmE8fpv3A+HrBGBdDrnx DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=18a6.5395be25.k1406; olt=johnl@user.iecc.com; bh=SIw2WVlIozOqdCO+0zhD2EyC5edGl2tRKqRO+ztUIEs=; b=ZUh/7XPHOH8FuylA+0a6+hx921Y5CI8/3zfNdNEc6V3qfQ4rWyasoZARkdll1CYpYZQpei2dKt7Qfr2z0MYnf2CyHOtaIR/BM39ZNC4RXTtl3pBbQH+XJGbfu2/MOo+ULkbjRoMah0mT11dUQvHi4Iblp8cxXs49q03JYtK63OC4OzT/jk1ZFyJQr8JpGL/6XtOJW8Ed6MYyhkmYkgYoNMNv4rGEIWD25b0rwOeTh9bNB1y4pmR4UMnwYS4Mtwzi Date: 9 Jun 2014 14:00:46 -0000 Message-ID: <20140609140046.6309.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <8761ka1mzy.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: http://mailarchive.ietf.org/arch/msg/dmarc/aEXSmkfXANcEtKrknmkKrL2ykVk Cc: stephen@xemacs.org Subject: Re: [dmarc-ietf] advice to MTAs 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, 09 Jun 2014 14:01:18 -0000 >Similarly in case of bypassing DMARC by wrapping the message, or a >length limit on the DKIM signature, IWBNI the unauthenticated parts of >the message were given a "nice UX" treatment semantically equivalent >to displaying it in grey45 on grey50, adding a big warning in red >explaining that From: header can't be trusted and clicking on links is >not advised, and a button to make it readable (and make the annoying >warning go away). People made this suggestion for l= DKIM signatures, too. It strikes me as hugely confusing, since it provides no useful answer to "should I believe this message or not?" Someone thinks it's bad, but it looks OK. Who do I believe? A note about why a message was put in the spam folder seems OK, since it is not demanding that the user make a security decision. R's, John From nobody Mon Jun 9 07:48:03 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5BE1A0204 for ; Mon, 9 Jun 2014 07:48:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.713 X-Spam-Level: X-Spam-Status: No, score=-0.713 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FB_BE_MILLION=1.837, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 tACRnb_2YSeC for ; Mon, 9 Jun 2014 07:48:00 -0700 (PDT) Received: from nm35.bullet.mail.gq1.yahoo.com (nm35.bullet.mail.gq1.yahoo.com [98.136.217.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8D011A01FF for ; Mon, 9 Jun 2014 07:48:00 -0700 (PDT) Received: from [127.0.0.1] by nm35.bullet.mail.gq1.yahoo.com with NNFMP; 09 Jun 2014 14:48:00 -0000 Received: from [98.137.12.56] by nm35.bullet.mail.gq1.yahoo.com with NNFMP; 09 Jun 2014 14:45:03 -0000 Received: from [98.137.12.53] by tm1.bullet.mail.gq1.yahoo.com with NNFMP; 09 Jun 2014 14:45:03 -0000 Received: from [127.0.0.1] by omp1068.mail.gq1.yahoo.com with NNFMP; 09 Jun 2014 14:45:03 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 834069.89075.bm@omp1068.mail.gq1.yahoo.com Received: (qmail 82546 invoked by uid 60001); 9 Jun 2014 14:45:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402325103; bh=gacSGaku8qWbgKqdx0mBHZZROWMhLLAvDOd23O+IXT8=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=2cZQAQlv7PyMBFZsP5BP7EQZAG+v/drmHwbtQlzLIRLv85aDOZnu3ptwAqgt29IWajQJSDDT9t5+dCJbv/rCK49m6ejvkEnQi6oyPWw5hBRHgUY8EATCweW4Uy7x4MEZTHi/yrQ1CHoeaMyKGcUEP5VSk/SIuc31MGT5RqPE3hs= X-YMail-OSG: iZKFfHIVM1kWDR96NRqhUv7yjGGPHotTVr0yjpIM1RKsIar FoXzYw6fFbnF_E_ip4hkxv3UPdu5vg6xEOJE7TdEF_E5udpWclEtDnhdSNFH plPwOpBamO0B0RyQ0455yrLZV3kp8o871DQi7MRz36JU3Ci08cHq91dqqQeo oinfEIH864QAeBcuWV9mlytkuhKjwlumnDiZOFyPdDwNkdXR6g7jibYyJv4. _cKnCQx5fGZz6hhPeKMtXkW9gCB4dMtIIvc.K1shUhoJ5_ng4_ZakMFC2NsU hN8eytqHcP8q0O3Jsrm1V1EqhzdGCSuuCYVWiO4mgE7LGx8kcCGO28u0UqPN 3aRqA3nUxVYA2.ZUP9yAgVnoQMqzmyQTUJCMw8LVvVh0MKQtycI1Ziy7t9LQ lH7mYgabGv4YPBA7z2WnDA.z8Cm5qh5GVBp5DfQERYMw..xReum2.eDws_Vn tgRZsWaeLG3bKYEnA2OpqoMCaRx6S9N2k8uE21_Jo_95XRLm7gHxXM73JZ4V UAUI..WrknsOAHgruI5zfH4dtDfrOsl6TMm9OFY1Xrt85pqlOLZvrSD0fIOk 2gbcbvMl7neF8U9aqwOor8XIBWyYyfl5pCCa_jmDYFZ.Tjg-- Received: from [79.175.112.242] by web164601.mail.gq1.yahoo.com via HTTP; Mon, 09 Jun 2014 07:45:03 PDT X-Rocket-MIMEInfo: 002.001, T24gTW9uZGF5LCBKdW5lIDksIDIwMTQgMzoyOCBQTSwgTUggTWljaGFlbCBIYW1tZXIgKDUzMDQpIDxNSGFtbWVyQGFnLmNvbT4gd3JvdGU6CgoKCj4gRlAgcmF0ZXMgcmFuZ2luZyBmcm9tIC4xNyUgdG8gLjMlCgpzbywgaW4gMSAwMDAgMDAwIDAwMCBvZiBub3RpZmljYXRpb25zLCAxIDcwMCAwMDAgdG8gMyAwMDAgMDAwIGlzIGxvc3QuCmFuZCB1IGRvbid0IGNvbnNpZGVyIHRoYXQgYSBwcm9ibGVtPwoKbGV0IGltYWdpbmUgdSBoYXZlIDMzMyAzMzMgY3VzdG9tZXJzLiBhbmQgdSBnZXQgYSBzZWN1cml0eSABMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1402042491.15608.YahooMailNeo@web164601.mail.gq1.yahoo.com> <877g4u2ws4.fsf@uwakimon.sk.tsukuba.ac.jp> <1402063755.61291.YahooMailNeo@web164602.mail.gq1.yahoo.com> <8738fi2bba.fsf@uwakimon.sk.tsukuba.ac.jp> <1402080444.6636.YahooMailNeo@web164602.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8D62B7FE@MSGRTPCCRF2WIN.DMN1.FMR.COM> <1402084248.69843.YahooMailNeo@web164606.mail.gq1.yahoo.com> <1402089514.72796.YahooMailNeo@web164603.mail.gq1.yahoo.com> Message-ID: <1402325103.54883.YahooMailNeo@web164601.mail.gq1.yahoo.com> Date: Mon, 9 Jun 2014 07:45:03 -0700 (PDT) From: Vlatko Salaj To: "MH Michael Hammer \(5304\)" , "Talamo, Victor" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ml4SlWQPAMXFlC8TH4fmPljqJtU Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 09 Jun 2014 14:48:02 -0000 On Monday, June 9, 2014 3:28 PM, MH Michael Hammer (5304) wrote: > FP rates ranging from .17% to .3% so, in 1 000 000 000 of notifications, 1 700 000 to 3 000 000 is lost. and u don't consider that a problem? let imagine u have 333 333 customers. and u get a security breach. and u decide to send instant security notice to customers by email asap. and about 1000 customers possibly doesn't receive any such notice, and about 560 of them doesn't get one for sure. and one of those 560 happens to be a millionaire with a forwarding email account which serves his iphone. well, if i were a bank, i would consider that a bad situation. >> exactly the reason behind DMARC being an independent document on IETF. > I think all who were "in the room" would agree that > the failure to do so was not a function of false positive rates. actually, my point was that DMARC excludes too much of legitimate email, not just false-positives. but i guess it depends how u define too much. not that it matters anyway. i'm somewhat sure any IETF DMARC work would include 3rd party support, so imo, we have passed the point of no return, and we r working to bring false positives down. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Mon Jun 9 08:15:21 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354621A01F9 for ; Mon, 9 Jun 2014 08:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 zmTPt34GoUyo for ; Mon, 9 Jun 2014 08:15:19 -0700 (PDT) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5462F1A01F2 for ; Mon, 9 Jun 2014 08:15:19 -0700 (PDT) Received: by mail-ve0-f173.google.com with SMTP id db11so1247446veb.32 for ; Mon, 09 Jun 2014 08:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=r/I+6wmdVcq9MqRaxXkPEhCVvF1SMY7eXpz0OALqMNM=; b=COUopjAE/SEVjZJOXgC4r6x4QuK0ugikiDQjD7F1OIycmq1N5lwhdhSrmz1SMsLC+n iChEbIlYPGf+IwTTkpwbEY6nkidQaoJhXVSJHzt36Ej2nIzKUrjQ58XPeWyP1V3HIcL4 dPkxlqTIYsVO6EZDxHrGlxPtB9qqOc2P99iJ4aAMWaYD8E9gbYRsM8n7oIiKNzJJvIcK C40gSvUkQTwYeZ6N6eM1EQ9cEkaD18hfSlfFw+YLBP4BSSXgIWmj84rbw6CwzMKArjsr QM2XNmkg0OHS6NuwhDGJUelispIJH36JURgLOGuHb7wlqwEfgbAVPB+2mM/ILUESB04f 52PA== MIME-Version: 1.0 X-Received: by 10.220.94.8 with SMTP id x8mr1230793vcm.67.1402326918432; Mon, 09 Jun 2014 08:15:18 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.33.199 with HTTP; Mon, 9 Jun 2014 08:15:18 -0700 (PDT) In-Reply-To: <1322124542.1687.1402245193573.JavaMail.zimbra@peachymango.org> References: <1402212310.40987.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1322124542.1687.1402245193573.JavaMail.zimbra@peachymango.org> Date: Mon, 9 Jun 2014 11:15:18 -0400 X-Google-Sender-Auth: UL3NyTcB_6e8movbpuhcplyd-rA Message-ID: From: Barry Leiba To: Franck Martin Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ERZV87o1xuv6yH4TGq2Mllj1qd8 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] advice to MTAs 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, 09 Jun 2014 15:15:20 -0000 > We based DMARC spec on the From header because it is visible to the end > user. Yes. Unfortunately, that's sort of a red herring. Most email clients show the "pretty text" of the From (the display-name ABNF construct) if it exists, and actually *hide* the actual address (the addr-spec ABNF construct). Putting as much value on RFC5322 From as DMARC does follows conventional wisdom, but I believe that wisdom is flawed. Of course, that speaks to the advice you want to give: tell UIs that they should show the From addr-spec to users always. But be clear about what you're asking for: you're not saying they should do it because it's objectively "right"; you're saying they should do it because it helps support the decision that DMARC has made. Barry > I understand it is hard to indicate a UI design specification, but we > should advice MUA that this header and especially the domain name(s) found > there are important, and they should remain visible and easily readable (in > a non confusing way) to the end user. From nobody Mon Jun 9 08:52:30 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074681A025B for ; Mon, 9 Jun 2014 08:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.053 X-Spam-Level: X-Spam-Status: No, score=-0.053 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_BE_MILLION=1.837, T_FILL_THIS_FORM_SHORT=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 CilMRYcwP_ko for ; Mon, 9 Jun 2014 08:52:28 -0700 (PDT) Received: from agwhqht.amgreetings.com (agwhqht.amgreetings.com [207.58.192.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA4171A021B for ; Mon, 9 Jun 2014 08:52:27 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES531.agna.amgreetings.com ([::1]) with mapi id 14.03.0158.001; Mon, 9 Jun 2014 11:52:26 -0400 From: "MH Michael Hammer (5304)" To: Vlatko Salaj , "Talamo, Victor" Thread-Topic: [dmarc-ietf] confusing 3rd party support so it remains out Thread-Index: AQHPgJE48Ol4iNEVL0Gsq8oF29G/u5ti9ojWgABQdQCAAAj6AIAAsLuAgAAaTYCAAEi4gIAAONeAgAAU4ACAAAZlgIAAC1IAgAASOQCAAAZMAIAD7jCggABa3ID//8eEYA== Date: Mon, 9 Jun 2014 15:52:25 +0000 Message-ID: References: <1401953757.92037.YahooMailNeo@web164605.mail.gq1.yahoo.com> <42D463AEF7054835AC8539ECE1BF9EBE@fgsr.local> <1402002610.13847.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1402042491.15608.YahooMailNeo@web164601.mail.gq1.yahoo.com> <877g4u2ws4.fsf@uwakimon.sk.tsukuba.ac.jp> <1402063755.61291.YahooMailNeo@web164602.mail.gq1.yahoo.com> <8738fi2bba.fsf@uwakimon.sk.tsukuba.ac.jp> <1402080444.6636.YahooMailNeo@web164602.mail.gq1.yahoo.com> <9495B91F5CA0E24C9161D71CD46E43DB011C8D62B7FE@MSGRTPCCRF2WIN.DMN1.FMR.COM> <1402084248.69843.YahooMailNeo@web164606.mail.gq1.yahoo.com> <1402089514.72796.YahooMailNeo@web164603.mail.gq1.yahoo.com> <1402325103.54883.YahooMailNeo@web164601.mail.gq1.yahoo.com> In-Reply-To: <1402325103.54883.YahooMailNeo@web164601.mail.gq1.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.144.15.220] 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: http://mailarchive.ietf.org/arch/msg/dmarc/gms5gkKSkMG-g_GFzXa2ce-Rm88 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out 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, 09 Jun 2014 15:52:29 -0000 > -----Original Message----- > From: Vlatko Salaj [mailto:vlatko.salaj@goodone.tk] > Sent: Monday, June 09, 2014 10:45 AM > To: MH Michael Hammer (5304); Talamo, Victor > Cc: dmarc@ietf.org > Subject: Re: [dmarc-ietf] confusing 3rd party support so it remains out >=20 > On Monday, June 9, 2014 3:28 PM, MH Michael Hammer (5304) > wrote: >=20 >=20 >=20 > > FP rates ranging from .17% to .3% >=20 > so, in 1 000 000 000 of notifications, 1 700 000 to 3 000 000 is lost. > and u don't consider that a problem? >=20 > let imagine u have 333 333 customers. and u get a security breach. > and u decide to send instant security notice to customers by email asap. > and about 1000 customers possibly doesn't receive any such notice, and > about 560 of them doesn't get one for sure. and one of those 560 happens = to > be a millionaire with a forwarding email account which serves his iphone. >=20 > well, if i were a bank, i would consider that a bad situation. >=20 Financial institutions can speak for themselves. I will point out that this= is about tradeoffs rather than absolutes. The majority of false positives = I see are because of forwarding on the recipient side. This is something th= e recipient can choose to address or not.It is beyond the control of the or= iginator of the message. For the financial institution the tradeoff is how= many of their customers are getting phished or abused because of fake noti= fications (or similar) claiming to be from their domain which some signific= antly larger number (than the FPs caused by DMARC) of their customers are i= mpacted by (as in theft of funds from their account).=20 That is a worse situation - for both the customer and the financial institu= tion. This is also why the financial institution asks for cellphone (SMS co= mmunication and/or voice), home phone and physical mailing address. If it i= s important enough then sending an email over the transom is not the way to= ensure that the recipient gets the message. This has been an issue even ab= sent SPF/DKIM/DMARC.=20 >=20 > >> exactly the reason behind DMARC being an independent document on > IETF. > > I think all who were "in the room" would agree that the failure to do > > so was not a function of false positive rates. >=20 > actually, my point was that DMARC excludes too much of legitimate email, > not just false-positives. >=20 > but i guess it depends how u define too much. >=20 Each domain, each user, each mailbox provider and each 3rd party service pr= ovider (for example MLs) will have a different definition based on their pe= rspective, needs and desires. >=20 > not that it matters anyway. i'm somewhat sure any IETF DMARC work would > include 3rd party support, so imo, we have passed the point of no return, > and we r working to bring false positives down. >=20 I expect we will see solutions that will address various aspects of FPs. Th= ere will always be a certain amount of FPs that any reasonable person would= expect. I have not seen much discussion of transient FPs where the validat= or is unable to look up the SPF or DKIM record. It does happen. From nobody Mon Jun 9 09:12:27 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F331A025A for ; Mon, 9 Jun 2014 09:12:25 -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 H5OrX_Nnazc5 for ; Mon, 9 Jun 2014 09:12:24 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 313361A0266 for ; Mon, 9 Jun 2014 09:12:24 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 4E9A9D045CE; Mon, 9 Jun 2014 12:12:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1402330343; bh=yxVDmMOS78+N0c2O5skAMVgmP7O6lRTr4dyAZtDOI/E=; h=In-Reply-To:References:Subject:From:Date:To:From; b=dwCx37hHd2wmMYvbWBVGUQaFQYpg2Yojf6CQFMChkKkP6zeNY8m/JmtLDSN/Nb/1P SZWbFvSeG5kPG2uQJEjo1z6jFELsxay61wxApPhAJD1qXJVzhyeVEhLzlYv5CaL2Pe qr5vaBjbzv2hhQAcMr/d+XsIPiM8JFul3QVZEjz0= Received: from [IPV6:2600:1003:b120:3e8e:b873:857b:7a42:df36] (unknown [IPv6:2600:1003:b120:3e8e:b873:857b:7a42:df36]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id C35D7D041AB; Mon, 9 Jun 2014 12:12:22 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: References: <1402212310.40987.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1322124542.1687.1402245193573.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Mon, 09 Jun 2014 12:12:19 -0400 To: "dmarc@ietf.org" Message-ID: <597dc384-7907-4a14-acaa-cd527650758b@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/6PhmOeObtRejey8Bw4kmVN2Iw_Q Subject: Re: [dmarc-ietf] advice to MTAs 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, 09 Jun 2014 16:12:25 -0000 On June 9, 2014 11:15:18 AM EDT, Barry Leiba wrote: >> We based DMARC spec on the From header because it is visible to the >end >> user. > >Yes. >Unfortunately, that's sort of a red herring. Most email clients show >the "pretty text" of the From (the display-name ABNF construct) if it >exists, and actually *hide* the actual address (the addr-spec ABNF >construct). > >Putting as much value on RFC5322 From as DMARC does follows >conventional wisdom, but I believe that wisdom is flawed. > >Of course, that speaks to the advice you want to give: tell UIs that >they should show the From addr-spec to users always. But be clear >about what you're asking for: you're not saying they should do it >because it's objectively "right"; you're saying they should do it >because it helps support the decision that DMARC has made. If any authentication technology is going to work, DMARC or whatever, it will have to be tied to some kind of identifier. 5322.From is as good as any and better than most. Scott K From nobody Mon Jun 9 09:46:30 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3AF61A01EF for ; Mon, 9 Jun 2014 09:46:28 -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 8O-x7mN2C9Rw for ; Mon, 9 Jun 2014 09:46:25 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 418031A01EA for ; Mon, 9 Jun 2014 09:46:25 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id x48so3373131wes.11 for ; Mon, 09 Jun 2014 09:46:23 -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=sk95NOcbIFrb+5rsLk/89wRxqgNgrhahQCc5jfQbb08=; b=OyoGqSLdVcX+byz9/HMtPZ9pWXC1O/vbJJiC9KWAW96UEFhKW4fCRAWEB0dj+nhKfc XUDGFWFB5G8m2DJYejAjo4KChv1AgxxrwtsB6kVnb7ftBOXQtaXO6F31Hd5WvvpXHt0u ZPNlbbuZGQuhEzZy2MHoAJcMgVHnf0jJynnBp9MaquY+AWmKKXj5NAFM2eiO2qlkN2Ga HvJn1MotO8W5lcr//NA84SwKFkpLCvi9dxsKAQBoK4G5gDByaQFdrc7umicUU1dt5syU ch7Q9ys4iEv2Qh0UEcjpkPN88fys/Y1049NAa2TnDOTnnsd+q8MpvaHw6suDj/sTGa0U vcfA== MIME-Version: 1.0 X-Received: by 10.194.89.168 with SMTP id bp8mr33453739wjb.73.1402332383713; Mon, 09 Jun 2014 09:46:23 -0700 (PDT) Received: by 10.180.23.104 with HTTP; Mon, 9 Jun 2014 09:46:23 -0700 (PDT) In-Reply-To: References: <1402212310.40987.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1322124542.1687.1402245193573.JavaMail.zimbra@peachymango.org> Date: Mon, 9 Jun 2014 09:46:23 -0700 Message-ID: From: "Murray S. Kucherawy" To: Barry Leiba Content-Type: multipart/alternative; boundary=047d7bf10a1c969ebd04fb69f355 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/19oxZ2WXLGgXsYNE6gjOK2Xc_O0 Cc: "dmarc@ietf.org" , Franck Martin Subject: Re: [dmarc-ietf] advice to MTAs 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, 09 Jun 2014 16:46:28 -0000 --047d7bf10a1c969ebd04fb69f355 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 9, 2014 at 8:15 AM, Barry Leiba wrote: > Unfortunately, that's sort of a red herring. Most email clients show > the "pretty text" of the From (the display-name ABNF construct) if it > exists, and actually *hide* the actual address (the addr-spec ABNF > construct). > > Putting as much value on RFC5322 From as DMARC does follows > conventional wisdom, but I believe that wisdom is flawed. > > Of course, that speaks to the advice you want to give: tell UIs that > they should show the From addr-spec to users always. But be clear > about what you're asking for: you're not saying they should do it > because it's objectively "right"; you're saying they should do it > because it helps support the decision that DMARC has made. There are some other options that are particularly interesting. For example, I'm told that Gmail will only show the display-name if the email address in the From field is also in the user's address book and the message authenticated. Otherwise, it shows the email address. Naturally, we can't rely on all MUAs doing that any time soon, and we don't really have much ability to nudge them in that direction either. -MSK --047d7bf10a1c969ebd04fb69f355 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 9, 2014 at 8:15 AM, Barry Leiba <barryl= eiba@computer.org> wrote:
Unfortunately, that's sort of a red herr= ing. =C2=A0Most email clients show
the "pretty text" of the From (the display-name ABNF construct) i= f it
exists, and actually *hide* the actual address (the addr-spec ABNF
construct).

Putting as much value on RFC5322 From as DMARC does follows
conventional wisdom, but I believe that wisdom is flawed.

Of course, that speaks to the advice you want to give: tell UIs that
they should show the From addr-spec to users always. =C2=A0But be clear
about what you're asking for: you're not saying they should do it because it's objectively "right"; you're saying they shou= ld do it
because it helps support the decision that DMARC has made.

There are some other options that are particularly interest= ing.=C2=A0 For example, I'm told that Gmail will only show the display-= name if the email address in the From field is also in the user's addre= ss book and the message authenticated.=C2=A0 Otherwise, it shows the email = address.

Naturally, we can't rely on all MUAs doing that any time= soon, and we don't really have much ability to nudge them in that dire= ction either.

-MSK
--047d7bf10a1c969ebd04fb69f355-- From nobody Mon Jun 9 09:54:46 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F541A01EF for ; Mon, 9 Jun 2014 09:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 to2eBpPXlqmt for ; Mon, 9 Jun 2014 09:54:41 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id E97701A01EA for ; Mon, 9 Jun 2014 09:54:40 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 099343FA0158; Tue, 10 Jun 2014 01:54:40 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id B951311F5B2; Tue, 10 Jun 2014 01:54:39 +0900 (JST) From: "Stephen J. Turnbull" To: "John Levine" In-Reply-To: <20140609140046.6309.qmail@joyce.lan> References: <8761ka1mzy.fsf@uwakimon.sk.tsukuba.ac.jp> <20140609140046.6309.qmail@joyce.lan> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 10 Jun 2014 01:54:39 +0900 Message-ID: <87fvje2fcg.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/S97iUq_VbeaCMiTM4Pa0fIExQWQ Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] advice to MTAs 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, 09 Jun 2014 16:54:43 -0000 John Levine writes: > People made this suggestion for l= DKIM signatures, too. l= DKIM signatures are a bad idea, precisely because in existing MUAs there will be no indication of what is covered by the signature, and what not. "Nobody" does that. But now mailing lists and other mediators are going to be systematically sidestepping DMARC, but (as we've seen with Yahoo! Groups already) still using "p=reject" mailboxes as identification. We know this is going to happen on a large scale. > It strikes me as hugely confusing, since it provides no useful > answer to "should I believe this message or not?" Someone thinks > it's bad, but it looks OK. Who do I believe? You believe what you believe, of course. The problem with the usual browser notification about unverifiable certificates is that it is too technical for most users to grasp, and they are unable to perform the necessary operations to determine whether it's secure. I don't know how to do any of this right, but surely it's worth trying to do better than we do it now. > A note about why a message was put in the spam folder seems OK, since > it is not demanding that the user make a security decision. ISTM that's just a different UI for the same semantics. I don't understand what you mean by "not demanding that the user make a security decision." If they continue reading the message ("because it's from Aunt Sally"), and take action on it, they may be defrauded. If they leave the message alone until they get corroboration through other channels, the probability is much less. In that sense they are making a security decision. Steve From nobody Mon Jun 9 11:32:57 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58401A02A3 for ; Mon, 9 Jun 2014 11:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 bTd8x1_BmKk2 for ; Mon, 9 Jun 2014 11:32:52 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61F9D1A0294 for ; Mon, 9 Jun 2014 11:32:51 -0700 (PDT) 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; Mon, 9 Jun 2014 20:32:49 +0200 Message-ID: <11E2FBD80B824A6C94C04B39E99CF14F@fgsr.local> From: "J. Gomez" To: Dave Crocker References: <1322530073.150717.1402179785354.JavaMail.zimbra@peachymango.org> <5393EC2B.6080501@gmail.com> Date: Mon, 9 Jun 2014 20:33: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: http://mailarchive.ietf.org/arch/msg/dmarc/WuyLQ5ZoROHynNTx_cSziseSnyQ Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Advice to MUA 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, 09 Jun 2014 18:32:55 -0000 On Sunday, June 08, 2014 6:52 AM [GMT+1=3DCET], Dave Crocker wrote: > On 6/8/2014 12:23 AM, Franck Martin wrote: > > I think we need to give advice to MUAs, while letting MUA developers > > some liberty on how to interpret it. > >=20 > > I'm proposing the following text to be added to the DMARC spec >=20 > Directives encased in standards that concern UI/UX design are > appropriate when there are empirical data to support them. Ok. Empirical data #1: web browsers[*] seem to be standardizing on = displaying the address bar in green when the user goes to a web site = with an Extended Validation SSL certificate. Empirical data #2: there seems to be industry-wide[*] consensus that #1 = is a good step forward. Empirical data #3: users[*] seem to be accepting #1 in good terms. Question: Could something akin to that be achieved in MUAs, leveraging = both DMARC *and* EV SSL certificates, for example coloring in green the = From: field which is displayed to the user (in MUA which happen to do = that[*]). [*]Exceptions may be found, caveat emptor. Regards, J.Gomez From nobody Mon Jun 9 11:53:30 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D3A1A02DA for ; Mon, 9 Jun 2014 11:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.902 X-Spam-Level: X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, 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 O30751Kk04Ij for ; Mon, 9 Jun 2014 11:53:21 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D1231A02D5 for ; Mon, 9 Jun 2014 11:53:21 -0700 (PDT) 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; Mon, 9 Jun 2014 20:53:19 +0200 Message-ID: <1B0121ADF8D04B9DBEDDD902EE39AAB9@fgsr.local> From: "J. Gomez" To: "Stephen J. Turnbull" References: <20140609064916.5597.qmail@joyce.lan> <8761ka1mzy.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Mon, 9 Jun 2014 20:53:30 +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: http://mailarchive.ietf.org/arch/msg/dmarc/vJNu89Xd6Th_zu7AKt8h2D6LPEk Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] advice to MTAs 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, 09 Jun 2014 18:53:23 -0000 On Monday, June 09, 2014 10:54 AM [GMT+1=3DCET], Stephen J. Turnbull = wrote: > John Levine writes: >=20 > > Recording stuff in A-R is fine. Advice about how MUAs should > display > them is not. Considering the dismal history of browser > warnings about > bad SSL certs, I would expect any user interface > advice we give to be > counterproductive. >=20 > Agreed. However, in case of "p=3Dquarantine", IWBNI MUAs told the > reader that there's a reason Aunt Sally's birthday greeting is in the > spam folder, and it's more than just the that fact that she emailed > you 27 invitations to join her Amway downline last month. >=20 > Similarly in case of bypassing DMARC by wrapping the message, or a > length limit on the DKIM signature, IWBNI the unauthenticated parts of > the message were given a "nice UX" treatment semantically equivalent > to displaying it in grey45 on grey50, adding a big warning in red > explaining that From: header can't be trusted and clicking on links is > not advised, and a button to make it readable (and make the annoying > warning go away). >=20 > I understand the reservations you and Dave are posting about trying to > make concrete suggestions about UI/UX in RFCs. Still, unless we get > closer to the end-user wetware than simply adding an invisible > Authentication-Results field, the phishers are just going mimic our > workarounds or create their own. Best would be direct coordination > with the major MUA teams, but we should also document the semantics > we'd like to convey. +1 I couldn't agree more. DMARC should not stay only in the MTA realm, after all DMARC deals with = the Header-From just because that's something the final user SEES, and = not because that's something the MTA naturally deals with. Therefore DMARC should leak to the final user who SEES that Header-From, = and that means MUAs have to enter the big picture of DMARC, somehow. And yes, that "somehow" is the difficult part, but it should not be left = aside, I think. And I think the recommendation to MUA authors should go into the = standard itself, not on a side document (BCP or whatever) which may or = may not be easy notice/find/know-about. Regards, J.Gomez From nobody Mon Jun 9 11:58:29 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560581A02DD for ; Mon, 9 Jun 2014 11:58: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 RsJQH1UFiEJO for ; Mon, 9 Jun 2014 11:58:24 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C27221A02D5 for ; Mon, 9 Jun 2014 11:58:23 -0700 (PDT) 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; Mon, 9 Jun 2014 20:58:22 +0200 Message-ID: From: "J. Gomez" To: Barry Leiba References: <1402212310.40987.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1322124542.1687.1402245193573.JavaMail.zimbra@peachymango.org> Date: Mon, 9 Jun 2014 20:58:32 +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: http://mailarchive.ietf.org/arch/msg/dmarc/lJLh93azllIuXMutXtHIsCT9Cbw Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] advice to MTAs 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, 09 Jun 2014 18:58:26 -0000 On Monday, June 09, 2014 5:15 PM [GMT+1=3DCET], Barry Leiba wrote: > > We based DMARC spec on the From header because it is visible to the > > end user. >=20 > Yes. > Unfortunately, that's sort of a red herring. Most email clients show > the "pretty text" of the From (the display-name ABNF construct) if it > exists, and actually *hide* the actual address (the addr-spec ABNF > construct). >=20 > Putting as much value on RFC5322 From as DMARC does follows > conventional wisdom, but I believe that wisdom is flawed. >=20 > Of course, that speaks to the advice you want to give: tell UIs that > they should show the From addr-spec to users always. But be clear > about what you're asking for: you're not saying they should do it > because it's objectively "right"; you're saying they should do it > because it helps support the decision that DMARC has made. I think that "asking for that" is both because it is "right", and = because "it helps support the decision that DMARC has made". DMARC is a security framework. If it helps DMARC, it is both things at = once. Regards, J.Gomez From nobody Mon Jun 9 12:05:43 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1FC71A0370 for ; Mon, 9 Jun 2014 12:05:41 -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 Lu5udTzWLRTg for ; Mon, 9 Jun 2014 12:05:40 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C4EA1A0328 for ; Mon, 9 Jun 2014 12:04:38 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id p10so6132153wes.6 for ; Mon, 09 Jun 2014 12:04:36 -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=IHr+BUH7bB72j+N29eWck7sdTnLSQEIgXGqvoowapYo=; b=uuzqitTYHfvLSGGQehMlI1Ql5ccRlfinB/o9Dcintl9qGL5Qwq6KhaqVxzjonmlkR0 WOh5149Mju2Uh6IVBhfjveEa1mdM6p4yitUyfJXyLICdA2tCJTJFE0oMXjDS4xWUyS+L 9X8pGw0YuHHxuMTTwjNNHDzXR2qBR+F5X0/my1wbt5R6f6QIMEnqJ3FiS8Js4BzrkYk7 k9lzJevxwAia+denVEqvsfugOw6BHsmv+lHsLMhtvXHXYr5jtc3L1jV1CHCmpoxRU7B/ fVg9pZkOgzGmmMJRKEdPJ2MyQ5C4TxC6D6RdKlpVifu6ZChDPBdxjb/sJMFLwSx0xY92 JATQ== X-Received: by 10.14.204.73 with SMTP id g49mr3931653eeo.2.1402340676760; Mon, 09 Jun 2014 12:04:36 -0700 (PDT) Received: from ?IPv6:2a02:a03f:1405:ee00:ac40:891b:473b:1f38? ([2a02:a03f:1405:ee00:ac40:891b:473b:1f38]) by mx.google.com with ESMTPSA id l41sm46840470eew.8.2014.06.09.12.04.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Jun 2014 12:04:36 -0700 (PDT) Message-ID: <5396050B.6070003@gmail.com> Date: Mon, 09 Jun 2014 21:03:39 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "J. Gomez" References: <1322530073.150717.1402179785354.JavaMail.zimbra@peachymango.org> <5393EC2B.6080501@gmail.com> <11E2FBD80B824A6C94C04B39E99CF14F@fgsr.local> In-Reply-To: <11E2FBD80B824A6C94C04B39E99CF14F@fgsr.local> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/fPyqe28Lb5geFTEd5uimGgZJ-ac Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Advice to MUA 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, 09 Jun 2014 19:05:42 -0000 On 6/9/2014 8:33 PM, J. Gomez wrote: > On Sunday, June 08, 2014 6:52 AM [GMT+1=CET], Dave Crocker wrote: >> Directives encased in standards that concern UI/UX design are >> appropriate when there are empirical data to support them. > > Ok. > > Empirical data #1: web browsers[*] seem to be standardizing on displaying the address bar in green when the user goes to a web site with an Extended Validation SSL certificate. Please forgive my having been unclear in what I meant. I mean empirical data about users, not about developers. That is, there needs to be evidence that what is being proposed has actual efficacy in user behavior, not merely popularity amongst software developers (or their managers.) > Empirical data #3: users[*] seem to be accepting #1 in good terms. "accepting" is an interesting word, since it refers to attitude, rather than actual utility. And then, of course, then there's the whole matter of needing external references that objectively support the assertions you are making... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jun 9 12:25:30 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FAF1A02D3 for ; Mon, 9 Jun 2014 12:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-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 7TIbmvR9DPzo for ; Mon, 9 Jun 2014 12:25:28 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EA651A02E2 for ; Mon, 9 Jun 2014 12:25:28 -0700 (PDT) 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; Mon, 9 Jun 2014 21:25:26 +0200 Message-ID: <9153E29A317845F3964C0060DBB2C21C@fgsr.local> From: "J. Gomez" To: Dave Crocker References: <1322530073.150717.1402179785354.JavaMail.zimbra@peachymango.org> <5393EC2B.6080501@gmail.com> <11E2FBD80B824A6C94C04B39E99CF14F@fgsr.local> <5396050B.6070003@gmail.com> Date: Mon, 9 Jun 2014 21:25:36 +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: http://mailarchive.ietf.org/arch/msg/dmarc/rZylBJ3BIWobabRkqImt_W5FHEI Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Advice to MUA 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, 09 Jun 2014 19:25:29 -0000 On Monday, June 09, 2014 9:03 PM [GMT+1=3DCET], Dave Crocker wrote: > And then, of course, then there's the whole matter of needing external > references that objectively support the assertions you are making... Yeah, well, we are having a mailing list exchange, not presenting a = doctoral thesis here. =20 Do you have references that objectively support the contrary to those = assertions, perhaps? =20 Do you know of any references/literature which posits contrary to those = assertions? Are those references/literature significant and/or = peacefully undisputed? Do you think those assertions are, as of today, = an undecided issue? Regards, J.Gomez From nobody Mon Jun 9 12:41:42 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC3C1A0354 for ; Mon, 9 Jun 2014 12:41:40 -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 eqU1XbP24_uX for ; Mon, 9 Jun 2014 12:41:39 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13C181A0305 for ; Mon, 9 Jun 2014 12:41:38 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hi2so2504228wib.0 for ; Mon, 09 Jun 2014 12:41:37 -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=EDN23JsNGdI1EZmEwY8Icbo9vzp5Fkwn1DpAvVipwQQ=; b=faesft9q6pwWoggZKkJWv2ckEl5VE8hhFqfEFa+3tEtBLzK8V5fGajXXSAoEpTXVSH HFRToHjUm5x8wPPuHcqUOjs7mNhRNeSAMimTaTCuq8wiUDHvhF2QNRhXcdEys0NqsJIH GJCV4nplUkMWiKFWoELHTo83XZDkDF7kR9MHon3wgm3ha4U0+H52VElopfAvatPhjOfY MZSAy+6xqDR/NvTVfzLegtVuanqNOBzb/Hy+awCRXsMg8vuBTSy3ZdmYuF6Qjb5o9lk1 cKiXMtn+jeYbmvmNvKPB1SHHVnrP6kU1VVGbUwEWM7P19MpGrGALGhqdwJCJCLvD5GSx 6P1A== X-Received: by 10.14.99.67 with SMTP id w43mr3707343eef.11.1402342897641; Mon, 09 Jun 2014 12:41:37 -0700 (PDT) Received: from ?IPv6:2a02:a03f:1405:ee00:ac40:891b:473b:1f38? ([2a02:a03f:1405:ee00:ac40:891b:473b:1f38]) by mx.google.com with ESMTPSA id 44sm47043092eer.35.2014.06.09.12.41.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Jun 2014 12:41:37 -0700 (PDT) Message-ID: <53960DB8.6000604@gmail.com> Date: Mon, 09 Jun 2014 21:40:40 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "J. Gomez" References: <1322530073.150717.1402179785354.JavaMail.zimbra@peachymango.org> <5393EC2B.6080501@gmail.com> <11E2FBD80B824A6C94C04B39E99CF14F@fgsr.local> <5396050B.6070003@gmail.com> <9153E29A317845F3964C0060DBB2C21C@fgsr.local> In-Reply-To: <9153E29A317845F3964C0060DBB2C21C@fgsr.local> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/-q-UTqfWq1I7yaOz7zedqd3uSVU Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Advice to MUA 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, 09 Jun 2014 19:41:41 -0000 On 6/9/2014 9:25 PM, J. Gomez wrote: > On Monday, June 09, 2014 9:03 PM [GMT+1=CET], Dave Crocker wrote: > >> And then, of course, then there's the whole matter of needing external >> references that objectively support the assertions you are making... > > Yeah, well, we are having a mailing list exchange, not presenting a doctoral thesis here. > > Do you have references that objectively support the contrary to those assertions, perhaps? You want me to prove the negative? What an exciting (if impossible) challenge. Besides being an inherently problematic requirement, the usual policy is that someone taking the affirmative position to do something is expected to justify it. We don't usually start with a default assumption that taking an action should be approved and it's everyone else's obligation to prove why the action should not be done. > Do you know of any references/literature which posits contrary to those assertions? Are those references/literature significant and/or peacefully undisputed? Do you think those assertions are, as of today, an undecided issue? Well, my masters in the topic certainly doesn't suffice, so take a quick scan of the last 10-15 years of SOUPS papers. And just to offer a quick example of how basic my point is about this topic, I did a google on "user interface design computer system efficacy" and the second result was: Efficacy of User Interface Design www.usernomics.com/user-interface-design.html which includes: "Optimized User Interface Design requires a systematic approach to the design process. But, to ensure optimum performance, Usability Testing is required." To repeat, UI/UX design is a specialty requiring extensive training in cognitive, memory and attention psychology, testing methodology and, oh yes, computer science. Users mostly don't notice the kinds of signals being proposed and when they do notice, they do it only erratically, and their interpretation of the signals is poor. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jun 9 13:00:11 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C591A02D6 for ; Mon, 9 Jun 2014 13:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.853 X-Spam-Level: X-Spam-Status: No, score=-4.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 zlYVxPtlYJiJ for ; Mon, 9 Jun 2014 13:00:07 -0700 (PDT) Received: from mx-tmp.wmich.edu (mx-tmp.wmich.edu [141.218.1.43]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31B5D1A0281 for ; Mon, 9 Jun 2014 13:00:07 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; charset=US-ASCII Received: from spaz.oit.wmich.edu (spaz.oit.wmich.edu [141.218.24.51]) by mta01.service.private (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 64bit)) with ESMTPSA id <0N6X0097J3K47N00@mta01.service.private> for dmarc@ietf.org; Mon, 09 Jun 2014 16:00:06 -0400 (EDT) X-WMU-Spam: Gauge=X, Probability=10% on Mon Jun 9 16:00:05 2014, Report=' WMU_MSA_SMTP+ 0, TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1300_1399 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, FROM_EDU_TLD 0, SPF_NEUTRAL 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_MAILTO 0, __URI_NS ' X-WMU-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2014.6.9.195118 - Mon Jun 9 16:00:05 2014 Date: Mon, 09 Jun 2014 16:00:04 -0400 (EDT) From: Derek Diget X-X-Sender: diget@spaz.oit.wmich.edu To: dmarc@ietf.org In-reply-to: <9153E29A317845F3964C0060DBB2C21C@fgsr.local> Message-id: References: <1322530073.150717.1402179785354.JavaMail.zimbra@peachymango.org> <5393EC2B.6080501@gmail.com> <11E2FBD80B824A6C94C04B39E99CF14F@fgsr.local> <5396050B.6070003@gmail.com> <9153E29A317845F3964C0060DBB2C21C@fgsr.local> Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/T9bau5ADYNipjojcedWqBKbYup4 Subject: Re: [dmarc-ietf] Advice to MUA 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, 09 Jun 2014 20:00:09 -0000 On Jun 9, 2014 at 21:25 +0200, J. Gomez wrote: =>On Monday, June 09, 2014 9:03 PM [GMT+1=CET], Dave Crocker wrote: => =>> And then, of course, then there's the whole matter of needing external =>> references that objectively support the assertions you are making... => =>Yeah, well, we are having a mailing list exchange, not presenting a =>doctoral thesis here. => =>Do you have references that objectively support the contrary to those =>assertions, perhaps? => =>Do you know of any references/literature which posits contrary to =>those assertions? Are those references/literature significant and/or =>peacefully undisputed? Do you think those assertions are, as of today, =>an undecided issue? Not directly related to email, but see "The Emperor's New Security Indicators" that was presented at the 2007 IEEE Symposium on Security and Privacy. My googling came up with the PDF at IEEE Xplore : If you can't get it there, there are many other sites that have the PDF. -- *********************************************************************** Derek Diget Office of Information Technology Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/ *********************************************************************** From nobody Mon Jun 9 13:02:12 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDFF1A02E3 for ; Mon, 9 Jun 2014 13:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 dsou9yWriO-5 for ; Mon, 9 Jun 2014 13:02:08 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FC611A02E2 for ; Mon, 9 Jun 2014 13:02:08 -0700 (PDT) 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; Mon, 9 Jun 2014 22:02:06 +0200 Message-ID: <1C4D2F51CE3D49418171A7E1DCCD17BF@fgsr.local> From: "J. Gomez" To: Dave Crocker References: <1322530073.150717.1402179785354.JavaMail.zimbra@peachymango.org> <5393EC2B.6080501@gmail.com> <11E2FBD80B824A6C94C04B39E99CF14F@fgsr.local> <5396050B.6070003@gmail.com> <9153E29A317845F3964C0060DBB2C21C@fgsr.local> <53960DB8.6000604@gmail.com> Date: Mon, 9 Jun 2014 22:02:16 +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: http://mailarchive.ietf.org/arch/msg/dmarc/w48_IDRdRBdl19x6ynf78gY2y4A Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Advice to MUA 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, 09 Jun 2014 20:02:10 -0000 On Monday, June 09, 2014 9:40 PM [GMT+1=3DCET], Dave Crocker wrote: > To repeat, UI/UX design is a specialty requiring extensive training in > cognitive, memory and attention psychology, testing methodology and, > oh yes, computer science. So I guess we will wait until Apples just does it, and then go and copy = it, whichever side it falls. Because, well, talking about it outside of a cathedral chorus full of = emminentiae is a no-no... Regards, J.Gomez From nobody Mon Jun 9 13:30:36 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F171A02D4 for ; Mon, 9 Jun 2014 13:30:34 -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 GGye1tlyqREI for ; Mon, 9 Jun 2014 13:30:33 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E2401A02E2 for ; Mon, 9 Jun 2014 13:30:33 -0700 (PDT) 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; Mon, 9 Jun 2014 22:30:31 +0200 Message-ID: <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> From: "J. Gomez" To: Matt Simerson References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> Date: Mon, 9 Jun 2014 22:30:42 +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: http://mailarchive.ietf.org/arch/msg/dmarc/qxTNBPC2Qe0zLSvmRbKrJJBBpl0 Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 09 Jun 2014 20:30:35 -0000 On Monday, June 09, 2014 8:01 AM [GMT+1=3DCET], Matt Simerson wrote: > On Jun 8, 2014, at 10:32 PM, Brandon Long wrote: >=20 > > The message is already corrupted, or there wouldn't be a problem to > > be solved.=20 >=20 > When the message arrives at the list, it's unlikely that it's already > corrupted. What has been described is corrupting the From header by > the same entity that is about to break the DKIM signature by altering > the the message. This should be called the "break it worse" method. So, when the MLM relaying the message adds a subject tag, that = alteration is a welcomed "decoration" - but when it changes the mailbox = in the Header-From to itself, it is an unwelcomed "corruption". =20 I can understand the welcomed vs unwelcomed thing, but I do not agree = with calling the alteration "decoration" in one place but "corruption" = in the other. =20 Loading the language in such a way is asking for a given conclusion even = before the debate has started. That's not fair (I'm not predicating that = from you, Matt, just talking in general terms). Regards, J.Gomez From nobody Mon Jun 9 13:51:25 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78EB01A034B for ; Mon, 9 Jun 2014 13:51:23 -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 DZx308e-VukV for ; Mon, 9 Jun 2014 13:51:20 -0700 (PDT) Received: from mail.theartfarm.com (mail.theartfarm.com [66.128.51.165]) by ietfa.amsl.com (Postfix) with SMTP id C71AB1A02C6 for ; Mon, 9 Jun 2014 13:51:19 -0700 (PDT) Received: (qmail 48461 invoked by uid 89); 9 Jun 2014 20:51:19 -0000 Received: from unknown (HELO mail.theartfarm.com) (127.0.0.30) by mail.theartfarm.com with SMTP; 9 Jun 2014 20:51:19 -0000 Received-SPF: Pass (mail.theartfarm.com: domain of tnpi.net designates 50.159.99.59 as permitted sender) receiver=mail.theartfarm.com; identity=mailfrom; client-ip=50.159.99.59; helo=[10.0.1.141]; envelope-from= Received: from [10.0.1.141] (c-50-159-99-59.hsd1.wa.comcast.net [50.159.99.59]) by mail.theartfarm.com (Haraka/2.5.0-toaster) with ESMTPSA id 7962867E-506F-47CE-A960-3FBCD1903DDF.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=AES128-SHA verify=FAIL); Mon, 09 Jun 2014 16:51:18 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Matt Simerson X-Priority: 3 In-Reply-To: <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> Date: Mon, 9 Jun 2014 13:51:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <21147788-473B-46CB-BAB6-81A1D224CA32@tnpi.net> References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> To: dmarc@ietf.org X-Mailer: Apple Mail (2.1878.2) X-Haraka-p0f: os="MacOS X 10.9 or newer (sometimes iPhone " link_type="Ethernet or modem" distance=11 total_conn=15 shared_ip=N X-Haraka-GeoIP: US, WA, Seattle, 2699km X-Haraka-GeoIP-Received: X-Haraka-ASN: 7922 50.128.0.0/9 X-Haraka-ASN-MONKEY: asn=7922 net=50.128.0.0/9 org=Comcast Cable Communications, Inc. date=1997-02-14 country=US X-Haraka-FCrDNS: c-50-159-99-59.hsd1.wa.comcast.net X-Spam-ASN: X-Spam-DCC: sonic.net: spamassassin.tnpi.net 1156; Body=1 Fuz1=1 Fuz2=1 X-Spam-SNF-Result: 0 (Standard White Rules) X-Spam-MessageSniffer-Scan-Result: 0 X-MessageSniffer-Rules: 0-0-0-5603-c X-MessageSniffer-Clean: Yes X-Spam-MessageSniffer-Rules: 0-0-0-5603-c X-MessageSniffer-Clean: Yes X-Spam-GBUdb-Analysis: 0, 10.0.1.141, Ugly c=0.353873 p=-1 Source Normal X-MessageSniffer-Scan-Result: 0 X-MessageSniffer-Rules: 0-0-0-5603-c X-MessageSniffer-Clean: Yes X-Haraka-Karma: connect: 4, history: 402, total_connects: 433, neighbors: -5510, pass:fcrdns.fcrdns, relaying, auth_user, fail:fcrdns.fail, neighbors, dnsbl.fail, helo.checks.fail, helo.checks.fail, skip:penalty DKIM-Signature: v=1; a=rsa-sha256; bh=+lJCq5H6b72NsgJ6Pvm6PHePzIln422SaAypAD0nm4Q=; c=relaxed/simple; d=tnpi.net; h=from:subject:date:message-id:to:mime-version; s=mar2013; b=gnyRqjAgaNeggCBWfhlI1Gp7BqWhzgmYfmi+GUS3MjpoMhMM22bRVBAb2l9B8jT9lQKjz17e5tyN8p8rYrOZgJkMOo8T9Xxp+6VzO+JSV24BC4nHogSVAYGiAYQqQCnDc2JHm35UroAhYmx9V45nyOzxRl7TZmMFt7RDdwywgI6EOyu2ET1byCm0PGgI4J5Q3uXH82CA+axSS8XQDz8/XicSlRl/6kn8JOIcCVFgN2UDJ20Lj6x8KE4cKz+SJhJozaKBZPQmoDTYUu1CQUwcs6GLGzaI+QpzWb00SwW8Bry2E/wj4adMsDk9SGwUxUbyvCVBrEfhNUzwpmitCh2LXg== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/vlzwTd5_sauqG6Zs0EGP54ET3g0 Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 09 Jun 2014 20:51:23 -0000 On Jun 9, 2014, at 1:30 PM, J. Gomez wrote: > On Monday, June 09, 2014 8:01 AM [GMT+1=3DCET], Matt Simerson wrote: >=20 >> On Jun 8, 2014, at 10:32 PM, Brandon Long wrote: >>=20 >>> The message is already corrupted, or there wouldn't be a problem to >>> be solved.=20 >>=20 >> When the message arrives at the list, it's unlikely that it's already >> corrupted. What has been described is corrupting the =46rom header by >> the same entity that is about to break the DKIM signature by altering >> the the message. This should be called the "break it worse" method. >=20 > So, when the MLM relaying the message adds a subject tag, that = alteration is a welcomed "decoration" - but when it changes the mailbox = in the Header-=46rom to itself, it is an unwelcomed "corruption". > I can understand the welcomed vs unwelcomed thing, but I do not agree = with calling the alteration "decoration" in one place but "corruption" = in the other. >=20 > Loading the language in such a way is asking for a given conclusion = even before the debate has started. That's not fair (I'm not predicating = that from you, Matt, just talking in general terms). You'll note that I didn't introduce either the terms decoration or = corruption. I described *both* message alterations as breakage. In the = context of DKIM, and consequently DMARC, I think that's a perfectly fair = description. Breaking DKIM has been a liberty that mailing lists have = thus far been able to get away with.=20 For a time, DMARC early adopters danced around it the DKIM breakage = problem by splitting their message streams into "transactional" vs = "personal." For some, that recently changed and now there are = consequences for mailers that break DKIM signatures. I think that's a = *very* fair assessment. Matt= From nobody Mon Jun 9 14:12:42 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51AB71A020E for ; Mon, 9 Jun 2014 14:12:41 -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 ehCUX1fOy3B8 for ; Mon, 9 Jun 2014 14:12:39 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.94]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A95571A01CF for ; Mon, 9 Jun 2014 14:12:39 -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.0.974.2; Mon, 9 Jun 2014 21:12:38 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.234]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.234]) with mapi id 15.00.0974.002; Mon, 9 Jun 2014 21:12:38 +0000 From: Terry Zink To: "J. Gomez" , Dave Crocker Thread-Topic: [dmarc-ietf] Advice to MUA Thread-Index: Qzkwqgflr7mpCPEQy0C/IUCamwIUJaykVvqAgAJ3c6mAAAiOgIAABiW+gAAEMwCAAAYLnIAAE6VQ Date: Mon, 9 Jun 2014 21:12:37 +0000 Message-ID: <608501251ed94f628e67aeb699c03de0@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> References: <1322530073.150717.1402179785354.JavaMail.zimbra@peachymango.org> <5393EC2B.6080501@gmail.com> <11E2FBD80B824A6C94C04B39E99CF14F@fgsr.local> <5396050B.6070003@gmail.com> <9153E29A317845F3964C0060DBB2C21C@fgsr.local> <53960DB8.6000604@gmail.com> <1C4D2F51CE3D49418171A7E1DCCD17BF@fgsr.local> In-Reply-To: <1C4D2F51CE3D49418171A7E1DCCD17BF@fgsr.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ee31::3] x-exchange-antispam-report-test: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02379661A3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(199002)(189002)(74662001)(93516002)(98676001)(74502001)(81342001)(33646001)(99396002)(81816001)(31966008)(69226001)(76786001)(76796001)(79102001)(81542001)(21056001)(95666003)(74706001)(77096001)(92566001)(80022001)(4396001)(94946001)(50986002)(93136001)(95416001)(101416001)(81686001)(74366001)(46102001)(85306002)(56776002)(56816006)(47976003)(65816002)(59766002)(64706001)(51856002)(47736002)(49866002)(63696004)(83322001)(20776003)(54316003)(54356002)(53806002)(47446003)(2656002)(77982001)(97186001)(87266001)(83072002)(85852003)(90146001)(97336001)(87936001)(76482001)(74876001)(93886002)(94316002)(24736002)(3826001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2SR01MB605; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/BhInx2WghcmzE1ZkBV1CXMX08xc Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Advice to MUA 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, 09 Jun 2014 21:12:41 -0000 >> To repeat, UI/UX design is a specialty requiring extensive training in >> cognitive, memory and attention psychology, testing methodology and, >> oh yes, computer science. > So I guess we will wait until Apples just does it, and then go and copy i= t, whichever side it falls. Your response is tongue-in-cheek but I think represents a harsh reality; on= ly large companies have the resources to test UX'es and the associated user= behavior. For example, Amazon tests everything on its webpage when it come= s to pixel placement, and I believe that Netflix does the same. Alternatively, some universities who have researchers or grad students or p= rofessors study this sort of thing may similarly come up with recommendatio= ns. -- Terry From nobody Mon Jun 9 14:30:20 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E581A01CF for ; Mon, 9 Jun 2014 14:30:19 -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_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 BmQYqhJmTquK for ; Mon, 9 Jun 2014 14:30:16 -0700 (PDT) Received: from eh.msi.es (eh.msi.es [213.27.239.123]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36E051A0348 for ; Mon, 9 Jun 2014 14:30:13 -0700 (PDT) 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; Mon, 9 Jun 2014 23:30:11 +0200 Message-ID: From: "J. Gomez" To: Terry Zink References: <1322530073.150717.1402179785354.JavaMail.zimbra@peachymango.org> <5393EC2B.6080501@gmail.com> <11E2FBD80B824A6C94C04B39E99CF14F@fgsr.local> <5396050B.6070003@gmail.com> <9153E29A317845F3964C0060DBB2C21C@fgsr.local> <53960DB8.6000604@gmail.com> <1C4D2F51CE3D49418171A7E1DCCD17BF@fgsr.local> <608501251ed94f628e67aeb699c03de0@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Date: Mon, 9 Jun 2014 23:30:21 +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: http://mailarchive.ietf.org/arch/msg/dmarc/DNo7qzm17Q4Yv1GdjltKzUdEdKs Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Advice to MUA 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, 09 Jun 2014 21:30:19 -0000 On Monday, June 09, 2014 11:12 PM [GMT+1=3DCET], Terry Zink wrote: > > > To repeat, UI/UX design is a specialty requiring extensive > > > training in cognitive, memory and attention psychology, testing > > > methodology and, oh yes, computer science. >=20 > > So I guess we will wait until Apples just does it, and then go and > > copy it, whichever side it falls.=20 >=20 > Your response is tongue-in-cheek but I think represents a harsh > reality; only large companies have the resources to test UX'es and > the associated user behavior. For example, Amazon tests everything on > its webpage when it comes to pixel placement, and I believe that > Netflix does the same. True, but at the same time UX is something that every user can talk = about, as per se every user has experience with it. =20 Every time I hear that UI is a black art to be refined only by ultra = specialists, I shiver in fear, because not only I have seen no = improvement in that area since the Windows 95 days (except perhaps the = Windows 2000 cosmetic improvements), but on the contrary what I have = seen and *experienced* is plain user disgust. However, they call it the = product of deep field tests helped by teams of psychologists and what = not, so that "evolution" must be great and I be just wrong about it. Regards, J.Gomez From nobody Mon Jun 9 14:44:38 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626C21A01CF for ; Mon, 9 Jun 2014 14:44:36 -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 ew2IxeZI3qq6 for ; Mon, 9 Jun 2014 14:44:33 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1080D1A0331 for ; Mon, 9 Jun 2014 14:44:29 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id x48so3713286wes.39 for ; Mon, 09 Jun 2014 14:44:28 -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=GGtuRlr20wzc9BemTR0Jmz1sJJsiUAWH1Zy/DnKCvYg=; b=g9UczrEYhyjNfWVaeGoNK+jyuv3sF0pAjJI+lglTbndl/sXYVxsaC1cB+gHkOp3QGC DkG1981GRDtORQ4cmiU6GhJG0D1InLgSxNcEjEMWb9hddQqSDCm3d6BJPmFrmOflH51p UVy3CA5mIrXu+za5/PTi2cLNZzFw+eiOQpKYmetsq5/54dNvBjQn3CeQmchq8LCrINhO yMWmzV27veM+F3PuUqOlDxIBO4SSRxNUhEKmSk87yD85QYeveuyeBFVN7m3JOQd3KGa/ PBGP7LOIZmO3xkwg5eAKGH1XCRkFj9WTxy+rbEyuFVof85i+IplIKYdqNG3U+cawkjRh QfnQ== MIME-Version: 1.0 X-Received: by 10.181.8.67 with SMTP id di3mr31971002wid.8.1402350268623; Mon, 09 Jun 2014 14:44:28 -0700 (PDT) Received: by 10.180.23.104 with HTTP; Mon, 9 Jun 2014 14:44:28 -0700 (PDT) In-Reply-To: References: <1322530073.150717.1402179785354.JavaMail.zimbra@peachymango.org> <5393EC2B.6080501@gmail.com> <11E2FBD80B824A6C94C04B39E99CF14F@fgsr.local> <5396050B.6070003@gmail.com> <9153E29A317845F3964C0060DBB2C21C@fgsr.local> <53960DB8.6000604@gmail.com> <1C4D2F51CE3D49418171A7E1DCCD17BF@fgsr.local> <608501251ed94f628e67aeb699c03de0@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Date: Mon, 9 Jun 2014 14:44:28 -0700 Message-ID: From: "Murray S. Kucherawy" To: "J. Gomez" Content-Type: multipart/alternative; boundary=001a1134d2449cb24704fb6e1d8b Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/yqc5BjqyX8kwxvmB3-4_kujeqZs Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Advice to MUA 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, 09 Jun 2014 21:44:36 -0000 --001a1134d2449cb24704fb6e1d8b Content-Type: text/plain; charset=UTF-8 On Mon, Jun 9, 2014 at 2:30 PM, J. Gomez wrote: > True, but at the same time UX is something that every user can talk about, > as per se every user has experience with it. > > Every time I hear that UI is a black art to be refined only by ultra > specialists, I shiver in fear, because not only I have seen no improvement > in that area since the Windows 95 days (except perhaps the Windows 2000 > cosmetic improvements), but on the contrary what I have seen and > *experienced* is plain user disgust. However, they call it the product of > deep field tests helped by teams of psychologists and what not, so that > "evolution" must be great and I be just wrong about it. > True, but who's to say our proposed improvements would make things any better than the ones that would (or would not) happen without our guidance? This group might come to consensus on what we think users would understand and [try to] push that into user space, but in the end that's merely what we imagine would work based on our own experiences or extrapolations, and might actually make things worse. I'm not saying we shouldn't talk about it or even that we shouldn't try, but I am saying we'd better be pretty darned sure about the end result, and I'm not really sure how to go about doing that. -MSK --001a1134d2449cb24704fb6e1d8b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 9, 2014 at 2:30 PM, J. Gomez <jgomez@seryri= ch.com> wrote:
True, but at the same time UX is something t= hat every user can talk about, as per se every user has experience with it.=

Every time I hear that UI is a black art to be refined only by ultra specia= lists, I shiver in fear, because not only I have seen no improvement in tha= t area since the Windows 95 days (except perhaps the Windows 2000 cosmetic = improvements), but on the contrary what I have seen and *experienced* is pl= ain user disgust. However, they call it the product of deep field tests hel= ped by teams of psychologists and what not, so that "evolution" m= ust be great and I be just wrong about it.

True, but who's to say our proposed im= provements would make things any better than the ones that would (or would = not) happen without our guidance?=C2=A0 This group might come to consensus = on what we think users would understand and [try to] push that into user sp= ace, but in the end that's merely what we imagine would work based on o= ur own experiences or extrapolations, and might actually make things worse.=

I'm not saying we shouldn't talk about it or even th= at we shouldn't try, but I am saying we'd better be pretty darned s= ure about the end result, and I'm not really sure how to go about doing= that.

-MSK
--001a1134d2449cb24704fb6e1d8b-- From nobody Mon Jun 9 16:38:47 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32A41A021B for ; Mon, 9 Jun 2014 16:38:44 -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_22=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 c7l9eRbBDuCp for ; Mon, 9 Jun 2014 16:38:42 -0700 (PDT) Received: from news.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3C77D1A0074 for ; Mon, 9 Jun 2014 16:38:41 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3752; t=1402357114; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=YlD+lNEk3Ix7GQP1FvxXpR5bXxo=; b=E5vMGJ21lwqlMIupRWDv 4VCQWPeNOOo5qKfLUe8WcvfX4Z7nx5saAFKYYtvoL5/8IXRPgs+gd5cpl1HbWDhl vg7Kp9fmAEWZov6ALDQmj5rwpIxdO4CAsH5x3CrSNhodvjWNERx0kuaf6HbilZ40 okwJwGxDBo8NHHl+Sf4zNnw= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 09 Jun 2014 19:38: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; Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1837237518.10081.4268; Mon, 09 Jun 2014 19:38:33 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3752; t=1402356951; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=CfZkxH+ 4gKu0giC8dSoMVV4T1BdQz6fOvo4Aw1ilNb8=; b=M3yWWLnabQD7toH2vbWVM4N taoIN8klTEURG1xU5E8nUCbzaIXSScOZ8yrTS1h6DzY3oySMh/XIvKs8V/Xdj5FQ 1uTnIVCQCUQPyNOVoXYtkv0bvfpUeA9nzRN96yHT285imYRzO1FYeUC6dcAhzIpz 0JodIUAH1E7wFvKAvFqs= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 09 Jun 2014 19:35: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 1853597312.9.1500; Mon, 09 Jun 2014 19:35:49 -0400 Message-ID: <53964578.7040800@isdg.net> Date: Mon, 09 Jun 2014 19:38: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: "J. Gomez" , Terry Zink References: <1322530073.150717.1402179785354.JavaMail.zimbra@peachymango.org> <5393EC2B.6080501@gmail.com> <11E2FBD80B824A6C94C04B39E99CF14F@fgsr.local> <5396050B.6070003@gmail.com> <9153E29A317845F3964C0060DBB2C21C@fgsr.local> <53960DB8.6000604@gmail.com> <1C4D2F51CE3D49418171A7E1DCCD17BF@fgsr.local> <608501251ed94f628e67aeb699c03de0@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/vyx4YlUnIDDeUFQQtWYQmbmucJg Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Advice to MUA 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, 09 Jun 2014 23:38:45 -0000 On 6/9/2014 5:30 PM, J. Gomez wrote: > On Monday, June 09, 2014 11:12 PM [GMT+1=CET], Terry Zink wrote: > >>>> To repeat, UI/UX design is a specialty requiring extensive >>>> training in cognitive, memory and attention psychology, testing >>>> methodology and, oh yes, computer science. >> >>> So I guess we will wait until Apples just does it, and then go and >>> copy it, whichever side it falls. >> >> Your response is tongue-in-cheek but I think represents a harsh >> reality; only large companies have the resources to test UX'es and >> the associated user behavior. For example, Amazon tests everything on >> its webpage when it comes to pixel placement, and I believe that >> Netflix does the same. > > True, but at the same time UX is something that every user can talk about, as per se every user has experience with it. > > Every time I hear that UI is a black art to be refined only by ultra specialists, I shiver in fear, because not only I have seen no improvement in that area since the Windows 95 days (except perhaps the Windows 2000 cosmetic improvements), but on the contrary what I have seen and *experienced* is plain user disgust. However, they call it the product of deep field tests helped by teams of psychologists and what not, so that "evolution" must be great and I be just wrong about it. > Good points. Its a very complex subject. How many different mail portals do you use/need as a user? How many different mail portals does the service host offer, they need to design for? Vendors that have strategic control of the many integrated mail parts have a better means of doing the things that you would to see. Make a change here, comes with a change there. But sometimes these things are split by product department, team, etc, so change doesn't always come easy or fast. The more you can single source your mail infrastructure, the better it is and this has been happening more with long time established systems. Centralization and a renewed direction towards online, with full duplex interactive I/O is on the move, and it offer more intelligent information to the end users. I have at least 4-5 different MUA designs and thats hard to get right with new stuff. Its also hard to change too. For example, Microsoft recently (a few years now) abandoned their 20+ years of Newsgroups NNTP servers and move their support operation to online forums. They were already exploring with various UI look and feels for a few years so now you have different competing support operations. When the MS NNTP servers were turned off, to help support legacy NNTP news reader users, like me, I wrote a NNTP proxy (Wildcat! Live Exchange, http://opensite.winserver.com/wclex) with authenticated Live ID access to the backend mail host using their SOAP protocol API wire. I did it knowing it wasn't going to be a big thing as more and more people went directly to the online forums. I can also control what the news reader will display in the fields and also body by transforming the extra data bits from the backend user and mail records; how many brownie points the reader has, MVP, etc. You are still using OE, thats old dude!! :) But sure, it works. I have it on various machines. How do we change it to show the info would like? Will you adapt to a new reader? In the mean time, we have only the IETF protocols as a means to communicate with each other, ideally, in a cooperative competitive manner using global common methods, format and standards. It is possible to put data bits in the 5322 headers. But its only good if the MUA can use it. It is still a good idea to extract general MUA ideas and offer them as guidelines for the general MUA. -- HLS From nobody Mon Jun 9 19:38:59 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E937E1A0350 for ; Mon, 9 Jun 2014 19:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 r7uTf9Ql6yhx for ; Mon, 9 Jun 2014 19:38:55 -0700 (PDT) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 078641A0358 for ; Mon, 9 Jun 2014 19:38:54 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id db12so4452142veb.21 for ; Mon, 09 Jun 2014 19:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=PGgwxkOq6BZbI+B1dC+bioeeYA6K69Ar6LXCBgscfbQ=; b=KlghwSOxksX65MKvg8xJECD3VQCeWV07x7Oei1dIMkrKtr87VapqRlviNY/P5M8Mjd FDJ/NMbqCG8K/JqzPVVyj52F0bNGS6tomJF0aT7TEpf/yO5D3FiFqILPYq9fFQ5bAfje zdC7rlXUfmOeSj9lo1csUWWES42ElTI/q6lVafBE4Y7BdgD+ridDXivy+LHF0zQ35FzY 60x9eyimtHF938QOF6f+fg6EwvmyJL574oUIJOFgaR2P+I3XF09fiAOHQUkJIc+71G/r IwV1wXuNkP0iy5JbC42i1Mqfh6btikRIq5MmpA+aDZSl2n5LEhwIxrOE6CLkuJToviys 7jWg== MIME-Version: 1.0 X-Received: by 10.220.159.4 with SMTP id h4mr29378469vcx.1.1402367934127; Mon, 09 Jun 2014 19:38:54 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.33.199 with HTTP; Mon, 9 Jun 2014 19:38:54 -0700 (PDT) In-Reply-To: <597dc384-7907-4a14-acaa-cd527650758b@email.android.com> References: <1402212310.40987.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1322124542.1687.1402245193573.JavaMail.zimbra@peachymango.org> <597dc384-7907-4a14-acaa-cd527650758b@email.android.com> Date: Mon, 9 Jun 2014 22:38:54 -0400 X-Google-Sender-Auth: HDHQxvBS-VOjg__L3iv3U2iB2G8 Message-ID: From: Barry Leiba To: Scott Kitterman Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/PAGkEFFiMhOVvnpCd4JM7JTvY-0 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] advice to MTAs 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, 10 Jun 2014 02:38:56 -0000 >>Putting as much value on RFC5322 From as DMARC does follows >>conventional wisdom, but I believe that wisdom is flawed. >> >>Of course, that speaks to the advice you want to give: tell UIs that >>they should show the From addr-spec to users always. But be clear >>about what you're asking for: you're not saying they should do it >>because it's objectively "right"; you're saying they should do it >>because it helps support the decision that DMARC has made. > > If any authentication technology is going to work, DMARC or whatever, > it will have to be tied to some kind of identifier. 5322.From is as good > as any and better than most. And yet SPF uses a different one (5321.Mail.From), and there've been suggestions to use Sender, rather than From, if Sender is present, or to check both. There's no one "right" answer, and all have failings. If a spec is going to suggest UI changes to match the choices that spec has made, it needs to be clear about where those suggestions come from. And the people making the recommendations need to understand that their recommendations might be wildly in conflict with what UI experts know to work best for users. Barry From nobody Mon Jun 9 20:17:20 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342381A038E for ; Mon, 9 Jun 2014 20:17:18 -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 ji9h9qdjCjNW for ; Mon, 9 Jun 2014 20:17:16 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 990021A038B for ; Mon, 9 Jun 2014 20:17:16 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id A48CF956117; Mon, 9 Jun 2014 23:17:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1402370235; bh=ywjWcopZMSvy/c1SI3rr9WaEFrFbjJQZJ10n+d2Ggvg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=K+K8fpJpSkPIfogF/VgltjoKEcY6lwEVX7n7XdQi3pWZ5YcrlGf1aif9eFJRnJdQ6 hRfgT2E6SRFS6C77iQcHKVqe19SM7MLr3boYbUnVfGENDY0z7krkfHlZ0GuhV6yfpQ lESbaAnNWvV3zQrJ7GX5NA15OtEmwDZAoYDuDJX0= Received: from scott-latitude-e6320.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 7149DD04145; Mon, 9 Jun 2014 23:17:15 -0400 (EDT) From: Scott Kitterman To: dmarc@ietf.org Date: Mon, 09 Jun 2014 23:17:12 -0400 Message-ID: <4588977.sc8XK00kAI@scott-latitude-e6320> User-Agent: KMail/4.13.1 (Linux/3.13.0-29-generic; KDE/4.13.1; x86_64; ; ) In-Reply-To: References: <1402212310.40987.YahooMailNeo@web164605.mail.gq1.yahoo.com> <597dc384-7907-4a14-acaa-cd527650758b@email.android.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/78PGUYcyyubkerYgfrBQi17zaeo Subject: Re: [dmarc-ietf] advice to MTAs 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, 10 Jun 2014 03:17:18 -0000 On Monday, June 09, 2014 22:38:54 Barry Leiba wrote: > >>Putting as much value on RFC5322 From as DMARC does follows > >>conventional wisdom, but I believe that wisdom is flawed. > >> > >>Of course, that speaks to the advice you want to give: tell UIs that > >>they should show the From addr-spec to users always. But be clear > >>about what you're asking for: you're not saying they should do it > >>because it's objectively "right"; you're saying they should do it > >>because it helps support the decision that DMARC has made. > >> > > If any authentication technology is going to work, DMARC or whatever, > > it will have to be tied to some kind of identifier. 5322.From is as good > > as any and better than most. > > And yet SPF uses a different one (5321.Mail.From), and there've been > suggestions to use Sender, rather than From, if Sender is present, or > to check both. There's no one "right" answer, and all have failings. > > If a spec is going to suggest UI changes to match the choices that > spec has made, it needs to be clear about where those suggestions come > from. And the people making the recommendations need to understand > that their recommendations might be wildly in conflict with what UI > experts know to work best for users. When developed, SPF had a different design goal, bounce reduction. Any anti- phising/anti-spam benefit was really a side effect. No U/I exposure was needed for it to be successful. You've got to hang your hat on one identity. The wild market success of Sender ID is possibly instructive of the implications when you don't. As has been discussed more than one time, if you allow Sender and From, then arbitrary Sender's can send mail that will pass with an unverified 5322.From (either the address or maybe just the pretty name) being all that's displayed to the end user. Perhaps I'm oversimplifying, but it has seemed self-evident that you need a single identifier that is displayed to the end user and 5322.From is the only identifier that even comes close to being the right one. Scott K From nobody Mon Jun 9 20:33:50 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D50E1A0393 for ; Mon, 9 Jun 2014 20:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.209 X-Spam-Level: * X-Spam-Status: No, score=1.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_22=0.6] 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 3tR5iugkDBDd for ; Mon, 9 Jun 2014 20:33:46 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id EF8701A0392 for ; Mon, 9 Jun 2014 20:33:45 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 9FFE63FA0B18; Tue, 10 Jun 2014 12:33:44 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 924BA1A32C5; Tue, 10 Jun 2014 12:33:44 +0900 (JST) From: "Stephen J. Turnbull" To: Terry Zink In-Reply-To: <608501251ed94f628e67aeb699c03de0@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> References: <1322530073.150717.1402179785354.JavaMail.zimbra@peachymango.org> <5393EC2B.6080501@gmail.com> <11E2FBD80B824A6C94C04B39E99CF14F@fgsr.local> <5396050B.6070003@gmail.com> <9153E29A317845F3964C0060DBB2C21C@fgsr.local> <53960DB8.6000604@gmail.com> <1C4D2F51CE3D49418171A7E1DCCD17BF@fgsr.local> <608501251ed94f628e67aeb699c03de0@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 10 Jun 2014 12:33:43 +0900 Message-ID: <87bnu1cuaw.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/lVHSYY68x59-0l3tpwoeMVsZqfk Cc: Dave Crocker , "dmarc@ietf.org" , "J. Gomez" Subject: Re: [dmarc-ietf] Advice to MUA 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, 10 Jun 2014 03:33:47 -0000 Terry Zink writes: > Your response is tongue-in-cheek but I think represents a harsh > reality; only large companies have the resources to test UX'es and > the associated user behavior. Open source projects can simply do it, and let the real users of their software test directly. They often do so graciously, too. It still has to be tested, though, and until there is data, I have to agree that at best we're talking about "Best Unimplemented Practices", and that doesn't belong in a standards-track RFC (yes, I know, but this *should* be a standards-track RFC given its content). From nobody Mon Jun 9 20:38:13 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98EEB1A038B for ; Mon, 9 Jun 2014 20:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 gCfQxbQ4bOKE for ; Mon, 9 Jun 2014 20:38:11 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id EBB7D1A036E for ; Mon, 9 Jun 2014 20:38:10 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 5CD523FA0158; Tue, 10 Jun 2014 12:38:10 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 4F4A31A32C5; Tue, 10 Jun 2014 12:38:10 +0900 (JST) From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: <1322530073.150717.1402179785354.JavaMail.zimbra@peachymango.org> <5393EC2B.6080501@gmail.com> <11E2FBD80B824A6C94C04B39E99CF14F@fgsr.local> <5396050B.6070003@gmail.com> <9153E29A317845F3964C0060DBB2C21C@fgsr.local> <53960DB8.6000604@gmail.com> <1C4D2F51CE3D49418171A7E1DCCD17BF@fgsr.local> <608501251ed94f628e67aeb699c03de0@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 10 Jun 2014 12:38:10 +0900 Message-ID: <87a99lcu3h.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/GAPpnCboKrXfnHAz3abpDS4-DZA Cc: "dmarc@ietf.org" , "J. Gomez" Subject: Re: [dmarc-ietf] Advice to MUA 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, 10 Jun 2014 03:38:11 -0000 Murray S. Kucherawy writes: > True, but who's to say our proposed improvements would make things any > better than the ones that would (or would not) happen without our > guidance? I don't think we should propose improvements, at least not expecting them to be taken at all seriously, and possibly not at all unless asked for examples by the MUA developers. IMO, what we should do is lay out the security model that we're trying to implement, and explain why we need the users' help to complete it. Then ask the MUA developers to help the users help us keep the users (more) secure. From nobody Mon Jun 9 20:59:06 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAFD1A03A2 for ; Mon, 9 Jun 2014 20:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 OFOSay9bx1Sq for ; Mon, 9 Jun 2014 20:59:03 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD361A03A0 for ; Mon, 9 Jun 2014 20:59:03 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id B10FF3FA0B18; Tue, 10 Jun 2014 12:59:02 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id A33CA1A32C5; Tue, 10 Jun 2014 12:59:02 +0900 (JST) From: "Stephen J. Turnbull" To: "J. Gomez" In-Reply-To: <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 10 Jun 2014 12:59:02 +0900 Message-ID: <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/WnTZCnebEviBfDNk2wQWrqknQsI Cc: dmarc@ietf.org, Matt Simerson Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 03:59:05 -0000 J. Gomez writes: > I can understand the welcomed vs unwelcomed thing, but I do not > agree with calling the alteration "decoration" in one place but > "corruption" in the other. > > Loading the language in such a way is asking for a given conclusion > even before the debate has started. That's not fair (I'm not > predicating that from you, Matt, just talking in general terms). What Yahoo! did wasn't fair, either. I'm just responding in kind, partly because some people define "legitimate" as "conforming to standard" so "legitimate alteration" vs. "illegitimate alteration" doesn't convey the same meaning. Anyway, I intend to continue using "corruption" vs. "decoration"[1] because I believe that they convey exactly the nuances I want. Not merely "unwelcome" vs. "welcome", but a corrupt From: breaks both the user's model of email and RFC 5322 semantics, while a decorated subject or footer breaks neither. (Decoration can break DKIM and PGP, however. The practice of decorating list posts long precedes signature technology, though, so I consider that to be a defect in the signature protocols, or at least their common implementations.[2] IMHO YMMV, there.) Footnotes: [1] I don't claim to be the originator of either terminology, but I'm definitely using them consciously. [2] PGP can be worked around by placing the signed body in a separate MIME part from the header and/or footer parts, and DKIM could at least be adapted to decorated subjects using z= and footers using l=, although this would require MUA support to be at all realistic (and if John Levine's most pessimistic assessment of typical users' ability to interpret MUA signals is correct, these workarounds are too dangerous to be used). From nobody Mon Jun 9 21:36:14 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33EB51A03BB for ; Mon, 9 Jun 2014 21:36: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 5_qz0msk2VSr for ; Mon, 9 Jun 2014 21:36:10 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2A951A03B1 for ; Mon, 9 Jun 2014 21:36:09 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id n3so2697651wiv.15 for ; Mon, 09 Jun 2014 21:36: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=MgC9DDXwj/SYg/hiwUfbKKnOyADefwu6jHzVBUJ4Wcw=; b=IrkrBZJxFfTGfp0BwqP0skm8QURF0xaCR0cRlAWJMfzWoVv9cpS1M9RMaio/jQjULR CM8C5/wPK9pKQug0K5VnSnfeQO8d/7+mAAY+5QiFpuVbCMIcTHuZPJhHxCen2/Djt4Cy c4R1cFBTw3t4XZnxSZaqtR2xGHQcUSFPHFYkSIF2g1vTeBAMl0fQDm4AmHHtQDXRFrMp cyoI5/6ayDqjgWElw+1lMm/DpTIKYMODgsYd43WrLrjrLYgyZGszyJCVusyHHRnUf6td +ma57hc3gomtssryhyR9+mQU9fqiUWUPMjX/Isp+7vrY0m1P2rvuMAqFi8ZZbDDkbc2e 3ynw== MIME-Version: 1.0 X-Received: by 10.180.75.212 with SMTP id e20mr8581135wiw.5.1402374968260; Mon, 09 Jun 2014 21:36:08 -0700 (PDT) Received: by 10.180.23.104 with HTTP; Mon, 9 Jun 2014 21:36:08 -0700 (PDT) In-Reply-To: <87bnu1cuaw.fsf@uwakimon.sk.tsukuba.ac.jp> References: <1322530073.150717.1402179785354.JavaMail.zimbra@peachymango.org> <5393EC2B.6080501@gmail.com> <11E2FBD80B824A6C94C04B39E99CF14F@fgsr.local> <5396050B.6070003@gmail.com> <9153E29A317845F3964C0060DBB2C21C@fgsr.local> <53960DB8.6000604@gmail.com> <1C4D2F51CE3D49418171A7E1DCCD17BF@fgsr.local> <608501251ed94f628e67aeb699c03de0@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <87bnu1cuaw.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Mon, 9 Jun 2014 21:36:08 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=f46d043890a5d33e4904fb73dd3e Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/73x7knf-rcU7nWx7g38kKpNszhc Cc: Dave Crocker , "dmarc@ietf.org" , Terry Zink , "J. Gomez" Subject: Re: [dmarc-ietf] Advice to MUA 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, 10 Jun 2014 04:36:12 -0000 --f46d043890a5d33e4904fb73dd3e Content-Type: text/plain; charset=UTF-8 On Mon, Jun 9, 2014 at 8:33 PM, Stephen J. Turnbull wrote: > Open source projects can simply do it, and let the real users of their > software test directly. They often do so graciously, too. It still > has to be tested, though, and until there is data, I have to agree > that at best we're talking about "Best Unimplemented Practices", and > that doesn't belong in a standards-track RFC (yes, I know, but this > *should* be a standards-track RFC given its content). > Even with those caveats, I see open source implementations as a huge resource to vetting good solutions to these problems. There were extremely useful in the development of SPF, DKIM, and DMARC, for example, and you've done so with Mailman as well. I'd be happy make some of these recent proposals available as experiments in my open source packages if there end up being one or two front runners. -MSK --f46d043890a5d33e4904fb73dd3e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 9, 2014 at 8:33 PM, Stephen J. Turnbull <ste= phen@xemacs.org> wrote:
Open source projects can simply do it, and l= et the real users of their
software test directly. =C2=A0They often do so graciously, too. =C2=A0It st= ill
has to be tested, though, and until there is data, I have to agree
that at best we're talking about "Best Unimplemented Practices&quo= t;, and
that doesn't belong in a standards-track RFC (yes, I know, but this
*should* be a standards-track RFC given its content).
=
Even with those caveats, I see open source implementations as a h= uge resource to vetting good solutions to these problems.=C2=A0 There were = extremely useful in the development of SPF, DKIM, and DMARC, for example, a= nd you've done so with Mailman as well.=C2=A0 I'd be happy make som= e of these recent proposals available as experiments in my open source pack= ages if there end up being one or two front runners.

-MSK
--f46d043890a5d33e4904fb73dd3e-- From nobody Mon Jun 9 21:50:37 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFDB1A03C9 for ; Mon, 9 Jun 2014 21:50:34 -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 IOpB46ZdseEs for ; Mon, 9 Jun 2014 21:50:31 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09FD91A03C2 for ; Mon, 9 Jun 2014 21:50:30 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id q59so1519422wes.40 for ; Mon, 09 Jun 2014 21:50:29 -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=d+VVn/FVA3FpGXUqdVd2vluN1GB7/WGD5JyePX6DmZM=; b=kS9dJiAoN+Suqvw6zAxSf9vS3jDtcjh42i37FHJzRHBdniEmAVwzAQpWVXRPG+FW9W JJ1YiDzIy5mT1GyNAyElL2GzenbKc41rZoHGKgScO9NaDcRdymvFK3YFt+Dy0L5mpCXB YSNhOq+cO8v9WOeeYcYRdgKXNuztg5p5PSAfWb+H/kpp8ZJvErPXDiGcoRz5l3xJvcYW VTFo4OOSr57LtGhmAsIRrFu/HHXQ+g857Osa7YfN7Rfp0j+PopAeuKSpPKSmj2keDsEv STCUK6m1i1gouDdaIxJzacAPxUWo/kPRtEm4yD9D4eAEJaHCIjdklpCQFxe1YS7CdNeA Vuqg== MIME-Version: 1.0 X-Received: by 10.180.212.77 with SMTP id ni13mr36464880wic.5.1402375829408; Mon, 09 Jun 2014 21:50:29 -0700 (PDT) Received: by 10.180.23.104 with HTTP; Mon, 9 Jun 2014 21:50:29 -0700 (PDT) In-Reply-To: <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Mon, 9 Jun 2014 21:50:29 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=001a11c23e5a27500e04fb74111d Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/cBFVvpvT0fQBS8hHW_cBJ0MbR7Q Cc: Matt Simerson , "dmarc@ietf.org" , "J. Gomez" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 04:50:34 -0000 --001a11c23e5a27500e04fb74111d Content-Type: text/plain; charset=UTF-8 On Mon, Jun 9, 2014 at 8:59 PM, Stephen J. Turnbull wrote: > [2] PGP can be worked around by placing the signed body in a separate > MIME part from the header and/or footer parts, and DKIM could at least > be adapted to decorated subjects using z= and footers using l=, > although this would require MUA support to be at all realistic (and if > John Levine's most pessimistic assessment of typical users' ability to > interpret MUA signals is correct, these workarounds are too dangerous > to be used). > The use of z= to get a "secondary" validation of an originator's signature makes me uneasy. A failed signature is supposed to fail. If one wishes to allow Subject: field alterations, then don't sign it. (I would rather abolish the practice of Subject tagging altogether and use the List-* fields to identify and sort list posts, but I am fully aware it's me vs. deployed inertia there.) Back in the DKIM WG days, that was also the consensus position as I recall. We also didn't expect MUAs to show which header fields or what part of the body were covered by a signature; the output of DKIM signature validation is just pass/fail and a domain name. Moreover, give a message with multiple signatures that passed yet covered different stuff, what could an MUA do that wouldn't be utterly confusing to users? I think back then someone suggested a modified header canonicalization method that was the same as "relaxed" except that a single limited-size token surrounded by square brackets and followed by a couple of whitespaces at most would be omitted from the hash, which would mean Subject tagging doesn't invalidate anything. It was rejected, but I can't remember why off the top of my head, maybe something to do with the fact that the unmodified Subject field could also start the same way, so it's ambiguous. Either way, to do it now would mean touching every deployed DKIM signer/validator out there. Finally, in addition to DKIM-Delegate, I posted another draft that captures a MIME-sensitive body canonicalization proposal that was suggested some time ago by Ned Freed. It may or may not be interesting for this effort. It's here: https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/ -MSK --001a11c23e5a27500e04fb74111d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 9, 2014 at 8:59 PM, Stephen J. Turnbull <ste= phen@xemacs.org> wrote:
[2] =C2=A0PGP can be work= ed around by placing the signed body in a separate
MIME part from the header and/or footer parts, and DKIM could at least
be adapted to decorated subjects using z=3D and footers using l=3D,
although this would require MUA support to be at all realistic (and if
John Levine's most pessimistic assessment of typical users' ability= to
interpret MUA signals is correct, these workarounds are too dangerous
to be used).

The use of z=3D to get a &= quot;secondary" validation of an originator's signature makes me u= neasy.=C2=A0 A failed signature is supposed to fail.=C2=A0 If one wishes to= allow Subject: field alterations, then don't sign it.=C2=A0 (I would r= ather abolish the practice of Subject tagging altogether and use the List-*= fields to identify and sort list posts, but I am fully aware it's me v= s. deployed inertia there.)

Back in the DKIM WG days, that was also the consensus p= osition as I recall.=C2=A0 We also didn't expect MUAs to show which header fields o= r what part of the body were covered by a signature; the output of DKIM=20 signature validation is just pass/fail and a domain name.=C2=A0 Moreover, g= ive a message with multiple signatures that passed yet covered=20 different stuff, what could an MUA do that wouldn't be utterly confusin= g to users?

I think back then someone suggested a modified hea= der canonicalization method that was the same as "relaxed" except= that a single limited-size token surrounded by square brackets and followe= d by a couple of whitespaces at most would be omitted from the hash, which = would mean Subject tagging doesn't invalidate anything.=C2=A0 It was re= jected, but I can't remember why off the top of my head, maybe somethin= g to do with the fact that the unmodified Subject field could also start th= e same way, so it's ambiguous.=C2=A0 Either way, to do it now would mea= n touching every deployed DKIM signer/validator out there.

Finally, in addition to DKIM-Delegate, I posted another draf= t that captures a MIME-sensitive body canonicalization proposal that was su= ggested some time ago by Ned Freed.=C2=A0 It may or may not be interesting = for this effort.=C2=A0 It's here:

https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/

-MSK
--001a11c23e5a27500e04fb74111d-- From nobody Mon Jun 9 23:17:02 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E721A03DB for ; Mon, 9 Jun 2014 23:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 pUrF6hNYXB7P for ; Mon, 9 Jun 2014 23:16:43 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 7E57D1A03DC for ; Mon, 9 Jun 2014 23:16:43 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 62AF63FA0B18; Tue, 10 Jun 2014 15:16:42 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 542B81A32C5; Tue, 10 Jun 2014 15:16:42 +0900 (JST) From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 10 Jun 2014 15:16:42 +0900 Message-ID: <87ppihgugl.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/8bo8hlsS0v8RtOvImJphY5PfvrI Cc: "dmarc@ietf.org" , Matt Simerson , "J. Gomez" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 06:16:45 -0000 Murray S. Kucherawy writes: > On Mon, Jun 9, 2014 at 8:59 PM, Stephen J. Turnbull > wrote: > > > [2] PGP can be worked around by placing the signed body in a separate > > MIME part from the header and/or footer parts, and DKIM could at least > > be adapted to decorated subjects using z= and footers using l=, > > although this would require MUA support to be at all realistic (and if > > John Levine's most pessimistic assessment of typical users' ability to > > interpret MUA signals is correct, these workarounds are too dangerous > > to be used). > > > > The use of z= to get a "secondary" validation of an originator's signature > makes me uneasy. A failed signature is supposed to fail. I'm not proposing additional validation. As I've said before, I have no quarrel with the DMARC protocol or its component protocols (at least I've not found a reason to dislike it yet), although I strongly dislike Yahoo!'s policy use of "p=reject". I'm suggesting the information could be used in the MUA UI. A failed signature *would* fail. Consider the following scenario: (1) User posts, MTA DKIM-signs using DKIM-delegate protocol (main signature signs Subject and body, delegate signature does not). (2) Mailing list decorates Subject, MTA DKIM-signs all the usual fields and body, and distributes. (3) Recipient MTA notes failure of main originator signature but accepts according to local policy about DKIM-delegate and valid ML signature, ignoring z=. Isn't that OK? Now (4) Recipient MUA has a choice of (a) Displaying decorated Subject verbatim. (b) Displaying z= Subject verbatim. (c) Matching decorated and z= subjects, and discarding mismatched portions. (d) As (c), but demphasizing mismatched decorations (eg, grey-on-grey). (e) Something else. I'm suggesting something along the lines of (b), (c), or (d). If the MUA does (a), it just falls into the abuser's trap, of course. But that's exactly what would happen now if somebody found a way to suborn dkim-delegate. > Back in the DKIM WG days, that was also the consensus position as I > recall. We also didn't expect MUAs to show which header fields or > what part of the body were covered by a signature; Agreed, we cannot expect help from current MUA versions. > the output of DKIM signature validation is just pass/fail and a > domain name. Moreover, give a message with multiple signatures > that passed yet covered different stuff, what could an MUA do that > wouldn't be utterly confusing to users? Dunno. I like (4)(d), but I wouldn't be surprised if everybody else hates it. But the situation has changed. What could be more confusing than mail that falls into a black hole because of "p=reject"? People are losing money over this, you know. Suddenly better MUA handling of security information may be a competitive advantage or something to puff your chest over. > I think back then someone suggested a modified header canonicalization > method that was the same as "relaxed" except that a single limited-size > token surrounded by square brackets and followed by a couple of whitespaces > at most would be omitted from the hash, which would mean Subject tagging > doesn't invalidate anything. Yuck. It would work, I guess, but I've seen mailing lists that remove existing prefixes (Re:, Fwd:) and I can imagine one that removes "was:" clauses. And that doesn't help with the footer, anyway. > Finally, in addition to DKIM-Delegate, I posted another draft that > captures a MIME-sensitive body canonicalization proposal that was > suggested some time ago by Ned Freed. It may or may not be > interesting for this effort. It's here: > > https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/ Day job has caught up with me, I'll have to read that later. I'm making a bet with myself on how far it is from current Mailman behavior. :-) Thanks for the URL! From nobody Mon Jun 9 23:40:43 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 579F51A03DC for ; Mon, 9 Jun 2014 23:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 qcyHv4RjaSOm for ; Mon, 9 Jun 2014 23:40:38 -0700 (PDT) Received: from nm32.bullet.mail.ne1.yahoo.com (nm32.bullet.mail.ne1.yahoo.com [98.138.229.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97CA91A0402 for ; Mon, 9 Jun 2014 23:40:38 -0700 (PDT) Received: from [127.0.0.1] by nm32.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2014 06:40:37 -0000 Received: from [98.138.100.112] by nm32.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2014 06:37:37 -0000 Received: from [98.137.12.190] by tm103.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2014 06:37:20 -0000 Received: from [98.137.12.253] by tm11.bullet.mail.gq1.yahoo.com with NNFMP; 10 Jun 2014 06:37:20 -0000 Received: from [127.0.0.1] by omp1061.mail.gq1.yahoo.com with NNFMP; 10 Jun 2014 06:37:20 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 764619.89260.bm@omp1061.mail.gq1.yahoo.com Received: (qmail 35708 invoked by uid 60001); 10 Jun 2014 06:37:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402382240; bh=rMJ5Lek9L6UceetxkECI6RpNMo+IlVLeCopU5AEQC2s=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=HsB34KjI4HsZQErT5fDl9YPxeyBoLHBZPy2lRktArNNB9QeI+qQU7WP+WnTQv9D/LtL7vsKkbj1Cyzc8TzmWGP/VGV77rMpznT0BbXfd7zE+xx6aVaXc3YPfTZn3bSbsJJxu/dT9xk0yMQk1deTghxnhAbGFimXXXZ0UdJDVmx0= X-YMail-OSG: WQkZB80VM1ncN.bUvXz4tlNUScbXRpKiJnt6zR.RsSJSUow KehLj5wPD2YOqrkgKfi8DmwrbLPXrQcoc_J76yax8FpUmHxX8CNAu0qL0Trx 2W.3P13a96EEWy1s6VJWJzNhLtUwC2sSCP.mhN1uoBT5W.mdx3DV.WvD_eOH IdSkfoa.uZP5Czpx1YhW7751TSy9XnGrZ.yrDdfbWUS1DJwZ6.z1m7Ci6imx 2Cuxm95VdUDWRM8AfpbY2z6W0pFya_O_Gk65vruppkJNdhhQ4o6pWIGt.nU. GwqCyIn8tsgVJ2BT4P_0YojOKKvEALi6CjZLHiL5fINRTUtgCZ7U3L9eOazv ULtE9pw0aWnpLVsV4UW5JJT2XlAolKra33I72_zLmKWCYo1uycm7r0Ag77.8 I6SMCpnLd3jfVvP9F.SWNG9L5KocuhzeF6PXOGOo1OqpX5POyBzXG0Mz_cEU 2OPAGODwXHKf.FY6rsrLTUfNH9MMR24zH1T24ncOeiF3kcgfPA7VMtIV7P8X Xducd6X2IOM3Smmk3FyVI2KRR7CahViFTqILgMIkU2kPtbo_Uk8SFekUwsoX lWf6HnnGAxg4l54vww8UPZU28JnKA7L8PUSZhc2hA.0W6UX6QDpYJxb63uTm FsNI3.Wz1zkeUy1ujYdmwN6avx_CK5YAAIMVPKq4Tl4hfa8myWQa0C9pYCFg YhGoXN7XH77n7MNU6MVCjoMY0DTCvhA-- Received: from [79.175.112.222] by web164601.mail.gq1.yahoo.com via HTTP; Mon, 09 Jun 2014 23:37:20 PDT X-Rocket-MIMEInfo: 002.001, T24gVHVlc2RheSwgSnVuZSAxMCwgMjAxNCA2OjUwIEFNLCBNdXJyYXkgUy4gS3VjaGVyYXd5IDxzdXBlcnVzZXJAZ21haWwuY29tPiB3cm90ZToKCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWt1Y2hlcmF3eS1ka2ltLWxpc3QtY2Fub24vCgp0aGUgbWFzdGVyLXBpZWNlIG9mIERLSU0gbWVzc2luZXNzLiB1bmZvcnR1bmF0ZWx5LAppdCBkb2Vzbid0IHNvbHZlIGN1cnJlbnQgTUwgcHJvYmxlbSwgYnV0IGludHJvZHVjZXMKbmV3IE1MIHJlcXVpcmVtZW50cy4KCgotLSAKVmxhdGtvIFMBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <1402382240.57323.YahooMailNeo@web164601.mail.gq1.yahoo.com> Date: Mon, 9 Jun 2014 23:37:20 -0700 (PDT) From: Vlatko Salaj To: "Murray S. Kucherawy" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/2hm8Y-UngvRf3jMkcmU-Jt91xdg Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 10 Jun 2014 06:40:41 -0000 On Tuesday, June 10, 2014 6:50 AM, Murray S. Kucherawy wrote: https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/ the master-piece of DKIM messiness. unfortunately, it doesn't solve current ML problem, but introduces new ML requirements. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Mon Jun 9 23:44:58 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2709D1A02DB for ; Mon, 9 Jun 2014 23:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 GFLRXyh0C1nq for ; Mon, 9 Jun 2014 23:44:55 -0700 (PDT) Received: from nm34.bullet.mail.gq1.yahoo.com (nm34.bullet.mail.gq1.yahoo.com [98.136.217.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05C121A03DC for ; Mon, 9 Jun 2014 23:44:54 -0700 (PDT) Received: from [127.0.0.1] by nm34.bullet.mail.gq1.yahoo.com with NNFMP; 10 Jun 2014 06:44:54 -0000 Received: from [98.137.12.63] by nm34.bullet.mail.gq1.yahoo.com with NNFMP; 10 Jun 2014 06:42:12 -0000 Received: from [98.137.12.232] by tm8.bullet.mail.gq1.yahoo.com with NNFMP; 10 Jun 2014 06:42:12 -0000 Received: from [127.0.0.1] by omp1040.mail.gq1.yahoo.com with NNFMP; 10 Jun 2014 06:42:12 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 23263.37440.bm@omp1040.mail.gq1.yahoo.com Received: (qmail 86690 invoked by uid 60001); 10 Jun 2014 06:42:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402382531; bh=ZRNYRVDp9X5Uc9ZFYNj1urJFPi2h//lc5/o9SZOFoYo=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=IDjLcqWpK+AHzruBz//oGciTO/5OmCwGU+RQnRWoqrr4iwtZPvXYgRtqllFXK6vKNP74s5hoXSgtRl24Zv/uup2TbRgySJrZhe/IZ/Ri3EWrPOW7tfy217TEry3pBo/tKsj6KPXGvw8QnR+A4hX034IK+wVZOhYwpW+vpHBDtTU= X-YMail-OSG: 1_.Ps9UVM1m7m31ebEz4KTD4Fmw66gjOEo59z8gg8VXyyXE LXQqS7mKZZazIaZE9l9vCWQjUWTZasQoocoSIwrwc9cvoSSIN8f37UpJ0GTT k08upqmf7pNoq1VHTjCSbWPFC70BJCUP0yaVyiwf.kpjujeBtPapNP2.m5rF 6pfz01rGuDY_LdTbWRweRlAqbLUyIvRk3brE4GOVa8TqXXTX7BI8BKepSF2W qtV6aiThOAZGd7GuMyeUy6G2DzZ2n_jlxlAjF0J.9by6kq7V7aPcSGjuY.K6 iwIVVHx1JhACnVWhaILkwCMovWtNI4emdaKaejk6dovabKM0kI78Y6b6l5xg uZxxCyFFsG2tH8qTd0I_NtwwW8QJ1bEQb2i7Ky3tvyGoVob3ExaOrCXDIz3z qFawuESn3N9NsLZK8yQXipjuhEma4ftnOHNsSC7deI3o8VoyDSXLCZEnqp7S 1zjsjx3ho0yRwN4Pmf1PMeUadGL4WK2rv2Fw5m4txvei06iDmfiWMl02.N0S gKgrVmioD1VzuieXibK6D7LrGp6hEA2SonSqqp5TtszU.srOxZqWArwcZ1rb zwZJcLRaZrb5Bq.fbQci4zuTYaOIFz8SjSYHs4Q9gquU6FJcoBRWWm1wuPzw tWvfD5L3IJ4CvTsRVngOACQJyh1X0DC2ocxjuIyenjIFmlcRyQ9.G_6iLuoM wEY7ytXvcR3Vv Received: from [79.175.112.222] by web164604.mail.gq1.yahoo.com via HTTP; Mon, 09 Jun 2014 23:42:11 PDT X-Rocket-MIMEInfo: 002.001, T24gTW9uZGF5LCBKdW5lIDksIDIwMTQgMTA6MDQgQU0sIFZsYXRrbyBTYWxhaiA8dmxhdGtvLnNhbGFqQGdvb2RvbmUudGs.IHdyb3RlOgoKCj4gbW9yZSBjb21wbGV4IGFuZCBzY2FsYWJsZSAzcmQgcGFydHkgc3VwcG9ydAo.IFtpJ20gY29uc2lkZXJpbmcgVFBBLUxhYmVsXSwKCmkgd291bGQgbGlrZSB0byBrbm93IGlmIGFueWJvZHkgb24gdGhpcwpsaXN0IHdhcyBwZXJzaXN0ZW50IGVub3VnaCB0byByZXJlYWQgVFBBLUxhYmVsCmRyYWZ0IGFzIG1hbnkgdGltZXMgYXMgbmVlZGVkIHRvIGZ1bGx5IGdyYXMBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <1402218789.64411.YahooMailNeo@web164602.mail.gq1.yahoo.com> <53946D15.5090103@isdg.net> <1402301084.4746.YahooMailNeo@web164602.mail.gq1.yahoo.com> Message-ID: <1402382531.24881.YahooMailNeo@web164604.mail.gq1.yahoo.com> Date: Mon, 9 Jun 2014 23:42:11 -0700 (PDT) From: Vlatko Salaj To: Vlatko Salaj , "dmarc@ietf.org" In-Reply-To: <1402301084.4746.YahooMailNeo@web164602.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/7O47hE-BvjFdgfVts_kfVjLAgnU Subject: Re: [dmarc-ietf] 3rd party alignment DMARC upgrade moving to RFC X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 10 Jun 2014 06:44:57 -0000 On Monday, June 9, 2014 10:04 AM, Vlatko Salaj wrote: > more complex and scalable 3rd party support > [i'm considering TPA-Label], i would like to know if anybody on this list was persistent enough to reread TPA-Label draft as many times as needed to fully grasp its operational logic? it's here: https://datatracker.ietf.org/doc/draft-otis-tpa-label -- Vlatko Salaj aka goodone http://goodone.tk From nobody Mon Jun 9 23:47:14 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F5A1A0402 for ; Mon, 9 Jun 2014 23:47:13 -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 q-byC7mWnF-J for ; Mon, 9 Jun 2014 23:47:10 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 650E31A03DC for ; Mon, 9 Jun 2014 23:47:10 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id q59so1678633wes.13 for ; Mon, 09 Jun 2014 23:47: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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=4rgESLMr3UkwHvxw06yC5S4sWeU+xeXZBN+/4/igouo=; b=GauXA8Xv1FS3jXxF5cknKcLbsK+HfB99B53tqT4maN4A8s4KL0K8j15LQohH1xoAAC GAGzNJ0QtkezBdg9XHfJvET+teTdZCtZPeZrcxt16Sxw4FYiCopu5gFNx2xMS5bbFESR Xqq0GtA42DV6G5cyX7RxMvewb3+N90boG2agIhozOfMQ9+yd+BJoisLY9X1pqGzatTdI eTBBBlw6IViBBDTQ+k1rUrK0u+Sob4SIWuC5XC/2bBVRWN4iDwRrvtYAeydJgQU7QrCu xxqqSm2lNkOWj3jpi1kPioqwzVFuoA16s/a4fXljwGG3p3yU5y86bd65OACiOGGkuHVB 5gRQ== X-Received: by 10.14.204.73 with SMTP id g49mr4300400eeo.2.1402382828891; Mon, 09 Jun 2014 23:47:08 -0700 (PDT) Received: from ?IPv6:2001:730:40:4:c46f:6289:48ff:f82c? ([2001:730:40:4:c46f:6289:48ff:f82c]) by mx.google.com with ESMTPSA id f3sm50315758eep.40.2014.06.09.23.47.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Jun 2014 23:47:07 -0700 (PDT) Message-ID: <5396A9B4.8000103@gmail.com> Date: Tue, 10 Jun 2014 08:46:12 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Stephen J. Turnbull" References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <87ppihgugl.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87ppihgugl.fsf@uwakimon.sk.tsukuba.ac.jp> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/0him-uPlfy0fwsFpBTDP--gKhF0 Cc: Matt Simerson , "dmarc@ietf.org" , "J. Gomez" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 06:47:13 -0000 On 6/10/2014 8:16 AM, Stephen J. Turnbull wrote: > I'm suggesting the information could be used in the MUA UI. ... > (4) Recipient MUA has a choice of > (a) Displaying decorated Subject verbatim. > (b) Displaying z= Subject verbatim. > (c) Matching decorated and z= subjects, and discarding mismatched > portions. > (d) As (c), but demphasizing mismatched decorations (eg, > grey-on-grey). > (e) Something else. > > I'm suggesting something along the lines of (b), (c), or (d). So now I get to demonstrate that I am an equal-opportunity MUA UI guidance critic: The premise of your proposal is that users will notice that there's extra information, know what to do with it, and do the right thing, with reasonable consistency. Each of those conditionals will not actually be satisfied. User's tend not to notice such things. The tend not to understand what they mean. Even when they understand, they tend to evaluate choices poorly. They tend to apply choices inconsistently. Everything gets much easier if we specify guidance for filtering engines, before humans come into the picture. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jun 9 23:50:25 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E46FD1A0439 for ; Mon, 9 Jun 2014 23:50:22 -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 98sIMZBuuMfQ for ; Mon, 9 Jun 2014 23:50:21 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 040D71A0407 for ; Mon, 9 Jun 2014 23:50:20 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id t60so118978wes.18 for ; Mon, 09 Jun 2014 23:50:19 -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=nZZ6zsDoFyVSxAm/59p9KMP+NMRJydmmu2H0SB3Gdxk=; b=kyB/Xnlk3ORmSy1JW4O6UPqX+z+4UQoqXScHA7saELARco5l7DnVq40vzaOmjFflnS zqlenI0lOWuQTufSpNjsHlV0CKSJSTY2a+GMHVKxZCjB0rohad64Z2X7aX5HN1rYGEPB N0FoCoEdYx30sBxWt/pyzBIPNTV15uelW0X6bN/IUqRQSQmOItOK8npWFFhrkPla3r2z lUWU1kZBkABiIXGCSWY1eug9UHS2MuQadF+LzCvJ5a8dgpOuLFrz7qvs128R3YZiLVxj PYE8I7cVGJoHyHfuMMowDfd9BthF1g3UuaRMI4WBt+wtYYQ0ybMIBybBAwjZSgwwgVat pWEQ== X-Received: by 10.14.174.135 with SMTP id x7mr4002604eel.10.1402383019521; Mon, 09 Jun 2014 23:50:19 -0700 (PDT) Received: from ?IPv6:2001:730:40:4:c46f:6289:48ff:f82c? ([2001:730:40:4:c46f:6289:48ff:f82c]) by mx.google.com with ESMTPSA id cj41sm50333169eeb.34.2014.06.09.23.50.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Jun 2014 23:50:18 -0700 (PDT) Message-ID: <5396AA73.8040109@gmail.com> Date: Tue, 10 Jun 2014 08:49:23 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Vlatko Salaj References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <1402382240.57323.YahooMailNeo@web164601.mail.gq1.yahoo.com> In-Reply-To: <1402382240.57323.YahooMailNeo@web164601.mail.gq1.yahoo.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/1kiy8uwzu-m1dQ6hcO2XSdtLZto Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 06:50:23 -0000 On 6/10/2014 8:37 AM, Vlatko Salaj wrote: > On Tuesday, June 10, 2014 6:50 AM, Murray S. Kucherawy wrote: > > https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/ > > the master-piece of DKIM messiness. unfortunately, > it doesn't solve current ML problem, but introduces > new ML requirements. On the average, technical discussion is facilitated by technical substance. That is, criticism that involves technical details. On the average technical discussion is not aided very much by summary judgements of personal opinions about technology. So rather than offer dismissive, summary comments, please offer criticisms of technical substance. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jun 9 23:52:18 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D099A1A0442 for ; Mon, 9 Jun 2014 23:52:16 -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 S8WQv2f7Hf1T for ; Mon, 9 Jun 2014 23:52:14 -0700 (PDT) Received: from smtp-4.01.com (adminr.01.com [162.209.88.187]) by ietfa.amsl.com (Postfix) with ESMTP id CBF3F1A0422 for ; Mon, 9 Jun 2014 23:52:14 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [192.254.77.197]) by smtp-4.01.com (Postfix) with ESMTP id B94B54C716; Tue, 10 Jun 2014 01:52:12 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 8B675A034F; Tue, 10 Jun 2014 01:52:12 -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 7NMqNV_sT6JC; Tue, 10 Jun 2014 01:52:12 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 694C0A034D; Tue, 10 Jun 2014 01:52:12 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 5AA53A034F; Tue, 10 Jun 2014 01:52:12 -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 XlgNjhxtpWtm; Tue, 10 Jun 2014 01:52:12 -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 401DAA034D; Tue, 10 Jun 2014 01:52:12 -0500 (CDT) Date: Tue, 10 Jun 2014 01:52:11 -0500 (CDT) From: Franck Martin To: Dave Crocker Message-ID: <1755889339.33315.1402383131643.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <5392ECED.5010404@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF29 (Mac)/8.0.5_GA_5839) Thread-Topic: New Version Notification for draft-kucherawy-dkim-delegate-00.txt Thread-Index: c/rWQu7hZSnnsxrPB9qoRcAo1BqYZg== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/X_P_kcLap2squR2mB7ZlfGA0SqE Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 10 Jun 2014 06:52:17 -0000 This is interesting, however it seems to me that DMARC should be more aware of it if used. I would suggest to sign with a sub domain. This would keep alignement, but would allow you to see which DKIM signature worked. Once both DKIM signature work, you would not need the delegated one. I think DMARC should be made aware, so that it apply some constraints on when this signature is used/valid. May be only when there is a List-ID or List-Post header present, and the list has DKIM signed the whole message with its domain. It would require MLM to not drop DKIM headers... Still some configuration on MLM side, but less in the way messages are modified ----- Original Message ----- From: "Dave Crocker" To: dmarc@ietf.org Sent: Saturday, June 7, 2014 12:43:57 PM Subject: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt Folks, I've been stewing on this idea for awhile and Murray pressed to get it into writing, adding his usual, significant enhancements to the original concept. We've gone a couple of rounds before releasing it, but it's still nascent enough to warrant gentle-but-firm handling. In other words, comments eagerly solicited. d/ -------- Original Message -------- Name: draft-kucherawy-dkim-delegate Revision: 00 Title: Delegating DKIM Signing Authority Document date: 2014-06-07 Group: Individual Submission Pages: 10 URL: http://www.ietf.org/internet-drafts/draft-kucherawy-dkim-delegate-00.txt Status: https://datatracker.ietf.org/doc/draft-kucherawy-dkim-delegate/ Htmlized: http://tools.ietf.org/html/draft-kucherawy-dkim-delegate-00 Abstract: DomainKeys Identified Mail (DKIM) permits a handling agent to affix a digital signature to an email message, associating a domain name with that message using cryptographic signing techniques. The digital signature typically covers most of a message's original portions, although the specific choices for content hashing are at the discretion of the signer. DKIM signatures survive simply email relaying but typically are invalidated by processing through Mediators, such as mailing lists. For such cases, the signer needs a way to indicate that a valid signature from some third party was anticipated, and constitutes an acceptable handling of the message. This enables a receiver to conclude that the content is legitimately from that original signer, even though its original signature no longer validates. This document defines a mechanism for improving the ability to assess DKIM validity for such messages. -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Tue Jun 10 00:14:50 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703851A0496 for ; Tue, 10 Jun 2014 00:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 f4PZG0fDRFQq for ; Tue, 10 Jun 2014 00:14:44 -0700 (PDT) Received: from nm31.bullet.mail.ne1.yahoo.com (nm31.bullet.mail.ne1.yahoo.com [98.138.229.24]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC0A1A04A7 for ; Tue, 10 Jun 2014 00:14:44 -0700 (PDT) Received: from [127.0.0.1] by nm31.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2014 07:14:43 -0000 Received: from [98.138.100.118] by nm31.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2014 07:11:51 -0000 Received: from [98.137.12.175] by tm109.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2014 07:11:51 -0000 Received: from [98.137.12.236] by tm14.bullet.mail.gq1.yahoo.com with NNFMP; 10 Jun 2014 07:11:51 -0000 Received: from [127.0.0.1] by omp1044.mail.gq1.yahoo.com with NNFMP; 10 Jun 2014 07:11:51 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 483916.42876.bm@omp1044.mail.gq1.yahoo.com Received: (qmail 42115 invoked by uid 60001); 10 Jun 2014 07:11:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402384311; bh=46cTCx5uNzCko5DhoYKW9QDrpBAD4FvwSaYhRI/s3Vc=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=li8SU/kuEQAiye/fXEigtIXUoaQ0W9WfZp/ulJWFcLzb0FgRpd/RrrpxmL7DPVWTdiZJLril0BZMkd1C+4WG378cQxXe/CRkXs7eydM1mGkUgMgcRpaaMntIGzwCyy4MHpOUVj1UcBBy78fiC1kWmUKuQRenjVclNDlXRD5ORwQ= X-YMail-OSG: p5e9xKAVM1nLj9D1hgjIVgn1rigZWEiuU.mcU.NYlFx.37f uWsPu_Gybplbh6i6dZ5LESg6NshJsJtyQ2v2H78KKtrOkG0UCVOJACXfggZ3 la4CcKUZqBw3veDCUi9xmv56euczSS5afaq9gYeraIORZCcl6jrWIopUZQ60 P86lSqLnlhKv3kNYWrZeRM2rR0vUxaTBF3rB6JpU4vkIe9zP1hSB6_9hwSd7 96twKRewqJDqaejIMJVGkp1v.gJYYrchUErURhXFEpiSOcJUgzBQ2d10Y5AR hyaB5tJHYFcoJ_Ipn1XKCsDt4buQzbsFov1jI69x4NksMDz.nlX_npXzntiV fiKF.BgJh1U3lIZaOs0esaToD2p6MR2nzQxiVStgoxhJZ72Cf3kiv9B3ZxC_ B1FcA9_COqwSrGqTNkYMl47G6_IAVT9mpPP3xb3mq7DRSzLv2TqrblfGZE03 JX9kFCruUQH3x4gYwvMvqap6RQRcmK0OxeDe76X5dPDRhJ0i2I9X0yUCFn1s DebawXtU.uiHdKW6RtctdYsoSsOQVtjLFakL3DbzxzYhVKd5pqvqaUYmhw6_ wkEw1Ol0ugKmIch7W8vRXowLMx5PMunb1Q_CJ_FIegZCq4FhsFINizXiRlog oWInQ3GOQxjJGRw3SC7rny_Uv.ojKzGSGgTNP3EfucdpPgjqmmSAHSVRg.89 _aUC2AEuS510ChGY9HFvFNv31_bMkMA-- Received: from [79.175.112.222] by web164603.mail.gq1.yahoo.com via HTTP; Tue, 10 Jun 2014 00:11:51 PDT X-Rocket-MIMEInfo: 002.001, T24gVHVlc2RheSwgSnVuZSAxMCwgMjAxNCA4OjQ5IEFNLCBEYXZlIENyb2NrZXIgPGRjcm9ja2VyQGdtYWlsLmNvbT4gd3JvdGU6CgoKCj4.IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWt1Y2hlcmF3eS1ka2ltLWxpc3QtY2Fub24vCj4.IHRoZSBtYXN0ZXItcGllY2Ugb2YgREtJTSBtZXNzaW5lc3MuIHVuZm9ydHVuYXRlbHksCj4.IGl0IGRvZXNuJ3Qgc29sdmUgY3VycmVudCBNTCBwcm9ibGVtLCBidXQgaW50cm9kdWNlcwo.PiBuZXcgTUwgcmVxdWlyZW1lbnRzLgo.IFNvIHJhdGgBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <1402382240.57323.YahooMailNeo@web164601.mail.gq1.yahoo.com> <5396AA73.8040109@gmail.com> Message-ID: <1402384311.51951.YahooMailNeo@web164603.mail.gq1.yahoo.com> Date: Tue, 10 Jun 2014 00:11:51 -0700 (PDT) From: Vlatko Salaj To: Dave Crocker In-Reply-To: <5396AA73.8040109@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/8sOkmSu6--yxHG6uEw4RFuz9ZJ4 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 10 Jun 2014 07:14:47 -0000 On Tuesday, June 10, 2014 8:49 AM, Dave Crocker wrote: >> https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/ >> the master-piece of DKIM messiness. unfortunately, >> it doesn't solve current ML problem, but introduces >> new ML requirements. > So rather than offer dismissive, summary comments, > please offer criticisms of technical substance. i would rather not waste time on elaborate thesis about YADA [yet another DKIM addon]. someone who has time will do it and they can add my vote apriori. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Tue Jun 10 00:18:11 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A82491A0460 for ; Tue, 10 Jun 2014 00:17: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_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_ABOUTYOU=0.5, 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 LiXLwYT1olz1 for ; Tue, 10 Jun 2014 00:17:55 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BE731A044D for ; Tue, 10 Jun 2014 00:17:55 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id cc10so1154980wib.12 for ; Tue, 10 Jun 2014 00:17:54 -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=YkN0BELlAtYhJsqMaCpvhd+26lqRBcek5hzWDWABjpw=; b=rQudjb7lbXFMfzLiNMEjuLUzLu1VMnW02iZUIZQ4jHPTpG0xZe8P2bDuQbeLad1Zmb DYZPmx8Ow8uLEy0nYGxvdBlk6L04nin8+dW2uKGhOHzqYdqXz5AG001X5PKeoAaHvc8t e/WRxFQfA46Xw+z9iufCiK4te/NaJ3WuQplfYNik7iP/CjAQ6nM3AC2KaNuhr7HofuBt GFL1Q4w5fYY+ngyhSdxrnK/hGE6dZ8XSD09EWYV+XSkjnaJoElcFk9ZKeZZtdaOAEn3V FkKfPybJH8FWR6Yi4vdfyNuHa+J8tA81O311KAiOUH5NEaNXegSENlnd/VLfbok16zBX TRkw== X-Received: by 10.14.104.200 with SMTP id i48mr6218eeg.24.1402384674010; Tue, 10 Jun 2014 00:17:54 -0700 (PDT) Received: from ?IPv6:2001:730:40:4:c46f:6289:48ff:f82c? ([2001:730:40:4:c46f:6289:48ff:f82c]) by mx.google.com with ESMTPSA id 44sm50481897eer.35.2014.06.10.00.17.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Jun 2014 00:17:53 -0700 (PDT) Message-ID: <5396B0E9.9010109@gmail.com> Date: Tue, 10 Jun 2014 09:16:57 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Vlatko Salaj References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <1402382240.57323.YahooMailNeo@web164601.mail.gq1.yahoo.com> <5396AA73.8040109@gmail.com> <1402384311.51951.YahooMailNeo@web164603.mail.gq1.yahoo.com> In-Reply-To: <1402384311.51951.YahooMailNeo@web164603.mail.gq1.yahoo.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/0OehRBqfd03DMPMg5Oy_lPLVa4o Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 07:17:56 -0000 On 6/10/2014 9:11 AM, Vlatko Salaj wrote: > On Tuesday, June 10, 2014 8:49 AM, Dave Crocker wrote: >>> https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/ >>> the master-piece of DKIM messiness. unfortunately, >>> it doesn't solve current ML problem, but introduces >>> new ML requirements. >> So rather than offer dismissive, summary comments, >> please offer criticisms of technical substance. > > i would rather not waste time on elaborate thesis > about YADA [yet another DKIM addon]. someone who has > time will do it and they can add my vote apriori. I'm a bit confused. You think it is ok to waste everyone's time by offering your personal, summary-dismissal notes, but not substantive criticism? An example of why postings like you've sent are unhelpful is that it implicitly invites others to offer summarily-dismissive notes about your notes. There's nothing productive about such a path. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jun 10 00:26:58 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD421A023C for ; Tue, 10 Jun 2014 00:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 Z0RNkMHfv7iO for ; Tue, 10 Jun 2014 00:26:54 -0700 (PDT) Received: from nm40.bullet.mail.ne1.yahoo.com (nm40.bullet.mail.ne1.yahoo.com [98.138.229.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0057B1A00B8 for ; Tue, 10 Jun 2014 00:26:53 -0700 (PDT) Received: from [127.0.0.1] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2014 07:26:53 -0000 Received: from [98.138.100.116] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2014 07:23:53 -0000 Received: from [98.137.12.55] by tm107.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2014 07:23:53 -0000 Received: from [216.39.60.201] by tm15.bullet.mail.gq1.yahoo.com with NNFMP; 10 Jun 2014 07:23:53 -0000 Received: from [127.0.0.1] by omp1088.mail.gq1.yahoo.com with NNFMP; 10 Jun 2014 07:23:53 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 299015.19759.bm@omp1088.mail.gq1.yahoo.com Received: (qmail 91814 invoked by uid 60001); 10 Jun 2014 07:23:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402385033; bh=gPvWbaWcajJqSnTvzzS5VdoyLJKrqM9A37iYsTLzXFI=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=vApHZlueHQSHnPeIGym5wFE151kxsrFiYHo2hY9CdoExrxkTrEjNbdCEkEd4itOUg+kywpJfUcCgUgR2mkqqEi68mfKsX7K/QBTGUQOhJMfJhFsZJTkWelVc0/hbgBMIuw1OgNXMPdhKK5mTVNBfwceYLUq4vv5XuPSc2KB3c+g= X-YMail-OSG: hqz3WfEVM1nvURKjXEkJFMxorclq8xRW5MiDHu2VgWoOzRE Na_F0C.8WEG9ABE1TXiZ9S2nr3iyk0Je8ZdQgZ2q7y61CX_4IFiEOLiGra99 4d062gNJtCIFEGJ7q5NIj5A1mMSHyl9jkotNpiupXn8.iqUpX4EdIk2NoBcO VmoCWdYCwEzvPKktrfrzvdlWFjBo7c2fBByTnc2aijzMUY6McvPBkSA_Krjx CkgLK8U6MU_30eTUBZ_Dlp.FkmavpMdZZ.1oPyV6XakA10Fi3MuiArRsH2cj SbmSmZh3GLNMxQRBTZqnjL7nSfk7TLTALJOygSDqOyDj2ObWcJQSnpDQESQ5 UmcYiqytFoF5r31VcGMctzSI08HHEaNP_pZqm0GKMEr.AztGNaaNdNNpAIwO EBaytMYhgq0Uqapw9u51ZFpsHO107MwXzkK5qANTIJia4eVIXKzHE2yZ4NYK 1_WFpMowC7ttZsyKtzlTnCHPG1iV3bDiEew0LWEJghwiOdA693z7jris3Qef juhx._XpTinWiI64n.uk_czHu8dmNIAUk2JOB28cDk9nFoYv4a2hRIOXcNik jDSiMOoZL5OQzJDYcwgzug.P.OkOzuG6XsgJA5NZQJoAubl6ibCUd7vuSBty U Received: from [79.175.112.222] by web164602.mail.gq1.yahoo.com via HTTP; Tue, 10 Jun 2014 00:23:53 PDT X-Rocket-MIMEInfo: 002.001, REtJTS1EZWxlZ2F0ZSBzdWZmZXJzIGZyb20gcmVwbGF5IGF0dGFja3MsIGFuZCB3aGVuIG5vdCwKaW50cm9kdWNlcyB3aGl0ZWxpc3Rpbmcgd2hpY2gsIGtpbmQgb2YsIGJyZWFrcyBpdHMgcHJlbWlzZS4KCmFsc28sIHdlIG5lZWQgYSBzb2x1dGlvbiB0aGF0IGRvZXNuJ3QgcmlzayBvZiBiZWluZyBtb2RpZmllZApieSBhbnkgbWlkZGxlIG1hbiBvbiBtZXNzYWdlIHBhdGguIERLSU0gY2FuJ3Qgb2ZmZXIgdGhhdCwKYW5kIHdpbGwgbmV2ZXIgYmUgYWJsZSB0by4KCgotLSAKVmxhdGtvIFNhbGFqIGFrYSBnb28BMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <5392ECED.5010404@gmail.com> <1755889339.33315.1402383131643.JavaMail.zimbra@peachymango.org> Message-ID: <1402385033.97400.YahooMailNeo@web164602.mail.gq1.yahoo.com> Date: Tue, 10 Jun 2014 00:23:53 -0700 (PDT) From: Vlatko Salaj To: Dave Crocker In-Reply-To: <1755889339.33315.1402383131643.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/xH_5QVvn3-QWt4A1l2hiRdiWm08 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 10 Jun 2014 07:26:56 -0000 DKIM-Delegate suffers from replay attacks, and when not, introduces whitelisting which, kind of, breaks its premise. also, we need a solution that doesn't risk of being modified by any middle man on message path. DKIM can't offer that, and will never be able to. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Tue Jun 10 00:44:37 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266EA1A0463 for ; Tue, 10 Jun 2014 00:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, GB_ABOUTYOU=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 yPEU0wZJHAnf for ; Tue, 10 Jun 2014 00:44:30 -0700 (PDT) Received: from nm35.bullet.mail.gq1.yahoo.com (nm35.bullet.mail.gq1.yahoo.com [98.136.217.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EB3C1A04CD for ; Tue, 10 Jun 2014 00:44:25 -0700 (PDT) Received: from [127.0.0.1] by nm35.bullet.mail.gq1.yahoo.com with NNFMP; 10 Jun 2014 07:44:24 -0000 Received: from [98.137.12.60] by nm35.bullet.mail.gq1.yahoo.com with NNFMP; 10 Jun 2014 07:41:36 -0000 Received: from [216.39.60.159] by tm5.bullet.mail.gq1.yahoo.com with NNFMP; 10 Jun 2014 07:41:36 -0000 Received: from [127.0.0.1] by omp1078.mail.gq1.yahoo.com with NNFMP; 10 Jun 2014 07:41:36 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 285446.45670.bm@omp1078.mail.gq1.yahoo.com Received: (qmail 35585 invoked by uid 60001); 10 Jun 2014 07:41:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402386096; bh=WiWPBKpd0Q71qmC4HYt9mPZnF+7BvY8BqCmwB3SRl0M=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=2F/6i2l8nulzNZnW4GtEjCWmqKIjQRgYAue3sgUZur6eVwRA6QfL7p8QQdbyK9HoOhCQA423FX0IJM7daoL9y6VSVXU1jZro4Bzo9Fgtl5TLRAEh+UEUESoLZmk2JNRvwANYncZ0TijfxusUKzc62/lp+2M0gLpLDgllZYt8Mzs= X-YMail-OSG: 5H3btA0VM1nfQUp6Jvap3aj0yqXC4eGfFiU97CmD1Y.pTs3 EYN_Ygvm_l.Qnw1bx_KSIicmAlXqr40xFfzFgMIcXKEDojavc8KR1HZ2qMC2 OSXCuaKThp6kqR8h.8lYIWyKpVEZj65ot.v3W.mTHcrv4nyCbwKhFDSWiZ8U fG2xftA.069yj6fSX.sIowjY53fg1T3Em4Pnq6.o03BLpcslemqpwU1gQUGP fOQxwqflO49HRpMx33OGQjf.1S8KRcDmPbDMD5WjrrvUHS0eQom2E.L.DdxD .cP0FGRbF_WtSgFof2J7N7_F7gS2uAlxH0D2dpDzep5ThcsZTyhfjY8aDOXL F4pZo3TwizvlD3jF_AsYpYaROToEr826sEbuK1FQEHuJs5I.O7V_bpB.qx7_ zRHfym0WKDrNW51dNyKB11WCOgt2K7aZWa0Yo18GgxfL46Jx_cnSaT5EI32m WUAncQjwV7nm6WLY3mrJwIeiTUU0tR0eHgJCrliH.YlybATwVZVby8Irw9zl LhezSDTozqoToRbm_nhyDRqK5jm.y.ujSAcXunwV2KhfZomBXNFTXivhTz7q I1ILvhTJnvIr0VbbBaqQnGC2hOXvGmMHsDcEMsW2zWQn2SlzATlMWftwSOaq 03xm7pfNi7ajj9csbRn.jBjb3T0qz3GW3PN25MxtLOTslDmg58_z3H1WQUcm CxGcNDtc4qt45lS.bm1GufJUaScpD Received: from [79.175.112.222] by web164604.mail.gq1.yahoo.com via HTTP; Tue, 10 Jun 2014 00:41:36 PDT X-Rocket-MIMEInfo: 002.001, T24gVHVlc2RheSwgSnVuZSAxMCwgMjAxNCA5OjE4IEFNLCBEYXZlIENyb2NrZXIgPGRjcm9ja2VyQGdtYWlsLmNvbT4gd3JvdGU6Cgo.Pj4.PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1rdWNoZXJhd3ktZGtpbS1saXN0LWNhbm9uLwo.Pj4.IFtpdF0gaW50cm9kdWNlcyBuZXcgTUwgcmVxdWlyZW1lbnRzLgo.Pj4gU28gcmF0aGVyIHRoYW4gb2ZmZXIgZGlzbWlzc2l2ZSwgc3VtbWFyeSBjb21tZW50cywKPj4.IHBsZWFzZSBvZmZlciBjcml0aWNpc21zIG9mIHRlY2huaWNhbCBzdWIBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <1402382240.57323.YahooMailNeo@web164601.mail.gq1.yahoo.com> <5396AA73.8040109@gmail.com> <1402384311.51951.YahooMailNeo@web164603.mail.gq1.yahoo.com> <5396B0E9.9010109@gmail.com> Message-ID: <1402386096.27670.YahooMailNeo@web164604.mail.gq1.yahoo.com> Date: Tue, 10 Jun 2014 00:41:36 -0700 (PDT) From: Vlatko Salaj To: Dave Crocker In-Reply-To: <5396B0E9.9010109@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/rZtn9JfC43gMa1qsmP523oMhqzw Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 10 Jun 2014 07:44:32 -0000 On Tuesday, June 10, 2014 9:18 AM, Dave Crocker wrote: >>>>> https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/ >>>> [it] introduces new ML requirements. >>> So rather than offer dismissive, summary comments, >>> please offer criticisms of technical substance. >> i would rather not waste time on elaborate thesis >> about YADA [yet another DKIM addon]. someone who has >> time will do it and they can add my vote apriori. > You think it is ok to waste everyone's time by > offering your personal, summary-dismissal notes, > but not substantive criticism? depends how u define substantive criticism. i DID say: "it introduces new ML requirements". "introducing new ML requirements" has already been characterised as not an ML solution. we have a few of them already, and all much simpler than any YADAs. > An example of why postings like you've > sent are unhelpful is that it implicitly > invites others to offer summarily-dismissive > notes about your notes. walk what u preach then and don't do it. sometimes ignoring is the best approach. i'm not looking to find ur approval, but those who stand on the same viewpoint as i do. > There's nothing productive about such a path. there's also nothing productive in *personal* thinking that DKIM is a holy grail of authorization, and based on that *personal* motivation, sponging endless YADAs [aka yet another DKIM addons], wasting urs and our time in process. yet u do it. so i do it, and we r here, doing this. nothing new. it's just who we r. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Tue Jun 10 02:22:29 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87601A0390 for ; Tue, 10 Jun 2014 02:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 1NwHnDiVPPjV for ; Tue, 10 Jun 2014 02:22:27 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 23B1F1A001B for ; Tue, 10 Jun 2014 02:22:26 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 3DC433FA0B18; Tue, 10 Jun 2014 18:22:26 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 325DD1A32C5; Tue, 10 Jun 2014 18:22:26 +0900 (JST) From: "Stephen J. Turnbull" To: Dave Crocker In-Reply-To: <5396A9B4.8000103@gmail.com> References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <87ppihgugl.fsf@uwakimon.sk.tsukuba.ac.jp> <5396A9B4.8000103@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 10 Jun 2014 18:22:25 +0900 Message-ID: <87sindt8z2.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/YtNY8sBBVi4oDCll5trClzwgm1E Cc: "dmarc@ietf.org" , Matt Simerson , "J. Gomez" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 09:22:28 -0000 Dave Crocker writes: > The premise of your proposal is that users will notice that there's > extra information, know what to do with it, and do the right thing, > with reasonable consistency. Yes, yes, yes, and yes. > Each of those conditionals will not actually be satisfied. User's > tend not to notice such things. The tend not to understand what > they mean. Even when they understand, they tend to evaluate > choices poorly. They tend to apply choices inconsistently. Yes, yes, yes, and yes (all modulo "are we letting 'perfect' be the enemy of 'better'?" -- you have a *really* dim view of the average users' capabilities!) > Everything gets much easier if we specify guidance for filtering > engines, before humans come into the picture. But now you are assuming filters that are very close to 100% accurate! Do you really think we can get there? I don't, because we already see Yahoo! Groups arranging that *humans* can see yahoo.com mailboxes in From: even though DKIM can't! If that isn't going to provide an opportunity for phishers and spammers, why are we doing DMARC in the first place? Similarly, several posters have already objected that DKIM-delegate is subject to replay attacks. I personally think DKIM-delegate is more likely to get adopted than (say) TPA-labels, and even if both succeed, DKIM-delegate is likely to be adopted and implemented more quickly because it's much simpler. Anyway, I'm assuming we've done the best we can at filtering at the "missing link" stage. In the scenarios I'm talking about, the message has already gotten through the filtering engines. Maybe it's in quarantine, and maybe nobody except me even looks in spam folders. But what if they do? I conclude that we should consider trying to enlist the MUA devs for "defense in depth." From nobody Tue Jun 10 03:57:49 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C381A0535 for ; Tue, 10 Jun 2014 03:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.48 X-Spam-Level: X-Spam-Status: No, score=-100.48 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_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 0YA37JxDE-7E for ; Tue, 10 Jun 2014 03:57:46 -0700 (PDT) Received: from catinthebox.net (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9A61A050E for ; Tue, 10 Jun 2014 03:57:45 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2220; t=1402397855; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=cEwYxIaDS6/2zOWV7soC/XPXjrc=; b=pkiHRvBzFWMRux4wfQ07 9RfjaSf3Q8YorIMmRRV4wwmcHCoDIJXyht5j2DVMfRpYBGxlLTdpLZn53BC7psTV JYePu3ezF78W3J3H0+v3FWKKsTtkF//z8pNGVN8j3kxfMCdGCxUnjzLuKdSWHtIB bhc1t0rovM2q0adt6oomTyQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 10 Jun 2014 06:57: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; Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1877978099.17216.5808; Tue, 10 Jun 2014 06:57:34 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2220; t=1402397688; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=iE2naVP uqfy2zn4sfTfC/bSrV9fUUPe43jJIWQrB0gU=; b=DajkjVZldUDMlKJdLrP80Bj ZumgN0G86EasHwad0YRdp6U0Jr+rwDBelDSvbDXOdszzfQJYZbNBG/1GhJKRO+rF fVYv3mo+QBR6undqPKqNNfQx80zcBZEUuVCLfMgT2OaXreIaGU8EuQpgj0uhQofW 7AdB0ue05h+9WQYSWYrE= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 10 Jun 2014 06:54: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 1894335734.9.5776; Tue, 10 Jun 2014 06:54:47 -0400 Message-ID: <5396E49C.2000808@isdg.net> Date: Tue, 10 Jun 2014 06:57: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: "Stephen J. Turnbull" References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <87ppihgugl.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87ppihgugl.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Shski5W-n_iy1tIBoLw4RC8s04o Cc: Matt Simerson , "dmarc@ietf.org" , "Murray S. Kucherawy" , "J. Gomez" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 10:57:48 -0000 On 6/10/2014 2:16 AM, Stephen J. Turnbull wrote: > I'm not proposing additional validation. As I've said before, I have > no quarrel with the DMARC protocol or its component protocols (at > least I've not found a reason to dislike it yet), although I strongly > dislike Yahoo!'s policy use of "p=reject". Are you oppose to any other domain using strong policies or just certain ones? In other words, would you honor the p=reject for other domains, just not Yahoo's? You didn't answer the question in another post regarding if you are even ready or support the idea of even doing a DNS lookup to find out what a domain's policy is? > I'm suggesting the information could be used in the MUA UI. A failed > signature *would* fail. Consider the following scenario: > > (1) User posts, MTA DKIM-signs using DKIM-delegate protocol (main > signature signs Subject and body, delegate signature does not). > (2) Mailing list decorates Subject, MTA DKIM-signs all the usual > fields and body, and distributes. > (3) Recipient MTA notes failure of main originator signature but > accepts according to local policy about DKIM-delegate and valid ML > signature, ignoring z=. > > Isn't that OK? Now It is more easier, more feasible, more safe, to just reject/discard the failed message (due to policy) at the backend and be done with it. > (4) Recipient MUA has a choice of > (a) Displaying decorated Subject verbatim. > (b) Displaying z= Subject verbatim. > (c) Matching decorated and z= subjects, and discarding mismatched > portions. > (d) As (c), but demphasizing mismatched decorations (eg, > grey-on-grey). > (e) Something else. > > I'm suggesting something along the lines of (b), (c), or (d). If the > MUA does (a), it just falls into the abuser's trap, of course. But > that's exactly what would happen now if somebody found a way to suborn > dkim-delegate. Do you realize how many different MUAs exist? and the different forms of MUAs? Why pass the buck to the user when the backend can deal with this and its works for all MUAs!! This is like assuming there is only GNU mailman out there. Even then, are you going to make the changes to your VM editor? -- HLS From nobody Tue Jun 10 04:27:14 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8101E1B27BA for ; Tue, 10 Jun 2014 04:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 2clPn5vw6v6X for ; Tue, 10 Jun 2014 04:27:11 -0700 (PDT) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96A891B27B8 for ; Tue, 10 Jun 2014 04:27:11 -0700 (PDT) Received: by mail-ve0-f179.google.com with SMTP id oy12so7930263veb.38 for ; Tue, 10 Jun 2014 04:27:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5BFkcRwExHAWXgl60p3wbDuyA4FxV9jyFVY0alc6b0o=; b=aA688WV/rC5xTVa9w8hvQIZAjWtu1xPFutdNMP9p9wr/HSj2Xs1qTYpeHjYLcekGfQ IR3R4txKpSdv2fzUDkLJ9aE1VVwuTFx6k0K15VX0vsE5psKYsACmD0rSEzI1cAPO8taT kcUGPdzDq3PirlIEHeypVdlnBjObhIWpbK6oLvj6Jfg3UuH7zOdi33JEmR24r3w03nQf 0+C7aRsP9CVB7JmfucJuvStZv7enS1/kZTFBG7hY/Fwvz9+98nHSiym3C2EBP19hrTEq QtWZ4H77I0jzIQ4it+9wCkAgKbUCCoxSri7aUdRxn4cRxu+3xMR7UaDnywZspys3gTx6 UkMQ== MIME-Version: 1.0 X-Received: by 10.220.183.4 with SMTP id ce4mr1308769vcb.54.1402399630621; Tue, 10 Jun 2014 04:27:10 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.33.199 with HTTP; Tue, 10 Jun 2014 04:27:10 -0700 (PDT) In-Reply-To: <87sindt8z2.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <87ppihgugl.fsf@uwakimon.sk.tsukuba.ac.jp> <5396A9B4.8000103@gmail.com> <87sindt8z2.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Tue, 10 Jun 2014 07:27:10 -0400 X-Google-Sender-Auth: kVLJk6k7LvVof36ko1BLaY30628 Message-ID: From: Barry Leiba To: "Stephen J. Turnbull" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/k6-9msHY6YhdMed01j9qqUJmS34 Cc: Dave Crocker , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 11:27:12 -0000 > > The premise of your proposal is that users will notice that there's > > extra information, know what to do with it, and do the right thing, > > with reasonable consistency. ... > > Each of those conditionals will not actually be satisfied. User's > > tend not to notice such things. The tend not to understand what > > they mean. Even when they understand, they tend to evaluate > > choices poorly. They tend to apply choices inconsistently. > > Yes, yes, yes, and yes (all modulo "are we letting 'perfect' be the > enemy of 'better'?" -- you have a *really* dim view of the average > users' capabilities!) I think Dave's dim view is pretty much accurate, though I can't show that in any concrete way. But the more important point is that you're presupposing that the changes are "better", and my contention is that we don't know enough about UI design and user experience to say that. To people like you and me, it's clear that giving more information -- and especially such important information as this! -- is better. But that's not really true, and even information that we think is essential... is actually confusing to non-technical users. Here I can cite studies; I have one that looked at browser cues such as the lock symbol, and found that users so misunderstand the lock symbol that they (1) think a lock symbol on the web page itself is *better* than one in the browser frame (that's quite backward), (2) don't know what the lock symbol is telling them *at all*, and have various cockamamie ideas about what it means, and so on. We have to be very careful about such changes, and not assume that we know what's better. Barry From nobody Tue Jun 10 04:43:18 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E191A007B for ; Tue, 10 Jun 2014 04:43:17 -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 inDN1L7MEy44 for ; Tue, 10 Jun 2014 04:43:16 -0700 (PDT) Received: from catinthebox.net (mail.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFBA1A0047 for ; Tue, 10 Jun 2014 04:43:16 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4951; t=1402400591; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=V3Q70pr5AjbEEMc5F7N2oAi/fcI=; b=i6XsWe3sY7rooiSzhoXP /yaa1UFDiPTbTXqMImyYyZ7O0YsIGInMQity8/WKAHXtDzXz3ugSwrUKR4l4hShk 53/kkVAk2v6OKlMDirUdcLPjxsMio5STyG/Rf99Fcd0M8ngFipySg4+4sUuFUkDW 6uaFvUG0duA6lQQ4XC4KpwY= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 10 Jun 2014 07:43: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; Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1880713764.17216.2012; Tue, 10 Jun 2014 07:43:10 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4951; t=1402400426; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=pUXCAIz 9T0Jea5PxquEDvuJn2vckaPTjcmECGqGnrEo=; b=TgKCd/f4s8X0nCLr+IlA/UZ 8IYnstGGUq9h3hJa3EibW3m+Xg+YF1CLIpOzw0jhYSEQL0Hiepz1o2kJiLJjV5Zl QZLVNX3nB/CafqBL2/JLhCFq6TNv+zR7/Ymd36VXXQoI0haXecZLys+fc2OmlFHm IcSr0RTy92Ln/oYaWyCw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 10 Jun 2014 07:40: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 1897073171.9.5784; Tue, 10 Jun 2014 07:40:25 -0400 Message-ID: <5396EF4D.2000100@isdg.net> Date: Tue, 10 Jun 2014 07:43:09 -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: Barry Leiba , Scott Kitterman References: <1402212310.40987.YahooMailNeo@web164605.mail.gq1.yahoo.com> <1322124542.1687.1402245193573.JavaMail.zimbra@peachymango.org> <597dc384-7907-4a14-acaa-cd527650758b@email.android.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/bTm09DP9cvapemFewAYnVlE37fs Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] advice to MTAs 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, 10 Jun 2014 11:43:17 -0000 On 6/9/2014 10:38 PM, Barry Leiba wrote: >>> Putting as much value on RFC5322 From as DMARC does follows >>> conventional wisdom, but I believe that wisdom is flawed. >>> >>> Of course, that speaks to the advice you want to give: tell UIs that >>> they should show the From addr-spec to users always. But be clear >>> about what you're asking for: you're not saying they should do it >>> because it's objectively "right"; you're saying they should do it >>> because it helps support the decision that DMARC has made. >> >> If any authentication technology is going to work, DMARC or whatever, >> it will have to be tied to some kind of identifier. 5322.From is as good >> as any and better than most. > > And yet SPF uses a different one (5321.Mail.From), and there've been > suggestions to use Sender, rather than From, if Sender is present, or > to check both. There's no one "right" answer, and all have failings. > > If a spec is going to suggest UI changes to match the choices that > spec has made, it needs to be clear about where those suggestions come > from. And the people making the recommendations need to understand > that their recommendations might be wildly in conflict with what UI > experts know to work best for users. +1. What is an UI expert? I have at least 4-5 MUA products, tools, under my belt; text-based, native gui-based, web-based, API-based, etc, a tremendous amount of consideration is made in how/what is displayed to the user, bells and whistles, and you know what, you can do a great job, and its still not perfect. In fact, sometimes the best thing to do is to do less, following Pareto's principle works very well. Take a look at some of the current reinvention simple ideas for communications fall back to the basic UI simply to make it "fit to print/display." There are two parts to this identity: - using it as an strong anchor for domain policy, - using it for displaying to the user. At the end of the day, its about consistency, and what we are talking about is basically what will be passed to the mail readers. For the IETF, its about 822/2822/5322 and the different mail access portals. We have currently within the IETF; POP3, NNTP and IMAP. Afair, there is no IETF RFC for a web-based Mail Access Protocol Inteface ("MAPI"). If we have control of the backend, you can do all sorts of things, but ultimately, what is the goal here? - Backend filter the message for the user, don't pass it? - Pass it with highlights? If the user has a conference based MUA, like the old MAPI exchange, IMAP, or even Newsreaders, then you can move non-rejected bad mail into special folders the user still has access to. If the user only has POP3, then the backend has to decide to filter the message unless it knows the MUA will be filtering it. Anyway, one of the central "battles" if we want to call it a battle, is the philosophical differences about what is to be done with "rejectable" mail. 5321 finally recognizes the probability of discardable mail, that was due to the pending ADSP proposed standard that would of provided technical authorization to operating in this mode. Yet, there are still folks here that believe that rejecting mail at SMTP is a "fantasy" not a "reality" and that all mail is always passed to users. I say, we are only dealing with the indeterminate mail, the relaxed, the "half-failed", the mail the backend can't make a decision and needs to just forget about it and pass on. The hard failures are really not a problem. They may have some False Positive yield, but it is extremely low to non-existence (set it and forget it). No, instead we are fighting, wasting so much time, about what to do with highly detectable rejectable mail based on a policy system. I go back to RFC5016, where at the last minute, this itemized section 5.3 provision was added: 10. SSP MUST NOT provide a mechanism that impugns the existence of non-first party signatures in a message. A corollary of this requirement is that the protocol MUST NOT link practices of first party signers with the practices of third party signers. INFORMATIVE NOTE: the main thrust of this requirement is that practices should only be published for that which the publisher has control, and should not meddle in what is ultimately the local policy of the receiver. Refs: Deployment Consideration, Section 4.3. We still haven't gotten over this hump. I had warned backed then this would be a conflict and it was never was resolved. That MUST NOT is still a strong influence, especially among the LSP (List Service Provider) who feel threaten by strong Author Domain policy protocols. Its a fundamental concept that if a DMARC WG was started, it would have to be revisited because if the above concept is still applicable, then I have a hard time seeing any resolution to any of this. -- HLS From nobody Tue Jun 10 05:50:15 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A007E1A0552 for ; Tue, 10 Jun 2014 05:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.102 X-Spam-Level: X-Spam-Status: No, score=-102.102 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, 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 WJw-r1tDgpMQ for ; Tue, 10 Jun 2014 05:50:11 -0700 (PDT) Received: from ftp.catinthebox.net (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 75F8A1A052E for ; Tue, 10 Jun 2014 05:50:08 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4275; t=1402404602; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=HGeVVTBv46Okke5XE3WPYWWPTeE=; b=KNvEHkMAGpAfBjZBT9CP C9sQOocyTkdAx+ZJ1qltyNhCaA+mesOm3BJHzXWJuYJjY4+RzOxIqS4hDoOrAuJ7 8FkZDmkb2/lLB5gGq/nma+VzZWNtY7ILwQA/CgqITTvupe0G1+0LMaTunRbxCV11 29yF4ruBtNTgWotKM+bUdUg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 10 Jun 2014 08:50:02 -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; Received: from beta.winserver.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1884724363.17216.4104; Tue, 10 Jun 2014 08:50:00 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4275; t=1402404433; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=hJlChbB A1jmND3WxIr8A+zFeyXZmRkR3qOh2QFu1IQw=; b=XzF2yl3MmWp234UwJ549G/f GSFMvX0xxKFkDZ0Z1Uq+quVnYQlFQt0wEzM/1EIQuSOt2XmpUHGjbpGSi8kCEZkc EAedhNwKIxXqzmleeOoe153tEty69apgDpWvJsKKS/Lq73R35kRCCZKxQe02MrNh oGZ7v6wPh47y6LvmGuco= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 10 Jun 2014 08:47:13 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1901079906.9.2484; Tue, 10 Jun 2014 08:47:12 -0400 Message-ID: <5396FEF4.6050307@isdg.net> Date: Tue, 10 Jun 2014 08:49:56 -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: Barry Leiba , "Stephen J. Turnbull" References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <87ppihgugl.fsf@uwakimon.sk.tsukuba.ac.jp> <5396A9B4.8000103@gmail.com> <87sindt8z2.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/TVjE2ICtHxqjmT7qqoDi5xT9WkA Cc: Dave Crocker , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 12:50:13 -0000 On 6/10/2014 7:27 AM, Barry Leiba wrote: >> > The premise of your proposal is that users will notice that there's >> > extra information, know what to do with it, and do the right thing, >> > with reasonable consistency. > ... >> > Each of those conditionals will not actually be satisfied. User's >> > tend not to notice such things. The tend not to understand what >> > they mean. Even when they understand, they tend to evaluate >> > choices poorly. They tend to apply choices inconsistently. >> >> Yes, yes, yes, and yes (all modulo "are we letting 'perfect' be the >> enemy of 'better'?" -- you have a *really* dim view of the average >> users' capabilities!) > > I think Dave's dim view is pretty much accurate, though I can't show > that in any concrete way. There are a set of "User Expectations" and the backend has a strong influence on satisfying the "user expectations." The three that the US EPCA molded in 1986 are: - Don't make private mail, public - Don't censor the mail, - Don't tamper the mail. This has been relaxed over the years to a, I kid you not, to the "Good Samaritan" provision which gives the backend more legal indemnifying controls and it make it fit better the existing 150+ year old exceptions provided to the newspaper industry which allows the newspaper editor to alter the "letter to the editor" for "fit to print" reasons. > But the more important point is that you're > presupposing that the changes are "better", and my contention is that > we don't know enough about UI design and user experience to say that. We do. But we are adding so much doubt to it, the promotion is to just pass everything to the user or do all the work at the client side. Thats is the OLD WAY when thats all the mail routers/receivers did, transport, send and receive and did no filtering whatsoever. So what we are battling with is what work and where is the client or server work done? > To people like you and me, it's clear that giving more information -- > and especially such important information as this! -- is better. Not always. System level considerations are a high consideration. Just reject and forget about it. All empirical data tells you that this is very feasible, reliable with an extremely low false positive rate, and for the exceptions, its going to be a hard pain to shallow. The LSP can no longer exist in a wild wild west world of "unrestricted" mail processing. The LSP needs to adjust. Note, I am not trying to change the subject away from the MUA UI. But this will always be a position that end-users, administrators will like to impose that have no control over the system level operations, the MSA, MTA, MDAs, etc. There are MUA considerations for sure, but we need to focus on the DMARC policy issues, or lack of them, that is causing such a high conflict between operations. We can't solve it with MUA stuff. But > that's not really true, and even information that we think is > essential... is actually confusing to non-technical users. +1. > Here I can cite studies; I have one that looked at browser cues such > as the lock symbol, and found that users so misunderstand the lock > symbol that they (1) think a lock symbol on the web page itself is > *better* than one in the browser frame (that's quite backward), (2) > don't know what the lock symbol is telling them *at all*, and have > various cockamamie ideas about what it means, and so on. > > We have to be very careful about such changes, and not assume that we > know what's better. and to add to this, how about satisfying visual impaired requirements? Too much? My first 1980's MUA (Silver Xpress Offline Mail System) was the first to support what I called "Speech Friendly Interface" or SFI that dealt with the MAIL-READY navigation for speech. It supported special on-board cards such as "Vocal Eyes" and "Windows Eyes" (https://www.gwmicro.com/Catalog/Window-Eyes/) Visual cues needs to be translated to speech signals too. Today, there are current W3C proposed standards/methods (web-base, CSS, etc) to satisfy "SFI" requirements. Quick reference before I have to leave for now.... http://www.w3.org/standards/webdesign/accessibility -- HLS From nobody Tue Jun 10 06:33:23 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FB71A0103 for ; Tue, 10 Jun 2014 06:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 rqZkcLWaJueL for ; Tue, 10 Jun 2014 06:33:18 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8841A00ED for ; Tue, 10 Jun 2014 06:33:17 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id DBAC23FA0158; Tue, 10 Jun 2014 22:33:16 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id CC1CF1A32C5; Tue, 10 Jun 2014 22:33:16 +0900 (JST) From: "Stephen J. Turnbull" To: Barry Leiba In-Reply-To: References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <87ppihgugl.fsf@uwakimon.sk.tsukuba.ac.jp> <5396A9B4.8000103@gmail.com> <87sindt8z2.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 10 Jun 2014 22:33:16 +0900 Message-ID: <874mzsrisj.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/XbRuWRL-tvJzSMtJ3JIdXEl6MKs Cc: Dave Crocker , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 13:33:20 -0000 Barry Leiba writes: > But the more important point is that you're presupposing that the > changes are "better", Yes and no. Obviously, if it is impossible to improve the MUAs, there's no point in discussing it. In that sense, I have to presume that improvements exist. That doesn't mean I assume I know what they are, or that any of the examples I gave are better. On the Mailman lists today, one postmaster posted that he is observing a surge in AOL-spoofing phishing this week, with AOL screen names in the display name and some other address as the actual From: mailbox. The abusers seem to have access to contact lists, as often the addressee is acquainted with the AOL screen name. I don't see how DMARC can help deal with that -- unless it cooperates with the MUA. Although writing MUAs is not what this list is about, I think we *should* think about what information we *can* make available to the MUA that may be useful in addressing such attacks, ask the MUA authors what information they could use, and write protocols that make useful authentication information available to the MUAs conveniently, to present to the users in appropriate ways as the MUA devs see it. > We have to be very careful about such changes, *We* can't make any changes in the MUAs, and there are few, if any, MUA devs here to be misled by our mistakes. Such speculation may be a waste of our time, but no worse than that. > and not assume that we know what's better. I don't. From nobody Tue Jun 10 06:48:01 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF151A0111 for ; Tue, 10 Jun 2014 06:48:00 -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 j2XHl59si5xk for ; Tue, 10 Jun 2014 06:47:58 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 730831A0046 for ; Tue, 10 Jun 2014 06:47:58 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id p10so5376078wes.37 for ; Tue, 10 Jun 2014 06:47: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=OJ+CfqnrWEPBobsgtQPFIjGitBU0NdQW4FrX+hhJ4Ko=; b=JGEwPf6rHTTDCEPWfuwW3XDjPSXjf3zqmfPSUuR0Wzwe/JbzYc1lZx+OApQditG9H+ AF+YYHNpxxqDcJ5S1cAd2eaXj4a0JX5/ydvv7P+FkhniGiFfWta4mhWd4r91ZZhL50v9 akLXGlGnW005xGBWSHDF2C3qv5YQDA2CkYr1br9UPlw7A3vseViCZ17NGtMmbtSgIwAP 5Hn9PCEFpVqVUBLOKMLZlYT3n8ElwC5DhMrHBWySe7whih5RmjSjMLePJJ7X4TMaEqMB /ZKyLAslOTqOyxM66is0UDMH0KJrZK2+3j97FRREgh2Dgh3u1PovohVEhoDosZOkk0s2 IH5Q== MIME-Version: 1.0 X-Received: by 10.180.75.212 with SMTP id e20mr12693092wiw.5.1402408077028; Tue, 10 Jun 2014 06:47:57 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Tue, 10 Jun 2014 06:47:56 -0700 (PDT) In-Reply-To: <1755889339.33315.1402383131643.JavaMail.zimbra@peachymango.org> References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <5392ECED.5010404@gmail.com> <1755889339.33315.1402383131643.JavaMail.zimbra@peachymango.org> Date: Tue, 10 Jun 2014 06:47:56 -0700 Message-ID: From: "Murray S. Kucherawy" To: Franck Martin Content-Type: multipart/alternative; boundary=f46d043890a542f36404fb7b93d0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/1BB1kClckwaHPLYvo0Gg_kcqHpU Cc: Dave Crocker , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 10 Jun 2014 13:48:00 -0000 --f46d043890a542f36404fb7b93d0 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 9, 2014 at 11:52 PM, Franck Martin wrote: > This is interesting, however it seems to me that DMARC should be more > aware of it if used. > Why? This is a way of satisfying the alignment requirement on the DKIM side. DMARC doesn't need to know it's there. The same is true of ATPS, for example. > I would suggest to sign with a sub domain. This would keep alignement, but > would allow you to see which DKIM signature worked. Once both DKIM > signature work, you would not need the delegated one. > What would make both start working again? The problem we're trying to solve here is that the originator signature is broken by the list, and that's a (theoretically) immutable condition. > I think DMARC should be made aware, so that it apply some constraints on > when this signature is used/valid. May be only when there is a List-ID or > List-Post header present, and the list has DKIM signed the whole message > with its domain. > Anyone can add a List-ID or List-Post header field, so I don't think that adds any additional security. > It would require MLM to not drop DKIM headers... Still some configuration > on MLM side, but less in the way messages are modified > That's a much less visible and thus probably more tolerable change for MLM operators. -MSK --f46d043890a542f36404fb7b93d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 9, 2014 at 11:52 PM, Franck Martin <fr= anck@peachymango.org> wrote:
This is interesting, however it seems to me = that DMARC should be more aware of it if used.

Why?=C2=A0 This is a way of satisfying the alignment requirement on th= e DKIM side.=C2=A0 DMARC doesn't need to know it's there.=C2=A0 The= same is true of ATPS, for example.
=C2=A0
I would suggest to sign with a sub domain. This would keep alignement, but = would allow you to see which DKIM signature worked. Once both DKIM signatur= e work, you would not need the delegated one.

What would make both start working again?=C2=A0 The problem we&#= 39;re trying to solve here is that the originator signature is broken by th= e list, and that's a (theoretically) immutable condition.
=C2=A0
I think DMARC should be made aware, so that it apply some constraints on wh= en this signature is used/valid. May be only when there is a List-ID or Lis= t-Post header present, and the list has DKIM signed the whole message with = its domain.

Anyone can add a List-ID or List-Post head= er field, so I don't think that adds any additional security.
=C2=A0=
It would require MLM to not drop DKIM headers... Still some configuration o= n MLM side, but less in the way messages are modified
=
That's a much less visible and thus probably more tolera= ble change for MLM operators.

-MSK
--f46d043890a542f36404fb7b93d0-- From nobody Tue Jun 10 06:50:05 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 150E41A0141 for ; Tue, 10 Jun 2014 06:49:59 -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 55dLY3HzfmC4 for ; Tue, 10 Jun 2014 06:49:56 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CF5F1A011E for ; Tue, 10 Jun 2014 06:49:56 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id l18so1547971wgh.16 for ; Tue, 10 Jun 2014 06:49: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=7nyEgT3XanrjGno9ekUhW4HS4PJtC//9cLcvGy16mBg=; b=KtBj7Xfb7U9xkV0K5DOhsAntHNGB2v0VRZjkAqiVunh4h16NbsJo8Mt0mtXAt6BZ1Y ilY7aRGJp+c886iiOZCNnutjGQMxCM8pvO1MQMnjA3d3yMzsa/p42m53t7iEt/l/OyzW W4ZX/WVUdMpMutUgexStybCG4ZXRUa200bm1kXxRufgJ7ZFv9Q96r4NQrjjKfgkB7XUO /rnduIR6hTLwSPk/VOBsGrzDzTpKt9yFAcqFF125NIY54LNlSYniFC/epJyqsv6USI+w LLPswab1ZfzdH2gRrvXyeFHGpMaZyx7f+Wqf7zPIQUh4g4ZHpWBf282KMsBc7jIbA6h1 jhtw== MIME-Version: 1.0 X-Received: by 10.180.212.77 with SMTP id ni13mr40510476wic.5.1402408193733; Tue, 10 Jun 2014 06:49:53 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Tue, 10 Jun 2014 06:49:53 -0700 (PDT) In-Reply-To: <1402385033.97400.YahooMailNeo@web164602.mail.gq1.yahoo.com> References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <5392ECED.5010404@gmail.com> <1755889339.33315.1402383131643.JavaMail.zimbra@peachymango.org> <1402385033.97400.YahooMailNeo@web164602.mail.gq1.yahoo.com> Date: Tue, 10 Jun 2014 06:49:53 -0700 Message-ID: From: "Murray S. Kucherawy" To: Vlatko Salaj Content-Type: multipart/alternative; boundary=001a11c23e5a37b9eb04fb7b9ad9 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/H56BqXzJXfMsVS44Zim1IeIWhV0 Cc: Dave Crocker , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 10 Jun 2014 13:49:59 -0000 --001a11c23e5a37b9eb04fb7b9ad9 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 10, 2014 at 12:23 AM, Vlatko Salaj wrote: > DKIM-Delegate suffers from replay attacks, and when not, > introduces whitelisting which, kind of, breaks its premise. > DKIM is already replayable. I don't see how this introduces whitelisting requirements. > also, we need a solution that doesn't risk of being modified > by any middle man on message path. DKIM can't offer that, > and will never be able to. > Yes, that is a risk. That's why a short-lived signature is used with other tight requirements. The risk might be a tolerable one for this application. -MSK --001a11c23e5a37b9eb04fb7b9ad9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 10, 2014 at 12:23 AM, Vlatko Salaj <v= latko.salaj@goodone.tk> wrote:
=
DKIM-Delegate suffers from replay attacks, a= nd when not,
introduces whitelisting which, kind of, breaks its premise.

DKIM is already replayable.

I don= 9;t see how this introduces whitelisting requirements.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> also, we need a solution that doesn't risk of being modified
by any middle man on message path. DKIM can't offer that,
and will never be able to.

Yes, that is= a risk.=C2=A0 That's why a short-lived signature is used with other ti= ght requirements.=C2=A0 The risk might be a tolerable one for this applicat= ion.

-MSK
--001a11c23e5a37b9eb04fb7b9ad9-- From nobody Tue Jun 10 06:55:53 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 536AB1A0141 for ; Tue, 10 Jun 2014 06:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 AJ6k3QdwhDAr for ; Tue, 10 Jun 2014 06:55:49 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 97CBD1A011F for ; Tue, 10 Jun 2014 06:55:49 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 0D9763FA0158; Tue, 10 Jun 2014 22:55:49 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 0026011F0DC; Tue, 10 Jun 2014 22:55:48 +0900 (JST) From: "Stephen J. Turnbull" To: Hector Santos In-Reply-To: <5396E49C.2000808@isdg.net> References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <87ppihgugl.fsf@uwakimon.sk.tsukuba.ac.jp> <5396E49C.2000808@isdg.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 10 Jun 2014 22:55:48 +0900 Message-ID: <8738fcrhqz.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Wecl1ZtfjO8mToD4noRajEeZemw Cc: "dmarc@ietf.org" , Matt Simerson , "Murray S. Kucherawy" , "J. Gomez" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 13:55:51 -0000 Hector Santos writes: > Are you oppose to any other domain using strong policies or just > certain ones? Domains where users have until now felt free to use their mailboxes as they see fit (posting to mailing lists, as From: in on-behalf-of services, etc) should not suddenly impose "p=reject" IMO. > You didn't answer the question in another post regarding if you are > even ready or support the idea of even doing a DNS lookup to find > out what a domain's policy is? I have stated several times that I have no quarrel with DMARC as is, that I think it is a good protocol overall, and that in particular "p=reject" is useful in "transactional" contexts. It is a logical consequence that I support the idea of a lookup to discover policy. > It is more easier, more feasible, more safe, to just reject/discard > the failed message (due to policy) at the backend and be done with it. In your opinion. In my experience, many postmasters resist that policy. > Do you realize how many different MUAs exist? and the different forms > of MUAs? I haven't counted. How many are there? > Why pass the buck to the user when the backend can deal with this > and its works for all MUAs!! Because the backend can't deal with it, except by imposing draconian policies that I know many sysadmins really want to avoid. From nobody Tue Jun 10 06:58:25 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD5471A0144 for ; Tue, 10 Jun 2014 06:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 qDNjDLLCRsjO for ; Tue, 10 Jun 2014 06:58:22 -0700 (PDT) Received: from smtp-4.01.com (adminr.01.com [162.209.88.187]) by ietfa.amsl.com (Postfix) with ESMTP id 37D791A0141 for ; Tue, 10 Jun 2014 06:58:22 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [192.254.77.197]) by smtp-4.01.com (Postfix) with ESMTP id 409BC4C7FC; Tue, 10 Jun 2014 08:58:19 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 0F5FA6023D; Tue, 10 Jun 2014 08:58:19 -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 55e9TXD1ohS4; Tue, 10 Jun 2014 08:58:18 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id E30B1601F7; Tue, 10 Jun 2014 08:58:18 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id D46E960236; Tue, 10 Jun 2014 08:58:18 -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 wjnghnxfJqdV; Tue, 10 Jun 2014 08:58:18 -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 B795C60237; Tue, 10 Jun 2014 08:58:18 -0500 (CDT) Date: Tue, 10 Jun 2014 08:58:18 -0500 (CDT) From: Franck Martin To: "Murray S. Kucherawy" Message-ID: <1019546957.39246.1402408698423.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <5392ECED.5010404@gmail.com> <1755889339.33315.1402383131643.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_39245_1990766631.1402408698423" X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF29 (Mac)/8.0.5_GA_5839) Thread-Topic: New Version Notification for draft-kucherawy-dkim-delegate-00.txt Thread-Index: zNDh+CfnI7XFP7/ErxX126IGrNhHUg== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/B8lAen_Y35v9EHac4WXF9b1Z1_8 Cc: Dave Crocker , dmarc@ietf.org Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 10 Jun 2014 13:58:23 -0000 ------=_Part_39245_1990766631.1402408698423 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Murray S. Kucherawy" > To: "Franck Martin" > Cc: "Dave Crocker" , dmarc@ietf.org > Sent: Tuesday, June 10, 2014 3:47:56 PM > Subject: Re: [dmarc-ietf] Fwd: New Version Notification for > draft-kucherawy-dkim-delegate-00.txt > On Mon, Jun 9, 2014 at 11:52 PM, Franck Martin < franck@peachymango.org > > wrote: > > This is interesting, however it seems to me that DMARC should be more aware > > of it if used. > > Why? This is a way of satisfying the alignment requirement on the DKIM side. > DMARC doesn't need to know it's there. The same is true of ATPS, for > example. Sure but you have a strong DKIM signature and a weak DKIM signature, using about the same domain, it is like the strong DKIM signature did not exist... ------=_Part_39245_1990766631.1402408698423 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: "Franck Martin" <franck@peachymango.org>
Cc: "Dave Crocker" <dcrocker@gmail.com>, dmarc@ietf.org
Sent: Tuesday, June 10, 2014 3:47:56 PM
Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt

On Mon, Jun 9, 2014 at 11:52 PM, Franck Martin <franck@peachymango.org> wrote:
This is interesting, however it seems to me that DMARC should be more aware of it if used.

Why?  This is a way of satisfying the alignment requirement on the DKIM side.  DMARC doesn't need to know it's there.  The same is true of ATPS, for example.
 
Sure but you have a strong DKIM signature and a weak DKIM signature, using about the same domain, it is like the strong DKIM signature did not exist...
------=_Part_39245_1990766631.1402408698423-- From nobody Tue Jun 10 07:00:47 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB75A1A016E for ; Tue, 10 Jun 2014 07:00:45 -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 UrBegTQarJkY for ; Tue, 10 Jun 2014 07:00:44 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A2EC1A0155 for ; Tue, 10 Jun 2014 07:00:44 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id hi2so3941576wib.1 for ; Tue, 10 Jun 2014 07:00: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=dZNMhDmbV5yHoBoQP46Wf+W04FoNnXZk4IEIM3nqUrA=; b=ZGBHo3MhbjikLidpMYx72bvCrmhx0XaqZL4X6jCYKOD2swscWV0QNDGFvB2FLbVxh/ 1Us14bXjs9/cfVEN/apUe837cPpYthvq87pQD7LpDjbAoaSS1gIsT0NFuYLKKVvQIvgC FPU8k3CBZb6I+7hZ5Q7p4vF0wa/b7gqEU4x28dh9Jgk/T1ukUVMS/C9jklUVODEgq5wR mvicUR8izkt1M7EBywpApK93bw7lSo4MNyQ5AI85Q5zUXUnimb5zT0OaU/euYcHqmUmV PkVnbrh/qQOw/5gjoPVZ2iu8ytCOT8brKaaiIvdkr1f3MDPFQY4en1O6m9Jvycdqqbph k+1A== MIME-Version: 1.0 X-Received: by 10.180.94.163 with SMTP id dd3mr38179825wib.26.1402408841355; Tue, 10 Jun 2014 07:00:41 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Tue, 10 Jun 2014 07:00:41 -0700 (PDT) In-Reply-To: <1402386096.27670.YahooMailNeo@web164604.mail.gq1.yahoo.com> References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <1402382240.57323.YahooMailNeo@web164601.mail.gq1.yahoo.com> <5396AA73.8040109@gmail.com> <1402384311.51951.YahooMailNeo@web164603.mail.gq1.yahoo.com> <5396B0E9.9010109@gmail.com> <1402386096.27670.YahooMailNeo@web164604.mail.gq1.yahoo.com> Date: Tue, 10 Jun 2014 07:00:41 -0700 Message-ID: From: "Murray S. Kucherawy" To: Vlatko Salaj Content-Type: multipart/alternative; boundary=f46d04462e5ed1ae1b04fb7bc0e6 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/rS2xVfHvCJmPe-FrNEmKFQYhwqQ Cc: Dave Crocker , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 14:00:46 -0000 --f46d04462e5ed1ae1b04fb7bc0e6 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 10, 2014 at 12:41 AM, Vlatko Salaj wrote: > "introducing new ML requirements" has already been > characterised as not an ML solution. we have a few > of them already, and all much simpler than any YADAs. > The person on this list that actually represents a mailing list so far seems to like the idea, and has explained why to some extent. I think that's much more valuable feedback. A proposal like this one might introduce new requirements, sure, but if they solve a huge problem and people are willing to implement it, then so what? They're worth the work in that case. My understanding of the constraint is that we need to avoid new requirements that affect common mailing list practices, like footers and Subject field tagging. DKIM-Delegate establishes a requirement that mailing lists sign the modified message in full. In a lot of cases, list software does that already; often it's the case that other software even does that for them, so how much of a burden is this really? The burden is actually on signers (who need to add DKIM-Delegate fields) and on verifiers (who need to look for them and know what to do with them), not on the lists themselves. Or do you mean something else when you say "new ML requirements"? > An example of why postings like you've > > sent are unhelpful is that it implicitly > > invites others to offer summarily-dismissive > > notes about your notes. > Speaking personally, I usually ignore the summarily-dismissive notes because I don't learn anything from them. The more well-developed criticisms are the valuable ones. > there's also nothing productive in *personal* thinking > that DKIM is a holy grail of authorization, > and based on that *personal* motivation, sponging endless > YADAs [aka yet another DKIM addons], wasting urs > and our time in process. > This is drifting toward the ad hominem again. Careful, please. -MSK --f46d04462e5ed1ae1b04fb7bc0e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 10, 2014 at 12:41 AM, Vlatko Salaj <v= latko.salaj@goodone.tk> wrote:
=
"introducing new ML requirements" = has already been
characterised as not an ML solution. we have a few
of them already, and all much simpler than any YADAs.

The person on this list that actually repr= esents a mailing list so far seems to like the idea, and has explained why = to some extent.=C2=A0 I think that's much more valuable feedback.
A proposal like this one might introduce new requirements, sure,= but if they solve a huge problem and people are willing to implement it, t= hen so what?=C2=A0 They're worth the work in that case.

My understanding of the constraint is that we need to avoid new requirement= s that affect common mailing list practices, like footers and Subject field= tagging.=C2=A0 DKIM-Delegate establishes a requirement that mailing lists = sign the modified message in full.=C2=A0 In a lot of cases, list software d= oes that already; often it's the case that other software even does tha= t for them, so how much of a burden is this really?

The burden is actually on signers (who need to add DKIM-Dele= gate fields) and on verifiers (who need to look for them and know what to d= o with them), not on the lists themselves.

Or do you mean something = else when you say "new ML requirements"?

> An example of why postings like you've
> sent are unhelpful is that it implicitly
> invites others to offer summarily-dismissive
> notes about your notes.

Spea= king personally, I usually ignore the summarily-dismissive notes because I = don't learn anything from them.=C2=A0 The more well-developed criticism= s are the valuable ones.
=C2=A0
there's also noth= ing productive in *personal* thinking
that DKIM is a holy grail of authorization,
and based on that *personal* motivation, sponging endless
YADAs [aka yet another DKIM addons], wasting urs
and our time in process.

This is drifti= ng toward the ad hominem again.=C2=A0 Careful, please.

-M= SK
--f46d04462e5ed1ae1b04fb7bc0e6-- From nobody Tue Jun 10 07:02:25 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBC01A011C for ; Tue, 10 Jun 2014 07:02:24 -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 fEmVwn8Z2OPJ for ; Tue, 10 Jun 2014 07:02:21 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F080A1A011F for ; Tue, 10 Jun 2014 07:02:20 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id rd3so739124pab.30 for ; Tue, 10 Jun 2014 07:02:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=2K/o68aeXlsJgeGYysPi74/ij+0bC34OAD5+mCvd7+c=; b=o+UCICDXDYq8Y9aJ72k3QVQ+ENiOpYqC7KHhN/zCgbejQvPu009wkPf92UENZX4BY0 MkBlhGqJhWkHds3UZ/1UHyLYfRK8A+OvZuUz6IpxpAMhM/abvl3G8gparIlG7WJT5Kar ivJBPvNdV5oH9cwcZr5u+09KpIXeW88w2gePkYHUbYxuaWurCtDJJoFyddzmDH9tHNn0 UEfXFmPO2DtDOrMNy/T2RJQA+JY2gGnK2uc/QWrv9oF1fMP1OG6b9mPZB27GR5adWVNJ +sVcSms3RTSHM2I6yK4Xje8WMADXsJhGSyIR72nlhGEm+JuIZwO0sV8KQVVpVSuCiCF4 75Jw== X-Received: by 10.66.145.233 with SMTP id sx9mr5490136pab.151.1402408940610; Tue, 10 Jun 2014 07:02:20 -0700 (PDT) Received: from [192.168.2.249] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id y2sm13599782pas.45.2014.06.10.07.02.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Jun 2014 07:02:19 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_DBBE3675-876A-4093-95B5-B7CC4DABC772" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: Date: Tue, 10 Jun 2014 15:02:13 +0100 Message-Id: References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <5392ECED.5010404@gmail.com> <1755889339.33315.1402383131643.JavaMail.zimbra@peachymango.org> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ETPct7Ro9WF-5x1W__hC7zRURm4 Cc: Dave Crocker , "dmarc@ietf.org" , Franck Martin Subject: Re: [dmarc-ietf] New Version Notification for draft-kucherawy-dkim-delegate-00.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, 10 Jun 2014 14:02:24 -0000 --Apple-Mail=_DBBE3675-876A-4093-95B5-B7CC4DABC772 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 10, 2014, at 2:47 PM, Murray S. Kucherawy = wrote: > On Mon, Jun 9, 2014 at 11:52 PM, Franck Martin = wrote: > This is interesting, however it seems to me that DMARC should be more = aware of it if used. >=20 > Why? This is a way of satisfying the alignment requirement on the = DKIM side. DMARC doesn't need to know it's there. The same is true of = ATPS, for example. > =20 > I would suggest to sign with a sub domain. This would keep alignement, = but would allow you to see which DKIM signature worked. Once both DKIM = signature work, you would not need the delegated one. >=20 > What would make both start working again? The problem we're trying to = solve here is that the originator signature is broken by the list, and = that's a (theoretically) immutable condition. > =20 > I think DMARC should be made aware, so that it apply some constraints = on when this signature is used/valid. May be only when there is a = List-ID or List-Post header present, and the list has DKIM signed the = whole message with its domain. >=20 > Anyone can add a List-ID or List-Post header field, so I don't think = that adds any additional security. > =20 > It would require MLM to not drop DKIM headers... Still some = configuration on MLM side, but less in the way messages are modified >=20 > That's a much less visible and thus probably more tolerable change for = MLM operators. Dear Murray, It would be helpful to reference TPA-Label instead of ATPS. ATPS can = never be deployed. While List-ID will not in itself confirm the message = source, when used as condition for authorization will help ensure = recipients can use this header to sort messages. I am about to update = this draft to help clarify why the TPA-Label approach is still better = than several of the other quick fixes being suggested. Regards, Douglas Otis --Apple-Mail=_DBBE3675-876A-4093-95B5-B7CC4DABC772 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Jun 10, 2014, at 2:47 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:

On Mon, Jun 9, 2014 at 11:52 PM, Franck Martin <franck@peachymango.org> wrote:
This is interesting, however it seems to me that DMARC should be more aware of it if used.

Why?  This is a way of satisfying the alignment requirement on the DKIM side.  DMARC doesn't need to know it's there.  The same is true of ATPS, for example.
 
I would suggest to sign with a sub domain. This would keep alignement, but would allow you to see which DKIM signature worked. Once both DKIM signature work, you would not need the delegated one.

What would make both start working again?  The problem we're trying to solve here is that the originator signature is broken by the list, and that's a (theoretically) immutable condition.
 
I think DMARC should be made aware, so that it apply some constraints on when this signature is used/valid. May be only when there is a List-ID or List-Post header present, and the list has DKIM signed the whole message with its domain.

Anyone can add a List-ID or List-Post header field, so I don't think that adds any additional security.
 
It would require MLM to not drop DKIM headers... Still some configuration on MLM side, but less in the way messages are modified

That's a much less visible and thus probably more tolerable change for MLM operators.

Dear Murray,

It would be helpful to reference TPA-Label instead of ATPS.  ATPS can never be deployed.  While List-ID will not in itself confirm the message source, when used as condition for authorization will help ensure recipients can use this header to sort messages.  I am about to update this draft to help clarify why the TPA-Label approach is still better than several of the other quick fixes being suggested.

Regards,
Douglas Otis

--Apple-Mail=_DBBE3675-876A-4093-95B5-B7CC4DABC772-- From nobody Tue Jun 10 07:03:27 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447DE1A011C for ; Tue, 10 Jun 2014 07:03:23 -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 umxRdtbBPM4M for ; Tue, 10 Jun 2014 07:03:21 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E0881A016E for ; Tue, 10 Jun 2014 07:03:18 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id cc10so1708806wib.5 for ; Tue, 10 Jun 2014 07:03: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=tTp3NJtRryIfJkuI/yBNhZZVhPN6MzRpHi9ZF9RuxUM=; b=GUEbzDYZ7kqaCRqVmWMVF2z31WIsOeS78L0eR1dmeFtDfe6njuU4/M0xvtk8r8Ln7M RBKD8g2SEoqFQxljIX7S2PmfqUki+dEo/IO+iRLZvrCAzAFlgZh4uKUSKYskR1EKVcK3 KLgjdWYYzG85mZq6PFNVIzHGgOFmr3ixDFeIzL+JLgfbwQAowxFbHWOPytANP024ELDf lWOizfePgaxHNi4RCixk58/vgfAwAqj0xWU/NqAhfez/8wQfeba+J10cxNuXJEU7tqJt szE8fqTnjJwJhjMvdKuyMpiWDksMp+5eFlJq6PQzONwYoAtvYGcHAfMZyFHULWW964VN /h4A== MIME-Version: 1.0 X-Received: by 10.180.94.163 with SMTP id dd3mr38202029wib.26.1402408997088; Tue, 10 Jun 2014 07:03:17 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Tue, 10 Jun 2014 07:03:16 -0700 (PDT) In-Reply-To: <1019546957.39246.1402408698423.JavaMail.zimbra@peachymango.org> References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <5392ECED.5010404@gmail.com> <1755889339.33315.1402383131643.JavaMail.zimbra@peachymango.org> <1019546957.39246.1402408698423.JavaMail.zimbra@peachymango.org> Date: Tue, 10 Jun 2014 07:03:16 -0700 Message-ID: From: "Murray S. Kucherawy" To: Franck Martin Content-Type: multipart/alternative; boundary=f46d04462e5e1abd8404fb7bca91 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/hLC2OJ-Daom3imT22ihsAboSBiU Cc: Dave Crocker , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 10 Jun 2014 14:03:24 -0000 --f46d04462e5e1abd8404fb7bca91 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 10, 2014 at 6:58 AM, Franck Martin wrote: > ------------------------------ > > On Mon, Jun 9, 2014 at 11:52 PM, Franck Martin > wrote: > >> This is interesting, however it seems to me that DMARC should be more >> aware of it if used. >> > > Why? This is a way of satisfying the alignment requirement on the DKIM > side. DMARC doesn't need to know it's there. The same is true of ATPS, > for example. > > > Sure but you have a strong DKIM signature and a weak DKIM signature, using > about the same domain, it is like the strong DKIM signature did not > exist... > Assuming by "strong DKIM signature" you mean the originator signature that covers the whole message, then given the MLM is going to invalidate it, it basically doesn't exist. -MSK --f46d04462e5e1abd8404fb7bca91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 10, 2014 at 6:58 AM, Franck Martin <fr= anck@peachymango.org> wrote:
On Mon, Jun 9, 2014 at 11:52 PM, Franck Martin <franck@peachymango.or= g> wrote:
This is interesting, however it seems to me = that DMARC should be more aware of it if used.

Why?=C2=A0 This is a way of satisfying the alignment requirement on th= e DKIM side.=C2=A0 DMARC doesn't need to know it's there.=C2=A0 The= same is true of ATPS, for example.
=C2=A0
Sure but you have a strong DKIM signature and a wea= k DKIM signature, using about the same domain, it is like the strong DKIM s= ignature did not exist...

Assuming by "strong DKIM signature&qu= ot; you mean the originator signature that covers the whole message, then g= iven the MLM is going to invalidate it, it basically doesn't exist.

-MSK
--f46d04462e5e1abd8404fb7bca91-- From nobody Tue Jun 10 07:07:16 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 588ED1A0178 for ; Tue, 10 Jun 2014 07:07:14 -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 9C3dgkMHwkdt for ; Tue, 10 Jun 2014 07:07:13 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A6DC1A0177 for ; Tue, 10 Jun 2014 07:07:12 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id f8so6226335wiw.16 for ; Tue, 10 Jun 2014 07:07:11 -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=Jk6IaBDcuVh9+i44ePmEdlzI8oPN9gd9MLJK2dfRLdw=; b=jweuLlWLKtx0G6+Fs+dcoukRaOnrtotavo903k+yCbXZmQ99PmoeWADcGIM+7WAEnm UUEj6Ce4WhuSqubVm3AJca5wweSEqtwlKK+++y/ECKRN3aT77EICk0gFwhOa9fajQfo/ eJzzLR3t4SZaAG198yat3V5Al0SX0Z7qY2hu1jeQqWMZvUlpWQiIGJjpjyc+m0ymIsxG lJ80q/qMfVJcjOSGL7hHmbNpknBoDH8I+oTaVkgYQNaQCTuqqj/D0dgIhEc5JnVUSIFP fJ4Z+oqc4gCAfjAFnLJq8FfoGTSBAaml3dlyTba6zhcv9ggbEVqpj9Qtbq6iEBd3jWfJ egyw== X-Received: by 10.14.209.130 with SMTP id s2mr217746eeo.15.1402409231109; Tue, 10 Jun 2014 07:07:11 -0700 (PDT) Received: from ?IPv6:2001:730:40:4:6978:bcd4:aaed:880b? ([2001:730:40:4:6978:bcd4:aaed:880b]) by mx.google.com with ESMTPSA id v45sm52449062eeg.29.2014.06.10.07.07.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Jun 2014 07:07:10 -0700 (PDT) Message-ID: <539710D5.6070806@gmail.com> Date: Tue, 10 Jun 2014 16:06:13 +0200 From: Dave Crocker 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" , Franck Martin References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <5392ECED.5010404@gmail.com> <1755889339.33315.1402383131643.JavaMail.zimbra@peachymango.org> <1019546957.39246.1402408698423.JavaMail.zimbra@peachymango.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/fyQ3hfuRLOQahn6LbtyR8-yyjLE Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 10 Jun 2014 14:07:14 -0000 On 6/10/2014 4:03 PM, Murray S. Kucherawy wrote: > Assuming by "strong DKIM signature" you mean the originator signature > that covers the whole message, then given the MLM is going to invalidate > it, it basically doesn't exist. If it happens to survive (such as to recpients of the original message who are not on a mailing list, so they get a direct copy) then their DKIM evaluation engine ought to pay attention to the 'strength' of the different signatures. Also note that the weaker signature is enabled by the DKIM-Delegate field, which specifies what intermediaries are tolerated. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jun 10 07:07:36 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922E01A0177 for ; Tue, 10 Jun 2014 07:07:26 -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 wuoLsRE8-Pdp for ; Tue, 10 Jun 2014 07:07:19 -0700 (PDT) Received: from smtp-4.01.com (adminr.01.com [162.209.88.187]) by ietfa.amsl.com (Postfix) with ESMTP id 92B521B27A4 for ; Tue, 10 Jun 2014 07:07:19 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [192.254.77.197]) by smtp-4.01.com (Postfix) with ESMTP id D5FDE4C7F7; Tue, 10 Jun 2014 09:07:16 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id A11B16023D; Tue, 10 Jun 2014 09:07:16 -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 8GjhqhPFbQGW; Tue, 10 Jun 2014 09:07:16 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 7EC5960241; Tue, 10 Jun 2014 09:07:16 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 5CBDC6023D; Tue, 10 Jun 2014 09:07:16 -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 Mwdm-RvjDPbe; Tue, 10 Jun 2014 09:07:16 -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 2242560239; Tue, 10 Jun 2014 09:07:16 -0500 (CDT) Date: Tue, 10 Jun 2014 09:07:15 -0500 (CDT) From: Franck Martin To: "Stephen J. Turnbull" Message-ID: <453779665.39646.1402409235314.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <87ppihgugl.fsf@uwakimon.sk.tsukuba.ac.jp> <5396A9B4.8000103@gmail.com> <87sindt8z2.fsf@uwakimon.sk.tsukuba.ac.jp> <874mzsrisj.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF29 (Mac)/8.0.5_GA_5839) Thread-Topic: Change the mailing list protocol, not DMARC. Thread-Index: o1wmhepRHtQqCngwIBOL/OlVLbcQrw== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Og42gSKK8nDhWtjs57eMpdh6gdc Cc: Dave Crocker , dmarc@ietf.org, Barry Leiba Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 14:07:26 -0000 ----- Original Message ----- > From: "Stephen J. Turnbull" > To: "Barry Leiba" > Cc: "Dave Crocker" , dmarc@ietf.org > Sent: Tuesday, June 10, 2014 3:33:16 PM > Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. > > Barry Leiba writes: > > > But the more important point is that you're presupposing that the > > changes are "better", > > Yes and no. Obviously, if it is impossible to improve the MUAs, > there's no point in discussing it. In that sense, I have to presume > that improvements exist. That doesn't mean I assume I know what they > are, or that any of the examples I gave are better. > > On the Mailman lists today, one postmaster posted that he is observing > a surge in AOL-spoofing phishing this week, with AOL screen names in > the display name and some other address as the actual From: mailbox. > The abusers seem to have access to contact lists, as often the > addressee is acquainted with the AOL screen name. I don't see how > DMARC can help deal with that -- unless it cooperates with the MUA. > We know that the display name abuse is something that need to be tackled. We should not recommend to put anything that looks like a domain name in the display part, cause eventually we will put a rule to dump emails with such property. I think also, MTA have become more strict, they know expect one and one only From header, with a Date header, and a few extra... to follow more strictly the RFCs. DMARC do not talk about invalid messages, because they should not even make it to DMARC evaluation in the first instance. From nobody Tue Jun 10 07:10:07 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A50A1A018D for ; Tue, 10 Jun 2014 07:10:03 -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 H1DRB9nLSjJD for ; Tue, 10 Jun 2014 07:09:59 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 084791A0162 for ; Tue, 10 Jun 2014 07:09:58 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id n15so3170767wiw.4 for ; Tue, 10 Jun 2014 07:09:56 -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=CiORHx/vGFgFmZPwZ/IU5WFtuJmUnK8j8y8jmiMbZeQ=; b=0qo9oNW7hTyAjhVZGLpdLKPz7wo7rxPSDbH7NWojn5x2rLnbowfMkAsAMmnhwaYcTG eOeyXkrhLg+FfYuYnbRi+tOLRExsuVGz5MwkI1Zys0670Vsj9CYOq8olNz2GOnGJaj7m 8ou7cACvcubX/b3SY4oGQpFT3pGs3MyKdr8CjwpOHwC/Gb4mYcSw9mjC4kIZnsAwLll5 zPL1FLBOEWPQSGdJo3EeoowRtMHoKwlhUF6/mTk5HwgB12aAlvCgXJn29DbntbDM8nQK huxFVR0wb7lGybo5d/8onQCAkYn+5pXnr42tJ+RJ8ZknQi4Kmo/vawmznbiyfsQSNM7U 3TRQ== X-Received: by 10.14.113.136 with SMTP id a8mr4619142eeh.0.1402409395906; Tue, 10 Jun 2014 07:09:55 -0700 (PDT) Received: from ?IPv6:2001:730:40:4:6978:bcd4:aaed:880b? ([2001:730:40:4:6978:bcd4:aaed:880b]) by mx.google.com with ESMTPSA id m2sm52463333eey.36.2014.06.10.07.09.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Jun 2014 07:09:54 -0700 (PDT) Message-ID: <53971178.8020301@gmail.com> Date: Tue, 10 Jun 2014 16:08:56 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Stephen J. Turnbull" References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <87ppihgugl.fsf@uwakimon.sk.tsukuba.ac.jp> <5396A9B4.8000103@gmail.com> <87sindt8z2.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87sindt8z2.fsf@uwakimon.sk.tsukuba.ac.jp> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/M5r8IDnMj1Ujfnfxq85DNFbhW7U Cc: "dmarc@ietf.org" , Matt Simerson , "J. Gomez" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 14:10:03 -0000 On 6/10/2014 11:22 AM, Stephen J. Turnbull wrote: > Dave Crocker writes: > > Everything gets much easier if we specify guidance for filtering > > engines, before humans come into the picture. > > But now you are assuming filters that are very close to 100% accurate! No. I am assuming that working with filtering engines is better than trying to work with 1-3 billion end users. There is quite a good track record of working with filtering engines. There is quite a poor track record of working with end users. > Do you really think we can get there? We are already there. SPF and DKIM and DMARC are examples of working with the filtering engine. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jun 10 07:13:28 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7AC1A0177 for ; Tue, 10 Jun 2014 07:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 2_bb0RqwtOn7 for ; Tue, 10 Jun 2014 07:13:22 -0700 (PDT) Received: from smtp-4.01.com (adminr.01.com [162.209.88.187]) by ietfa.amsl.com (Postfix) with ESMTP id B504D1A0162 for ; Tue, 10 Jun 2014 07:13:22 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [192.254.77.197]) by smtp-4.01.com (Postfix) with ESMTP id 6EDAF4C838; Tue, 10 Jun 2014 09:13:22 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 3DCB5A039C; Tue, 10 Jun 2014 09:13: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 10024) with ESMTP id yhaFYmqz5rGV; Tue, 10 Jun 2014 09:13:22 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 18A5EA03A2; Tue, 10 Jun 2014 09:13:22 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 02A18A03A0; Tue, 10 Jun 2014 09:13: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 qcmHE6997cbB; Tue, 10 Jun 2014 09:13:21 -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 D8726A039C; Tue, 10 Jun 2014 09:13:21 -0500 (CDT) Date: Tue, 10 Jun 2014 09:13:19 -0500 (CDT) From: Franck Martin To: "Murray S. Kucherawy" Message-ID: <699367420.39896.1402409599837.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <1755889339.33315.1402383131643.JavaMail.zimbra@peachymango.org> <1019546957.39246.1402408698423.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_39895_739337166.1402409599836" X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF29 (Mac)/8.0.5_GA_5839) Thread-Topic: New Version Notification for draft-kucherawy-dkim-delegate-00.txt Thread-Index: mviImkSp3L32yF2INk9Gs1cRr/yUEA== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/9xVmY0BJ56lTGFsCG22_vjLEfx4 Cc: Dave Crocker , dmarc@ietf.org Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 10 Jun 2014 14:13:25 -0000 ------=_Part_39895_739337166.1402409599836 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message ----- > From: "Murray S. Kucherawy" > To: "Franck Martin" > Cc: "Dave Crocker" , dmarc@ietf.org > Sent: Tuesday, June 10, 2014 4:03:16 PM > Subject: Re: [dmarc-ietf] Fwd: New Version Notification for > draft-kucherawy-dkim-delegate-00.txt > On Tue, Jun 10, 2014 at 6:58 AM, Franck Martin < franck@peachymango.org > > wrote: > > > On Mon, Jun 9, 2014 at 11:52 PM, Franck Martin < franck@peachymango.org > > > > wrote: > > > > > > > This is interesting, however it seems to me that DMARC should be more > > > > aware > > > > of it if used. > > > > > > > > > Why? This is a way of satisfying the alignment requirement on the DKIM > > > side. > > > DMARC doesn't need to know it's there. The same is true of ATPS, for > > > example. > > > > > Sure but you have a strong DKIM signature and a weak DKIM signature, using > > about the same domain, it is like the strong DKIM signature did not > > exist... > > Assuming by "strong DKIM signature" you mean the originator signature that > covers the whole message, then given the MLM is going to invalidate it, it > basically doesn't exist. Yes but are you assuming you only put the weak DKIM signature, when you specifically know you are emailing a mailing list? Or what about a receiver which is not a mailing list? You are just allowing better replay of the message, if you put any weak DKIM signature in the message... Unless the weak DKIM signature is constrained to a specific usage. ------=_Part_39895_739337166.1402409599836 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
From: "Murray S. Kucherawy" <superuser@= gmail.com>
To: "Franck Martin" <franck@peachymango.org><= br>Cc: "Dave Crocker" <dcrocker@gmail.com>, dmarc@ietf.org
= Sent: Tuesday, June 10, 2014 4:03:16 PM
Subject: Re: [dmar= c-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.= txt

On Tue, Jun 10, 2014 at 6:58 AM, Fra= nck Martin <franck@peachymango.org> wrote:
On Mon, Jun 9, 2014 at 11:52 PM, Franck Martin <franck@peachymango.or= g> wrote:
This = is interesting, however it seems to me that DMARC should be more aware of i= t if used.

Why?  This is a way of = satisfying the alignment requirement on the DKIM side.  DMARC doesn't = need to know it's there.  The same is true of ATPS, for example.
Sure but you have a stron= g DKIM signature and a weak DKIM signature, using about the same domain, it= is like the strong DKIM signature did not exist...
<= /blockquote>

Assuming by "strong = DKIM signature" you mean the originator signature that covers the whole mes= sage, then given the MLM is going to invalidate it, it basically doesn't ex= ist.

Yes but are you assuming you only= put the weak DKIM signature, when you specifically know you are emailing a= mailing list?

Or what about a receiver which = is not a mailing list? You are just allowing better replay of the message, = if you put any weak DKIM signature in the message... Unless the weak DKIM s= ignature is constrained to a specific usage.
------=_Part_39895_739337166.1402409599836-- From nobody Tue Jun 10 07:16:26 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B74081B27A4 for ; Tue, 10 Jun 2014 07:16: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 QHKWL5JCxGyE for ; Tue, 10 Jun 2014 07:16:22 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68E421A0162 for ; Tue, 10 Jun 2014 07:16:22 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id q59so2245233wes.40 for ; Tue, 10 Jun 2014 07:16:20 -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=C3FYL/rGqFeMIdZNvdgwlSF2UK3Bh/XqOeuUa8cuqbg=; b=KP46YimFF1Wfj3N559yqmqGneZp0uouApRYC6zxUwgD0CBjfE8iFRVsELfiHxhGhS4 T6sv66C6OT+mTFW/9bPKkgK+Jq9Oz/eIkWjmNCV4Wef+xuSRksH2suJ0JeBpJ601wMlB hbNDZKPK0D3KpYvrVEbRwkK/CwfnES2Q7iPGEFdcYUaHoDcwVSDVBc/tiPTdOr+wUfXL DCeU4dBpvLWRIFNyqF9dLCuplnaK/WL4x6f6YERGvdWSef3Fso4ZPGivIze9Wp2RoBI4 c15AceY8YIxEo8gcfQc9XnyUsnD+yLDZkgCBCymMTOWSCFCnQAzAVHdTczPmHvzQQJiT fARQ== X-Received: by 10.15.34.4 with SMTP id d4mr11452eev.51.1402409780810; Tue, 10 Jun 2014 07:16:20 -0700 (PDT) Received: from ?IPv6:2001:730:40:4:6978:bcd4:aaed:880b? ([2001:730:40:4:6978:bcd4:aaed:880b]) by mx.google.com with ESMTPSA id m2sm52493872eey.36.2014.06.10.07.16.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Jun 2014 07:16:20 -0700 (PDT) Message-ID: <539712FB.3050200@gmail.com> Date: Tue, 10 Jun 2014 16:15:23 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Barry Leiba , "Stephen J. Turnbull" References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <87ppihgugl.fsf@uwakimon.sk.tsukuba.ac.jp> <5396A9B4.8000103@gmail.com> <87sindt8z2.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/GrO-3x0YLKe-GF_PPSmWgzZ_WY8 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 14:16:23 -0000 On 6/10/2014 1:27 PM, Barry Leiba wrote: >> > Each of those conditionals will not actually be satisfied. User's >> > tend not to notice such things. The tend not to understand what >> > they mean. Even when they understand, they tend to evaluate >> > choices poorly. They tend to apply choices inconsistently. >> >> Yes, yes, yes, and yes (all modulo "are we letting 'perfect' be the >> enemy of 'better'?" -- you have a *really* dim view of the average >> users' capabilities!) Actually I have a pretty typical view, relative to folks who have to direct experience with human factors, UI/UX, cognitive, memory and attention models, and the like. And as I said, I made a point of testing my summary judgement with a group of real experts, last summer. My preference is to do design that accepts the realities of the operational context for the design. So, for example, a design that makes inappropriate demands on end users will fail. Humans are erratic in paying attention. Humans are typically quite poor at understanding computer security models. Humans are inconsistent in making decisions during real-time interactions. etc., etc. To repeat, my comments on this are not in the least controversial amongst folk who study such things. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jun 10 07:17:08 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47FE1B27AF for ; Tue, 10 Jun 2014 07:17:01 -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 Hem7rvpU2Xiu for ; Tue, 10 Jun 2014 07:17:00 -0700 (PDT) Received: from smtp-4.01.com (adminr.01.com [162.209.88.187]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5081B27A4 for ; Tue, 10 Jun 2014 07:17:00 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [192.254.77.197]) by smtp-4.01.com (Postfix) with ESMTP id 8B9F94C833; Tue, 10 Jun 2014 09:16:57 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 4D374A03A0; Tue, 10 Jun 2014 09:16:57 -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 SOYRq83kAL5N; Tue, 10 Jun 2014 09:16:57 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 30AAEA039C; Tue, 10 Jun 2014 09:16:57 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 1B08CA03A0; Tue, 10 Jun 2014 09:16:57 -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 0VzXSONrzr7M; Tue, 10 Jun 2014 09:16:57 -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 03954A039C; Tue, 10 Jun 2014 09:16:57 -0500 (CDT) Date: Tue, 10 Jun 2014 09:16:44 -0500 (CDT) From: Franck Martin To: Dave Crocker Message-ID: <748123218.40006.1402409804604.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <1755889339.33315.1402383131643.JavaMail.zimbra@peachymango.org> <1019546957.39246.1402408698423.JavaMail.zimbra@peachymango.org> <539710D5.6070806@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF29 (Mac)/8.0.5_GA_5839) Thread-Topic: New Version Notification for draft-kucherawy-dkim-delegate-00.txt Thread-Index: 7QGZHA9nmw/QWtxjmDl1VHX8XTz5rA== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/btdqvfovZPhrU_ROkbm7InMpwuQ Cc: dmarc@ietf.org, "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 10 Jun 2014 14:17:02 -0000 ----- Original Message ----- > From: "Dave Crocker" > To: "Murray S. Kucherawy" , "Franck Martin" > Cc: dmarc@ietf.org > Sent: Tuesday, June 10, 2014 4:06:13 PM > Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt > > On 6/10/2014 4:03 PM, Murray S. Kucherawy wrote: > > Assuming by "strong DKIM signature" you mean the originator signature > > that covers the whole message, then given the MLM is going to invalidate > > it, it basically doesn't exist. > > > If it happens to survive (such as to recpients of the original message > who are not on a mailing list, so they get a direct copy) then their > DKIM evaluation engine ought to pay attention to the 'strength' of the > different signatures. Yes, but it requires change in the deployed DKIM base, may be best to put these changes within DMARC, while there are still some motivated coordinated developers. > > Also note that the weaker signature is enabled by the DKIM-Delegate > field, which specifies what intermediaries are tolerated. > ah, yes... From nobody Tue Jun 10 07:19:39 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBA991A049F for ; Tue, 10 Jun 2014 07:19:25 -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 qvcqthZHNlIr for ; Tue, 10 Jun 2014 07:19:22 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ECCF1B27BA for ; Tue, 10 Jun 2014 07:19:18 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id r20so6270976wiv.1 for ; Tue, 10 Jun 2014 07:19: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=+UDMsSsr+oWRMBFAfjkTWBS9giQ9TFrSZKjnvtNcHYE=; b=HsW30tPJEpJeJUx61SRKf6/iqRwYb1EI8UQLzgPy/1N2DOHhj3wAl+j91CLxEehMlS 8zPYLOn/zO1NJWITB/kf9ZYFLGjPzxJPqNa8gpFNkef0KCcpEq5qXj6SQgB3NwUhReGL TxL2MuvAu84blEIGYaD88HAvu58OMF6ZWWBqOhHbdi8AL+7mZnvMaVQKAxBkISKbtORm UJSex0yXzjJEW73z/S1WIn6BqrZBY3raPakJdrYAi0hiE+EeRbTrWwv8yQLoVpy2Nhod 4om5RjKnTgOeF0vsv2Hj/wd0JuoqUr41XAHbHQwZTOFm3+HBZgpFqT4VJyQJLY0eZyCc r4/w== MIME-Version: 1.0 X-Received: by 10.180.94.163 with SMTP id dd3mr38335334wib.26.1402409957599; Tue, 10 Jun 2014 07:19:17 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Tue, 10 Jun 2014 07:19:17 -0700 (PDT) In-Reply-To: <699367420.39896.1402409599837.JavaMail.zimbra@peachymango.org> References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <1755889339.33315.1402383131643.JavaMail.zimbra@peachymango.org> <1019546957.39246.1402408698423.JavaMail.zimbra@peachymango.org> <699367420.39896.1402409599837.JavaMail.zimbra@peachymango.org> Date: Tue, 10 Jun 2014 07:19:17 -0700 Message-ID: From: "Murray S. Kucherawy" To: Franck Martin Content-Type: multipart/alternative; boundary=f46d04462e5e5a305604fb7c03b5 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/GPPzgXCiI8EO9bt0JuNFibO27LM Cc: Dave Crocker , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 10 Jun 2014 14:19:26 -0000 --f46d04462e5e5a305604fb7c03b5 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 10, 2014 at 7:13 AM, Franck Martin wrote: > ------------------------------ > > On Tue, Jun 10, 2014 at 6:58 AM, Franck Martin > wrote: > >> ------------------------------ >> >> On Mon, Jun 9, 2014 at 11:52 PM, Franck Martin >> wrote: >> >>> This is interesting, however it seems to me that DMARC should be more >>> aware of it if used. >>> >> >> Why? This is a way of satisfying the alignment requirement on the DKIM >> side. DMARC doesn't need to know it's there. The same is true of ATPS, >> for example. >> >> Sure but you have a strong DKIM signature and a weak DKIM signature, >> using about the same domain, it is like the strong DKIM signature did not >> exist... >> > > Assuming by "strong DKIM signature" you mean the originator signature that > covers the whole message, then given the MLM is going to invalidate it, it > basically doesn't exist. > > Yes but are you assuming you only put the weak DKIM signature, when you > specifically know you are emailing a mailing list? > > Or what about a receiver which is not a mailing list? You are just > allowing better replay of the message, if you put any weak DKIM signature > in the message... Unless the weak DKIM signature is constrained to a > specific usage. > You're constraining it to use by a specific, very small set of domains, and only for a limited time. -MSK --f46d04462e5e5a305604fb7c03b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 10, 2014 at 7:13 AM, Franck Martin <fr= anck@peachymango.org> wrote:
On Tue, Jun 10, 2014 at 6:58 AM, Franck Martin <franck@peachymango.or= g> wrote:
On Mon, Jun 9, 2014 at 11:52 PM, Franck Martin <franck@peachymango.or= g> wrote:
This is interesting, however it seems to me = that DMARC should be more aware of it if used.

Why?=C2=A0 This is a way of satisfying the alignment requirement on th= e DKIM side.=C2=A0 DMARC doesn't need to know it's there.=C2=A0 The= same is true of ATPS, for example.

Sure but you have a strong DKIM signature and a weak DKIM signature, u= sing about the same domain, it is like the strong DKIM signature did not ex= ist...

Assuming by "strong DKIM signature" you mean the originator signa= ture that covers the whole message, then given the MLM is going to invalida= te it, it basically doesn't exist.

Yes but are you assuming you only put the weak DKIM signature, when yo= u specifically know you are emailing a mailing list?

Or what about a receiver which is not a mailing list? You are just a= llowing better replay of the message, if you put any weak DKIM signature in= the message... Unless the weak DKIM signature is constrained to a specific= usage.

Y= ou're constraining it to use by a specific, very small set of domains, = and only for a limited time.

-MSK
--f46d04462e5e5a305604fb7c03b5-- From nobody Tue Jun 10 07:26:54 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A48D1B27BC for ; Tue, 10 Jun 2014 07:26: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 cUkgiZfTnFoH for ; Tue, 10 Jun 2014 07:26:50 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D52E1A0162 for ; Tue, 10 Jun 2014 07:26:50 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id f8so6259840wiw.10 for ; Tue, 10 Jun 2014 07:26:48 -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=S+lfrSqUsNbhGmwx1p04yri6mLHnymAgo11oLTUmDFM=; b=fc6NW6HJdSs6tkcaCja6Ya8DgPmGvowCXh7kxdagVBy2V2xb5vD7abtE6d+nPMDPCN Vavc61VE5wbNCWghCExoAlHYKJI74FY8r4dM7tq/olK2sayg8SjRv3Gm0yV+QC4IPfHZ 9b3we/aakKsELAd/5XJywthv6DBjNpl+awcEdTPiRqWZhapgFfeoNrXwDwj+XXdmAXcU EI2cbG/uxVH6fSFNmLnpQ1XWjYE2Pjir21g7bgX71JqnI8B95kwS3PK4+brgBEICq2tR HioeJceE7eX4ldrcHy4PjaLzNeYbsUDcr5+2zpEce0AMU2za0yQuCfIHytH5CmCzBcNc wG3w== X-Received: by 10.14.9.137 with SMTP id 9mr14629eet.53.1402410408876; Tue, 10 Jun 2014 07:26:48 -0700 (PDT) Received: from ?IPv6:2001:730:40:4:6978:bcd4:aaed:880b? ([2001:730:40:4:6978:bcd4:aaed:880b]) by mx.google.com with ESMTPSA id z44sm52543039eep.39.2014.06.10.07.26.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Jun 2014 07:26:47 -0700 (PDT) Message-ID: <5397156F.8010603@gmail.com> Date: Tue, 10 Jun 2014 16:25:51 +0200 From: Dave Crocker 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" , Franck Martin References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <1755889339.33315.1402383131643.JavaMail.zimbra@peachymango.org> <1019546957.39246.1402408698423.JavaMail.zimbra@peachymango.org> <699367420.39896.1402409599837.JavaMail.zimbra@peachymango.org> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/hPNbWKOtdPxtZEnbXl5ebO4Bek4 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 10 Jun 2014 14:26:52 -0000 On 6/10/2014 4:19 PM, Murray S. Kucherawy wrote: > Yes but are you assuming you only put the weak DKIM signature, when > you specifically know you are emailing a mailing list? > > Or what about a receiver which is not a mailing list? You are just > allowing better replay of the message, if you put any weak DKIM > signature in the message... Unless the weak DKIM signature is > constrained to a specific usage. > > > You're constraining it to use by a specific, very small set of domains, > and only for a limited time. Then again, let's note that this double-signed mail is going to show up at some receivers that don't know about DKIM-delegate. The underlying point needs to be that a receiver that is faced with multiple signatures for the same domain needs some assessment of which is the 'strongest' and to give that one the preference. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Tue Jun 10 07:32:21 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90DC1A0641 for ; Tue, 10 Jun 2014 07:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 fgNx3jEtEGz7 for ; Tue, 10 Jun 2014 07:32:18 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 711A11A0193 for ; Tue, 10 Jun 2014 07:32:18 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id D52DF3FA0B25; Tue, 10 Jun 2014 23:32:17 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id C60161A32C5; Tue, 10 Jun 2014 23:32:17 +0900 (JST) From: "Stephen J. Turnbull" To: Franck Martin In-Reply-To: <1019546957.39246.1402408698423.JavaMail.zimbra@peachymango.org> References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <5392ECED.5010404@gmail.com> <1755889339.33315.1402383131643.JavaMail.zimbra@peachymango.org> <1019546957.39246.1402408698423.JavaMail.zimbra@peachymango.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 10 Jun 2014 23:32:17 +0900 Message-ID: <87zjhkq1hq.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/cXlsj2xDLjp5777E314p4ZtZKxU Cc: Dave Crocker , dmarc@ietf.org, "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 10 Jun 2014 14:32:20 -0000 Franck Martin writes: > Sure but you have a strong DKIM signature and a weak DKIM > signature, using about the same domain, it is like the strong DKIM > signature did not exist... Of course, the strong signature exists for the forwarding third party. What the destination should do, is a question of how paranoid it is about MITM attacks etc, and how much it trusts the list (and whether the list re-signs). From nobody Tue Jun 10 07:59:11 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747F61B27E5 for ; Tue, 10 Jun 2014 07:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.209 X-Spam-Level: * X-Spam-Status: No, score=1.209 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] 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 DdauhoScgsu6 for ; Tue, 10 Jun 2014 07:59:05 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id AD3371B27CD for ; Tue, 10 Jun 2014 07:59:03 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 444783FA0B20; Tue, 10 Jun 2014 23:59:03 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 3467D11F0DC; Tue, 10 Jun 2014 23:59:03 +0900 (JST) From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <5392ECED.5010404@gmail.com> <1755889339.33315.1402383131643.JavaMail.zimbra@peachymango.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 10 Jun 2014 23:59:03 +0900 Message-ID: <87y4x4q094.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/xGfAozW467nI75lcYsPIGkxlAb4 Cc: Dave Crocker , "dmarc@ietf.org" , Franck Martin Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 10 Jun 2014 14:59:08 -0000 Murray S. Kucherawy writes: > > It would require MLM to not drop DKIM headers... Still some > > configuration on MLM side, but less in the way messages are > > modified > > That's a much less visible and thus probably more tolerable change > for MLM operators. Mailman added an *optional* capability to drop DKIM signatures at the request of list operators who believed that DKIM failures were being used to reject or discard messages (contrary to protocol, of course). It drops all such fields. I don't know whether other MLMs implement it. I don't know how commonly the capability is used or whether the list operators still want it. If this idea goes further, we can ask the -developers and -users lists. AFAIK otherwise Mailman doesn't delete fields. Nor does it alter fields except for: (1) Personalization (list is replaced by subscriber in To: and Cc:). (2) Anonymous lists (From: is replaced by list). (3) Subject (optionally tag is added). (4) Reply-To (traditional munging; as part of p=reject mitigation). This is probably typical of most MLMs. Steve From nobody Tue Jun 10 08:15:04 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1271B27CD for ; Tue, 10 Jun 2014 08:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.073 X-Spam-Level: X-Spam-Status: No, score=-3.073 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 85qWY3VBEc5N for ; Tue, 10 Jun 2014 08:15:01 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 482971A01A5 for ; Tue, 10 Jun 2014 08:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1402413298; bh=GDFlCJYurk6klevSjmvSG8JqrTP5y9tAZ+7v8847MWs=; l=2869; h=Date:From:To:References:In-Reply-To; b=roXbmdnu6ebAM+0w+FVrXM/lOA7B0m2xShAGMAz2BkngobiehKulFUCYgcQLcpxbf kkPKAcuIN0kOM17eyZwztt3CVeA4+6j040kzg3GvUxHGpMhZrRvL7UCMW3r1R0h/3m ldUTi8Mp2mYaVmMd6aOfB22llDdsiHJqy1bxh1Tg= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 10 Jun 2014 17:14:58 +0200 id 00000000005DC048.00000000539720F2.0000717E Message-ID: <539720F2.2060801@tana.it> Date: Tue, 10 Jun 2014 17:14:58 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <5392ECED.5010404@gmail.com> In-Reply-To: <5392ECED.5010404@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/lmJyoq7ZEvcId-QwErIV85RPxvE Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 10 Jun 2014 15:15:03 -0000 On Sat 07/Jun/2014 12:43:57 +0200 Dave Crocker wrote: > > I've been stewing on this idea for awhile and Murray pressed to get it > into writing, adding his usual, significant enhancements to the original > concept. We've gone a couple of rounds before releasing it, but it's > still nascent enough to warrant gentle-but-firm handling. In other > words, comments eagerly solicited. Some comments: First, weak signatures which are not part of a chain should be ignored by verifiers. An authentication chain can be defined as a set of valid DKIM signatures and possibly an SPF authentication of delegated domains ("D" set), ordered such that: * the first one is an author domain signature, * each signature covers more header fields than the preceding one, * the last authentication is a full (i.e. not weak) DKIM signature, or an SPF "pass" authentication. That way, by adding DKIM-Delegate: and/or Resent-To: as needed, it is possible to have a mailing list send to another one. The sentence starting this point is stronger than the wording in the document. The latter talks about satisfying "this profile", which may sound like allowing those verifiers who used to validate weak signatures to continue their practices so long as other profiles are concerned. Instead, since we encourage signers to produce weak signatures, we ought to tell verifiers to ignore them unless they are part of a chain. Second, Section 3 and its subsections overstate the meaning of adding a DKIM-Delegate: field. AIUI, it serves when the To:/Cc: fields contain more domains than those which are meant to be delegated. Bullet 2 of Section 3.2 could characterize that better. Bullets 3 and 7 should not assume the field is always there. I suggest to define weak signatures and then characterize the method independently of the presence of any DKIM-Delegate: field. Third, weakly signing should be limited to messages destined to known mediators of trusted domains. This point is just implied in the document. A discussion about the correspondence between envelope recipients and signed destination addresses may be appropriate too. Fourth, a full author domain signature seems to be useless if the only recipient is a ML. As a fifth and last point, I'd mention quotation marks (RFC 2045 token vs quoted-string) among the uses of z= in Section 5.1. Using z= is easier and probably more effective than trying to specify a list of admissible, innocuous message alterations, but looks ugly. Anyway, it may help having MLMs publish a how-to-sign DNS record. The record says what subject-tag the MLM adds, for which fields it wants z=, in which cases it applies which encoding transformation, and the like. By itself, the existence of such record will confirm that a given recipient expects weak signatures. Just mumbling. Ale From nobody Tue Jun 10 08:15:45 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6FF01B27CD for ; Tue, 10 Jun 2014 08:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 WlqwI3Z_OboX for ; Tue, 10 Jun 2014 08:15:42 -0700 (PDT) Received: from nm37.bullet.mail.ne1.yahoo.com (nm37.bullet.mail.ne1.yahoo.com [98.138.229.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27FD91A01A5 for ; Tue, 10 Jun 2014 08:15:42 -0700 (PDT) Received: from [127.0.0.1] by nm37.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2014 15:15:41 -0000 Received: from [98.138.226.180] by nm37.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2014 15:12:44 -0000 Received: from [98.137.12.55] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2014 15:12:44 -0000 Received: from [98.137.12.219] by tm15.bullet.mail.gq1.yahoo.com with NNFMP; 10 Jun 2014 15:12:44 -0000 Received: from [127.0.0.1] by omp1027.mail.gq1.yahoo.com with NNFMP; 10 Jun 2014 15:12:44 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 68725.54387.bm@omp1027.mail.gq1.yahoo.com Received: (qmail 74233 invoked by uid 60001); 10 Jun 2014 15:12:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402413164; bh=7mjsDnPErLPlw1cSW5eejD9uJxEi6TzS5YfFpQUYZY0=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=rsORTF1HWxJQzjfLw7Ojak8LodXXY4N1wwqbuHR4tkX28y6oyy6FiAjS8um4NxYXABFYyR6k0q9OfJqUjRAC1fn9Ee+dGoqn1/oBxYPD+ze34nJMiXriZdeYqrrdudagNzgdY541wGi1GBS5rt3K6PV7Uy+trqoyBuu17aO+n/s= X-YMail-OSG: f6EhQd4VM1n6qfMP3Irz0XSwwL7dmzF1OYIwbp297IzIkXW OCn8TqBOI6Io0hX9FWArdcYRrE2OX_1fDQdqsIzJMR01dT7_EScCCNhw_pAk d_Hiwej86pC8jOPD9oP3ch.47xQx_ojEb66__wzzf8kPTIeR8QxKE9sh1zMl dToUqOmyWE2EAkjRVPq5GS.0aXbLlP30TlA2YEIkXVOKHy5qpxzvp5lWrtTF gMueyueRPgW18i_ZKMsGVTyikWy2Oxucv0yCEmcNAyWfAtsMShEJHg.IZjBd NDgo5M6usVlxrYvif1QcV6EvMtTlCzRgkatoUkTZLmud1mKq0B.sLH5VTK98 NGccZUliNDTDwElUPiazU7xvnTagAN8xgFG7.OwWp1tjVL0hSS7J27otGKT0 Z032Jkj9dojNhKcss6OQSEh0I_6szTkE1bOLHLcTfpUhIZag.XAxfaRdGzMr QRqi_hpOMTvszE.pQBSAWdH8OgQReudPGh_SVzgM7B69Hjw8hZqfnCwUgK4o Nx8U_OagAwWtR3T0WYa9JtYFO9qRkmJ8eN9g4DupldOK9AIReCl2ifZrCECR G1YYCdsMvfSGKrisRKxHDnxCot1zYEqeeFDwttMi29gLPMpY- Received: from [79.175.112.222] by web164606.mail.gq1.yahoo.com via HTTP; Tue, 10 Jun 2014 08:12:43 PDT X-Rocket-MIMEInfo: 002.001, T24gVHVlc2RheSwgSnVuZSAxMCwgMjAxNCA0OjU5IFBNLCBNdXJyYXkgUy4gS3VjaGVyYXd5IDxzdXBlcnVzZXJAZ21haWwuY29tPiB3cm90ZToKCgo.IE9yIGRvIHlvdSBtZWFuIHNvbWV0aGluZyBlbHNlIHdoZW4geW91IHNheSAibmV3IE1MIHJlcXVpcmVtZW50cyI_CgppIHdhc24ndCB0YWxraW5nIGFib3V0IERLSU0tRGVsZWdhdGUsIG5vciBpcyB0aGlzIGl0cyB0aHJlYWQsCnNvLCB3aGlsZSBpIHdpbGwgZ2V0IHRvIHVyIGFyZ3VtZW50cyBpbiBES0lNLUQgdGhyZWFkLCB0aGV5IG1pc3MKdGhlIHBvaW4BMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <1402382240.57323.YahooMailNeo@web164601.mail.gq1.yahoo.com> <5396AA73.8040109@gmail.com> <1402384311.51951.YahooMailNeo@web164603.mail.gq1.yahoo.com> <5396B0E9.9010109@gmail.com> <1402386096.27670.YahooMailNeo@web164604.mail.gq1.yahoo.com> Message-ID: <1402413163.50221.YahooMailNeo@web164606.mail.gq1.yahoo.com> Date: Tue, 10 Jun 2014 08:12:43 -0700 (PDT) From: Vlatko Salaj To: "Murray S. Kucherawy" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/awcdqnvm7oz9WeOg4GtBFFQR994 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 10 Jun 2014 15:15:43 -0000 On Tuesday, June 10, 2014 4:59 PM, Murray S. Kucherawy wrote: > Or do you mean something else when you say "new ML requirements"? i wasn't talking about DKIM-Delegate, nor is this its thread, so, while i will get to ur arguments in DKIM-D thread, they miss the point here. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Tue Jun 10 08:44:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6600E1B281E for ; Tue, 10 Jun 2014 08:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 QTH18Wn46r48 for ; Tue, 10 Jun 2014 08:44:45 -0700 (PDT) Received: from nm31.bullet.mail.gq1.yahoo.com (nm31.bullet.mail.gq1.yahoo.com [98.136.217.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36FF81A0213 for ; Tue, 10 Jun 2014 08:44:40 -0700 (PDT) Received: from [127.0.0.1] by nm31.bullet.mail.gq1.yahoo.com with NNFMP; 10 Jun 2014 15:44:39 -0000 Received: from [98.137.12.58] by nm31.bullet.mail.gq1.yahoo.com with NNFMP; 10 Jun 2014 15:41:51 -0000 Received: from [98.137.12.212] by tm3.bullet.mail.gq1.yahoo.com with NNFMP; 10 Jun 2014 15:41:51 -0000 Received: from [127.0.0.1] by omp1020.mail.gq1.yahoo.com with NNFMP; 10 Jun 2014 15:41:51 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 938131.84639.bm@omp1020.mail.gq1.yahoo.com Received: (qmail 9728 invoked by uid 60001); 10 Jun 2014 15:41:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402414911; bh=xy0AwmcW1aoXTTTDVTsDUwBegzjZk8vOE60gX/5ZTrE=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=hSpakL+wQZ+U3hyIBr7YYtIyCRzPF7CdFE/IrkF49/WLMk2rkkf7EHgoUzkcHH6mI8Mscg4ubqtNt2fkopFhhHnWxm0vZIUgpSS0SxzzeJFt7f9M4p+8lV/mJXtCzEMGNAegYwbbpVLXW9SiLpdST3slQjXpvTUbOnW28ZEZw40= X-YMail-OSG: IPAE1aEVM1kA_4nKwjIJKEGHtmty7owchNI7GguO.7W1UL9 AXVaj8XIagg9uYgtWpMci0Ua6AN37_7vE5caEqDszgGimPgQmJSV8DYWmMs3 rI5cO6i0U6Xtd2vSqzcLPa9nP_ISkhH2aWK549Fb6KRmBl.o83pp1iH9fsn6 e9EHgRUaF8GbvmqZYAYjGxmPGlImVWc5TTK8cX7N5cSliclwJSDI8eGb83iQ nCM6yJjdj2YQLnxK_55wPezzHzywjPQVHqv8yIVz7MMNahYCboIz4MnmBEoT eA34udRqoo1QLMvhvUctwp1aWXrEo0d_MpYooHCtwSY.Cbd7gg7vuFdSwssc 6MFBk5U4QOZVieg96fkt.1eb.zOzdNWm2NoICx2gPBMxFFnx3IdWmMwyAZSt qr2nAnK.DY_F7MTL9TXlp3YfnYDbcnQzwKAC0Zk63lyZc_i_GoXTSI1tTHSr rlZ1lXU.tRffWIhMRBVrg9ma0XDClMc4ifUTkm_zP6Bm7AdchZj0lnEV8vyw vqMkYAhW6Bu0atVarHNb_Qdb.fx3eCn7o_E5ft__VgPHgpD4Qfi0jcjGYwqy 46MoeBPO2HVfXMQQmn5RsHBaujwxeeafZYMiDH5bTiRPGMhampg-- Received: from [79.175.112.222] by web164601.mail.gq1.yahoo.com via HTTP; Tue, 10 Jun 2014 08:41:51 PDT X-Rocket-MIMEInfo: 002.001, T24gVHVlc2RheSwgSnVuZSAxMCwgMjAxNCA1OjAwIFBNLCBNdXJyYXkgUy4gS3VjaGVyYXd5IDxzdXBlcnVzZXJAZ21haWwuY29tPiB3cm90ZToKCgo.PiBES0lNLURlbGVnYXRlIHN1ZmZlcnMgZnJvbSByZXBsYXkgYXR0YWNrcywgYW5kIHdoZW4gbm90LAo.IERLSU0gaXMgYWxyZWFkeSByZXBsYXlhYmxlLgoKaSdtIG5vdCB0YWxraW5nIGFib3V0IERLSU0sIGknbSB0YWxraW5nIGFib3V0IERLSU0tRC4KCmknbSBzdGlsbCB3YWl0aW5nIGZvciB1IHRvIGFkZHJlc3MgdGhlIHNwb29maW5nIGhvbGUKdSBsZWYBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <5392ECED.5010404@gmail.com> <1755889339.33315.1402383131643.JavaMail.zimbra@peachymango.org> <1402385033.97400.YahooMailNeo@web164602.mail.gq1.yahoo.com> Message-ID: <1402414911.96471.YahooMailNeo@web164601.mail.gq1.yahoo.com> Date: Tue, 10 Jun 2014 08:41:51 -0700 (PDT) From: Vlatko Salaj To: "Murray S. Kucherawy" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/PJhI45ew86i7aun6WNKApccjz_4 Cc: Dave Crocker , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 10 Jun 2014 15:44:49 -0000 On Tuesday, June 10, 2014 5:00 PM, Murray S. Kucherawy wrote: >> DKIM-Delegate suffers from replay attacks, and when not, > DKIM is already replayable. i'm not talking about DKIM, i'm talking about DKIM-D. i'm still waiting for u to address the spoofing hole u left wide open with this approach. no, i won't accept "short-lived" as a solution, cause that's easy to circumvent. >> introduces whitelisting which, kind of, breaks its premise. > I don't see how this introduces whitelisting requirements. === section 3, DKIM-Delegate [...] it asserts an ephemeral relationship between an original message signing domain and a later intermediary (Mediator). === this is, ESSENTIALLY, a whitelisting approach. and we have much better whitelisting solutions already. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Tue Jun 10 08:55:45 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76021A01A6 for ; Tue, 10 Jun 2014 08:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 6yLdkPknDZSe for ; Tue, 10 Jun 2014 08:55:38 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 85BA61A01F6 for ; Tue, 10 Jun 2014 08:55:38 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id D20593FA0B25; Wed, 11 Jun 2014 00:55:37 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id C16281A32C5; Wed, 11 Jun 2014 00:55:37 +0900 (JST) From: "Stephen J. Turnbull" To: Dave Crocker In-Reply-To: <53971178.8020301@gmail.com> References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <87ppihgugl.fsf@uwakimon.sk.tsukuba.ac.jp> <5396A9B4.8000103@gmail.com> <87sindt8z2.fsf@uwakimon.sk.tsukuba.ac.jp> <53971178.8020301@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 11 Jun 2014 00:55:37 +0900 Message-ID: <87wqcopxmu.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/IsvV_NQw3HTFLnmVRHAB-x6gHDM Cc: Matt Simerson , "dmarc@ietf.org" , "J. Gomez" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 15:55:40 -0000 Dave Crocker writes: > I am assuming that working with filtering engines is better than trying > to work with 1-3 billion end users. That's a pretty stiff requirement. I'd be satisfied if a simple indicator, e.g. based on parsing Authentication-Results, saved 1-3 end users from a phishing attack. But since I don't have a plan for dealing with at least a billion end users, I guess I should go find another venue. No problem. :-) From nobody Tue Jun 10 09:19:30 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F8A1B281D for ; Tue, 10 Jun 2014 09:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.938 X-Spam-Level: X-Spam-Status: No, score=-99.938 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_14=0.6, J_CHICKENPOX_66=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 FRGpF8oUtcBl for ; Tue, 10 Jun 2014 09:19:21 -0700 (PDT) Received: from mail.santronics.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7C26A1B2802 for ; Tue, 10 Jun 2014 09:19:21 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5796; t=1402417157; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=wldizFCVcwxeOkjymHanzaF6tXg=; b=U32C/8g0zUBgfIjAi24D wbB7pGPmJl7OwGhf3MQAFjO5SnmTDu1QRywgHKC4XBi/i7CUN8/I6eq7aQqwTG2C dBeAiN9WedQN4N4kDvCq1tBbFezOvz1t22jFgER/nwzE6KkDrn/+z8m1YioAiD3U t55nVe5xslanva22b851EBI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 10 Jun 2014 12:19: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; Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1897279916.17216.988; Tue, 10 Jun 2014 12:19:16 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5796; t=1402416989; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Q7Zj0Cx RS6ju7B7sCQI/VZG/E4FaJJrjlnj8Q7mm8O8=; b=zN88jh4AHWM88zrxgHBYuKJ ghUp6rVH9fMaFzIFP0FK2agtLmhBVQ47h3I8TAmOhTRv5Z7mgIU24vkNQ+mxX740 y6OhptWGVrb3u2hvm9s2SbdaHWtYP7eMtc5SuEh8Rt8Ohp7+hTLjq7ddoe5MoVH9 aP9SxHon95xcNINAgDI0= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 10 Jun 2014 12:16: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 1913635937.9.5364; Tue, 10 Jun 2014 12:16:28 -0400 Message-ID: <53973001.3020104@isdg.net> Date: Tue, 10 Jun 2014 12:19:13 -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" , Vlatko Salaj References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <1402382240.57323.YahooMailNeo@web164601.mail.gq1.yahoo.com> <5396AA73.8040109@gmail.com> <1402384311.51951.YahooMailNeo@web164603.mail.gq1.yahoo.com> <5396B0E9.9010109@gmail.com> <1402386096.27670.YahooMailNeo@web164604.mail.gq1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/PChT8R9DSeVxwN6NWMW9EoA30K4 Cc: Dave Crocker , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 16:19:27 -0000 On 6/10/2014 10:00 AM, Murray S. Kucherawy wrote: > On Tue, Jun 10, 2014 at 12:41 AM, Vlatko Salaj > > wrote: > > "introducing new ML requirements" has already been > characterised as not an ML solution. we have a few > of them already, and all much simpler than any YADAs. > > > The person on this list that actually represents a mailing list so far > seems to like the idea, and has explained why to some extent. I think > that's much more valuable feedback. More valuable than other feedback? There are also other full time mail professional folks on this list, active, lurkers or otherwise, that are very much involved with not only the development and production of Mailing List Software (MLS) but include also actually using their own tools for the business and support process. Regardless of size, they all have to work the same with the basic protocol "list" mechanics with the minimum functional expectations and requirements to get the job done. While volume helps to highlight where the potential weak points may be and this is always desirable, they are weak points nonetheless at all levels. > A proposal like this one might introduce new requirements, sure, but > if they solve a huge problem and people are willing to implement it, > then so what? They're worth the work in that case. We do need to extract them, talk about them, but there are certain ones that simply do not apply -- they are show stoppers, a "waste of time," not a "global common" with cooperative competition in mind among all parties. I think we identified a few of these already. > My understanding of the constraint is that we need to avoid new > requirements that affect common mailing list practices, like footers > and Subject field tagging. Whatever are the design constraints, the algorithms, the automation, it needs to include all the factors and that includes author domain policies, as in the case with DMARC with no LSP (list service provider) authorization provisions. The point is that, until they were available (endorsed and championed), we won't have the full field testing experience of what is possible or not, or how the LSP will adapt. Right now, they are crippled because of the lack of 3rd party signing semantics or capabilities. So the LSP are thinking of "radical" methods to bypass the security. That is not the solution to this. We need to have all the parameters available in the mail process environment to see the entire framework in action with two-way reversible, verification methods. The DKIM-Delegate suggestion is more complex when it comes to code change, more complex than just doing a simple DNS lookup and honoring the policies. When ignored, eventually problems occur as it did happen now with higher volume impact players enabling the technology. The problem was always there. LSP are just feeling the pains of their early ignorance of the technology. > DKIM-Delegate establishes a requirement > that mailing lists sign the modified message in full. Where would the requirement be established? Is it a policy lookup or just the presences of the header signifies a higher level of expectations? This is a change for multiple mail software components so it needs to justify why this change is better than just doing a DNS lookup and processing the policy. Of course, without 3rd party semantics available, all the LSP can do is fit the 1st party policy model by denying subscription/submissions from restrictive domains. But certain LSPs do not want to do this even at this simpler level. How do you stop this with DKIM-Delegate when the header is missing? Is this a short circuit optimizer? If DKIM-Delegate is not present then do Author Domain Lookup What changes are the LSP willing to accept? You know, back in 2005/2006, I remember a good idea conversation when Jim Fenton shortly before the ASDP post-XMAS holiday surprise. Again, using the rule above, we wanted to reduce the need to do a lookup by passing policy information in the signature itself, something like this, applied to DMARC today, it may look like: DKIM-Signature: d=example.com policy=reject We concluded that would be an optimizer for the exclusive strong reject/quarantine policies since no one would do this if it was possible to reject it. Its possible to do the same thing with DKIM-Delegage of passing the policy via this header. But if its said, p=none, and the actual policy was reject, it means a check is needed anyway. So the rule would be now: If DKIM-Delegate is not present or DKIM-Delegate.p is not reject or quarantine then do Author Domain Lookup? > In a lot of cases, list software does that already; often it's > the case that other software even does that for them, so how >much of a burden is this really? I am not sure what you mean about this, detecting a list processed message? > The burden is actually on signers (who need to add DKIM-Delegate > fields) and on verifiers (who need to look for them and know what to > do with them), not on the lists themselves. Right, a change is required. So why not just a lookup? A lookup eliminates the need for additional complex mail header processing ideas. Do you believe DKIM-delegate reduces the need to do a lookup while still satisfying all author domain related security requirements? Can bad guys use the DKIM-Delegate to bypass non-list related mail in an attempt to show a valid 3rd party signer? Or is DKIM-Delegate just a means to dynamically scale authorized 3rd party signer? I am just wondering how do you verify it and avoid the fraudulent facsimiles of such DKIM-Delegate stamped messages. -- HLS From nobody Tue Jun 10 10:31:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9FDD1A0040 for ; Tue, 10 Jun 2014 10:31:32 -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 j-Yjl8Z5aatV for ; Tue, 10 Jun 2014 10:31:31 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D803C1A0238 for ; Tue, 10 Jun 2014 10:31:17 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id t60so2634733wes.28 for ; Tue, 10 Jun 2014 10:31: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=WdXbas8xhQicfuATlblV8Kywo27LdMdN5vlJFQaYLJc=; b=Q/GKx6KunjNpbTAsO/zuJJ3vlMhfeSgGsSV2csBYKR/6HQH6q+IRYGWYxDGY/m/i0k 0lmvbleJkgpfZyWLSPryrt0NFiJ7Uj4p5JuquoJTU911CSzAMgzu119ucBQsXr2OYrfp Ad1fWYdFrLDBhjbfQIiAN56c/vtAHDBkLXmcGd0SFLy7+rp4AgyR5tsuGJkznNQVKrZ2 tEutO50TDhkBjX4WrwqeT28DkTC9zpRsg1JdZTWev8eQsK2lpokCQoqarLwoJ1EEjc6/ vzATY8h82uityUrlg5DW+zhU03CbhYRkP3hgEeSmHbMLNHjCT4WJ9nH2HP3kgKBPK6oB ghUg== MIME-Version: 1.0 X-Received: by 10.180.228.39 with SMTP id sf7mr38162668wic.26.1402421476236; Tue, 10 Jun 2014 10:31:16 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Tue, 10 Jun 2014 10:31:15 -0700 (PDT) In-Reply-To: <53973001.3020104@isdg.net> References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <1402382240.57323.YahooMailNeo@web164601.mail.gq1.yahoo.com> <5396AA73.8040109@gmail.com> <1402384311.51951.YahooMailNeo@web164603.mail.gq1.yahoo.com> <5396B0E9.9010109@gmail.com> <1402386096.27670.YahooMailNeo@web164604.mail.gq1.yahoo.com> <53973001.3020104@isdg.net> Date: Tue, 10 Jun 2014 10:31:15 -0700 Message-ID: From: "Murray S. Kucherawy" To: Hector Santos Content-Type: multipart/alternative; boundary=001a1134d18aeac07104fb7eb145 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ZDFaEQFPc7bJqbk_R3QlFRs6lxA Cc: Dave Crocker , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 17:31:33 -0000 --001a1134d18aeac07104fb7eb145 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 10, 2014 at 9:19 AM, Hector Santos wrote: > >> The person on this list that actually represents a mailing list so far >> seems to like the idea, and has explained why to some extent. I think >> that's much more valuable feedback. >> > > More valuable than other feedback? > [...] > Feedback that shows insight and detail is useful. Feedback that says "Your idea won't work" without details explaining why is mostly useless, and thus easy to ignore. It doesn't matter to me who says it, it's quality of the comment that matters. > A proposal like this one might introduce new requirements, sure, but >> if they solve a huge problem and people are willing to implement it, >> then so what? They're worth the work in that case. >> > > We do need to extract them, talk about them, but there are certain ones > that simply do not apply -- they are show stoppers, a "waste of time," not > a "global common" with cooperative competition in mind among all parties. > I think we identified a few of these already. Yes indeed. > We need to have all the parameters available in the mail process > environment to see the entire framework in action with two-way reversible, > verification methods. The DKIM-Delegate suggestion is more complex when > it comes to code change, more complex than just doing a simple DNS lookup > and honoring the policies. When ignored, eventually problems occur as it > did happen now with higher volume impact players enabling the technology. > The problem was always there. LSP are just feeling the pains of their > early ignorance of the technology. > I don't agree that DNS is a cheaper solution than a handful of comparisons of strings you already have locally. > DKIM-Delegate establishes a requirement >> that mailing lists sign the modified message in full. >> > > Where would the requirement be established? Is it a policy lookup or just > the presences of the header signifies a higher level of expectations? > As it says in the draft, it's presence of the header field that matters. > This is a change for multiple mail software components so it needs to > justify why this change is better than just doing a DNS lookup and > processing the policy. In fact, one of the specific benefits of DKIM-Delegate over ATPS and TPA-Labels and any sort of whitelisting scheme is that there is no DNS lookup. > In a lot of cases, list software does that already; often it's >> the case that other software even does that for them, so how >> much of a burden is this really? >> > > I am not sure what you mean about this, detecting a list processed message? No. I'm saying MLMs already seem to sign the mail, either by doing it themselves or because outbound mail is automatically signed anyway. > > The burden is actually on signers (who need to add DKIM-Delegate >> fields) and on verifiers (who need to look for them and know what to >> do with them), not on the lists themselves. >> > > Right, a change is required. So why not just a lookup? A lookup > eliminates the need for additional complex mail header processing ideas. > It also introduces additional latency and you have to deal with timeouts. String comparisons are much cheaper. > > Do you believe DKIM-delegate reduces the need to do a lookup while still > satisfying all author domain related security requirements? Can bad guys > use the DKIM-Delegate to bypass non-list related mail in an attempt to show > a valid 3rd party signer? Or is DKIM-Delegate just a means to dynamically > scale authorized 3rd party signer? > > I am just wondering how do you verify it and avoid the fraudulent > facsimiles of such DKIM-Delegate stamped messages. > In order: Yes, that's what the proposal suggests. It might be right or wrong; that's what we need to determine somehow. Yes, that's a risk, and it's acknowledged in the draft already. The question is whether that risk is worth the gain. Yes. Nobody says the proposal is final as-is. Useful feedback is welcome. -MSK --001a1134d18aeac07104fb7eb145 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 10, 2014 at 9:19 AM, Hector Santos <hsantos@= isdg.net> wrote:

The person on this list that actually represents a mailing list so far
seems to like the idea, and has explained why to some extent. =C2=A0I think=
that's much more valuable feedback.

More valuable than other feedback?
[...]

=
Feedback that shows insight and detail is useful.=C2=A0 Feedback that = says "Your idea won't work" without details explaining why is= mostly useless, and thus easy to ignore.=C2=A0 It doesn't matter to me= who says it, it's quality of the comment that matters.


A proposal like this one might introduce new requirements, sure, but
if they solve a huge problem and people are willing to implement it,
then so what? =C2=A0They're worth the work in that case.

We do need to extract them, talk about them, but there are certain ones tha= t simply do not apply -- they are show stoppers, a "waste of time,&quo= t; not a "global common" with cooperative competition in mind amo= ng all parties. =C2=A0I think we identified a few of these already.

Yes indeed.
=C2=A0
We need to have all the parameters available in the = mail process environment to see the entire framework in action with two-way= reversible, verification methods. =C2=A0 The DKIM-Delegate suggestion is m= ore complex when it comes to code change, more complex than just doing a si= mple DNS lookup and honoring the policies. =C2=A0When ignored, eventually p= roblems occur as it did happen now with higher volume impact players enabli= ng the technology. =C2=A0The problem was always there. LSP are just feeling= the pains of their early ignorance of the technology.

I don't agree that DNS is a cheaper so= lution than a handful of comparisons of strings you already have locally.

DKIM-Delegate establishes a requirement
that mailing lists sign the modified message in full.

Where would the requirement be established? =C2=A0Is it a policy lookup or = just the presences of the header signifies a higher level of expectations?<= br>

As it says in the draft, it's prese= nce of the header field that matters.
=C2=A0
This is a change for = multiple mail software components so it needs to justify why this change is= better than just doing a DNS lookup and processing the policy.

In fact, one of the specific benefits of DKIM-Delegate = over ATPS and TPA-Labels and any sort of whitelisting scheme is that there = is no DNS lookup.


In a lot of cases, list software does that already; often it's
the case that other software even does that for them, so how
much of a burden is this really?

I am not sure what you mean about this, detecting a list processed message?=

No.=C2=A0 I'm saying MLMs already seem= to sign the mail, either by doing it themselves or because outbound mail i= s automatically signed anyway.
=C2=A0

The burden is actually on signers (who need to add DKIM-Delegate
fields) and on verifiers (who need to look for them and know what to
do with them), not on the lists themselves.

Right, a change is required. So why not just a lookup? =C2=A0A lookup elimi= nates the need for additional complex mail header processing ideas.

It also introduces additional latency and you = have to deal with timeouts.=C2=A0 String comparisons are much cheaper.
=C2=A0

Do you believe DKIM-delegate reduces the need to do a lookup while still sa= tisfying all author domain related security requirements? =C2=A0Can bad guy= s use the DKIM-Delegate to bypass non-list related mail in an attempt to sh= ow a valid 3rd party signer? =C2=A0Or is DKIM-Delegate just a means to dyna= mically scale authorized 3rd party signer?

I am just wondering how do you verify it and avoid the fraudulent facsimile= s of such DKIM-Delegate stamped messages.

In order:
Yes, that's what the proposal suggests.=C2=A0 It might b= e right or wrong; that's what we need to determine somehow.

Yes, that's a risk, and it's acknowledged in the draft alrea= dy.=C2=A0 The question is whether that risk is worth the gain.

Yes.

Nobody says the proposal is final as-= is.=C2=A0 Useful feedback is welcome.

-MSK
--001a1134d18aeac07104fb7eb145-- From nobody Tue Jun 10 10:37:15 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D586A1A0257 for ; Tue, 10 Jun 2014 10:37: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 gVEIrISu_5V9 for ; Tue, 10 Jun 2014 10:37:02 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.92]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECD2B1A024D for ; Tue, 10 Jun 2014 10:37:01 -0700 (PDT) Received: from BY2SR01MB608.namsdf01.sdf.exchangelabs.com (10.255.93.167) by BY2SR01MB608.namsdf01.sdf.exchangelabs.com (10.255.93.167) with Microsoft SMTP Server (TLS) id 15.0.974.2; Tue, 10 Jun 2014 17:37:00 +0000 Received: from BY2SR01MB608.namsdf01.sdf.exchangelabs.com ([169.254.5.56]) by BY2SR01MB608.namsdf01.sdf.exchangelabs.com ([169.254.5.56]) with mapi id 15.00.0974.002; Tue, 10 Jun 2014 17:37:00 +0000 From: Terry Zink To: "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] Change the mailing list protocol, not DMARC. Thread-Index: AQHPgy3ptT0mGgPUB0KQ1Ym9DO+BIptnb/qAgABeroCAAD+PAIAAG8oAgAAX+QCAAAhPAIAA8r0CgAB9PwCAAA5ggIAAGBYAgAAIPgCAACumgIAAItsAgAAvAICAADfEoA== Date: Tue, 10 Jun 2014 17:37:00 +0000 Message-ID: <4bd50731870747049db28756e7ae052e@BY2SR01MB608.namsdf01.sdf.exchangelabs.com> References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <87ppihgugl.fsf@uwakimon.sk.tsukuba.ac.jp> <5396A9B4.8000103@gmail.com> <87sindt8z2.fsf@uwakimon.sk.tsukuba.ac.jp> <539712FB.3050200@gmail.com> In-Reply-To: <539712FB.3050200@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.241] x-exchange-antispam-report-test: BCL:0;PCL:0;RULEID: x-forefront-prvs: 0238AEEDB0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(24454002)(51704005)(189002)(199002)(74366001)(76786001)(76796001)(66066001)(50986002)(77096001)(47446003)(53806002)(87936001)(99396002)(77982001)(54316003)(54356002)(87266001)(2656002)(69226001)(93886003)(101416001)(83322001)(51856002)(47736002)(47976003)(63696004)(56776002)(65816002)(56816006)(59766002)(49866002)(74706001)(33646001)(81686001)(81342001)(85306002)(76482001)(81816001)(94946001)(95416001)(81542001)(20776003)(31966008)(74662001)(74502001)(4396001)(94316002)(95666003)(79102001)(80022001)(97336001)(90146001)(93136001)(92566001)(74876001)(83072002)(93516002)(21056001)(98676001)(85852003)(97186001)(64706001)(46102001)(24736002)(223123001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2SR01MB608; H:BY2SR01MB608.namsdf01.sdf.exchangelabs.com; FPR:; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/uuNax8ooj5yTJIs_w5PEpcaSUHc Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 17:37:04 -0000 Dave Crocker wrote: > > Actually I have a pretty typical view, relative to folks who have to > direct experience with human factors, UI/UX, cognitive, memory and > attention models, and the like. And as I said, I made a point of > testing my summary judgement with a group of real experts, last summer. >=20 > My preference is to do design that accepts the realities of the > operational context for the design. Dave, Do you have any links to articles on UX design and things like this? I've s= een a couple of conference presentations over the years about UX design and= security, but I'd be interested in learning more about it.=20 -- Terry From nobody Tue Jun 10 10:44:24 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5241A0234 for ; Tue, 10 Jun 2014 10:44:07 -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 TVSpGWJec5o4 for ; Tue, 10 Jun 2014 10:44:06 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C646E1A0240 for ; Tue, 10 Jun 2014 10:44:05 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id l18so1844183wgh.4 for ; Tue, 10 Jun 2014 10:44: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=skjXjbW3xhhP7vuL/aP2am8GTIYMpR96x17COzycFLU=; b=m7wY5IsrG3CW1yv8R5k+43uSiefMbkin8K0RsOCG+y7XVbo/AG5hF9Grkg0/GjuC5T 3bJcZvzg2Nxa16ut8cqURB45Lpfk98CZgFgRIf+haxvM8noqqMPhhFiDCt/dkeRlkSN7 oAyAbr64TO4ZBuqdaD6U1HpJhvKZ8FdMMneCPMLylYuE3+9PpmE5F9u5XtOr5IClfy3d 2dVws85n4p6dYlC26I0yDBtkWXhIwTGLCJz3R25Ahpq3g+b7N7ODlbPoxGBSlFbW+WU+ fNIbv+aDfW6ZHpo8SMaRd0+tBuL/qXaJCgUKEKSoNFlZJjW9nqes8iknURn3eyEc9Rze 1kvQ== MIME-Version: 1.0 X-Received: by 10.180.212.77 with SMTP id ni13mr42307906wic.5.1402422243831; Tue, 10 Jun 2014 10:44:03 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Tue, 10 Jun 2014 10:44:03 -0700 (PDT) In-Reply-To: <1402414911.96471.YahooMailNeo@web164601.mail.gq1.yahoo.com> References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <5392ECED.5010404@gmail.com> <1755889339.33315.1402383131643.JavaMail.zimbra@peachymango.org> <1402385033.97400.YahooMailNeo@web164602.mail.gq1.yahoo.com> <1402414911.96471.YahooMailNeo@web164601.mail.gq1.yahoo.com> Date: Tue, 10 Jun 2014 10:44:03 -0700 Message-ID: From: "Murray S. Kucherawy" To: Vlatko Salaj Content-Type: multipart/alternative; boundary=001a11c23e5aab376d04fb7edf75 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/0VqfPBq2nrwhlSgWBv43vdV3IAM Cc: Dave Crocker , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 10 Jun 2014 17:44:07 -0000 --001a11c23e5aab376d04fb7edf75 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 10, 2014 at 8:41 AM, Vlatko Salaj wrote: > > i'm still waiting for u to address the spoofing hole > u left wide open with this approach. > > no, i won't accept "short-lived" as a solution, cause that's > easy to circumvent. > > It means you have a limited time to reuse a delegation signature. Also, as defined, you have to be able to impersonate one of the domains in the To: and/or Cc: field because one of those domains has to DKIM-sign the altered content, and that signature has to pass for the receiver. If you can do both of those things, then yes, the attacker "wins". Not everything has to be bulletproof to be useful as either an experiment or a starting point for further discussion. The document already calls this out as a known risk; that's specifically what Security Considerations is for. The fact that there are risks doesn't automatically mean this proposal fails. If people aren't prepared to accept the risk, then they don't have to do what's described here, and maybe it quietly fades into history. Otherwise, if this solves a problem for them and the risk is palatable, then it might be useful to them. >> introduces whitelisting which, kind of, breaks its premise. > > I don't see how this introduces whitelisting requirements. > > === > section 3, DKIM-Delegate > > [...] it asserts an ephemeral relationship between an original > message signing domain and a later intermediary (Mediator). > === > > this is, ESSENTIALLY, a whitelisting approach. > > and we have much better whitelisting solutions already. > You must be using a different definition of "whitelisting" than I am. To me, a whitelist is something you have to query to provide elevated status to some identifier that might be on that list. There's no query happening here, unless you consider that DKIM-Delegate is carrying the whitelist with it implicitly for every message. -MSK --001a11c23e5aab376d04fb7edf75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 10, 2014 at 8:41 AM, Vlatko Salaj <vlat= ko.salaj@goodone.tk> wrote:

i'm still waiting for u to address the spoofing hole
u left wide open with this approach.

no, i won't accept "short-lived" as a solution, cause that= 9;s
easy to circumvent.


It means you hav= e a limited time to reuse a delegation signature.=C2=A0 Also, as defined, y= ou have to be able to impersonate one of the domains in the To: and/or Cc: = field because one of those domains has to DKIM-sign the altered content, an= d that signature has to pass for the receiver.=C2=A0 If you can do both of = those things, then yes, the attacker "wins".

Not everything has to be bulletproof to be useful as either = an experiment or a starting point for further discussion.=C2=A0 The documen= t already calls this out as a known risk; that's specifically what Secu= rity Considerations is for.=C2=A0 The fact that there are risks doesn't= automatically mean this proposal fails.=C2=A0 If people aren't prepare= d to accept the risk, then they don't have to do what's described h= ere, and maybe it quietly fades into history.=C2=A0 Otherwise, if this solv= es a problem for them and the risk is palatable, then it might be useful to= them.

>> introduces whitelisting which, kind of, breaks its premise.
> I don't see how this introduces whitelisting= requirements.

=3D=3D=3D
section 3, DKIM-Delegate

[...] it asserts an ephemeral relationship between an original
message signing domain and a later intermediary (Mediator).
=3D=3D=3D

this is, ESSENTIALLY, a whitelisting approach.

and we have much better whitelisting solutions already.

You must be using a different definition of "whitelis= ting" than I am.=C2=A0 To me, a whitelist is something you have to que= ry to provide elevated status to some identifier that might be on that list= .=C2=A0 There's no query happening here, unless you consider that DKIM-= Delegate is carrying the whitelist with it implicitly for every message.
-MSK
--001a11c23e5aab376d04fb7edf75-- From nobody Tue Jun 10 10:56:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF18A1A025C for ; Tue, 10 Jun 2014 10:56:33 -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_51=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 4jusrfvpcW4l for ; Tue, 10 Jun 2014 10:56:32 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E44BC1A020F for ; Tue, 10 Jun 2014 10:56:31 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id t60so1023360wes.18 for ; Tue, 10 Jun 2014 10:56:30 -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=xEjkU1r/UEgraxM3tUoZr3kkq1Q9Jseh9RMF2pMY+XA=; b=ewdB4wwmYIqujbnVYY8MbgxwaLosYy2ooP1wY0FXGMLvB/ZOwhe2QBbjk0XVP1AjlP H+3Yl5dgWx7V39arXPBR9GGVZU/qvsphzng6ESB3Qd50A2h1MbN09WBNrVTYPqX8cMHj lszfuxfkm98AhmHqLMd8uK0BiYca6Azgx6m7Iz2aZcSKFl2tYqtY9lR+X3CTL6pUWI63 N/0rpMyVdMELtJlSi1uQM2qkVfZ0N/8PcqA0a4WAcAar3NpqN/vAXl/PB/0rRa3WYpcX q5gYNEqRJ+Zg8lDjaKX57a0ssVTQzCPpPuhkuraP3gKULW4Jpngbep68cY6j8ouxMATO zkhA== MIME-Version: 1.0 X-Received: by 10.180.75.212 with SMTP id e20mr14605037wiw.5.1402422990493; Tue, 10 Jun 2014 10:56:30 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Tue, 10 Jun 2014 10:56:30 -0700 (PDT) In-Reply-To: <539720F2.2060801@tana.it> References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <5392ECED.5010404@gmail.com> <539720F2.2060801@tana.it> Date: Tue, 10 Jun 2014 10:56:30 -0700 Message-ID: From: "Murray S. Kucherawy" To: Alessandro Vesely Content-Type: multipart/alternative; boundary=f46d043890a52c5d4004fb7f0c10 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/lhs66mZXY1u_G4V2j7ovacCaAV8 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 10 Jun 2014 17:56:33 -0000 --f46d043890a52c5d4004fb7f0c10 Content-Type: text/plain; charset=UTF-8 Hi Alessandro, On Tue, Jun 10, 2014 at 8:14 AM, Alessandro Vesely wrote: > First, weak signatures which are not part of a chain should be ignored > by verifiers. An authentication chain can be defined as a set of > valid DKIM signatures and possibly an SPF authentication of delegated > domains ("D" set), ordered such that: > > * the first one is an author domain signature, > * each signature covers more header fields than the preceding one, > * the last authentication is a full (i.e. not weak) DKIM signature, or > an SPF "pass" authentication. > The first one might fail. In fact, for the use case of interest, we might as well assume it always does. Why the second requirement? We already have the third requirement, minus the SPF tie-in. I'm not sure I see the benefit of the latter, since DKIM and SPF evaluate different things in the first place. > That way, by adding DKIM-Delegate: and/or Resent-To: as needed, it is > possible to have a mailing list send to another one. > Isn't that already possible? > The sentence starting this point is stronger than the wording in the > document. The latter talks about satisfying "this profile", which may > sound like allowing those verifiers who used to validate weak > signatures to continue their practices so long as other profiles are > concerned. Instead, since we encourage signers to produce weak > signatures, we ought to tell verifiers to ignore them unless they are > part of a chain. > The "profile" language comes from an earlier version of the draft. I'll clean it up in the next version. I agree, there should be language warning about the delegation signature on its own. However, we also have to realize that if that happens and a receiver doesn't even know about this proposal, such text isn't going to help any either. > Second, Section 3 and its subsections overstate the meaning of adding > a DKIM-Delegate: field. AIUI, it serves when the To:/Cc: fields > contain more domains than those which are meant to be delegated. > That's not correct. DKIM-Delegate serves when there's a desire to delegate to one or more of the domains listed in To:/Cc:, and not beyond that. The "t=" tag is provided in case there's a need to further expand that list, such as when there's a Mediator in the envelope recipients but not in the recipient fields. (That, actually, needs to be called out in Security Considerations; the "t=" tag reveals envelope information that might not be intended to go anywhere.) > Bullet 2 of Section 3.2 could characterize that better. Bullets 3 and > 7 should not assume the field is always there. I suggest to define > weak signatures and then characterize the method independently of the > presence of any DKIM-Delegate: field. > Doesn't RFC6376 already talk at some length about what should be considered when deciding what content should get hashed? I'm also worried about using languages like "weak" and "strong" as it relates to signatures, because those are pretty subjective terms. > Third, weakly signing should be limited to messages destined to known > mediators of trusted domains. This point is just implied in the > document. A discussion about the correspondence between envelope > recipients and signed destination addresses may be appropriate too. > By "weak" I think you're referring to the delegation signature. Yes, that's a good suggestion, though it still imposes a requirement on the originator to know what domains contain trusted Mediators, which is something that has been a stalling point for things like ATPS. The Yahoo!s of the world would have to create some process by which they either determine what those domains are by observing their own traffic, or have a registration process for them. What correspondence are you referring to? DKIM has always been completely independent of the envelope, and it should remain so. > Fourth, a full author domain signature seems to be useless if the only > recipient is a ML. > Why? As a fifth and last point, I'd mention quotation marks (RFC 2045 token > vs quoted-string) among the uses of z= in Section 5.1. > > Using z= is easier and probably more effective than trying to specify > a list of admissible, innocuous message alterations, but looks ugly. > Anyway, it may help having MLMs publish a how-to-sign DNS record. The > record says what subject-tag the MLM adds, for which fields it wants > z=, in which cases it applies which encoding transformation, and the > like. By itself, the existence of such record will confirm that a > given recipient expects weak signatures. Just mumbling. > We're specifically hoping to avoid adding still more lookups here. I'm also not much of a fan of the proposed "z=" hacks, for the same reasons that we abandoned that idea during the DKIM working group years. "z=" should be used to identify what got modified, but not to report a different result. -MSK --f46d043890a52c5d4004fb7f0c10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alessandro,

On Tue, Jun 10, 2014 at 8:14 AM, Ale= ssandro Vesely <vesely@tana.it> wrote:
First, weak signatures which are not part of= a chain should be ignored
by verifiers. =C2=A0An authentication chain can be defined as a set of
valid DKIM signatures and possibly an SPF authentication of delegated
domains ("D" set), ordered such that:

* the first one is an author domain signature,
* each signature covers more header fields than the preceding one,
* the last authentication is a full (i.e. not weak) DKIM signature, or
=C2=A0 an SPF "pass" authentication.

The first one might fail.=C2=A0 In fact, for the use case of intere= st, we might as well assume it always does.

Why the secon= d requirement?

We already have the third requirement, minus the SPF tie-in.= =C2=A0 I'm not sure I see the benefit of the latter, since DKIM and SPF= evaluate different things in the first place.
=C2=A0
That way, by adding DKIM-Delegate: and/or Resent-To: as needed, it is
possible to have a mailing list send to another one.
<= br>
Isn't that already possible?
=C2=A0
The sentence starting this point is stronger than the wording in the
document. =C2=A0The latter talks about satisfying "this profile",= which may
sound like allowing those verifiers who used to validate weak
signatures to continue their practices so long as other profiles are
concerned. =C2=A0Instead, since we encourage signers to produce weak
signatures, we ought to tell verifiers to ignore them unless they are
part of a chain.

The "profile"= ; language comes from an earlier version of the draft.=C2=A0 I'll clean= it up in the next version.

I agree, there should be lang= uage warning about the delegation signature on its own.=C2=A0 However, we a= lso have to realize that if that happens and a receiver doesn't even kn= ow about this proposal, such text isn't going to help any either.
=C2=A0
Second, Section 3 and its subsections overstate the meaning of adding
a DKIM-Delegate: field. =C2=A0AIUI, it serves when the To:/Cc: fields
contain more domains than those which are meant to be delegated.

That's not correct.=C2=A0 DKIM-Delegate serve= s when there's a desire to delegate to one or more of the domains liste= d in To:/Cc:, and not beyond that.=C2=A0 The "t=3D" tag is provid= ed in case there's a need to further expand that list, such as when the= re's a Mediator in the envelope recipients but not in the recipient fie= lds.=C2=A0 (That, actually, needs to be called out in Security Consideratio= ns; the "t=3D" tag reveals envelope information that might not be= intended to go anywhere.)
=C2=A0
Bullet 2 of Section 3.2 could characterize that better. =C2=A0Bullets 3 and=
7 should not assume the field is always there. =C2=A0I suggest to define weak signatures and then characterize the method independently of the
presence of any DKIM-Delegate: field.

D= oesn't RFC6376 already talk at some length about what should be conside= red when deciding what content should get hashed?=C2=A0 I'm also worrie= d about using languages like "weak" and "strong" as it = relates to signatures, because those are pretty subjective terms.
=C2=A0
Third, weakly signing should be limited to messages destined to known
mediators of trusted domains. =C2=A0This point is just implied in the
document. =C2=A0A discussion about the correspondence between envelope
recipients and signed destination addresses may be appropriate too.

By "weak" I think you're referri= ng to the delegation signature.=C2=A0 Yes, that's a good suggestion, th= ough it still imposes a requirement on the originator to know what domains = contain trusted Mediators, which is something that has been a stalling poin= t for things like ATPS.=C2=A0 The Yahoo!s of the world would have to create= some process by which they either determine what those domains are by obse= rving their own traffic, or have a registration process for them.

What correspondence are you referring to?=C2=A0 DKIM has alw= ays been completely independent of the envelope, and it should remain so.=C2=A0
Fourth, a full author domain signature seems to be useless if the only
recipient is a ML.

Why?

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> As a fifth and last point, I'd mention quotation marks (RFC 2045 token<= br> vs quoted-string) among the uses of z=3D in Section 5.1.

Using z=3D is easier and probably more effective than trying to specify
a list of admissible, innocuous message alterations, but looks ugly.
Anyway, it may help having MLMs publish a how-to-sign DNS record. =C2=A0The=
record says what subject-tag the MLM adds, for which fields it wants
z=3D, in which cases it applies which encoding transformation, and the
like. =C2=A0By itself, the existence of such record will confirm that a
given recipient expects weak signatures. =C2=A0Just mumbling.

We're specifically hoping to avoid adding still = more lookups here.=C2=A0 I'm also not much of a fan of the proposed &qu= ot;z=3D" hacks, for the same reasons that we abandoned that idea durin= g the DKIM working group years.=C2=A0 "z=3D" should be used to id= entify what got modified, but not to report a different result.

-MSK
--f46d043890a52c5d4004fb7f0c10-- From nobody Tue Jun 10 11:00:37 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDBD1A0069 for ; Mon, 9 Jun 2014 03:33:50 -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 fSgH2m3CoGU8 for ; Mon, 9 Jun 2014 03:33:49 -0700 (PDT) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A5501A0064 for ; Mon, 9 Jun 2014 03:33:49 -0700 (PDT) Received: from gsp.org (localhost [127.0.0.1]) by taos.firemountain.net (8.14.9/8.14.9) with SMTP id s59AXkr4031167 for ; Mon, 9 Jun 2014 06:33:46 -0400 (EDT) Date: Mon, 9 Jun 2014 06:33:46 -0400 From: Rich Kulawiec To: dmarc@ietf.org Message-ID: <20140609103346.GB16003@gsp.org> References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/UFp1_MXr02DfWvNh-syyptrLrA4 X-Mailman-Approved-At: Tue, 10 Jun 2014 11:00:30 -0700 Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 09 Jun 2014 10:33:50 -0000 On Sun, Jun 08, 2014 at 08:46:00AM -0400, Phillip Hallam-Baker wrote: > NNTP was designed 30 years ago. We should consider moving on. The > modern protocol world is JSON/REST Let's not be so quick to dismiss NNTP: it's a more elegant weapon from a more civilized age. ;) It has long since proven itself to be very robust under adverse conditions, which once upon a time might have been defined as "very slow network transport plagued with serious lag and frequent disconnects" and might now be defined as "network transport being actively interfered with for commercial or political reasons". (And I think it's worth noting that Usenet traffic can still propagate quite nicely via sneakernet, a seriously useful feature in certain locales. Not everyone is so fortunate and wealthy as to enjoy high-speed IP connectivity free of tampering, throttling and DPI.) But that's not really relevant here. The flooding propagation model of Usenet is quite different from the model used by mailing lists. (And if something like DMARC were used there, it would limit article propagation from users at example.com to example.com's immediately-adjacent neighbors only, clearly not a desirable property.) ---rsk From nobody Tue Jun 10 11:00:59 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE151A00DF for ; Mon, 9 Jun 2014 05:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 IwnBg_BBUVj8 for ; Mon, 9 Jun 2014 05:14:29 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66C681A00D5 for ; Mon, 9 Jun 2014 05:14:29 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id f8so4128239wiw.8 for ; Mon, 09 Jun 2014 05:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lq11YGr0EIBIJBNoLnumh73OwSC89bvkn/Ks/E2sPDo=; b=zrJSkpLJYVen9XO3h3j+PbJffWlDM1LPgdWI5GuWZ1V/t58Ahj73n62KMKjnshhiT1 40IDE7V9h4ys//IgqV95LUSFhXkm1UZDk/d+Iw4k8X5/0IX09H0mqameoGvLchPRFHyb p7Um8+RlKhBQK7Apnu2KmS1tUhEdB1ETh1ksEj32gIA0yVBQ8a4Bl6UPZX9fLce/rHOM /fz+0B1E7Au7Zhk7g8O2RW7oIh6jd3rRdehsblqj5h8qTKqdrqoJLFCi/lavHiV5VTWY AdTxVl9bLZjO14EeyvSqZPOEQnQZwLbP3BFEMF38PYuBN0HKgN0G7+TumlLG9V5dJCye MlkA== MIME-Version: 1.0 X-Received: by 10.180.76.6 with SMTP id g6mr28013570wiw.34.1402316068017; Mon, 09 Jun 2014 05:14:28 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.79.136 with HTTP; Mon, 9 Jun 2014 05:14:27 -0700 (PDT) In-Reply-To: <539532C2.9030406@isdg.net> References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> Date: Mon, 9 Jun 2014 08:14:27 -0400 X-Google-Sender-Auth: I24wC9lY3KNp8LN5DtWWFLWsRPU Message-ID: From: Phillip Hallam-Baker To: Hector Santos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/JVWYpOdEHipOvcU4By4WpkqA5Dk X-Mailman-Approved-At: Tue, 10 Jun 2014 11:00:47 -0700 Cc: "Stephen J. Turnbull" , "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 09 Jun 2014 12:14:31 -0000 On Mon, Jun 9, 2014 at 12:06 AM, Hector Santos wrote: > On 6/8/2014 10:26 PM, Murray S. Kucherawy wrote: >> >> >> To express how strong I feel about this.... >> >> If there is a charter for a new DMARC WG work, you can bet I will >> request that any form of 5322.From-Corruption concept be >> considered OFF TOPIC and OUT OF SCOPE in the new WG charter except >> to be aware of intentional From-Corruption is to be considered a >> new security exploit and threat to be mitigated. And for the >> record, I will also appeal any IETF work that begins to suggest >> From-Corruption concepts as a means to bypass security protocols. >> I will appeal it. >> >> Setting aside for the moment how premature this threat is given that >> there's not even a skeleton charter under proposal right now, > > > Its better to get this bud nipped now. Yes, always best to act before thinking about the problem Always best to make sure that the group considers only the problem it is allowed to consider. How can the IETF be a consensus organization if people are allowed to block consideration of alternatives? My understanding of the remit of this group is to consider what to do about the DMARC situation. The reason I proposed looking at changing the mailing list scheme is that the DMARC 'discussion' consists of one group of folk saying 'we have to stop this' and another pointing out that it has already happened. Most Internet users do not care whether mailing lists work or not. So expecting them to accept tons of spam from criminals trying to cheat them to preserve the equivalent of vinyl records is not going to succeed. The Internet does not have a rule that the people who got here first make the rules. There is a traffic jam in Cambridge/Boston several times a day as the lifting bridge opens to let some plutocrat sail his yacht through at rush hour. Several thousand people have to wait half an hour to get to work for one person to enjoy their hobby. I think that is a rotten and selfish way to run things. So given the fact that DMARC is causing problems for mailing lists we should not automatically assume that the solution is to change DMARC. I think that this point is completely on topic for a pre-WG list that is discussing ways to address a problem. Chances are that the conclusion is going to be that NO DMARC WG is formed because the people using DMARC are not interested in the changes that are going to be proposed. Mailing lists are not an optimal solution. They have high administrative burdens, the mail they send is often caught in spam filters because a mailing list is a bulk sender. These problems were recognized when NNTP was designed. Though as Dave Crocker points out, flood filling is hardly an approach we should endorse for the modern Internet. But given that we have the attention of Google and Yahoo here we do have the critical mass that could make a major change in mailing list technology stick. And it is to their interest to do so. So I am not just proposing a better solution, I am proposing a solution that has more chance of being adopted. Though since 'shut DMARC down because we says to' is not going happen pretty much anything has a better chance of deployment. >> I >> suggest you read Section 6.5 of RFC2026 to figure out what the >> official basis would be for such an appeal. > > > Murray, > > Fundamentally, any From-Corruption (good term to use) concept is bad. 30 > years of mail software/product/hosting development across multiple networks > tells me so, it ethically burns inside me as wrong and I have strong > confidence the IETF/IESG wise ones will agree. I hope you agree too. > > You will need to add security information to your DMARC document as this > From-Corruption concept would be a security exploit that can potentially get > by RFC5322 validation checks that can hurt DMARC publishers and create bad > PR for the DMARC protocol itself. DMARC receivers will need to be warned. > > You will need to provide guidelines for mitigating it, not for allowing it > unless there is an explicit policy defining language authorizing it, and > even then, that can be cracking open a loophole. > > You may want to make it a boundary layer check thing. The exploit will need > to be described just like it was done for DKIM's Double From situation with > RFC5322 validation checks done at receivers. > > Consider it a "to-do" note for when the anticipated official DMARC WG > begins. > > Thanks > > -- > Hector Santos, CTO > http://www.santronics.com > > From nobody Tue Jun 10 11:20:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3971A025C for ; Tue, 10 Jun 2014 11:20:35 -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_44=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 lsnmnBOn9OQT for ; Tue, 10 Jun 2014 11:20:33 -0700 (PDT) Received: from winserver.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id A036E1A0240 for ; Tue, 10 Jun 2014 11:20:32 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4644; t=1402424422; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Tii0byokHD61CmLf8U7fjzZneeg=; b=JfHJkqXt8tEDuLSY6sx9 kbD0ITqoujAWNochUENvxrcC+JqANIQhy2jdS7XTX2wcrpSqCxz5hPY6IXMHNvlv La2LtlTRhLgUTE38csLN4mnZqlXYdCkcjZ4uhbrnRX+2+moGXHUBcmZTuKSqsNQI DnTCuvn7N9iJuwUEnIkAusE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 10 Jun 2014 14:20: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; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1904545226.17216.4360; Tue, 10 Jun 2014 14:20:21 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4644; t=1402424255; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=BmXucLA K4XR+OU9xQJ5ZiATXI2h8JenK/fhUK4hdV6g=; b=bwflA/vNjyI/YZz8e2VGIUM uUQnb2uyuAbbmvvYd9WbNvEc1lASWD6KQttebBkiJ+HTeCsqHt28OeXUJaHr83wS afvyxhIvSVNWevHSw7eDk5qZR7ilg+qUKhMGxeC0TMiBJrqu5nbTLT8NA/xJR3yD x+E9KFjv1TRqwRyGkloE= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 10 Jun 2014 14:17: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 1920901359.9.3588; Tue, 10 Jun 2014 14:17:33 -0400 Message-ID: <53974C62.9050408@isdg.net> Date: Tue, 10 Jun 2014 14:20:18 -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: "Stephen J. Turnbull" References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <87ppihgugl.fsf@uwakimon.sk.tsukuba.ac.jp> <5396E49C.2000808@isdg.net> <8738fcrhqz.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <8738fcrhqz.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/hSkEA-u180346mdFqY7wZQnXIqI Cc: Matt Simerson , "dmarc@ietf.org" , "Murray S. Kucherawy" , "J. Gomez" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 18:20:37 -0000 On 6/10/2014 9:55 AM, Stephen J. Turnbull wrote: > Hector Santos writes: > > > Are you oppose to any other domain using strong policies or just > > certain ones? > > Domains where users have until now felt free to use their mailboxes as > they see fit (posting to mailing lists, as From: in on-behalf-of > services, etc) should not suddenly impose "p=reject" IMO. Right and so has the world of no-authentication required port 25, local recipient transactions where massive abuse has occurred world wide. The LSP, the bulk mailers, was among the tools used by the "bad guys." Millions of aged domains have been spam polluted, including Yahoo.com, etc. It is everyone's problem. I hope you agree. It was time for a change, and it started in 2003 with SPF and soon with DKIM+ADSP. Forward into time, ADSP was replaced with DMARC. LSP were warned. > I have stated several times that I have no quarrel with DMARC as is, > that I think it is a good protocol overall, and that in particular > "p=reject" is useful in "transactional" contexts. It is a logical > consequence that I support the idea of a lookup to discover policy. Will you implement it? You need to implement it as part of the LSP integration. Because if you are not, I need to stop writing to you trying to convince you. :) >> It is more easier, more feasible, more safe, to just reject/discard >> the failed message (due to policy) at the backend and be done with it. > > In your opinion. It is the expert opinion of million of IETF-MAN-HOURS and SMTP systems that have long implemented and deployed 4yz/5yz client/server response system and state machine. That includes my expert opinion. Its the expert opinion of systems that have deployed strong system level rejection methods, among them SPF, DNSRBL and now DMARC. I understand you are a LSP. DMARC effects you differently, but we can't throw out the proverbial baby. > In my experience, many postmasters resist that policy. Software developers provide the postmasters the option to reject/accept mail. So whether it is many or not, it is pointless. The demand is high to deploy system level rejections for older and newer policy reasons. >> Do you realize how many different MUAs exist? and the different forms >> of MUAs? > > I haven't counted. How many are there? Lots, too long to list. Its not about my stuff but everyones you have to work with. I have number of MUAs of my own for our own system. For tech support, we have different mail access portals: web: http://www.winserver.com telnet: telnet://bbs.winserver.com nntp: news://publicnews.winserver.com smtp/pop3: mail.winserver.com GUI: http://www.winserver.com/public/wcnavigator.wct plus a few internal Sysop Editor/Management/Watchdog tools. How can I single source your ideas for each of these MUA? The web side is a big concentration these days. So do we just deal with that? Do I forget the rest? I can apply the single source logic at the backend and it applies to all MUAs, the user using his favorite mail portal is secured against abuse. Is this practical business expert "opinion" acceptable? > > Why pass the buck to the user when the backend can deal with this > > and its works for all MUAs!! > > Because the backend can't deal with it, But it does and it works very well. If the backend software can't, then who? The user software? Software is software, why not the software at the backend? Do you wish to make this a USER defined policy where he can teach the backend because his frontend software is not capable of doing this? I'm cool with that, so what are the defaults? Maybe you can add user options like: [X] I want to reject mail from unauthorized DMARC sites. Will you provide it to them or is it too "Draconian" for them to have available? >except by imposing draconian > policies that I know many sysadmins really want to avoid. Well, it pointless to say "many" because what the "many" is really suffering from is the lack of options with the DMARC protocol. It is missing LSP provisions and once that happens then you will have your tools to adjust gracefully. But you have to agree the LSP needs to do the lookup or its frontend receiver has to do the lookup and be aware of the ML part, i.e. acceptable list addresses. Stephen, I do believe that it is "Bad Policy" to be promoting a concept of ignoring new growing policy protocols. It isn't going to help in the long run. DMARC is here. It isn't going to go away. Sure, its my opinion and I like to think I am more right than wrong. :) -- HLS From nobody Tue Jun 10 11:31:13 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6963C1A025C for ; Tue, 10 Jun 2014 11:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 Lya-kEVEvliO for ; Tue, 10 Jun 2014 11:30:47 -0700 (PDT) Received: from nm43.bullet.mail.ne1.yahoo.com (nm43.bullet.mail.ne1.yahoo.com [98.138.120.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27C321A00BD for ; Tue, 10 Jun 2014 11:30:47 -0700 (PDT) Received: from [127.0.0.1] by nm43.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2014 18:30:46 -0000 Received: from [98.138.226.179] by nm43.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2014 18:28:03 -0000 Received: from [216.39.60.180] by tm14.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2014 18:28:02 -0000 Received: from [98.137.12.196] by tm16.bullet.mail.gq1.yahoo.com with NNFMP; 10 Jun 2014 18:28:02 -0000 Received: from [127.0.0.1] by omp1004.mail.gq1.yahoo.com with NNFMP; 10 Jun 2014 18:28:02 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 671709.52966.bm@omp1004.mail.gq1.yahoo.com Received: (qmail 95418 invoked by uid 60001); 10 Jun 2014 18:28:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402424882; bh=ny7S28XX7srsKoeYGDewN7beHuspUCEIjyZbqEFTkFc=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ch2Mu7YmtqmJWYuwIExe6QCOUmzKz9/b/ymAxiWiNhoYRyc8CCTD7p8uWIYWQM3Q+HBC/79HBzenvyHuYb1DE9WJgWeDQNCwZKN8exd9zgRZhSJ9IR1t22nGhucmB/U7vFpeK33o09JmrglNiCE1Qx0I+EjbHL9MrjhXan7qhpU= X-YMail-OSG: MHjKIiYVM1l93K2KXdUZz55Mc5ojZxhVLL9eikIbs0XDtC8 OW7uRspb9KMroU4smtIayCUB3yDH6I_bn7kLgW9v.y1QhPE_IOce9iwZTiRH DJDhmbB.fNxDM.YsyW82hGVn0jxVZJ_gTgVkWAhvIl0V3lrse0uBCdNH9ajy GStk7uDZJ5Dg91BkO2OM7beLY.jPwHEmVdV4a6wkRY50M1u_2wFFw_VPj06e tyH8FXs.U0HtyFFf0hXaLxU3xZYFDB90iAPi.LfZpPRt9o5X9oUoiGxIS6JH 8DAhfyysaCXFN_2_6IRXR1h1nh5sGvyM6aufyp.O0PlbLMJO5kRKxHtfgeh8 PrQLUUpedApkRPOjEQnu57qzrNc_xdFoJc6m4YeZND3ZlmTi46cysO9jmXXQ aLpnndWjf62AtIkb42ChEw_wSto9K0y2dUIK94IDzHa9RHeUo_WCP27Py3Lh SV4MVW43RZSbjcFUByWJqurpI6lWWYPJt_qWo.xxEcNygi0WNJ6pj30UbJhh 3ko3AV.bS64xIknAa0hniuX0NOS.FAHp4A2YgXuPXpf5LP2mu9vQgc0pCrEG LyxOQ6Q0ar8LXL7SC4gHEd24EN72cIRogAPB5Ns48pw-- Received: from [79.175.112.222] by web164602.mail.gq1.yahoo.com via HTTP; Tue, 10 Jun 2014 11:28:02 PDT X-Rocket-MIMEInfo: 002.001, T24gVHVlc2RheSwgSnVuZSAxMCwgMjAxNCA4OjAxIFBNLCBQaGlsbGlwIEhhbGxhbS1CYWtlciA8cGhpbGxAaGFsbGFtYmFrZXIuY29tPiB3cm90ZToKCgo.IFRoZXJlIGlzIGEgdHJhZmZpYyBqYW0gaW4gQ2FtYnJpZGdlL0Jvc3Rvbgo.IHNldmVyYWwgdGltZXMgYSBkYXkgYXMgdGhlIGxpZnRpbmcgYnJpZGdlIG9wZW5zIHRvIGxldCBzb21lIHBsdXRvY3JhdAo.IHNhaWwgaGlzIHlhY2h0IHRocm91Z2ggYXQgcnVzaCBob3VyLiBTZXZlcmFsIHRob3VzYW5kIHBlb3BsZSBoYXZlIHRvCj4gd2FpdCBoYWxmIGEBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> Message-ID: <1402424882.80268.YahooMailNeo@web164602.mail.gq1.yahoo.com> Date: Tue, 10 Jun 2014 11:28:02 -0700 (PDT) From: Vlatko Salaj To: Phillip Hallam-Baker , Hector Santos In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ua-i_gMukNlY4IEXj7ebUMKVTd8 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 10 Jun 2014 18:30:55 -0000 On Tuesday, June 10, 2014 8:01 PM, Phillip Hallam-Baker wrote: > There is a traffic jam in Cambridge/Boston > several times a day as the lifting bridge opens to let some plutocrat > sail his yacht through at rush hour. Several thousand people have to > wait half an hour to get to work for one person to enjoy their hobby. > I think that is a rotten and selfish way to run things. > Chances are that the > conclusion is going to be that NO DMARC WG is formed because the > people using DMARC are not interested in the changes that are going to > be proposed. i just love this, i had to comment. Phillip goes about a story of a bridge and rich, selfish ppl disallowing thousands of workers, and then he mentions how rich [read selfish] corporations don't wanna change DMARC and thus go on affecting thousands of domains... and he doesn't realize the paralel. > So given the fact that DMARC is causing problems for mailing lists we > should not automatically assume that the solution is to change DMARC. DMARC is causing problems for many things, not just mailing lists. otherwise we wouldn't be having 3rd party alignment support proposals. yet we have 3 of them. and it's just beginning. > Though since 'shut > DMARC down because we says to' is not going happen pretty much > anything has a better chance of deployment. well, since we don't have an oracle to ask what will happen to DMARC, i'll rather leave all options open. however, i'm sure not gonna subscribe to this bullying, rich corporation tactic: "we will do what we want, and u can't stop us". either a protocol is for all the ppl, or abandoned by ppl. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Tue Jun 10 11:43:53 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7141A00BD for ; Tue, 10 Jun 2014 11:43:34 -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 v61RwQl-T70h for ; Tue, 10 Jun 2014 11:43:33 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C846A1A01EA for ; Tue, 10 Jun 2014 11:43:32 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id bs8so272340wib.1 for ; Tue, 10 Jun 2014 11:43: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=H0PSaru0OiYatqT3wq3gzkDtHVFtdqnb901by/2efgE=; b=DmDhd8NPYbNVEuQ3sLEtCbEAfih6cjgvFEs6BCwtIYDsMWzrNkZNdS5/BQsS5rTL1f wE/dBa1aBJ4Vb/IPyLbQjp8JLbWXoQCiD7CATYJhZppx1ZKhQKdEqqhKf5mZmnqcEBbg lcF/nC4eJo78YjrEISd1qXT3rcgZ77z5p59iSp8d/9/elEMPF7w+sbp/hYxFIRpDZU/6 F/oXJv4U+l84PG16M/U/4Gp0CrTj1BuodBI+zOIja4ZPSGCsAA97r0bm+sG+GMOKO3Fj 38e4xgqa5ZTUc2UPVisd2bwgBCv+VeuB90C4EAiuB/RaZUhLlAIJfwoLbnxNb/SJTjsp WO7A== MIME-Version: 1.0 X-Received: by 10.180.75.212 with SMTP id e20mr14939689wiw.5.1402425811241; Tue, 10 Jun 2014 11:43:31 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Tue, 10 Jun 2014 11:43:31 -0700 (PDT) In-Reply-To: <53974C62.9050408@isdg.net> References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <87ppihgugl.fsf@uwakimon.sk.tsukuba.ac.jp> <5396E49C.2000808@isdg.net> <8738fcrhqz.fsf@uwakimon.sk.tsukuba.ac.jp> <53974C62.9050408@isdg.net> Date: Tue, 10 Jun 2014 11:43:31 -0700 Message-ID: From: "Murray S. Kucherawy" To: Hector Santos Content-Type: multipart/alternative; boundary=f46d043890a54d921304fb7fb4d5 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/bQJnBPkMzVnpp_nL2WSCuhCSNA8 Cc: "Stephen J. Turnbull" , "dmarc@ietf.org" , Matt Simerson , "J. Gomez" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 18:43:34 -0000 --f46d043890a54d921304fb7fb4d5 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 10, 2014 at 11:20 AM, Hector Santos wrote: > > It is more easier, more feasible, more safe, to just reject/discard >>> the failed message (due to policy) at the backend and be done with it. >>> >> >> In your opinion. >> > > It is the expert opinion of million of IETF-MAN-HOURS and SMTP systems > that have long implemented and deployed 4yz/5yz client/server response > system and state machine. That includes my expert opinion. Its the expert > opinion of systems that have deployed strong system level rejection > methods, among them SPF, DNSRBL and now DMARC. I understand you are a > LSP. DMARC effects you differently, but we can't throw out the proverbial > baby. That's colorful, but not automatically true. There's plenty of other expert opinion (and, to date, consensus) to suggest that it's not a universal truth. -MSK --f46d043890a54d921304fb7fb4d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 10, 2014 at 11:20 AM, Hector Santos <hsantos@= isdg.net> wrote:

It is more easier, more feasible, more safe, to just reject/discard
the failed message (due to policy) at the backend and be done with it.

In your opinion.

It is the expert opinion of million of IETF-MAN-HOURS and SMTP systems that= have long implemented and deployed 4yz/5yz client/server response system a= nd state =C2=A0machine. That includes my expert opinion. =C2=A0Its the expe= rt opinion of systems that have deployed strong system level rejection meth= ods, among them SPF, DNSRBL and now DMARC. =C2=A0 I understand you are a LS= P. =C2=A0DMARC effects you differently, but we can't throw out the prov= erbial baby.

That's colorful, but not automatically true.=C2=A0 = There's plenty of other expert opinion (and, to date, consensus) to sug= gest that it's not a universal truth.

-MSK
<= /div>
--f46d043890a54d921304fb7fb4d5-- From nobody Tue Jun 10 12:01:21 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A3E1A01EA for ; Tue, 10 Jun 2014 12:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 JNR2WMep8IYf for ; Tue, 10 Jun 2014 12:00:59 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 082FB1A0081 for ; Tue, 10 Jun 2014 12:00:58 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id DB98A3FA0B23; Wed, 11 Jun 2014 04:00:57 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id CEF361A32C5; Wed, 11 Jun 2014 04:00:57 +0900 (JST) From: "Stephen J. Turnbull" To: Hector Santos In-Reply-To: <53973001.3020104@isdg.net> References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <1402382240.57323.YahooMailNeo@web164601.mail.gq1.yahoo.com> <5396AA73.8040109@gmail.com> <1402384311.51951.YahooMailNeo@web164603.mail.gq1.yahoo.com> <5396B0E9.9010109@gmail.com> <1402386096.27670.YahooMailNeo@web164604.mail.gq1.yahoo.com> <53973001.3020104@isdg.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 11 Jun 2014 04:00:57 +0900 Message-ID: <87vbs8pp1y.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/YKfhzmrD1tJ6gAq0sAnkpEqnsRs Cc: Dave Crocker , "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 19:01:00 -0000 Hector Santos writes: > LSP are just feeling the pains of their early ignorance of the > technology. That, sir, is false, both as to fact and as to causality. The LSPs were not "ignorant" of DMARC or its component technologies -- e.g., Mailman already had mitigations (courtesy of Franck Martin) in v2.1.16 released in Oct. 2013. Nor was the state of LSP knowledge relevant to the pain. Once Yahoo! published "p=reject" pain was inevitable because the authentication technology makes no allowance for Mediators. The choice was among different varieties of pain, but no amount of preparation would have made the pain avoidable. Regards From nobody Tue Jun 10 12:19:47 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05761A0081 for ; Tue, 10 Jun 2014 12:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=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 dIgU0-bO3jbv for ; Tue, 10 Jun 2014 12:19:18 -0700 (PDT) Received: from nm47.bullet.mail.ne1.yahoo.com (nm47.bullet.mail.ne1.yahoo.com [98.138.120.54]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52C9E1A028A for ; Tue, 10 Jun 2014 12:19:18 -0700 (PDT) Received: from [127.0.0.1] by nm47.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2014 19:19:17 -0000 Received: from [98.138.100.103] by nm47.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2014 19:16:17 -0000 Received: from [98.137.12.55] by tm102.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2014 19:16:17 -0000 Received: from [216.39.60.202] by tm15.bullet.mail.gq1.yahoo.com with NNFMP; 10 Jun 2014 19:16:17 -0000 Received: from [127.0.0.1] by omp1089.mail.gq1.yahoo.com with NNFMP; 10 Jun 2014 19:16:17 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 227991.96301.bm@omp1089.mail.gq1.yahoo.com Received: (qmail 44850 invoked by uid 60001); 10 Jun 2014 19:16:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402427777; bh=eX3JrpMCnBWBvV8rexXodnS4r1E5bpLhkPC78zPDCS4=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=f1jFlmosdf3nR+uzY7OcOUL+l6KbEimdAcb7FtNgdKqAKBSgU1rNEONBLo7Dp9QrFxks83kVhBOsLegUGu8xyquxw5DN2GEAbtuSMR1Htglc2YsfIzgV/KbVZkjwDhAe4xW6UYFt2/ziyCk9E3+Mc5wm+1wbqAKYQZWsffuz2XE= X-YMail-OSG: _8kpQtgVM1mlsIi.XIxqMg.GDNyAE2zAEVfyp48Tj4KI7M7 RYxU9ELwlaev7ZMTExJFs21Cxsn6J_Wz8xOSmGHkHzKm1OQshitsCsGVk_X7 oyv7Y9W1EzROK6mZrLGByFkfnmHfQzI._wT4xhk3zfqU9Jjgj9yWsJosrfZw VQq4PmlxMoc3.0XhyaKOQIFiArnY8M5NIjYMLUDWkDMEMatjKHtiRJigRB9g GNTg22MAe9N_bVRxyqXCBp0CMe6clWWcnOVYRDPO0hDgJFDtPLFibxB2FQJF kCHauAYNqKa3PyOwSK2Nz1ksCuC4Uw513K0wRKNn43bLvN1jpLMGkaJsNBno .LBKxBekiFfKbYnMs6wYX9UT4FiC9ETxd7OkARMnzv8hgF2CSWitkZi9fl3A kmh02FEd95pZfdIHeNAvFREFNhpoWRVe182nm3PIuM5ioEj4FPnbt6h6AxwZ K.ZB6rpKbF.om58Xnh4LIvugr7vVtc7OdmrIhV.QK9GILvjbJl4zTUToGFLW Itpfppp61EV.pisxqk0YwKZq2AwwX3xKqjA4kBPzNeGXzvu1xPPP8dMXPjKh L7VKQYKv35sb2x9oL1COWy8gNElKeP1G7mscsae_valMmucVBNQ-- Received: from [79.175.112.222] by web164602.mail.gq1.yahoo.com via HTTP; Tue, 10 Jun 2014 12:16:16 PDT X-Rocket-MIMEInfo: 002.001, T24gVHVlc2RheSwgSnVuZSAxMCwgMjAxNCA5OjAxIFBNLCBTdGVwaGVuIEouIFR1cm5idWxsIDxzdGVwaGVuQHhlbWFjcy5vcmc.IHdyb3RlOgoKCj4.IExTUCBhcmUganVzdCBmZWVsaW5nIHRoZSBwYWlucyBvZiB0aGVpciBlYXJseSBpZ25vcmFuY2Ugb2YgdGhlCj4.IHRlY2hub2xvZ3kuCj4gVGhhdCwgc2lyLCBpcyBmYWxzZSwgYm90aCBhcyB0byBmYWN0IGFuZCBhcyB0byBjYXVzYWxpdHkuCj4gVGhlIGNob2ljZSB3YXMgYW1vbmcgZGlmZmVyZW50IHZhcmlldGllcyBvZiBwYWluLCBidXQKPiBubyBhbW8BMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <1402382240.57323.YahooMailNeo@web164601.mail.gq1.yahoo.com> <5396AA73.8040109@gmail.com> <1402384311.51951.YahooMailNeo@web164603.mail.gq1.yahoo.com> <5396B0E9.9010109@gmail.com> <1402386096.27670.YahooMailNeo@web164604.mail.gq1.yahoo.com> <53973001.3020104@isdg.net> <87vbs8pp1y.fsf@uwakimon .sk.tsukuba.ac.jp> Message-ID: <1402427776.29329.YahooMailNeo@web164602.mail.gq1.yahoo.com> Date: Tue, 10 Jun 2014 12:16:16 -0700 (PDT) From: Vlatko Salaj To: "Stephen J. Turnbull" In-Reply-To: <87vbs8pp1y.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/oB8zMEgz9qoyLs_BnJvQ1ME8X50 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 10 Jun 2014 19:19:20 -0000 On Tuesday, June 10, 2014 9:01 PM, Stephen J. Turnbull wrote: >> LSP are just feeling the pains of their early ignorance of the >> technology. > That, sir, is false, both as to fact and as to causality. > The choice was among different varieties of pain, but > no amount of preparation would have made the pain avoidable. that's a completely wrong assumption. they all knew DMARC doesn't work for any case where 3rd party is involved. document even says so. however, they decided it's not their problem, and instead of solving it, they just ignored it, cause no rich corporation is using 3rd party services anyway. and thus, early ignorance brought us here where we have DMARC on non-IETF path, where we r bitching about mailing lists and where we have 3 different 3rd party proposals. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Tue Jun 10 12:23:10 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7421A01EA for ; Tue, 10 Jun 2014 12:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 RedOvgm_AUcb for ; Tue, 10 Jun 2014 12:09:07 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98B221A0081 for ; Tue, 10 Jun 2014 12:09:07 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id k48so8009611wev.31 for ; Tue, 10 Jun 2014 12:09:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=IYFU5diFjz6WDPzz7HtYrFFUWwYjxxjwUwSwK8UiOqo=; b=L9/ul6F9cI459pMDTHr4Pw9sOqETiBrBGsvDE8+DTUiCcszuVRxIwP9JIomR8RFKJ7 PE/cGE6hSzK/+oHiBhHOgcAcbkuzDGWDolDi8jvnBB7cgCvdKRzr9lD2V8O3pRnMaj7i Z+1JyeZqtqQZxghCX4k8XowthVRF3ipYLNKPIE7weI7vtBYeIJtZ5dOtIG1vt/DY4fAf pV+kMlwY9yw/N2GCQmeP8ybwchQwyYOO13G8i5ipB2/YUOWZeUjAplv1CMuWMneBN27b Mrt9u3JTLO/3BhTc6DOwVd+PslGbuwfSwh3MZB3Pr7h02WMZ4A54jH0cyOTcSUHDGhE+ of+A== MIME-Version: 1.0 X-Received: by 10.180.38.107 with SMTP id f11mr31927680wik.59.1402427346009; Tue, 10 Jun 2014 12:09:06 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.79.136 with HTTP; Tue, 10 Jun 2014 12:09:05 -0700 (PDT) In-Reply-To: <1402424882.80268.YahooMailNeo@web164602.mail.gq1.yahoo.com> References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <1402424882.80268.YahooMailNeo@web164602.mail.gq1.yahoo.com> Date: Tue, 10 Jun 2014 15:09:05 -0400 X-Google-Sender-Auth: 4ZSFw8tfFkjac5oXbOc3EzDOFsA Message-ID: From: Phillip Hallam-Baker To: Vlatko Salaj Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/FA-7EW9ACUDn8ktkNz0ZeBzZ5BM X-Mailman-Approved-At: Tue, 10 Jun 2014 12:22:52 -0700 Cc: "dmarc@ietf.org" , Hector Santos Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 19:09:09 -0000 On Tue, Jun 10, 2014 at 2:28 PM, Vlatko Salaj wrote: > On Tuesday, June 10, 2014 8:01 PM, Phillip Hallam-Baker wrote: > > >> There is a traffic jam in Cambridge/Boston >> several times a day as the lifting bridge opens to let some plutocrat >> sail his yacht through at rush hour. Several thousand people have to >> wait half an hour to get to work for one person to enjoy their hobby. >> I think that is a rotten and selfish way to run things. > >> Chances are that the >> conclusion is going to be that NO DMARC WG is formed because the >> people using DMARC are not interested in the changes that are going to >> be proposed. > > i just love this, i had to comment. > > Phillip goes about a story of a bridge and rich, selfish ppl disallowing > thousands of workers, and then he mentions how rich [read selfish] corporations > don't wanna change DMARC and thus go on affecting thousands of domains... > > and he doesn't realize the paralel. No it is you who don't see the parallel. Google and Yahoo's position here is analogous to that of the MBTA, they are one entity with a lot of money but they are acting for the benefit of thousands. Meanwhile we have a bunch of privileged Internet early adopters who think that the rest of the world should revolve around them. The number of people using Yahoo/Google is over a billion. The number of people being inconvenienced by DMARC more than they spend effort on complaining about it is likely to be zero. The issue here is not that the yacht owner is rich, it is that there is one person able to inconvenience thousands by citing a precedent. >> So given the fact that DMARC is causing problems for mailing lists we >> should not automatically assume that the solution is to change DMARC. > > DMARC is causing problems for many things, not just mailing lists. > otherwise we wouldn't be having 3rd party alignment support > proposals. yet we have 3 of them. > > and it's just beginning. Yes, its not just SMTP that is going to be extended with as policy layer. Every Internet protocol will be covered by one. Back in the day I was the only person saying that NAT was the deployment mechanism for IPv6, not something to be deliberately sabotaged because it does not meet some IETF dogma. I was right then and I am right on this one. DMARC is the right way to do email. It is over done, deployed. The only question that is left for the IETF now is whether to fix any damage it might have caused and if so, how. >> Though since 'shut >> DMARC down because we says to' is not going happen pretty much >> anything has a better chance of deployment. > > well, since we don't have an oracle to ask what will happen to > DMARC, i'll rather leave all options open. When was the last time I was wrong on something like this? It is possible that Google and Yahoo might retreat but I can't see why they would. > however, i'm sure not gonna subscribe to this bullying, rich > corporation tactic: "we will do what we want, and u can't stop us". You don't understand the Internet then. All that makes the Internet different is that everyone has that same exit option. The only sine qua non of the Internet is that networks communicated via IP. That is a strict rule but it is the only rule. Everything else is on the table and anyone who wants to do something different can. And there is nobody to go to to ask permission. The Internet is an empowerment technology. Or at least it is since the Web reworked it. The goal of the Web was to put publication capabilities in the hands of everyone so it wouldn't just be Rupert Murdoch who could decide what was news. We don't have rules, we have conventions and standards. But anyone who does not like those standards is always free to rip them up and do something else. This is not a decision making body. From nobody Tue Jun 10 12:35:37 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DEED1A0292 for ; Tue, 10 Jun 2014 12:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 m-HXX2ddhK0I for ; Tue, 10 Jun 2014 12:35:05 -0700 (PDT) Received: from nm45.bullet.mail.ne1.yahoo.com (nm45.bullet.mail.ne1.yahoo.com [98.138.120.52]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A93431A028E for ; Tue, 10 Jun 2014 12:35:04 -0700 (PDT) Received: from [127.0.0.1] by nm45.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2014 19:35:03 -0000 Received: from [98.138.100.103] by nm45.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2014 19:32:16 -0000 Received: from [98.137.12.174] by tm102.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2014 19:32:16 -0000 Received: from [98.137.12.245] by tm13.bullet.mail.gq1.yahoo.com with NNFMP; 10 Jun 2014 19:32:16 -0000 Received: from [127.0.0.1] by omp1053.mail.gq1.yahoo.com with NNFMP; 10 Jun 2014 19:32:16 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 241324.1936.bm@omp1053.mail.gq1.yahoo.com Received: (qmail 23244 invoked by uid 60001); 10 Jun 2014 19:32:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402428731; bh=xGyiF2tLdlMaZhz4ogWqv9sHAr0u9tUP4WXjTZgybms=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=a2TI6+rsEOs89rD4cUrBGDX0nRGHjAFBmgiFzHFQo7+MG4X26ruVKioPa1ekv6ztC29nhAd4q4YSHB1rn60OX5obf2w24Kqi1ND0ddi+4uHnM4gl1W83UT6wgiaL97wN3vlCHadpPNSF/rDMVOZfPJ8FvkzoDGPRW3q/OdAqs+0= X-YMail-OSG: 9gkqlH4VM1lHGJWm5gYr9wESlkPqO3bKoXUA84pSjVtppRs qx6nYppieDictR_vXX2S4P80bsZxfdBJrmZANpsB03BpIq5wj6QzW0J5VAFI FFqf1vYHOr3WwHz9TGFGTwpCxJJGvzeN_L1cZnoDYs1x4NTyDn2hsg5h6k1A _8Wr61.W3OnCMUvM7_XLYsh0dc_nSkK6OEu3rcgZE3pD0_RBkOsJPPKLldOl JBLR5XWKbyD0uCNNUDXQmfp6e70nWhwKEjLpPMrWJQCcM1Q5YdUCGF_GBqZP NLuNBUyh1tCtukk_O9SnFr8ZaSgpfvuU0ljlugfkxpXB8ytFJ_quiZV2PhUn BL_P50dvR_NRgdtOCcANRoH1Wmb_oA2YE6iz.1rZccahrcc3XSDZiBiirb6D Pu.xrHmkewwCMmr_Uaec13EblFsC6ZfWKi_.WUWq28u7Pap34A57VAT8Qwsn JiYRgre8W0Rr8hhvtBMAXQ_bWRF2UtAw.8XuzR.xF_NkCzo5FnkxvnWMGvHG 3Z_rvEB7VF1zWnl5A7NexEof6bWmirkA8Af6ATepd5OsP4RC_Fx.eKLxD4.x VdceEK1A0Sel3aQuv1z5ufla8vIDIFIFGtM3YG2Mp Received: from [79.175.112.222] by web164606.mail.gq1.yahoo.com via HTTP; Tue, 10 Jun 2014 12:32:10 PDT X-Rocket-MIMEInfo: 002.001, T24gVHVlc2RheSwgSnVuZSAxMCwgMjAxNCA5OjA5IFBNLCBQaGlsbGlwIEhhbGxhbS1CYWtlciA8cGhpbGxAaGFsbGFtYmFrZXIuY29tPiB3cm90ZToKCgp1bmZvcnR1bmF0ZWx5LCBQaGlsbGlwLCB0aGVyZSdzIG5vIGhvcGUgZm9yIHVzCnRvIGFncmVlIG9uIHRoZXNlIHRoaW5ncy4KCmV2ZXJ5dGhpbmcgdSBzYXkgc2VlbXMgc28gZG91YmxlLWZhY2VkIGFuZCBjeW5pY2FsLAppdCdzIGJleW9uZCBteSBiZXN0IGhvcGUgdG8gY29tcGx5LgoKbm90aGluZyBwZXJzb25hbCBvZmMuCgpzaW1wbHkgY2F1c2UgaSABMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <1402424882.80268.YahooMailNeo@web164602.mail.gq1.yahoo.com> Message-ID: <1402428730.11827.YahooMailNeo@web164606.mail.gq1.yahoo.com> Date: Tue, 10 Jun 2014 12:32:10 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/jiBpJC6uSWnNpJGUqsIYCilyF00 Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 10 Jun 2014 19:35:11 -0000 On Tuesday, June 10, 2014 9:09 PM, Phillip Hallam-Baker wrote: unfortunately, Phillip, there's no hope for us to agree on these things. everything u say seems so double-faced and cynical, it's beyond my best hope to comply. nothing personal ofc. simply cause i majored both philosophy and computer sciences, and beside being an IT pro, i'm also a human rights activist, i just can't participate in this kind of viewpoint of anything, yet alone internet. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Tue Jun 10 12:37:24 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C29F1A02A5 for ; Tue, 10 Jun 2014 12:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.052 X-Spam-Level: X-Spam-Status: No, score=-2.052 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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 5FIdIh7bu0bV for ; Tue, 10 Jun 2014 12:36:39 -0700 (PDT) Received: from mailer4.americangreetings.com (mailer4.americangreetings.com [66.119.43.173]) by ietfa.amsl.com (Postfix) with ESMTP id 324401A028B for ; Tue, 10 Jun 2014 12:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=americangreetings.com; s=q42010; c=relaxed/relaxed; q=dns/txt; i=@americangreetings.com; t=1402428990; x=1433964990; h=From:Subject:Date:To:CC:Reply-To:Message-ID:MIME-Version:Content-Type; bh=yV3m4Lmb5Fs8mPJBjeuGodr3Y7iBii/RaAy/49J3VWQ=; b=hWQF+cGMO/GdVC2Z8JjZIPid8Fy7WbIa1WS/puvohfpVu355PsvNs+4TASgguiGr yuwM1hbem/K4tbffNg/iBjeHv672D2Y5+npLdXZSu22GdPH0961cTK6zww69z6gA PvtjRGlUIo2GjnYCzF6IbdCxFAgAQMjBzFCEbVV6HLg=; Received: from [66.119.43.83] ([66.119.43.83:33467] helo=dc3-mbox.ops.ag.com) by momentum4 (envelope-from ) (ecelerity 3.5.2.36399 r(ssh://hg@repos.int.messagesystems.com/MessageSystems/Platform:3.5.2.0)) with ESMTP id 9A/CB-01859-E3E57935; Tue, 10 Jun 2014 15:36:30 -0400 Received: from [10.10.232.56] ([10.10.232.56]) by dc3-mbox.ops.ag.com (8.14.4/8.14.4) with SMTP id s5AJaTIV008693; Tue, 10 Jun 2014 15:36:30 -0400 Message-ID: <53975E3D.40603@americangreetings.com> Date: Tue, 10 Jun 2014 15:36:29 -0400 From: "M. Hammer" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Vlatko Salaj , "Stephen J. Turnbull" References: <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <1402382240.57323.YahooMailNeo@web164601.mail.gq1.yahoo.com> <5396AA73.8040109@gmail.com> <1402384311.51951.YahooMailNeo@web164603.mail.gq1.yahoo.com> <5396B0E9.9010109@gmail.com> <1402386096.27670.YahooMailNeo@web164604.mail.gq1.yahoo.com> <53973001.3020104@isdg.net> <87vbs8pp1y.fsf@uwakimon .sk.tsukuba.ac.jp> <1402427776.29329.YahooMailNeo@web164602.mail.gq1.yahoo.com> In-Reply-To: <1402427776.29329.YahooMailNeo@web164602.mail.gq1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/geNabrB2Nz-cmyg8OwuE9megD8s Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 19:36:41 -0000 On 6/10/2014 3:16 PM, Vlatko Salaj wrote: > On Tuesday, June 10, 2014 9:01 PM, Stephen J. Turnbull wrote: > > >>> LSP are just feeling the pains of their early ignorance of the >>> technology. >> That, sir, is false, both as to fact and as to causality. >> The choice was among different varieties of pain, but >> no amount of preparation would have made the pain avoidable. > that's a completely wrong assumption. they all knew DMARC doesn't > work for any case where 3rd party is involved. document even says so. As someone who has been involved in this space for quite some time, Stephan's perspective is much closer to reality. I'll grant what the document says but I'll also point out that the expectation was that domains without end users (or tightly controlled end users) were the candidates for p=reject. Even proponents such as myself that the community is best served by MLMs adapting to email authentication practices were somewhat blindsided by the moves of large mailbox providers to implement p=reject. My personal expectation was that the issue would be forced as more enterprises and vendor dependent organizations had access to DMARC through their appliance/application vendors. > however, they decided it's not their problem, and instead > of solving it, they just ignored it, cause no rich corporation > is using 3rd party services anyway. In this you are correct to a certain extent. It may be that the voices "representing" MLM developers/operators were not as representative as some thought. Personally I find Stephan's observations and comments thoughtful even if I do not necessarily agree with everything he writes. "Rich" corporations do use 3rd party services such as ESPs quite frequently. > and thus, early ignorance brought us here where we have DMARC > on non-IETF path, where we r bitching about mailing lists and > where we have 3 different 3rd party proposals. > > Quite a few things brought us here where we have DMARC on a non-IETF path - mailing lists are only one item among a number of items. That is not to say that we will not find DMARC on an IETF path in the future. As the furor and tempest have declined and more thoughtful discussions have emerged, I'm personally encouraged that we collectively have an opportunity to find good (for some definition of good) approaches to the issues at hand, including getting DMARC on an IETF path. From nobody Tue Jun 10 12:42:30 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 558B21A02B0 for ; Tue, 10 Jun 2014 12:42: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 5GLx0JBbn_Tg for ; Tue, 10 Jun 2014 12:42:06 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974411A02AA for ; Tue, 10 Jun 2014 12:42:06 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id bs8so352336wib.9 for ; Tue, 10 Jun 2014 12:42: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=GlD7BA/WSfUZKOqjyVGkPtvMZ1in1+w+qfCii0FUGF0=; b=ZZiuy5AKwziehcfcQCNAPLTggKto8tZBDcDCdr/HOsN9IQusuTpxPZ4VZgx80PldKY ZC0dVJwhHsctb0nl066VfOJp6TLQ71WjTzRMzeuvv90kkNNc1DAt0AvTFEpNtoZE3V4f GjoN01AJSV00UBMGdo2OZAU2clB9r2PkghC3hTK8qQqFNVpJQWwUlXMNEv9E/Ws5X5Af RAjIddAXARpAMQMvGt/KRkTyBp32sG1iBqrdHHJ7H4ga85jbvt2iakErDfWf4AlPbE3Q rVIzDr2xIafDSJeBxdVWOvB0FCAXp6szsxNmLC6W8AVPsy/jeNsGqZXv4tf7OgdwvKqV eINw== MIME-Version: 1.0 X-Received: by 10.194.89.168 with SMTP id bp8mr44775841wjb.73.1402429325222; Tue, 10 Jun 2014 12:42:05 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Tue, 10 Jun 2014 12:42:05 -0700 (PDT) In-Reply-To: <1402427776.29329.YahooMailNeo@web164602.mail.gq1.yahoo.com> References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <1402382240.57323.YahooMailNeo@web164601.mail.gq1.yahoo.com> <5396AA73.8040109@gmail.com> <1402384311.51951.YahooMailNeo@web164603.mail.gq1.yahoo.com> <5396B0E9.9010109@gmail.com> <1402386096.27670.YahooMailNeo@web164604.mail.gq1.yahoo.com> <53973001.3020104@isdg.net> <87vbs8pp1y.fsf@uwakimon.sk.tsukuba.ac.jp> <1402427776.29329.YahooMailNeo@web164602.mail.gq1.yahoo.com> Date: Tue, 10 Jun 2014 12:42:05 -0700 Message-ID: From: "Murray S. Kucherawy" To: Vlatko Salaj Content-Type: multipart/alternative; boundary=047d7bf10a1cc0aab304fb8085c8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/VDzkHx0BmH6ZdXdzMLt-8shdFJk Cc: "Stephen J. Turnbull" , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 19:42:08 -0000 --047d7bf10a1cc0aab304fb8085c8 Content-Type: text/plain; charset=UTF-8 On Tue, Jun 10, 2014 at 12:16 PM, Vlatko Salaj wrote: > > That, sir, is false, both as to fact and as to causality. > > The choice was among different varieties of pain, but > > no amount of preparation would have made the pain avoidable. > > that's a completely wrong assumption. they all knew DMARC doesn't > work for any case where 3rd party is involved. document even says so. > I think you're talking about different "they"s here. I believe Stephen is talking about mailing list operators and software developers, while you're talking about large ISPs. > and thus, early ignorance brought us here where we have DMARC > on non-IETF path, where we r bitching about mailing lists and > where we have 3 different 3rd party proposals. > Sorry, but that's not at all correct. The reason DMARC is not (presently) in the IETF stream has nothing to do with any of the above points. -MSK --047d7bf10a1cc0aab304fb8085c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 10, 2014 at 12:16 PM, Vlatko Salaj <v= latko.salaj@goodone.tk> wrote:
=
> That, sir, is false, bo= th as to fact and as to causality.
> The choice was among different varieties of pain= , but
> no amount of preparation would have made the pain avoidable.

that's a completely wrong assumption. they all knew DMARC doesn&#= 39;t
work for any case where 3rd party is involved. document even says so.

I think you're talking about different &= quot;they"s here.=C2=A0 I believe Stephen is talking about mailing lis= t operators and software developers, while you're talking about large I= SPs.
=C2=A0
and thus, early ignorance brought us here where we have DMARC
on non-IETF path, where we r bitching about mailing lists and
where we have 3 different 3rd party proposals.

Sorry, but that's not at all correct.=C2=A0 The reason DMARC is= not (presently) in the IETF stream has nothing to do with any of the above= points.

-MSK
--047d7bf10a1cc0aab304fb8085c8-- From nobody Tue Jun 10 12:59:16 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18081A035B for ; Tue, 10 Jun 2014 12:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_DKIM_INVALID=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 TwUbd0FbsnHt for ; Tue, 10 Jun 2014 12:58:58 -0700 (PDT) Received: from nm33.bullet.mail.ne1.yahoo.com (nm33.bullet.mail.ne1.yahoo.com [98.138.229.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A5771A0354 for ; Tue, 10 Jun 2014 12:58:57 -0700 (PDT) Received: from [127.0.0.1] by nm33.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2014 19:58:57 -0000 Received: from [98.138.100.115] by nm33.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2014 19:56:15 -0000 Received: from [98.137.12.175] by tm106.bullet.mail.ne1.yahoo.com with NNFMP; 10 Jun 2014 19:56:08 -0000 Received: from [98.137.12.194] by tm14.bullet.mail.gq1.yahoo.com with NNFMP; 10 Jun 2014 19:56:07 -0000 Received: from [127.0.0.1] by omp1002.mail.gq1.yahoo.com with NNFMP; 10 Jun 2014 19:56:07 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 978302.37715.bm@omp1002.mail.gq1.yahoo.com Received: (qmail 3079 invoked by uid 60001); 10 Jun 2014 19:56:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402430166; bh=pX4Q1GVtOABcKurNbp7B3lfFsa7k4eHZxXtEga6CjXs=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=nw/EUSsKjyzyyLMm+5AFiIi2h2mL+OIgKksJYPW7nQsxv8VkZtkgsdeovvqDbFNSY15RXB8cYHG/imvJ/TSmeOPNjHQ0BAyp9TgiPbcyh5jGYdfF9FzzAUACVB6ym8v5Vm3w4QzXjX7Juowy9VeDjZ39r+KnksLu0abOIgrh/bY= X-YMail-OSG: FxdYhecVM1mBJeaWrHzikjUuFOImc76f7r3MIdkbrHHzoG6 WXYTM1cmvzO_6fpoJR2OCfbkP1EH0BIxEGGbEKvb_xpYjfvR.K9GdITXC9qN wsn_GoDIylvcpK6oH__l0sPjj00SUJs3BImdhpP8qUGoJCYqxV2KEnBXx1LO OcZotLo.PuTxlAUw74fAOjKiI7ySmB.xyh7D7a1iPerdGxgE.J6dTnSUnnHS ZV8EQr2m06SVs5.KYCXHxE_7pvDs7w0kHHRssQ5gTAP_xhrmMWZCv47pw3zO Y6dA46xCeC7KYF.dlZ16CnS.uratHlOA6NrQL_Tc7EKL_2AdOuNYpvpp4_uL hPiytYQHhgGQ_rx6ATR76q4xfHt5F8RYJipZl2BuPy.aYcXM1YSnNcGqt0C_ voMdKK.feE3JFiln9_nA3sL6nOZy.AS_Yd3N52JeKOd4tv_mrguMq6dxoz7x Mgp6wUVZMU.7i5XQsloT06o0Ykqn0jmIjMZjjML3LG8rGl.Ye_GbrDhRbdqS 3CePiRFLYZ_4mzd7815mddGEUXGdNhtwdesXuJ95cI3ppZziDXNn68dqEvOz wp3DRHT0XBXyRZexgkigdoyCR7Fv9By.ivqCXa81TPPC0j_P8aw-- Received: from [79.175.112.222] by web164603.mail.gq1.yahoo.com via HTTP; Tue, 10 Jun 2014 12:56:06 PDT X-Rocket-MIMEInfo: 002.001, T24gVHVlc2RheSwgSnVuZSAxMCwgMjAxNCA5OjQyIFBNLCBNdXJyYXkgUy4gS3VjaGVyYXd5IDxzdXBlcnVzZXJAZ21haWwuY29tPiB3cm90ZToKCgo.IFRoZSByZWFzb24gRE1BUkMgaXMgbm90IChwcmVzZW50bHkpIGluIHRoZSBJRVRGIHN0cmVhbSBoYXMKPiBub3RoaW5nIHRvIGRvIHdpdGggYW55IG9mIHRoZSBhYm92ZSBwb2ludHMuCgoKdSBwcGwga2VlcCByZXBlYXRpbmcgdGhhdC4gaG93ZXZlciwgdSBuZXZlciBzYXkgd2hhdCBJUyB0aGUgcmVhc29uLgp3aHkgZG9uJ3QgdSBlbmxpZ2h0ZW4gdXMsIHQBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <1402382240.57323.YahooMailNeo@web164601.mail.gq1.yahoo.com> <5396AA73.8040109@gmail.com> <1402384311.51951.YahooMailNeo@web164603.mail.gq1.yahoo.com> <5396B0E9.9010109@gmail.com> <1402386096.27670.YahooMailNeo@web164604.mail.gq1.yahoo.com> <53973001.3020104@isdg.net> <87vbs8pp1y.fsf@uwakimon .sk.tsukuba.ac.jp> <1402427776.29329.YahooMailNeo@web164602.mail.gq1.yahoo.com> Message-ID: <1402430166.64721.YahooMailNeo@web164603.mail.gq1.yahoo.com> Date: Tue, 10 Jun 2014 12:56:06 -0700 (PDT) From: Vlatko Salaj To: "Murray S. Kucherawy" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/KXdqjzQUdLoL-xtlY9Z1V8oULmw Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 10 Jun 2014 19:59:02 -0000 On Tuesday, June 10, 2014 9:42 PM, Murray S. Kucherawy wrote: > The reason DMARC is not (presently) in the IETF stream has > nothing to do with any of the above points. u ppl keep repeating that. however, u never say what IS the reason. why don't u enlighten us, then? maybe we'll bitch less if we knew the truth, but considering it has nothing to with it, i guess not. however, maybe Hector won't go around making early threats, which seem to injure many. the story of my life... i'm always in minority, fighting for survival. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Tue Jun 10 13:05:14 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F24D1A0284 for ; Tue, 10 Jun 2014 13:04:55 -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 Oya9pJhsgFVP for ; Tue, 10 Jun 2014 13:04:54 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5FC91A0282 for ; Tue, 10 Jun 2014 13:04:53 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id cc10so2460229wib.0 for ; Tue, 10 Jun 2014 13:04:52 -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=cScak4yiUTS9U5AWxfOchStkBhebUVfINpm6JvkKFDc=; b=tWCJxfOowvLqJTbbAN4VKVkkjzk6nvpbz3e+J2x+zjj+VKlJvirUPOW0Zk4nlkuCQF 7KRGhJR1lI5zAdaIz9MwaHgTY5I47pJ1tdQnQpfQSilGQKyYdXs2H2X7ts9+A7EtfQ+1 5xl7/tfGMZrypzoz2OoTt+e5+mYNrNPmSZsKchEdRzLRsynGXKRU3KQGVeCxXRFTac5G sPjK9669EZb8zrcyfZzQ2x3phbrkXC/sVECJ/QkwBZOnaFOnExHrnqrlmaCe94nRBxxk gKqfKdvsC4d8GTmEkU/U8ewrsqwArjjQ9ljMAltlxtezERufsNvX6UxhFRLwaTUH7EFl XsvQ== MIME-Version: 1.0 X-Received: by 10.180.83.105 with SMTP id p9mr16151439wiy.8.1402430692610; Tue, 10 Jun 2014 13:04:52 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Tue, 10 Jun 2014 13:04:52 -0700 (PDT) In-Reply-To: <1402430166.64721.YahooMailNeo@web164603.mail.gq1.yahoo.com> References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <1402382240.57323.YahooMailNeo@web164601.mail.gq1.yahoo.com> <5396AA73.8040109@gmail.com> <1402384311.51951.YahooMailNeo@web164603.mail.gq1.yahoo.com> <5396B0E9.9010109@gmail.com> <1402386096.27670.YahooMailNeo@web164604.mail.gq1.yahoo.com> <53973001.3020104@isdg.net> <87vbs8pp1y.fsf@uwakimon.sk.tsukuba.ac.jp> <1402427776.29329.YahooMailNeo@web164602.mail.gq1.yahoo.com> <1402430166.64721.YahooMailNeo@web164603.mail.gq1.yahoo.com> Date: Tue, 10 Jun 2014 13:04:52 -0700 Message-ID: From: "Murray S. Kucherawy" To: Vlatko Salaj Content-Type: multipart/alternative; boundary=f46d044282de415b4104fb80d7ab Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Ii7maqyI5vBk_9OtsQupOqlKKhg Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 20:04:55 -0000 --f46d044282de415b4104fb80d7ab Content-Type: text/plain; charset=UTF-8 On Tue, Jun 10, 2014 at 12:56 PM, Vlatko Salaj wrote: > u ppl keep repeating that. however, u never say what IS the reason. > why don't u enlighten us, then? > Instead of assuming the reason and thus making false accusations, you could've asked for the details first. > maybe we'll bitch less if we knew the truth, but considering it > has nothing to with it, i guess not. > We couldn't come to agreement on the terms for a working group charter at the time we tried. The details are available in the archives of this list if you want to go back and get more detail, but that's the basics of it. I'm hoping we will try again so that there is a standards track version of DMARC in the not-too-distant future, because I think just about everyone believes that's a good idea. -MSK --f46d044282de415b4104fb80d7ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 10, 2014 at 12:56 PM, Vlatko Salaj <v= latko.salaj@goodone.tk> wrote:
=
u ppl keep repeating that. however, u never = say what IS the reason.
why don't u enlighten us, then?

Ins= tead of assuming the reason and thus making false accusations, you could= 9;ve asked for the details first.
=C2=A0
maybe we'll bitch less if we knew the truth, but considering it
has nothing to with it, i guess not.

We= couldn't come to agreement on the terms for a working group charter at= the time we tried.=C2=A0 The details are available in the archives of this= list if you want to go back and get more detail, but that's the basics= of it.

I'm hoping we will try again so that there is a standards track ver= sion of DMARC in the not-too-distant future, because I think just about eve= ryone believes that's a good idea.

-MSK

--f46d044282de415b4104fb80d7ab-- From nobody Tue Jun 10 13:06:32 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E21E1A02A6 for ; Tue, 10 Jun 2014 13:06:20 -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 g0TgbDXnsrs0 for ; Tue, 10 Jun 2014 13:06:19 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07A751A028A for ; Tue, 10 Jun 2014 13:06:17 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id q59so2686179wes.26 for ; Tue, 10 Jun 2014 13:06:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=EqfKjtji7i7bkKN9+SY8FIx89xp3RZJwj09OM3cD8Ew=; b=hNlA8LICfRsqmjDS1OZDUwPB4DUl6JOV+PFZNM3pM2CwGBaOCuN2QDJecXDenLmd+l T189WfyW70h8UWCTR9j8rlSaWcq0Ta3YzPTzoGGcjY49Er9P/Ylf70Zh9HdwjqE4z5CG E1YVoxnYSvuW4EpsT7QwQTETrdZ8ckvzKS/Cz/LUvjlDf55KVB9Y+05HVa7ek/vpihyN 9fk7VjAVF+xH73EkvyS1VVnHkf2hdAAklCVWXjsa+Og8EFOKizJ7n9HgoD5II7g9yP+S kM/XibDlah91OVWyPZgl2heHYT9OXYE/Rb3J9Y5ztPgR8qYhpyOgkGZ+yQ+AuD6UOqBk tCNQ== MIME-Version: 1.0 X-Received: by 10.181.8.67 with SMTP id di3mr40775788wid.8.1402430776510; Tue, 10 Jun 2014 13:06:16 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Tue, 10 Jun 2014 13:06:16 -0700 (PDT) Date: Tue, 10 Jun 2014 13:06:16 -0700 Message-ID: From: "Murray S. Kucherawy" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=001a1134d24441908504fb80dc09 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/iiMw4hZ9I9VovDIIfwuq6rSVUlc Subject: [dmarc-ietf] Moderation of Vlatko Salaj 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, 10 Jun 2014 20:06:20 -0000 --001a1134d24441908504fb80dc09 Content-Type: text/plain; charset=UTF-8 Colleagues, Under the procedures of BCP 94, the list administrators have decided to moderate the access of Vlatko Salaj to the mailing list, effective immediately, until 10 July 2014. If Mr. Salaj posts anything, it will come to us first, and we shall permit the message to be posted only if, in our opinion, it is a positive contribution to the WG discussion and is entirely on topic. Please do not post on Mr. Salaj's behalf. If you are asked to post something on Mr. Salaj's behalf and you do so, we will regard that as a violation of the moderators' decision, and will treat such acts as another vector of attack on the list. We shall respond to such attacks using our discretion under BCP 94. Best regards, Murray Kucherawy (dmarc list co-admin) --001a1134d24441908504fb80dc09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Colleagues,

Under the procedures of BCP 94, the lis= t administrators have decided to moderate the access of Vlatko Salaj to the= mailing list, effective immediately, until 10 July 2014. =C2=A0If Mr. Sala= j posts anything, it will come to us first, and we shall permit the message= to be posted only if, in our opinion, it is a positive contribution to the= WG discussion and is entirely on topic.

Please do not post on Mr. Salaj's behalf. =C2=A0If you are asked to= post something on Mr. Salaj's behalf and you do so, we will regard tha= t as a violation of the moderators' decision, and will treat such acts = as another vector of attack on the list. =C2=A0We shall respond to such att= acks using our discretion under BCP 94.

Best regards,

Murray Kucherawy (dmarc list co-admin)

--001a1134d24441908504fb80dc09-- From nobody Tue Jun 10 13:12:03 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C34151A02D0 for ; Tue, 10 Jun 2014 13:11:44 -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 cygkQxqzASya for ; Tue, 10 Jun 2014 13:11:43 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BAB51A0282 for ; Tue, 10 Jun 2014 13:11:43 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z12so4295340wgg.1 for ; Tue, 10 Jun 2014 13:11:42 -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=tYFkaX1djRoot5UT2A7xH0x/OG/FLVNMski7XNWEWIY=; b=eGA2jzQ1TeIEX6RWt9+9syuzt9ac7Cwhr6CoOdjee0S6C33PF7MPlbcycQBPbylb0g wc1Mz95QqBSNtgL6bPxWauamvMSzA/hieJgTcKnSOQqwy56zyNZqpVnfWJRcihrIqvVo 2NswKSyIvnuvTJ/pUuN7VBmEDVkqEKW9T60N9lmDlChZn3Y/R/m1v0bYo/amTv8QKCSL NOYQaVAiJS036gNQCpPmJ67ysEQLBQKkoAXs3VVLwpfmgoZJo/KOrVBKUtcFOqhoBiFQ eNC1tK6opsbJ3euthvrQlkZJ9K482JpfWXLT/SQ8iCDVkAOH0FQPJW4FQoirhHy6ovEv 8MKw== MIME-Version: 1.0 X-Received: by 10.181.8.67 with SMTP id di3mr40810097wid.8.1402431102208; Tue, 10 Jun 2014 13:11:42 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Tue, 10 Jun 2014 13:11:42 -0700 (PDT) In-Reply-To: <1402430166.64721.YahooMailNeo@web164603.mail.gq1.yahoo.com> References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <1402382240.57323.YahooMailNeo@web164601.mail.gq1.yahoo.com> <5396AA73.8040109@gmail.com> <1402384311.51951.YahooMailNeo@web164603.mail.gq1.yahoo.com> <5396B0E9.9010109@gmail.com> <1402386096.27670.YahooMailNeo@web164604.mail.gq1.yahoo.com> <53973001.3020104@isdg.net> <87vbs8pp1y.fsf@uwakimon.sk.tsukuba.ac.jp> <1402427776.29329.YahooMailNeo@web164602.mail.gq1.yahoo.com> <1402430166.64721.YahooMailNeo@web164603.mail.gq1.yahoo.com> Date: Tue, 10 Jun 2014 13:11:42 -0700 Message-ID: From: "Murray S. Kucherawy" To: Vlatko Salaj Content-Type: multipart/alternative; boundary=001a1134d244ab544504fb80ef7f Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/dA_u46_SUG0PxyC6kTml1Mz3Ukg Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 20:11:44 -0000 --001a1134d244ab544504fb80ef7f Content-Type: text/plain; charset=UTF-8 On Tue, Jun 10, 2014 at 12:56 PM, Vlatko Salaj wrote: > > the story of my life... i'm always in minority, fighting for > survival. > > It is entirely possible to fight for the minority without acting this way. It's unfortunate that you feel like your lifetime of frustration has to be taken out on this list. However, despite both public and private warnings and a brief period of remission, I find you have decided to continue your abrasive and non-constructive pattern of participation. Under the procedure in BCP 94, and in coordination with my Area Directors, your subscription to dmarc@ietf.org has now been placed under moderation and will remain so until July 10th. You may still post, but your postings will be held and will not be approved unless they are both constructive and on-topic. You may appeal this decision to Barry Leiba and/or Pete Resnick if you wish. -MSK --001a1134d244ab544504fb80ef7f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jun 10, 2014 at 12:56 PM, Vlatko Salaj <v= latko.salaj@goodone.tk> wrote:
=

the story of my life... i'm always in minority, fighting for
survival.


It is entirely p= ossible to fight for the minority without acting this way.

It's unfortunate that you feel like your lifetime of frustration has = to be taken out on this list.=C2=A0 However, despite both public and privat= e warnings and a brief period of remission, I find you have decided to cont= inue your abrasive and non-constructive pattern of participation.

Under the procedure in BCP 94, and in coordination with my A= rea Directors, your subscription to dmarc@ietf.org has now been placed under moderation and wi= ll remain so until July 10th.=C2=A0 You may still post, but your postings w= ill be held and will not be approved unless they are both constructive and = on-topic.

You may appeal this decision to Barry Leiba and/or Pete Resn= ick if you wish.

-MSK
--001a1134d244ab544504fb80ef7f-- From nobody Tue Jun 10 13:22:24 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE77E1A02D8 for ; Tue, 10 Jun 2014 13:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 rvr9rYjJCvVc for ; Tue, 10 Jun 2014 13:21:46 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id BF8861A02D0 for ; Tue, 10 Jun 2014 13:21:45 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id D786D3FA0B20; Wed, 11 Jun 2014 05:21:44 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id CA2491A32C5; Wed, 11 Jun 2014 05:21:44 +0900 (JST) From: "Stephen J. Turnbull" To: Hector Santos In-Reply-To: <53974C62.9050408@isdg.net> References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <87ppihgugl.fsf@uwakimon.sk.tsukuba.ac.jp> <5396E49C.2000808@isdg.net> <8738fcrhqz.fsf@uwakimon.sk.tsukuba.ac.jp> <53974C62.9050408@isdg.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 11 Jun 2014 05:21:44 +0900 Message-ID: <87tx7splbb.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/xucIWXzwY3T2wZnrem4XPoH-Xjo Cc: "dmarc@ietf.org" , Matt Simerson , "Murray S. Kucherawy" , "J. Gomez" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 20:21:47 -0000 Hector Santos writes: > Will you implement it? You need to implement it as part of the LSP > integration. What LSP integration? DMARC is an agreement between Author Domains and destination hosts. Mediators are not party to it. It's arguable that the host MTA should be checking DMARC authentication and alignment, but that's different from saying the list should. > understand you are a LSP. DMARC effects you differently, but we can't > throw out the proverbial baby. I don't care what *you* do with your proverbial baby. The point is that *LSPs* are mostly not in a position to say "Fork off" to Yahoo! subscribers. And subject tags, headers, footers, and removal of bloated attachments are services that are very popular with users, although these features break DKIM signatures. Since we're going to continue to provide those signature-breaking features, and lists are not going to ban Yahoo! subscribers, the policies you propose are simply not going to be used by a significant fraction of lists. Instead they're going to corrupt "From:" or wrap messages "From:" "p=reject" domains. And just as there's not a damn thing you can do to get Yahoo! to revert their policy to quarantine or none, there's not a damn thing you can do stop lists from sidestepping DMARC. > The demand is high to deploy system level rejections for older and > newer policy reasons. Not among Mailman list owners, it isn't. > >> Do you realize how many different MUAs exist? and the different forms > >> of MUAs? > > > > I haven't counted. How many are there? > > Lots, too long to list. I didn't need you to tell me that. I was hoping for useful data. > Is this practical business expert "opinion" acceptable? No. You assert that you are an expert, you assert various things are true or necessary, but you clearly lack understanding of the context of mailing lists that makes MLM developers provide the mitigations we do. So your advice is not trustworthy, not for list operators. > I'm cool with that, so what are the defaults? Maybe you can add user > options like: > > [X] I want to reject mail from unauthorized DMARC sites. I have no idea what you're trying to get at. What is an "unauthorized DMARC site"? Do we need to get permission to use DMARC? > Will you provide it to them or is it too "Draconian" for them to > have available? Do you even understand the technology? Lists are Mediators, they are not party to DMARC, and they don't need to be to provide that option. They just let the mail go through, and take care not to let the bounces bounce subscribers into disablement or unsubscription. Anyway, an expert like you should know that it's really inefficient to have the list bounce "unauthorized DMARC sites" when we can have the MTA do it. In fact, that's the point you've been trying to make to me over and over again (you would even like to reject before DATA, right?) So why are you talking to me when you should be lobbying the Postfix, Exim and Sendmail guys? > Well, it pointless to say "many" Why, thank you for caring so much about our problems. > because what the "many" is really suffering from is the lack of > options with the DMARC protocol. It is missing LSP provisions and > once that happens then you will have your tools to adjust > gracefully. You mean *if* DMARC gets LSP provisions. DKIM is what, 7 years old or so? Obviously 3rd party provisions are hard to implement. That may be for political reasons, as you have implied several times. But I don't care -- if politics means we won't get 3rd party authentication for another 7 years, lists will have to use alternative mitigations until then. And if it's actually a hard technology problem, it may take longer than that. Besides which, as expert as you claim to be, you should be aware that it may take several years before systems upgrade to the most recent versions of software. DMARC is here *now*, yahoo.com has a "p=reject" policy *now*, and we (the MLM developers) need to get mitigations into the pipeline *now* for immediate (or asap, anyway) use by our users. We cannot wait for your vaporware, as graceful as it may be when it at long last arrives in usable form. > But you have to agree the LSP needs to do the lookup or its > frontend receiver has to do the lookup and be aware of the ML part, > i.e. acceptable list addresses. Not at all. DMARC is an agreement (100% private and unsanctioned by the Internet, at this point in time) between Author Domains and destination hosts. Lists and the systems that host them are not parties. The list's host may very well check alignment on the way in, and guess what? it will be satisfied for legitimate list traffic. That doesn't help getting it delivered though. Note that the most efficient way to handle this task is going to vary by MTA, so although we may wish to publish FAQs to help our users (assuming any actually do wish to adopt the inflexible policy you advocate), it's clearly not the MLM dev's job to implement anything. > Stephen, I do believe that it is "Bad Policy" to be promoting a > concept of ignoring new growing policy protocols. That's FUD. Nobody is promoting "ignorance", and I don't appreciate you implying that I do. > It isn't going to help in the long run. DMARC is here. It isn't > going to go away. You're the only one who talks about DMARC going away as if anybody were seriously hoping it would. Nobody believes that is going to happen, nobody believes that Yahoo! is going to change its policy, either. I wish you would stop misinterpreting other people's positions, and I especially wish you would stop *posting* your misinformation. > Sure, its my opinion and I like to think I am more right than > wrong. :) That's beyond obvious. :( From nobody Tue Jun 10 13:33:07 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5226F1A02D3 for ; Tue, 10 Jun 2014 13:32:47 -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 cF2bIBc4FNHs for ; Tue, 10 Jun 2014 13:32:45 -0700 (PDT) Received: from mail.theartfarm.com (mail.theartfarm.com [66.128.51.165]) by ietfa.amsl.com (Postfix) with SMTP id 955551A02D0 for ; Tue, 10 Jun 2014 13:32:45 -0700 (PDT) Received: (qmail 69161 invoked by uid 89); 10 Jun 2014 20:32:44 -0000 Received: from unknown (HELO mail.theartfarm.com) (127.0.0.30) by mail.theartfarm.com with SMTP; 10 Jun 2014 20:32:44 -0000 Received-SPF: Pass (mail.theartfarm.com: domain of tnpi.net designates 50.159.99.59 as permitted sender) receiver=mail.theartfarm.com; identity=mailfrom; client-ip=50.159.99.59; helo=imac27.simerson.net; envelope-from= Received-SPF: None (mail.theartfarm.com: domain of imac27.simerson.net does not designate 50.159.99.59 as permitted sender) receiver=mail.theartfarm.com; identity=helo; client-ip=50.159.99.59; helo=imac27.simerson.net; envelope-from= Received: from imac27.simerson.net (c-50-159-99-59.hsd1.wa.comcast.net [50.159.99.59]) by mail.theartfarm.com (Haraka/2.5.0-toaster) with ESMTPSA id 7D0EDF01-5A95-489C-ABE4-227F41F40B26.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=AES128-SHA verify=FAIL); Tue, 10 Jun 2014 16:32:42 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Matt Simerson In-Reply-To: <87tx7splbb.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Tue, 10 Jun 2014 13:32:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <998FA07D-E6D7-41FB-A143-CE7B426E6763@tnpi.net> References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <87ppihgugl.fsf@uwakimon.sk.tsukuba.ac.jp> <5396E49C.2000808@isdg.net> <8738fcrhqz.fsf@uwakimon.sk.tsukuba.ac.jp> <53974C62.9050408@isdg.net> <87tx7splbb.fsf@uwakimon.sk.tsukuba.ac.jp> To: "dmarc@ietf.org" X-Mailer: Apple Mail (2.1878.2) X-Haraka-p0f: os="MacOS X 10.9 or newer (sometimes iPhone " link_type="Ethernet or modem" distance=11 total_conn=2 shared_ip=N X-Haraka-GeoIP: US, WA, Seattle, 2699km X-Haraka-GeoIP-Received: 50.159.99.59:US X-Haraka-ASN: 7922 50.128.0.0/9 X-Haraka-ASN-MONKEY: asn=7922 net=50.128.0.0/9 org=Comcast Cable Communications, Inc. date=1997-02-14 country=US X-Haraka-FCrDNS: c-50-159-99-59.hsd1.wa.comcast.net X-Spam-ASN: X-Spam-DCC: sonic.net: spamassassin.tnpi.net 1156; Body=1 Fuz1=1 Fuz2=1 X-Spam-SNF-Result: 0 (Standard White Rules) X-Spam-MessageSniffer-Scan-Result: 0 X-MessageSniffer-Rules: 0-0-0-5143-c X-MessageSniffer-Clean: Yes X-Spam-MessageSniffer-Rules: 0-0-0-5143-c X-MessageSniffer-Clean: Yes X-Spam-GBUdb-Analysis: 0, 50.159.99.59, Ugly c=0.071429 p=-1 Source Normal X-MessageSniffer-Scan-Result: 0 X-MessageSniffer-Rules: 0-0-0-5143-c X-MessageSniffer-Clean: Yes X-Haraka-Karma: connect: 5, history: 411, total_connects: 442, neighbors: -5523, pass:fcrdns.fcrdns, relaying, auth_user, fail:fcrdns.fail, neighbors, dnsbl.fail, helo.checks.fail, skip:penalty DKIM-Signature: v=1; a=rsa-sha256; bh=DptcAztfuJltPLEjJYJMGQNc2Q7ltvQEjqj3je7ECLU=; c=relaxed/simple; d=tnpi.net; h=from:subject:date:message-id:to:mime-version; s=mar2013; b=MFstamWRvZlilAomlwmDf43zgMGDXSWy42sGzcdL5UfLr6hIOPJNzziuUD8JftA7Mjd6gtp6GaA4LXR3FeA1BzIiQfW2PJVHrEf/iVYdYN8Op1/3RE4Cz8ztZvg77xTpZ7wGpy2hfT6p98vswr4mAKD6NBR0y+CxCCMwTA2VIbiHq+HRmXIk8jIysCjFVmqerwD50czJsDv0ewWESFVhBlKli63l4Se9mcQRBPos+ZyRpl76cVaPLYlPesdKvkM6X4tdzAX3QXhicN07KP8pwjlgTOEYvnwX5ujRDG7adMD4QaNKsKle103k1uvolN5eU0Y8sFoeTBAIuRMd9cmLaA== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/58ojyfV7KqUy5S9NjUB1KYney34 Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 20:32:47 -0000 On Jun 10, 2014, at 1:21 PM, Stephen J. Turnbull = wrote: > Hector Santos writes: >=20 >> understand you are a LSP. DMARC effects you differently, but we = can't=20 >> throw out the proverbial baby. >=20 > I don't care what *you* do with your proverbial baby. The point is > that *LSPs* are mostly not in a position to say "Fork off" to Yahoo!=20= > subscribers. And subject tags, headers, footers, and removal of > bloated attachments are services that are very popular with users, If message headers and footers are so popular, how do you explain the = continued "please unsubscribe me posts" sent to practically every = mailing list? Message trailers have insured that the answer is *right = there* in every single message. Message trailers are part of the message = users have been trained to recognize as "noise" and skim right over. = That's why I didn't hesitate to remove them when I made my mailing lists = DKIM compatible. Also while it's certainly true that subject prefixes are popular with = list operators, I didn't hear a single peep from my list users when I = removed them. I doubt anyone noticed. Granted, mine is a small sample = group of a few hundred mail server operators, but I would have expected = *someone* to notice.=20 Matt= From nobody Tue Jun 10 15:30:59 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F751A032B for ; Tue, 10 Jun 2014 15:30:57 -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 Xgho3b1pH5B4 for ; Tue, 10 Jun 2014 15:30:54 -0700 (PDT) Received: from ntbbs.santronics.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4B13B1A0328 for ; Tue, 10 Jun 2014 15:30:54 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=6039; t=1402439444; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=lm1MqOgt3MJXNiHmvaXkzZ3PlL8=; b=rgNGgIHaTxGBOfuwZTdU XHP+GkQLkLUXhJpen+zFmoftmT05QlEDMCLNDaGmupCYYbwZYLdhLnKEAHpyFz0u oj8EKLfxuidNLNSDt39dIftc1zz5dS07um2sKntGyWWerhpaK7ZQ7NLL677Ux5qS 24VDYqRW/PevJhNyU50GBI4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 10 Jun 2014 18:30: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; Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1919566063.17216.2276; Tue, 10 Jun 2014 18:30:42 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=6039; t=1402439276; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=A4zOyjo xzjan5wqRAIuoBvsuyhuiSGrip4Ajom67ZYw=; b=fkaRcmvc16IHbUITqVCp+fm G7FyoWlWNJ47Wa5QddklQf1cIZ96P1jTu4bHRdo9GKHaSANg34h/DEuaZDxPKWOV otjGC80dvaIvI6TEHROFUBmDMOkmL4P4ylks05vCLDons0isvrHTkAvRzOZQWkK4 77MapTxbxhh9rxKOH+Nk= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Tue, 10 Jun 2014 18:27: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 1935923515.9.4036; Tue, 10 Jun 2014 18:27:55 -0400 Message-ID: <53978711.6080608@isdg.net> Date: Tue, 10 Jun 2014 18:30:41 -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: "Stephen J. Turnbull" References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <87ppihgugl.fsf@uwakimon.sk.tsukuba.ac.jp> <5396E49C.2000808@isdg.net> <8738fcrhqz.fsf@uwakimon.sk.tsukuba.ac.jp> <53974C62.9050408@isdg.net> <87tx7splbb.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87tx7splbb.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/hOGcN8-bOoGe5CwNaqka0M73an8 Cc: Matt Simerson , "dmarc@ietf.org" , "Murray S. Kucherawy" , "J. Gomez" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 22:30:57 -0000 On 6/10/2014 4:21 PM, Stephen J. Turnbull wrote: > Hector Santos writes: > > > Will you implement it? You need to implement it as part of the LSP > > integration. > > What LSP integration? DMARC is an agreement between Author Domains > and destination hosts. Mediators are not party to it. Once you got involved with DKIM, you became a party of it. > It's arguable that the host MTA should be checking DMARC > authentication and alignment, but that's different from saying > the list should. Someone has to do it. Thats an implementation issue. The MTA, the LSP, whoever, whatever, the entry point is where it needs to be done. I thought this was understood. > I didn't need you to tell me that. I was hoping for useful data. You really don't need a list of MUAs, do you? Don't think so. >> Is this practical business expert "opinion" acceptable? > > No. You assert that you are an expert, you assert various things are > true or necessary, but you clearly lack understanding of the context > of mailing lists that makes MLM developers provide the mitigations we > do. So your advice is not trustworthy, not for list operators. You are being rude again, this is completely off-base. I'm an engineer. In principle, I prefer to follow protocols rather than break them, and if they is a bug in the protocol, then I will help in addressing it. I believe that is where we are at. > I have no idea what you're trying to get at. What is an "unauthorized > DMARC site"? You indicated your preference not to reject at the system level. Perhaps user level? >> Will you provide it to them or is it too "Draconian" for them to >> have available? > > Do you even understand the technology? Rude again. > Lists are Mediators, they are not party to DMARC, and they don't need > to be to provide that option. This is why we have a problem. You think the LSP does not need to do any lookups. This is major hurdle #1 the expected pending IETF DMARC WG needs to consider in its charter. > Anyway, an expert like you should know that it's really inefficient to > have the list bounce "unauthorized DMARC sites" when we can have the > MTA do it. In fact, that's the point you've been trying to make to me > over and over again (you would even like to reject before DATA, > right?) So why are you talking to me when you should be lobbying the > Postfix, Exim and Sendmail guys? The problem is not with the SMTP system. Its the LSP. > Besides which, as expert as you claim to be, you are being rude again... but go on... > you should be aware that > it may take several years before systems upgrade to the most recent > versions of software. DMARC is here *now*, yahoo.com has a "p=reject" > policy *now*, and we (the MLM developers) need to get mitigations into > the pipeline *now* for immediate (or asap, anyway) use by our users. > We cannot wait for your vaporware, as graceful as it may be when it at > long last arrives in usable form. Its a tough situation. That is why I am trying to figure what it is taking so long for the IETF to get going with a DMARC WG. But I was made aware, things are in the works. So we wait... We really do need another emergency "MARID" working group started. You can do whatever you think as necessary as a temporary solution, I don't recommend it, I won't add it to our wcListServer product, but I can understand why you are passionate about it. But it is not the solution by any measure. I can only hope that is remains to be a temporary isolated (to GNU Mailman) kludge. My thinking is this will be the case. Once we get the IETF endorsement to proceed with known methods that have been proposed and already implemented with "running code" then the others will follow. I believe the Yahoo's will support it but we still have to remember there will be domains that DO NOT want you to intentionally bypass the security. So you will need to decide what to do with them. In principle, the LSP is part of the network and needs to support it whether that is done with a MTA-receiver component or otherwise. > Not at all. DMARC is an agreement (100% private and unsanctioned by > the Internet, at this point in time) between Author Domains and > destination hosts. The LSP is a destination host for the user submitting list mail. The LSP is part of the total picture. > Note that the most efficient way to handle this task is going to vary > by MTA, so although we may wish to publish FAQs to help our users > (assuming any actually do wish to adopt the inflexible policy you > advocate), it's clearly not the MLM dev's job to implement anything. The MTA-Receiver is where it should be at. But what if the MTA receiver does not support DMARC? "Installation note for GNU Mailman. Requires DMARC compliant SMTP receivers." Thats fine. Our MLS works the same way. >> Stephen, I do believe that it is "Bad Policy" to be promoting a >> concept of ignoring new growing policy protocols. > > That's FUD. Nobody is promoting "ignorance", and I don't appreciate > you implying that I do. You stated in a very militant manner that your LSPs software will ignore DMARC. I don't recommend it but I understand the dilemma. Other systems will just not worry about the domains that do have strong policies and let those accounts just automated get unsubscribed. This is what happen in our support list. >> It isn't going to help in the long run. DMARC is here. It isn't >> going to go away. > > You're the only one who talks about DMARC going away as if anybody > were seriously hoping it would. Being rude again.... > Nobody believes that is going to > happen, nobody believes that Yahoo! is going to change its policy, > either. I wish you would stop misinterpreting other people's > positions, and I especially wish you would stop *posting* your > misinformation. And again.... Ok, I know where you stand. I hope you understand where I stand. -- HLS From nobody Tue Jun 10 15:55:32 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06391A0264 for ; Tue, 10 Jun 2014 15:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_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 rXY0hxtdzt2T for ; Tue, 10 Jun 2014 15:55:28 -0700 (PDT) Received: from vincent.hireahit.com (vincent.hireahit.com [23.19.120.58]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 884751A00A5 for ; Tue, 10 Jun 2014 15:55:28 -0700 (PDT) Received: from VINCENT.hireahit.com by hireahit.com (vincent.hireahit.com) (SecurityGateway 3.0.1a) with SMTP id SG000900744.MSG for ; Tue, 10 Jun 2014 15:55:28 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=hireahit.com; s=MD-20140321; t=1402440926; x=1403045726; q=dns/txt; h=Received: Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; bh=wXcidXnv5UutEnVOFSz2hR3vskbXyVWw22bfHUCyEcY=; b=t9lQNyx+xx4de yv3rgwUdLfrfVcjRJLnRAkv0EvynIpnCmJ0vzPekSZr88+AmZgnnBk+Dce04Zr1A IrVdX/FxG3DGt4o0C4r9vo//wRKQ6Tzcb6r+6nKdEmWOIjWSnU3DRhZfGwxiyE4K /MIuCsqDLxjsl5PsBClvWVi8LjZfwE= Received: from [172.24.0.151] ([184.68.44.226]) by VINCENT.hireahit.com (VINCENT.hireahit.com [23.19.120.58]) (Cipher TLSv1:AES-SHA:128) (MDaemon PRO v14.0.2) with ESMTP id 23-md50000007905.msg for ; Tue, 10 Jun 2014 15:55:26 -0700 X-Spam-Processed: VINCENT.hireahit.com, Tue, 10 Jun 2014 15:55:26 -0700 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: davew@hireahit.com X-MDRemoteIP: 184.68.44.226 X-Return-Path: davew@hireahit.com X-Envelope-From: davew@hireahit.com X-MDaemon-Deliver-To: dmarc@ietf.org Message-ID: <53978CD9.3000907@hireahit.com> Date: Tue, 10 Jun 2014 15:55:21 -0700 From: Dave Warren User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <87ppihgugl.fsf@uwakimon.sk.tsukuba.ac.jp> <5396E49C.2000808@isdg.net> <8738fcrhqz.fsf@uwakimon.sk.tsukuba.ac.jp> <53974C62.9050408@isdg.net> <87tx7splbb.fsf@uwakimon.sk.tsukuba.ac.jp> <998FA07D-E6D7-41FB-A143-CE7B426E6763@tnpi.net> In-Reply-To: <998FA07D-E6D7-41FB-A143-CE7B426E6763@tnpi.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/2bv46P9W4w6CNwbBy2-SdqqPnjY Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 10 Jun 2014 22:55:29 -0000 On 2014-06-10 13:32, Matt Simerson wrote: > If message headers and footers are so popular, how do you explain the continued "please unsubscribe me posts" sent to practically every mailing list? Message trailers have insured that the answer is *right there* in every single message. Message trailers are part of the message users have been trained to recognize as "noise" and skim right over. That's why I didn't hesitate to remove them when I made my mailing lists DKIM compatible. > > Also while it's certainly true that subject prefixes are popular with list operators, I didn't hear a single peep from my list users when I removed them. I doubt anyone noticed. Granted, mine is a small sample group of a few hundred mail server operators, but I would have expected *someone* to notice. I've been surprised how many otherwise-technically-competent people use subject tags to filter mailing lists. However, I suspect much/most of this could go away if MUAs started displaying List-* information in a useful way, and made filtering on those headers easier than the Subject header or the To header. Either way, if message footers and subject tags have to go away and that gets us DKIM signatures through mailing lists (which seems to mostly be possible now), that seems like a step forward. On the other hand, it's only a matter of time before some idiot DKIM signs the (lack of) List-ID or List-Unsubscribe header while using a DMARC reject policy, resulting in the list engine damaging the DKIM signature. I'd class this as abusive and ban such posts from any list I operate, but no doubt it's only a matter of time before it happens. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren From nobody Tue Jun 10 22:10:50 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19B41A036B for ; Tue, 10 Jun 2014 22:10:49 -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_44=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 kNVOolLMpEgE for ; Tue, 10 Jun 2014 22:10:47 -0700 (PDT) Received: from news.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 12B751A00E8 for ; Tue, 10 Jun 2014 22:10:46 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2991; t=1402463439; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=7NDwPpViIp1c9pcZU6ZumOJrmo4=; b=HqLsVDOQeTej1CQQ1jBR 1b57cjHlmyWQHwjJLoXmDzXnk5oVDNVvw4PbyCeJLFndYS2XQcTLw3dwtJK/1q7B j3aOYpg2F2KcJ/vhv6CuzucK8o41Lb2gFznJeB/5a5O40KQWPA+AJJOAz18Lu/XL tkV6ZNi4fFaFG0IcMageHuQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 11 Jun 2014 01:10: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; Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1943561762.17216.1340; Wed, 11 Jun 2014 01:10:38 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2991; t=1402463269; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=mewzzMo s6KPfvAKQ4F75MDyO7uxk5sKvEGVxG2+YUmg=; b=FwyYTqV43LH8CRc3UR2PJ4P tje0A9hmY0e/E3CGl3Rx9n09DV910z4gg0ADa5zeVe3qw2+XhQEfzed36L6GkBYq hJE6+yo5NoeWJh95/68UE4SKtE48DYtxgvzOzVCykJq7vluURm+lZ9kbEMT765oA X6RcJdodBtH3pJQpzZxs= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 11 Jun 2014 01:07: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 1959916281.9.1692; Wed, 11 Jun 2014 01:07:48 -0400 Message-ID: <5397E4CB.6020305@isdg.net> Date: Wed, 11 Jun 2014 01:10:35 -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: Dave Warren , dmarc@ietf.org References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <87ppihgugl.fsf@uwakimon.sk.tsukuba.ac.jp> <5396E49C.2000808@isdg.net> <8738fcrhqz.fsf@uwakimon.sk.tsukuba.ac.jp> <53974C62.9050408@isdg.net> <87tx7splbb.fsf@uwakimon.sk.tsukuba.ac.jp> <998FA07D-E6D7-41FB-A143-CE7B426E6763@tnpi.net> <53978CD9.3000907@hireahit.com> In-Reply-To: <53978CD9.3000907@hireahit.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/u6_Ydqa0sPfUb5-Uz-sHSRUZxts Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 11 Jun 2014 05:10:49 -0000 On 6/10/2014 6:55 PM, Dave Warren wrote: > I've been surprised how many otherwise-technically-competent people > use subject tags to filter mailing lists. However, I suspect much/most > of this could go away if MUAs started displaying List-* information in > a useful way, and made filtering on those headers easier than the > Subject header or the To header. Some MUAs have began to use the List-ID, especially on the reply side of things, so now you have a "Reply to List" button/option on some of them. Opera Mail also uses List-ID to show a "Mailing List" collapsible panel/view selection box of your subscriptions. For Thunderbird (tbird), I had to manually added a message rule to use the List-ID but the first time, I had to add the new header to the selection of headers list. > Either way, if message footers and subject tags have to go away and > that gets us DKIM signatures through mailing lists (which seems to > mostly be possible now), that seems like a step forward. I believe for some markets, there may be a legal requirement to add footers. I think mail can survive, especially where its very active, bugs will and have been fixed. But there some legacy systems and someone has to tweak them. I believe in the chain of trust concept. It is ok for the LSP do resign. I just think it doesn't help the security when unauthorized signing is unchecked. For TBIRD, I added two DKIM rules in TBIRD to add two color tags: Green "DKIM PASS" Red "DKIM FAIL" This allowed me to explore problem areas. By now, we pretty much know the reasons, the original 1st party signature fails. My backend verified this message from you and it shows: Authentication-Results: dkim.winserver.com; dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org; adsp=fail policy=unknown author.d=hireahit.com signer.d=ietf.org (unauthorized signer); dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=hireahit.com header.s=MD-20140321 header.i=hireahit.com; adsp=pass policy=unknown author.d=hireahit.com signer.d=hireahit.com (originating signer); First, if you add the ADSP/ATPS recods your hireahit.com zone, it all works for the 3rd party ietf.org resigner. _adsp._domainkey.hireahit.com IN TXT "dkim=unknown; atps=y; asl=ietf.org;" PQ6XADOZSI47RLUIQ5YOHG2HY3MVJYOO._atps.hireahit.com IN TXT "v=atps01; d=ietf.org;" This authorizes ietf.org and you will have adsp=pass. You can use this wizard to explore the record and create other authorizations. http://www.winserver.com/public/wcadsp Second, notice the DKIM_BODY_HASH_MISMATCH. This is pretty much a signal it was a body integrity error, not the signature itself. So all the 5322 Headers are fine. This is good information to use in logic. But if you use ADSP/ATPS, then you also telling the world, that your original signature doesn't matter any more after it was resigned by the trusted signer. All we need to do is apply the same idea to DMARC. -- HLS From nobody Tue Jun 10 22:15:08 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C6D1A036B for ; Tue, 10 Jun 2014 22:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 NMiwP9if9eQY for ; Tue, 10 Jun 2014 22:15:03 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 476C61A00E8 for ; Tue, 10 Jun 2014 22:15:03 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id A8C033FA0158; Wed, 11 Jun 2014 14:15:02 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 9CFFF1A32C5; Wed, 11 Jun 2014 14:15:02 +0900 (JST) From: "Stephen J. Turnbull" To: Matt Simerson In-Reply-To: <998FA07D-E6D7-41FB-A143-CE7B426E6763@tnpi.net> References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <87ppihgugl.fsf@uwakimon.sk.tsukuba.ac.jp> <5396E49C.2000808@isdg.net> <8738fcrhqz.fsf@uwakimon.sk.tsukuba.ac.jp> <53974C62.9050408@isdg.net> <87tx7splbb.fsf@uwakimon.sk.tsukuba.ac.jp> <998FA07D-E6D7-41FB-A143-CE7B426E6763@tnpi.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 11 Jun 2014 14:15:02 +0900 Message-ID: <87ppigowmh.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/b_1LXNVvEdPzD4m6QozJwlI0eUQ Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 11 Jun 2014 05:15:06 -0000 Matt Simerson writes: > If message headers and footers are so popular, how do you explain > the continued "please unsubscribe me posts" sent to practically > every mailing list? Bell curve. Some people are 2-sigma self-centered, and others are 2-sigma clueless. What else is new?[1] Note that the kind of people who answer FAQs do like having the footer so they can say "just click on the link in the footer of any message, including this one." > Also while it's certainly true that subject prefixes are popular > with list operators, I didn't hear a single peep from my list users > when I removed them. Sure, there are groups like that, some quite large and varied, as yours seems to be. On the other hand, I've participated in a couple of lists where there was vociferous opposition to removing them from several users because they had MUA filters based on them. (Whether they constituted a significant fraction of the membership is unclear.) Removal of prohibited content is not so easily addressed, as left to their own devices users' .doc and .mp4 files can constitute a large fraction of outgoing bandwidth from list servers that otherwise don't need much (on a couple of my lists we still get the occasional oldtimer sending core files for debugging!) Footnotes: [1] There's also a long-standing bug in Mailman itself, which is that it requires some effort find the unsubscribe page even if you click on the link in the footer. From nobody Tue Jun 10 23:07:12 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A641A03A5 for ; Tue, 10 Jun 2014 23:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 OFUcbi1Fc8Ls for ; Tue, 10 Jun 2014 23:07:07 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id C82591A039C for ; Tue, 10 Jun 2014 23:07:07 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id EB1893FA0158; Wed, 11 Jun 2014 15:07:06 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id D1F9A1A32C5; Wed, 11 Jun 2014 15:07:06 +0900 (JST) From: "Stephen J. Turnbull" To: Rich Kulawiec In-Reply-To: <20140609103346.GB16003@gsp.org> References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <20140609103346.GB16003@gsp.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Wed, 11 Jun 2014 15:07:06 +0900 Message-ID: <87mwdkou7p.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/lCedVye0_geD8TFFCDsF3A0L52E Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 11 Jun 2014 06:07:09 -0000 Rich Kulawiec writes: > But that's not really relevant here. The flooding propagation > model of Usenet is quite different from the model used by mailing > lists. I'm not sure if it's been made clear already or not, but the Gmane model (copied by the experimental Mailman add-on) is a NNTP network per site (perhaps multiple lists), ie, a star topology. I was not suggesting that mailing lists become Usenet. I was suggesting that NNTP would be an alternative transport to SMTP, which might have fewer security issues. Partly just because it's obscure, but more fundamentally because *as a point-to-point transport* it's a pull protocol, and so inherently less attractive to spammers and phishers. (That's based on zero careful analysis, so feel free to give me a clue. NB To me the point of this idea is that in the medium term MLs may be able to avoid DMARC by avoiding SMTP, which would reduce the need for this group to consider mailing lists. Another protocol which has been proposed as an alternative transport is IMAP4.) For redundancy, of course groups of sites might find it useful to federate in the manner of Usenet. But that's not the point as far as I am concerned. Regards, From nobody Wed Jun 11 07:16:05 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D7F1A053B for ; Wed, 11 Jun 2014 07:15:59 -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 Z12_VN2EHp_n for ; Wed, 11 Jun 2014 07:15:54 -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 C95C21A0538 for ; Wed, 11 Jun 2014 07:15:53 -0700 (PDT) Received: (qmail 89454 invoked from network); 11 Jun 2014 14:15:52 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 11 Jun 2014 14:15:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=121a.53986497.k1406; i=johnl@user.iecc.com; bh=UtL+AAU4GbZIg4TIJ7upBFEQoz7MNL4IupIu14VlZzA=; b=fPHYv0bWJSV0+8wULipH8gau180TiPA/ZzMRhu7/nIeNBJLIzXN2F9bClDX8yi5rBvmBwmj7e52r+89NMPeqi2G0HKn0/c3vb6EbFL3g3U/ymVtbHTNj7IzBtQAtgwEcsz3T/ySDrQXU5gHsBwAM0C/1GjZMrzqzQA3cwpOfJA6bcFFhuhqm19gGF959GMwNi7XkTwfGf/LlOIlr9zFaXR9AMXJK2YCPH7/PPKh61fPgk65wmDqSlzjwY5blrzYZ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=121a.53986497.k1406; olt=johnl@user.iecc.com; bh=UtL+AAU4GbZIg4TIJ7upBFEQoz7MNL4IupIu14VlZzA=; b=ifWjMR52x60erweBUevY16PHN49AhwIkkrht4E4wgj9m7G5yq58VKb4tce5P0wrKn5MckeBRVgIJLaXAYZbzHnMU8pSCf3VlS3WWY8qFrFUJr3B1xlPJKomZf7qUPVtdFE1hJsvrPRFP7+T2A0a0NZ9pi7MSZnsdYWDB6waWYmv0IfGLmuHYlktgQyYa/OQ6QRDQada1marSSybVr3BJY0Jl6T5VckYomdWe/+IHOKPYqr7TH5UF3JjCQbS/kryL Date: 11 Jun 2014 14:15:29 -0000 Message-ID: <20140611141529.4633.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <5397156F.8010603@gmail.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/XjXup2eYNa89yoAwzC_n0o6lPOo Cc: dcrocker@gmail.com Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Wed, 11 Jun 2014 14:16:00 -0000 This looks like a cleaner version of my forwarding token proposal. >> You're constraining it to use by a specific, very small set of domains, >> and only for a limited time. > >Then again, let's note that this double-signed mail is going to show up >at some receivers that don't know about DKIM-delegate. Right. So if you don't want people using unforwarded weak signatures for reputation management, you need to put something into them so that old clients don't accept them as signatures and ignore the t= tag. Either call them something other than DKIM-Signature, or do a version bump to v=2. R's, John From nobody Wed Jun 11 07:45:13 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94EA1A0127 for ; Wed, 11 Jun 2014 07:45: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 FTOt7NraMRfy for ; Wed, 11 Jun 2014 07:45:08 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360101A0113 for ; Wed, 11 Jun 2014 07:45:08 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id cc10so3560093wib.5 for ; Wed, 11 Jun 2014 07:45:06 -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=dOrng7SbnHw9E1BetyovJv0NxqS0KVfXE+zzH7moe60=; b=IB2In+n65jxQDHVW5RtRisF79/v5h7N8tWtfPzXdjHx3ECzuRQXI8dulFeOiGriXEA MLQKILpwyCmB9lMfj9Y0FMRW21R7mcL0q+KYPeKzxVSh8Ssk2w/SvTgEaLAARl9lgYm1 Fsytoxt1+VNAuA7x5N/shtDkJa0dyT0sHG6H3+d1D45P3Yu644HLuMKyHA5OOYT2MPTB k+ogUW9ft6HCgt0gpY+gPXcaF4nz75W4oeoQj9r7saU7BOqSAtqxMKkV4MtkkpJCx2Wx myl1Y/ASw/7GWyacvRVWzDbYtbJKfrH16ULr0bLXamKFROngytDwunQRzGbs7Sn0D7+c 1Olg== X-Received: by 10.194.1.242 with SMTP id 18mr53472226wjp.22.1402497906585; Wed, 11 Jun 2014 07:45:06 -0700 (PDT) Received: from ?IPv6:2001:730:40:4:b012:9ae5:2f7c:209b? ([2001:730:40:4:b012:9ae5:2f7c:209b]) by mx.google.com with ESMTPSA id ge6sm5754756wic.0.2014.06.11.07.45.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Jun 2014 07:45:05 -0700 (PDT) Message-ID: <53986B38.2010401@gmail.com> Date: Wed, 11 Jun 2014 16:44:08 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John Levine , dmarc@ietf.org References: <20140611141529.4633.qmail@joyce.lan> In-Reply-To: <20140611141529.4633.qmail@joyce.lan> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/1utBiLdwakSreQvfiMqk51x5uko Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Wed, 11 Jun 2014 14:45:10 -0000 On 6/11/2014 4:15 PM, John Levine wrote: > So if you don't want people using unforwarded weak signatures > for reputation management, you need to put something into them so that > old clients don't accept them as signatures and ignore the t= tag. > Either call them something other than DKIM-Signature, or do a version > bump to v=2. If a receiver cares about 'strength' (or perhaps robustness) of signatures, they should pay attention to that. This does not require changes to DKIM. Rather, it requires receivers being diligent. The issue has nothing to do with DKIM-Delegate. That is, -Delegate is not creating the issue. Signers have always been free to hash less or more of the message. So while -Delegate might be making the issue more salient, by making everyone more aware of it, the issue already existed. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jun 11 07:56:48 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB6B1A0148 for ; Wed, 11 Jun 2014 07:56:46 -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 XO1cL4Hiv_0a for ; Wed, 11 Jun 2014 07:56:45 -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 8ACC71A0141 for ; Wed, 11 Jun 2014 07:56:45 -0700 (PDT) Received: (qmail 96611 invoked from network); 11 Jun 2014 14:56:44 -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:cleverness; s=17962.53986e2c.k1406; bh=VJ3hODAoRFT7emGSbfJ0xjiXHyl1MGYDOFAeNuC9Uhc=; b=acBGZBikOaM+I1Me23KS+Nsl8LPh3dVl1eOjp6EY3VMAxd4sf1u/kr1oDscwexMi2CPYq3TpikuCwKoEcCY++WMIVw9EwcpbPMgVrqJFpmpUy5Y9kG06SGy7ck2bWHG/VpqsT1qpVIQJ64q51c5FtuhEZ7YF6tZW8UJYa2xRV2KFtKnjVLvzhw6kavUafPWo+HHRHsmN6ktkEo79C4/DELnTMR1B48Mf7hx+NKyO7TmYYl/cwva1P48G7uXBqvcN 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:cleverness; s=17962.53986e2c.k1406; bh=VJ3hODAoRFT7emGSbfJ0xjiXHyl1MGYDOFAeNuC9Uhc=; b=GRza6ekK9/p+lCztp6jgpxdabT7WhHjBO/nQEo/ZROlKpVe/wP9HVi80wtJQcv+yq4X4o/zrOG5xcM0rhmuEWlBOLHj8sPrDAds2j4hKjkAfg3xN+r+SC2Pp7duwiWDf24Gke8EKWtf/310DKBKy4M1k2DDE2/pJFnoRIeVx17yh8301d7u5wER7DK59MqwMzj4k1vN5XygaayBL+EBMnFQ67K69zv/dw6CDmaVe8Zkpc9FCh6QAbDDrpJOiP7Pp 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; 11 Jun 2014 14:56:44 -0000 Date: 11 Jun 2014 16:56:42 +0200 Message-ID: From: "John R Levine" To: "Dave Crocker" In-Reply-To: <53986B38.2010401@gmail.com> References: <20140611141529.4633.qmail@joyce.lan> <53986B38.2010401@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/H3v8ziYHu19jhSRKlqTpWBWY54o Cc: dmarc@ietf.org, John Levine Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Wed, 11 Jun 2014 14:56:46 -0000 > If a receiver cares about 'strength' (or perhaps robustness) of > signatures, they should pay attention to that. It is my impression that the idea here is that a signature with t= isn't interesting unless there's a matching signature with d=. Or did I misunderstand that. You are of course correct that senders have always been allowed to create weak signatures, but until now there has been little incentive to do so. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Wed Jun 11 08:02:00 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D46C1A011F for ; Wed, 11 Jun 2014 08:01:58 -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 2PUNumA1NrGg for ; Wed, 11 Jun 2014 08:01:57 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C421F1A00FA for ; Wed, 11 Jun 2014 08:01:56 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b13so4289067wgh.23 for ; Wed, 11 Jun 2014 08:01: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=FCBRn8kuCllkjziL52vOeewPcM2EqXHn/zZvX6bzY9U=; b=CLFSjzIg0zTgcHpa2EwmNjZoB2LuiZ0zXSrQ5V3KP3ZtFIpnb0UdyVHmOmCeroRiIA 4+eJPC7ERMvccFey+ow0nfmE9gcKmOGAjmwZqzrBNHZgV2e4ZlwdRWDxQPNc2ZmkBGA+ bQ9EiJLgqjJhHMOxK6VVFDkrzqioMWwSZze2Wpwxn/bsL9PE+JnMP0kQUFE9wXFzNr8Z zS1Tf0HHEfqP+3jX0H3ZgZ/h8BEFGOkwvevUzcH2POpGS/wS9nu31C35zBj5HgdOGXVl nRZW1Ao6Ru63pSWlC7I86a1YjRHGyBs4x91qijC1ZrinVuJgt/VeIs7Gb+ExUP6K+MKh Hozw== X-Received: by 10.180.36.241 with SMTP id t17mr48833501wij.38.1402498910187; Wed, 11 Jun 2014 08:01:50 -0700 (PDT) Received: from ?IPv6:2001:730:40:4:b012:9ae5:2f7c:209b? ([2001:730:40:4:b012:9ae5:2f7c:209b]) by mx.google.com with ESMTPSA id m1sm27766946wib.20.2014.06.11.08.01.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Jun 2014 08:01:49 -0700 (PDT) Message-ID: <53986F24.8020404@gmail.com> Date: Wed, 11 Jun 2014 17:00:52 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: John R Levine References: <20140611141529.4633.qmail@joyce.lan> <53986B38.2010401@gmail.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/EMz4She-0-nuNVCsvToRjdHLqP0 Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Wed, 11 Jun 2014 15:01:58 -0000 On 6/11/2014 4:56 PM, John R Levine wrote: >> If a receiver cares about 'strength' (or perhaps robustness) of >> signatures, they should pay attention to that. > > It is my impression that the idea here is that a signature with t= isn't > interesting unless there's a matching signature with d=. Or did I > misunderstand that. It is provided because there is a -Delegate enabled, yes. On the other hand, the concern that the token signature will get used when it shouldn't essentially means it is interpreted without awareness of -Delegate. Hence this is merely the case of two, competing signatures and deciding which to choose. That's a generic DKIM issue, and its resolution depends on the DKIM evaluation. > You are of course correct that senders have always been allowed to > create weak signatures, but until now there has been little incentive to > do so. Hence my citing 'salience'. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jun 11 08:10:01 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F881A015B for ; Wed, 11 Jun 2014 08:10:00 -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 mhnMY8E4PZpr for ; Wed, 11 Jun 2014 08:09:57 -0700 (PDT) Received: from mail.catinthebox.net (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C9F1A1A00F0 for ; Wed, 11 Jun 2014 08:09:56 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=6288; t=1402499392; h=Received:Received: Subject:From:Message-Id:Date:To:Organization:List-ID; bh=7YYVDOZ T0tkNzeNhDraBy7eJREI=; b=f5afaRF8FtO9j/ZOLOoX8jZOann0UTYIoZ1iXTC GlNkKqRlid6d2zD8uiMmzr9DR1NmLQWSdVCVLxZmeY5elcNd5TtG9asRFuLDVrxR 85QOSLufOhNt5r1UCOUcZDb9lBDHeFVWjoNdJlMgdyxK7AkfKT4DgH9VIyXAk7Zy ZaB4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 11 Jun 2014 11:09:52 -0400 Received: from [192.168.1.221] (99-72-160-212.lightspeed.miamfl.sbcglobal.net [99.72.160.212]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1979514236.18742.5604; Wed, 11 Jun 2014 11:09:51 -0400 References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <1755889339.33315.1402383131643.JavaMail.zimbra@peachymango.org> <1019546957.39246.1402408698423.JavaMail.zimbra@peachymango.org> <699367420.39896.1402409599837.JavaMail.zimbra@peachymango.org> <5397156F.8010603@gmail.com> From: Hector Santos Content-Type: multipart/alternative; boundary=Apple-Mail-FC70F01C-2FAE-4BE1-9358-BD8046D6384D X-Mailer: iPad Mail (11B651) In-Reply-To: <5397156F.8010603@gmail.com> Message-Id: <3E16067A-64CB-4B84-ABBD-82873DB63E88@isdg.net> Date: Wed, 11 Jun 2014 11:09:48 -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: http://mailarchive.ietf.org/arch/msg/dmarc/TzO_GEuNyz3DYHnCfceCuGnr5XU Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Wed, 11 Jun 2014 15:10:00 -0000 --Apple-Mail-FC70F01C-2FAE-4BE1-9358-BD8046D6384D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Preference should be given to the author domain explicitly authorized resign= ers, how ever that black box functionality is achieved. Currently, there are= three DNS-based authorization proposals on the table. =46rom Murray's foll= ow-up comments, the DKIM-delegate is basically an optimizer to avoid doing a= lookup. If this can address the basic protocol fault failures the DNS look= up proposals addresses, the I would like see how that is done. I plan to stu= dy the draft more. The most basic protocol fault is when no signatures, no extra new headers ar= e available -- the legacy operation. Here the lookup is required. If not, t= he bad guy loophole is simply to remain in legacy mode. They don't need to t= hink about trying to find a fake signature. -- Hectorb Santos http://www.santronics.com > On Jun 10, 2014, at 10:25 AM, Dave Crocker wrote: >=20 >> On 6/10/2014 4:19 PM, Murray S. Kucherawy wrote: >> Yes but are you assuming you only put the weak DKIM signature, when >> you specifically know you are emailing a mailing list? >>=20 >> Or what about a receiver which is not a mailing list? You are just >> allowing better replay of the message, if you put any weak DKIM >> signature in the message... Unless the weak DKIM signature is >> constrained to a specific usage. >>=20 >>=20 >> You're constraining it to use by a specific, very small set of domains, >> and only for a limited time. >=20 >=20 > Then again, let's note that this double-signed mail is going to show up > at some receivers that don't know about DKIM-delegate. >=20 > The underlying point needs to be that a receiver that is faced with > multiple signatures for the same domain needs some assessment of which > is the 'strongest' and to give that one the preference. >=20 > d/ >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >=20 --Apple-Mail-FC70F01C-2FAE-4BE1-9358-BD8046D6384D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Preference should be giv= en to the author domain explicitly authorized resigners, how ever that black= box functionality is achieved. Currently, there are three DNS-based authori= zation proposals on the table.  =46rom Murray's follow-up comments, &nb= sp;the DKIM-delegate is basically an optimizer to avoid doing a lookup. &nbs= p;If this can address the basic protocol fault failures the DNS lookup propo= sals addresses, the I would like see how that is done. I plan to study the d= raft more.

The most basic protocol fault is when no signatures, no ex= tra new headers are available -- the legacy operation. Here the lookup is re= quired.  If not, the bad guy loophole is simply to remain in legacy mod= e.  They don't need to think about trying to find a fake signature.
=
--
Hectorb Santos
http://www.santronics.com


On Jun 10, 2014, at 10:25 AM, D= ave Crocker <dcrocker@gmail.com= > wrote:

On 6/10/2014 4:19 PM, Mu= rray S. Kucherawy wrote:
 &n= bsp; Yes but are you assuming you only put the weak DKIM signature, whe= n
   = you specifically know you are emailing a mailing list?

   Or what about a receiver which is not a mail= ing list? You are just
   allowing better replay of the message, if you put any w= eak DKIM
  = ; signature in the message... Unless the weak DKIM signature is<= br>
   constrain= ed to a specific usage.


You're constraining it to use by a sp= ecific, very small set of domains,
and only for a limited time.


Then again, let's note that this double-signed m= ail is going to show up
at some receivers that don't know ab= out DKIM-delegate.

The underlying point nee= ds to be that a receiver that is faced with
multiple signatu= res for the same domain needs some assessment of which
is th= e 'strongest' and to give that one the preference.
d/

--
Dave Crocker=
Brandenburg InternetWorking
bbiw.net

_________________= ______________________________
dmarc mailing list
= dmarc@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/dmarc">https://www.ietf.org/= mailman/listinfo/dmarc

= --Apple-Mail-FC70F01C-2FAE-4BE1-9358-BD8046D6384D-- From nobody Wed Jun 11 13:58:44 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18CA71A02B7 for ; Wed, 11 Jun 2014 13:58:44 -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 yhISBDmq4JHD for ; Wed, 11 Jun 2014 13:58:42 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DE281A02BC for ; Wed, 11 Jun 2014 13:58:42 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z12so307442wgg.13 for ; Wed, 11 Jun 2014 13:58:40 -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=5Q4WFJ7ziZlQv6V3blEmeIm+Q/KMfIsW9vQDqVWGXEs=; b=XK1HMlE0DrOLAX3l1wcuLtVNVCfB0QcnUAWUN/xm96VVl0tRV1nzl17yZvz216IBUH JFlVNRsiPHR0ANl1zHhw2j5uQJ76HLWD4MfU1h0fWvQxxOkpF7mGzVxTpAofTgob1pox NNc8mMCG88kYgEnKCmLAN6a9OpJdQgPKeHfIr1jrjhGF/L692J/zWlQhp12OZXiXoMHr qam9vL9oe3VDe/MQacZmt2XJjpDWk4vd8GjayJkfxzYZ5uzAWvwZ1/fkkZY673poQEwk BEU6DNDJ+3xCp5cNY4lu5zWv2iiR542q8K6TiAPNVmoc4EKvCy4AFiB3J0DC1dYyWxC4 gm6Q== MIME-Version: 1.0 X-Received: by 10.180.94.163 with SMTP id dd3mr536381wib.26.1402520320868; Wed, 11 Jun 2014 13:58:40 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Wed, 11 Jun 2014 13:58:40 -0700 (PDT) In-Reply-To: <3E16067A-64CB-4B84-ABBD-82873DB63E88@isdg.net> References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <1755889339.33315.1402383131643.JavaMail.zimbra@peachymango.org> <1019546957.39246.1402408698423.JavaMail.zimbra@peachymango.org> <699367420.39896.1402409599837.JavaMail.zimbra@peachymango.org> <5397156F.8010603@gmail.com> <3E16067A-64CB-4B84-ABBD-82873DB63E88@isdg.net> Date: Wed, 11 Jun 2014 13:58:40 -0700 Message-ID: From: "Murray S. Kucherawy" To: Hector Santos Content-Type: multipart/alternative; boundary=f46d04462e5e840a0404fb95b5a6 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/zbZSCgAaTLRRx4phtgG9kOir9ZE Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Wed, 11 Jun 2014 20:58:44 -0000 --f46d04462e5e840a0404fb95b5a6 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 11, 2014 at 8:09 AM, Hector Santos wrote: > Preference should be given to the author domain explicitly authorized > resigners, how ever that black box functionality is achieved. Currently, > there are three DNS-based authorization proposals on the table. From > Murray's follow-up comments, the DKIM-delegate is basically an optimizer > to avoid doing a lookup. If this can address the basic protocol fault > failures the DNS lookup proposals addresses, the I would like see how that > is done. I plan to study the draft more. > One thing that is missing (and there's a placeholder for it) is examples so you can see how it works. I'll make sure that's there for -01. > The most basic protocol fault is when no signatures, no extra new headers > are available -- the legacy operation. Here the lookup is required. If > not, the bad guy loophole is simply to remain in legacy mode. They don't > need to think about trying to find a fake signature. > A lookup for what, and where? But you're right, there's a risk of a legacy DKIM verifier getting only the delegation signature for some reason. The exposure is supposedly time-limited, and we're assuming verifiers all pay attention to "x=", but it should also be documented. -MSK --f46d04462e5e840a0404fb95b5a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 11, 2014 at 8:09 AM, Hector Santos <hsantos@= isdg.net> wrote:
Preference should be given to the author do= main explicitly authorized resigners, how ever that black box functionality= is achieved. Currently, there are three DNS-based authorization proposals = on the table. =C2=A0From Murray's follow-up comments, =C2=A0the DKIM-de= legate is basically an optimizer to avoid doing a lookup. =C2=A0If this can= address the basic protocol fault failures the DNS lookup proposals address= es, the I would like see how that is done. I plan to study the draft more.<= br>

One thing that is missi= ng (and there's a placeholder for it) is examples so you can see how it= works.=C2=A0 I'll make sure that's there for -01.
=C2=A0
The most basic protocol fault is when no signatures, no extra new headers = are available -- the legacy operation. Here the lookup is required. =C2=A0I= f not, the bad guy loophole is simply to remain in legacy mode. =C2=A0They = don't need to think about trying to find a fake signature.

A lookup for what, and = where?

But you're right, there's a risk of a lega= cy DKIM verifier getting only the delegation signature for some reason.=C2= =A0 The exposure is supposedly time-limited, and we're assuming verifie= rs all pay attention to "x=3D", but it should also be documented.=

-MSK
--f46d04462e5e840a0404fb95b5a6-- From nobody Wed Jun 11 14:03:10 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406E91A0403 for ; Wed, 11 Jun 2014 14:03:09 -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 TJvKDgMOs8zU for ; Wed, 11 Jun 2014 14:03:07 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 780E51A02E1 for ; Wed, 11 Jun 2014 14:03:07 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b13so317258wgh.11 for ; Wed, 11 Jun 2014 14:03: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=VNf7iGf2WMqcS/Hf/PaIaGGwW1UR348wH2ZDJJ0aFLw=; b=uezWla4VxtBXuWhE2Nrff5a1LoBGfb9ZxEDkZJV3YfuZUv/an3yTKxDYPSNqcBQPEK Yprtw1IrdT7xGh7PrGOwmfQavCFGWn2LPp/d3/elYt1pf4i/aLWUtNxeDcaSgdwdXcww HbEu+CkViWlUAegZkxdvETf7QTd34Sg/5wogn0M1mehEQ3VBCdkd/gSVLhZUZs/RsiaA M4Gy07/0FVGWU8ta3Vbd+WaSSmyduDWWlvQ0ymFtf2RytVaVgqbUVno5fWBJ0XJmuu7N LIcKoT3w1mdzqkcPqdd7e5vGj9TJHv4UdOv60K7JkETAbCBrpVzKMCSR99zK0BGHqt9o nl6w== MIME-Version: 1.0 X-Received: by 10.194.71.81 with SMTP id s17mr56142450wju.10.1402520585670; Wed, 11 Jun 2014 14:03:05 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Wed, 11 Jun 2014 14:03:05 -0700 (PDT) In-Reply-To: <20140611141529.4633.qmail@joyce.lan> References: <5397156F.8010603@gmail.com> <20140611141529.4633.qmail@joyce.lan> Date: Wed, 11 Jun 2014 14:03:05 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=047d7bfcf8944c973f04fb95c5c3 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ht5FBRNmc7B12ph0XJ5UZwAZnOI Cc: Dave Crocker , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Wed, 11 Jun 2014 21:03:09 -0000 --047d7bfcf8944c973f04fb95c5c3 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 11, 2014 at 7:15 AM, John Levine wrote: > Right. So if you don't want people using unforwarded weak signatures > for reputation management, you need to put something into them so that > old clients don't accept them as signatures and ignore the t= tag. > Either call them something other than DKIM-Signature, or do a version > bump to v=2. > I'm not clear on the case you're describing. Can you mock up an example? Also, isn't it "x=" that's interesting here, not "t="? -MSK --047d7bfcf8944c973f04fb95c5c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 11, 2014 at 7:15 AM, John Levine <johnl@taugh.c= om> wrote:
Right. =C2=A0So if you don't want people using unforwarded weak signatu= res
for reputation management, you need to put something into them so that
old clients don't accept them as signatures and ignore the t=3D tag. Either call them something other than DKIM-Signature, or do a version
bump to v=3D2.

I'm not clear on the= case you're describing.=C2=A0 Can you mock up an example?

Also,= isn't it "x=3D" that's interesting here, not "t=3D&= quot;?

-MSK
--047d7bfcf8944c973f04fb95c5c3-- From nobody Wed Jun 11 14:03:58 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAD01B27C2 for ; Wed, 11 Jun 2014 14:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, RP_MATCHES_RCVD=-0.651, 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 HBrXC3PoIQTQ for ; Wed, 11 Jun 2014 14:03:55 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40FD71A02E1 for ; Wed, 11 Jun 2014 14:03:55 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id rd18so313316iec.7 for ; Wed, 11 Jun 2014 14:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EfDI5YcbLe6RUSLh4oSY//io+hHvahA4gfelfBXiqKw=; b=KZBCNW6NoHyAM+xNPPH6FaT7UHgicExzD7oPclL5++N+ya2VFq1uEZESyExxv/2xQV ZphSmn2pte2Cn/Wr4E9RiUSy/cWbOex8lwE713LCSpGy/x59BysfYHHI8T/O6dbL/wMg Nh5Xf32f61bYg/ISVqTBzs5gSh0922vAluaffKaZpFaYLH6e/zEApTSF6DGcZvsuHoix gc86ODhfBi0CZ/A/e6CbhbRmtEeslsTmxux1AaI7MeyQh5u2QFmLfITNjp7Oc9f/vGQj ZW2TlyBMWTkWHbrhwYrzrmfbeWkTiePZPReJ0uOEcX1zbX5+PsYp1YWqVjK00bV6p6am WRVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EfDI5YcbLe6RUSLh4oSY//io+hHvahA4gfelfBXiqKw=; b=J/pvbIrO5t3g6fiZkYfJrDjUHnXHMpMiaz9CMYJqMQ8sJwyBpWtTFRXO0P7oAu/h+Q yZ3bW7BwYMPvVyuWKHb3AsnomK1Q4LjoqhXJjaVF2+e7UREJVQe72iYnIdQMtio3J1HM 6pxJPT1lzm+GavAGrY7AnxFKODmZR5aCS5x1FvugU5bgaRgTOAaclKz9RaZTzbiVetbd Qfufi6RYCNVejkNBpx8oAmQTfRZ7v1aQl3LpfbewLjHw7dndpwS1ywPxNf/l9QvlsrUm NExnA4Q+qdIt4EAWXODT8H+OmE8KQlVwkr1P65cPTvBTZnBN35OsEehYtdRV99UWqZEc 9svA== X-Gm-Message-State: ALoCoQm8Nlg7dd5YQB7PdtGtdZdjKl26n67Kn50KgiK10o9ADeC7uaVqUkTZTm1dkaowYhwn6zR8 MIME-Version: 1.0 X-Received: by 10.50.33.72 with SMTP id p8mr671593igi.32.1402520634627; Wed, 11 Jun 2014 14:03:54 -0700 (PDT) Received: by 10.64.136.202 with HTTP; Wed, 11 Jun 2014 14:03:54 -0700 (PDT) In-Reply-To: <87ppigowmh.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <87ppihgugl.fsf@uwakimon.sk.tsukuba.ac.jp> <5396E49C.2000808@isdg.net> <8738fcrhqz.fsf@uwakimon.sk.tsukuba.ac.jp> <53974C62.9050408@isdg.net> <87tx7splbb.fsf@uwakimon.sk.tsukuba.ac.jp> <998FA07D-E6D7-41FB-A143-CE7B426E6763@tnpi.net> <87ppigowmh.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Wed, 11 Jun 2014 14:03:54 -0700 Message-ID: From: Brandon Long To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=089e0153874237bdd004fb95c87b Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/RRy15hQLaxw50XSyo4KUY6lOP9I Cc: "dmarc@ietf.org" , Matt Simerson Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 11 Jun 2014 21:03:57 -0000 --089e0153874237bdd004fb95c87b Content-Type: text/plain; charset=UTF-8 On Tue, Jun 10, 2014 at 10:15 PM, Stephen J. Turnbull wrote: > Matt Simerson writes: > > > If message headers and footers are so popular, how do you explain > > the continued "please unsubscribe me posts" sent to practically > > every mailing list? > > Bell curve. Some people are 2-sigma self-centered, and others are > 2-sigma clueless. What else is new?[1] > > Note that the kind of people who answer FAQs do like having the footer > so they can say "just click on the link in the footer of any message, > including this one." > In the past (not sure if current), both Y!Groups and GoogleGroups would send an unsubscribe-confirm message to any message containing the unsubscribe or similar words in the subject/first 2 lines of the message. Another option was to moderate those messages. In any case, IANAL but some tell me that recent anti-spam laws in the EU (and maybe CAN-SPAM) can be interpreted to mean that any list which allows manually added users would require an unsub link in the message. Probably not something that is a requirement on the writers of mailman, but something that major list operators have to deal with. > > > Also while it's certainly true that subject prefixes are popular > > with list operators, I didn't hear a single peep from my list users > > when I removed them. > > Sure, there are groups like that, some quite large and varied, as > yours seems to be. On the other hand, I've participated in a couple > of lists where there was vociferous opposition to removing them from > several users because they had MUA filters based on them. (Whether > they constituted a significant fraction of the membership is unclear.) > > Removal of prohibited content is not so easily addressed, as left to > their own devices users' .doc and .mp4 files can constitute a large > fraction of outgoing bandwidth from list servers that otherwise don't > need much (on a couple of my lists we still get the occasional > oldtimer sending core files for debugging!) > I would think that rejecting the messages with prohibited content would be more useful than automatically removing it, especially since the resultant message may be pretty useless without the content... YMMV. Obviously there are other use cases, for example Y!Groups used to strip attachments and make them available online, which resolved quota and bandwidth issues. They also used to let moderators edit the content of the messages during moderation, including removing attachments or editing the text.. I really didn't like that feature. Brandon --089e0153874237bdd004fb95c87b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Jun 10, 2014 at 10:15 PM, Stephen J. Turnbull <stephen@xe= macs.org> wrote:
Matt Simerson writes:

=C2=A0> If message headers and footers are so popular, how do you explai= n
=C2=A0> the continued "please unsubscribe me posts" sent to pr= actically
=C2=A0> every mailing list?

Bell curve. =C2=A0Some people are 2-sigma self-centered, and others a= re
2-sigma clueless. =C2=A0What else is new?[1]

Note that the kind of people who answer FAQs do like having the footer
so they can say "just click on the link in the footer of any message,<= br> including this one."

In the past (= not sure if current), both Y!Groups and GoogleGroups would send an unsubscr= ibe-confirm message
to any message containing the unsubscribe or = similar words in the subject/first 2 lines of the message.

Another option was to moderate those messages.

In any case, IANAL but some tell me that recent anti-spam = laws in the EU (and maybe CAN-SPAM) can be interpreted to mean that any lis= t which allows manually added users would require an unsub link in the mess= age. =C2=A0Probably not something that is a requirement on the writers of m= ailman, but something that major list operators have to deal with.
=C2=A0

=C2=A0> Also while it's certainly true that subject prefixes are pop= ular
=C2=A0> with list operators, I didn't hear a single peep from my lis= t users
=C2=A0> when I removed them.

Sure, there are groups like that, some quite large and varied, as
yours seems to be. =C2=A0On the other hand, I've participated in a coup= le
of lists where there was vociferous opposition to removing them from
several users because they had MUA filters based on them. =C2=A0(Whether they constituted a significant fraction of the membership is unclear.)

Removal of prohibited content is not so easily addressed, as left to
their own devices users' .doc and .mp4 files can constitute a large
fraction of outgoing bandwidth from list servers that otherwise don't need much (on a couple of my lists we still get the occasional
oldtimer sending core files for debugging!)

=
I would think that rejecting the messages with prohibited content woul= d be more useful than automatically removing it, especially since the resul= tant message may be pretty useless without the content... YMMV.

Obviously there are other use cases, for example Y!Grou= ps used to strip attachments and make them
available online, whic= h resolved quota and bandwidth issues. =C2=A0They also used to let moderato= rs edit the content
of the messages during moderation, including removing attachments or e= diting the text.. I really didn't like that feature.

Brandon
--089e0153874237bdd004fb95c87b-- From nobody Wed Jun 11 14:14:13 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58EAA1B289B for ; Wed, 11 Jun 2014 14:14:09 -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 fj-BLPEuCjy0 for ; Wed, 11 Jun 2014 14:14:06 -0700 (PDT) Received: from mail.theartfarm.com (mail.theartfarm.com [66.128.51.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6A4F1A02F7 for ; Wed, 11 Jun 2014 14:14:05 -0700 (PDT) Received: (qmail 23066 invoked by uid 89); 11 Jun 2014 21:14:05 -0000 Received: from unknown (HELO mail.theartfarm.com) (127.0.0.30) by mail.theartfarm.com with SMTP; 11 Jun 2014 21:14:05 -0000 Received-SPF: Pass (mail.theartfarm.com: domain of tnpi.net designates 50.159.99.59 as permitted sender) receiver=mail.theartfarm.com; identity=mailfrom; client-ip=50.159.99.59; helo=imac27.simerson.net; envelope-from= Received-SPF: None (mail.theartfarm.com: domain of imac27.simerson.net does not designate 50.159.99.59 as permitted sender) receiver=mail.theartfarm.com; identity=helo; client-ip=50.159.99.59; helo=imac27.simerson.net; envelope-from= Received: from imac27.simerson.net (c-50-159-99-59.hsd1.wa.comcast.net [50.159.99.59]) by mail.theartfarm.com (Haraka/2.5.0-toaster) with ESMTPSA id 102F3F27-289A-4F23-B21D-0D4CD93D7708.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=AES128-SHA verify=FAIL); Wed, 11 Jun 2014 17:14:03 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Matt Simerson In-Reply-To: <87ppigowmh.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Wed, 11 Jun 2014 14:13:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <87ppihgugl.fsf@uwakimon.sk.tsukuba.ac.jp> <5396E49C.2000808@isdg.net> <8738fcrhqz.fsf@uwakimon.sk.tsukuba.ac.jp> <53974C62.9050408@isdg.net> <87tx7splbb.fsf@uwakimon.sk.tsukuba.ac.jp> <998FA07D-E6D7-41FB-A143-CE7B426E6763@tnpi.net> <87ppigowmh.fsf@uwakimon.sk.tsukuba.ac.jp> To: "dmarc@ietf.org" X-Mailer: Apple Mail (2.1878.2) X-Haraka-p0f: os="MacOS X 10.9 or newer (sometimes iPhone " link_type="Ethernet or modem" distance=11 total_conn=45 shared_ip=N X-Haraka-GeoIP: US, WA, Seattle, 2699km X-Haraka-GeoIP-Received: 50.159.99.59:US X-Haraka-ASN: 7922 50.128.0.0/9 X-Haraka-ASN-MONKEY: asn=7922 net=50.128.0.0/9 org=Comcast Cable Communications, Inc. date=1997-02-14 country=US X-Haraka-FCrDNS: c-50-159-99-59.hsd1.wa.comcast.net X-Spam-ASN: X-Spam-DCC: x.dcc-servers: spamassassin.tnpi.net 104; Body=1 Fuz1=1 Fuz2=1 X-Spam-SNF-Result: 0 (Standard White Rules) X-Spam-MessageSniffer-Scan-Result: 0 X-MessageSniffer-Rules: 0-0-0-10966-c X-MessageSniffer-Clean: Yes X-Spam-MessageSniffer-Rules: 0-0-0-10966-c X-MessageSniffer-Clean: Yes X-Spam-GBUdb-Analysis: 0, 50.159.99.59, Ugly c=0.327499 p=-1 Source Normal X-MessageSniffer-Scan-Result: 0 X-MessageSniffer-Rules: 0-0-0-10966-c X-MessageSniffer-Clean: Yes X-Haraka-Karma: connect: 5, history: 458, total_connects: 489, neighbors: -5517, pass:fcrdns.fcrdns, relaying, auth_user, fail:fcrdns.fail, neighbors, dnsbl.fail, helo.checks.fail, skip:penalty DKIM-Signature: v=1; a=rsa-sha256; bh=g2FnG1P0YX/ChRA+2+UhDl2HMwwfsdtqEXiADdoy/44=; c=relaxed/simple; d=tnpi.net; h=from:subject:date:message-id:to:mime-version; s=mar2013; b=YmM1AecFXhUo8rGJO90nI6//+ShvUEPeKagg9+GOK1VL3oml2mgpfHduNUpl99Vhykz5M0vHdvBr+bgbI69SpB5szn1DRf+7H5vrGtCl9q3EYtSSEvKHlqIqUSrHtTbarOf1cSLCIiN29nLvAWZnM/KPtT2klO68gwSry4pJ5+/BuUEq3jjY0HtRLturSte7NJAkzqz7zJ8N903LVkD/vkETbH8LPY2aA+P9wTpCl9IVMCAzOygGTsLLqrLe3AN3fwVFIRy9UadOzaZG+N6LUX2ruAiZMwyc9sNRENWeimpuM/LuE9GAvRuB2eQQWkK/KL/1jSX6w5pYl0Bm3Vm/7g== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Bcj-F8rLJxB00LEPrGgr2R5iEg4 Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 11 Jun 2014 21:14:09 -0000 On Jun 10, 2014, at 10:15 PM, Stephen J. Turnbull = wrote: > Matt Simerson writes: >=20 >> If message headers and footers are so popular, how do you explain >> the continued "please unsubscribe me posts" sent to practically >> every mailing list? >=20 > Bell curve. Some people are 2-sigma self-centered, and others are > 2-sigma clueless. What else is new?[1] >=20 > Note that the kind of people who answer FAQs do like having the footer > so they can say "just click on the link in the footer of any message, > including this one." That just seems to reinforce the point that the message alterations are = far more popular with list *operators* than they are with list *users.* I can't help but think that all this energy would be better spent = focusing on solutions that provides a consistent method for email lists = to present their decoration and admin URIs without breaking DKIM. = Something that: a) Identifies messages as list traffic (aka: List-ID) b) Incorporates list info into headers (see below) c) Requests MUA authors to identify list messages in a safe and = useful fashion** I fully realize that c) is a can of worms, but I can't help but think = that MUA authors are equal to the task. If we provided them with a = defined set of Mailing List Actions that were enabled when the MLM = software populated the appropriate headers, we could eliminate the vast = majority of message alterations. List-ID: List-Prefix: dmarc-ietf (MUA: prefix the subject with this = string) List-Unsubscribe: https://www.ietf.org/mailman/listinfo/dmarc List-Unsubscribe: mailto://list-unsubscribe@example.com List-Archives: = http://www.ietf.org/mail-archive/web/dmarc/current/maillist.html List-Preferences: https://www.ietf.org/mailman/listinfo/dmarc If an implementation of "how to present this in a useful way" was = available in JS and PHP, it could likely be incorporated into releases = of *most* webmail clients in a matter of months. Matt ** Mail.app already provides a dropdown list of options when one hovers = their mouse over the =46rom and To recipients. It's not hard to imagine = a section of that list being List Functions / Manage My Subscription. = Similarly, the subject prefix could be decorated with a disclosure = triangle that when clicked, presented the list options. >> Also while it's certainly true that subject prefixes are popular >> with list operators, I didn't hear a single peep from my list users >> when I removed them. >=20 > Sure, there are groups like that, some quite large and varied, as > yours seems to be. On the other hand, I've participated in a couple > of lists where there was vociferous opposition to removing them from > several users because they had MUA filters based on them. (Whether > they constituted a significant fraction of the membership is unclear.) No doubt. I've been on such lists, where just the discussion of it alone = generated vast amounts of controversy. But if they silently disappeared = in the dead of night, approximately 1% of participants would notice and = 0.1% would care. Granted, that 0.1% would likely squeal very loudly, = until you pointed out they can filter using the list headers.* > Removal of prohibited content is not so easily addressed, as left to > their own devices users' .doc and .mp4 files can constitute a large > fraction of outgoing bandwidth from list servers that otherwise don't > need much (on a couple of my lists we still get the occasional > oldtimer sending core files for debugging!) In such cases, don't you think it's appropriate for the list to take = ownership of the message, after applying the transformations necessary = to make it conform to site policy? Matt * Incomplete, but covers a goodly portion of list traffic: var mlms =3D { 'Mailing-List' : [ { mlm: 'ezmlm', match: 'ezmlm' }, { mlm: 'yahoogroups', match: 'yahoogroups' }, ], 'Sender' : [ { mlm: 'majordomo', start: 'owner-' }, ], 'X-Mailman-Version' : [ { mlm: 'mailman' }, ], 'X-Majordomo-Version': [ { mlm: 'majordomo' }, ], 'X-Google-Loop' : [ { mlm: 'googlegroups' } ], }; From nobody Wed Jun 11 15:22:38 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4018C1B28A8 for ; Wed, 11 Jun 2014 15:22:34 -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 kLY8lhxehmlz for ; Wed, 11 Jun 2014 15:22:33 -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 00CC01B28B5 for ; Wed, 11 Jun 2014 15:22:32 -0700 (PDT) Received: (qmail 64575 invoked from network); 11 Jun 2014 22:22:31 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 11 Jun 2014 22:22:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=923.5398d6a6.k1406; i=johnl@user.iecc.com; bh=6S4CJD5PT/l8n8KLYBBFmxuE4qLkQvuxxzAzJkywkqE=; b=uzKS3AvvedROQnz1B/tJ8PEIlTXgHiUv+eUGCrmOy6HBaa89ro1KTdCDGN3yI8Fc9O5JQvCJsQvvlLuFiIp/s4g1vOIxL1Zjd/jJCdLX/n14stqalzTqDUjQypsQaAjH/9WRlU1FZUE5gU3x9PWSWH0tj0gc0K0QqS55WVzyt/jWcOkEVxASfMXVIzEqB0DmFfEswhDbXS03WaQgs7OVkwhU/0nMMfpKXzmNXHHhuyX9ss8Uh/wQ8gtFS5cHve9B DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=923.5398d6a6.k1406; olt=johnl@user.iecc.com; bh=6S4CJD5PT/l8n8KLYBBFmxuE4qLkQvuxxzAzJkywkqE=; b=1KApIC3aRr+JsP1aRxA37Fs9EGe3WSVf5MYlOoPKftsYvgkBxZU4SAmOWIu8VJkJzaXIvIxnQCbFZgmIIaDSu0Ur6CH7I41yJccBZiqJPlVL8JO/kHXypm1eJORJ6oq+AjGye04zbmupMBtdl34PJO3HOCqAZiRJe/QNFEMQGRrcYpodO6Db2l32lA83QqZZrHgXYR4DyPnkhi60Hti1cU26BJsfMzT4B7l34Tw5eFn1vdm9zvXNA2Y0162gU98l Date: 11 Jun 2014 22:22:07 -0000 Message-ID: <20140611222207.2338.qmail@joyce.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: http://mailarchive.ietf.org/arch/msg/dmarc/iZJWi38vEhhhc_uZGQ9PgqLssjc Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Wed, 11 Jun 2014 22:22:34 -0000 >On Wed, Jun 11, 2014 at 7:15 AM, John Levine wrote: > >> Right. So if you don't want people using unforwarded weak signatures >> for reputation management, you need to put something into them so that >> old clients don't accept them as signatures and ignore the t= tag. >> Either call them something other than DKIM-Signature, or do a version >> bump to v=2. >> > >I'm not clear on the case you're describing. Can you mock up an example? > >Also, isn't it "x=" that's interesting here, not "t="? Someone sends off a message to a mailing list with the two DKIM signatures and DKIM-Delegate. Someone else, perhaps a list subscriber, notes that the weaker signature doesn't cover the body, so he replaces the body with nose enlargement spam and blasts it out. Recipient MTAs which haven't been updated since 2014 and don't know about DKIM-Delegate see the weak but valid signature and since the signer has a generally good reputation, delivers it. Ugh. This hasn't been a problem before. Although you've always been allowed to use weak signatures, there's been no advantage to doing so, so nobody did. Now you do, but with new semantics that you shouldn't pay much (any?) attention to that signature unless it's paired with the forwarder's. One could make an argument that it's not technically a semantic change to DKIM (indeed, Dave just did), but in practical terms, it is likely to interact poorly with existing unupgraded software, so I'd want a version bump so that the old software ignores the special purpose signature. Bonus question: why put the author domain and target domain fields in a new header rather than just addding ddd= and ddt= to the signature header? R's, John From nobody Wed Jun 11 15:41:18 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C5B1A01F9; Wed, 11 Jun 2014 10:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.653 X-Spam-Level: X-Spam-Status: No, score=-4.653 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 5JQJA-ZUn7g6; Wed, 11 Jun 2014 10:00:20 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13B3C1A01ED; Wed, 11 Jun 2014 10:00:19 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s5BH04Sx000426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Jun 2014 19:00:04 +0200 (MEST) In-Reply-To: To: Phillip Hallam-Baker Date: Wed, 11 Jun 2014 19:00:04 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20140611170004.5D75E1AD4D@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/_LmZMpdG2q0lMFSzoXp4zdKvP1U X-Mailman-Approved-At: Wed, 11 Jun 2014 15:41:15 -0700 Cc: "dmarc@ietf.org" , Hector Santos , IETF , Dave Crocker Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com 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, 11 Jun 2014 17:00:23 -0000 Phillip Hallam-Baker wrote: > Hector Santos wrote: >> >> Let me ask, what if a fedex.com employee use this email domain for >> subscribing to the IETF list? > > Any subsequent problems are irrelevant unless FedEx, the owner of > fedex.com considers them to be relevant. > > That is what folk complaining don't get: you don't have the right to > use your employers email or a public email provider's email any way > you want. The domain name owner makes the rules. > > As Craster insists: My domain, my rules. Strange concept! Does your jurisdiction allow your landlord to interfere with postal/snail mail that is delivered from or to your rented appartment? And unless your jurisdiction is hopelessly outdated, the same rules ought to apply to interference with telecommunications. > > In the medium term, lets kill the stupidity of mailing lists with a > protocol that works. NNTP was originally designed to replace mailing > lists. It actually works quite well at that. The only problem was the > IT-Dictator mindset that underlies it: newsgroups have to be approved > by the Commune! Set up your own mail2news gateway. /usr/lib/aliases http://www.tldp.org/LDP/nag/node213.html main2news script http://www.sirlab.de/linux/descr_m2n.html -Martin From nobody Wed Jun 11 15:41:38 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464851B28AE for ; Wed, 11 Jun 2014 14:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=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 n4XaMj3YCKMJ for ; Wed, 11 Jun 2014 14:54:59 -0700 (PDT) Received: from nm31.bullet.mail.gq1.yahoo.com (nm31.bullet.mail.gq1.yahoo.com [98.136.217.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 804161A029B for ; Wed, 11 Jun 2014 14:54:59 -0700 (PDT) Received: from [127.0.0.1] by nm31.bullet.mail.gq1.yahoo.com with NNFMP; 11 Jun 2014 21:54:59 -0000 Received: from [98.137.12.63] by nm31.bullet.mail.gq1.yahoo.com with NNFMP; 11 Jun 2014 21:52:03 -0000 Received: from [216.39.60.198] by tm8.bullet.mail.gq1.yahoo.com with NNFMP; 11 Jun 2014 21:52:03 -0000 Received: from [127.0.0.1] by omp1085.mail.gq1.yahoo.com with NNFMP; 11 Jun 2014 21:52:03 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 604015.1037.bm@omp1085.mail.gq1.yahoo.com Received: (qmail 68234 invoked by uid 60001); 11 Jun 2014 21:52:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402523523; bh=jlRGpDBvsYB6mbJttWvpyH5Oc59AKstKvEXYzUhoYFk=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=X66Qh/P4G/8Exgy3szIooez+xgNlwmqlP2odbzvJWsGozCWzuGgoIpTPXjctJuDRJCkDvjo+GXFW7aGHx7/enJdPfZUjbi7hbBPEQyFKxVqDJiDVA4xGv+3MyBP6RiB/dFN4AaMBtINCqd3vM8F0X795I9Pp4wnz+Gm/OTJRADo= X-YMail-OSG: ObDS9t4VM1m_Mal4hc_sHTM9GVog.TbeTPoaoVA6RitH5UE rG0joCu7QBxpsziDQA.JfdAoaaXcE4uYASZ.1B106pRcYV5D2oLCx3.Au2pv ngAV8_qKwuWckp0Vo0a_c6P35YHICPn0KbkThnJyHn6OCYM28fheqnj7UKV6 v3dC9MQn.p31qiBfV9_zapCHhaFkFKVeYlVw7ShNlCJbI6mPnSASDrkWWILm v_B4Er2q_B7_FwVGx0ThE6ISoJKTkvENRLmq6zuerrz7qrXLh1vFYcMRMX9o 7WtP4N3Io6bWWQxKFgnVllOE_8LFf1FEzbBqQTXEFth.0hJdo_aDu5Q_y894 bcNi1JcxZfPIu0ylDA2qN7Nvw1q1vrLUmhnZnlkPlJVbrqcA88VW66XxSoNP ZuFPRAwcHnbnDbsrGFzav_9YW5UwQBEe.2WibtzAE3b_6GPA1TGIFVu4U8_T TIP.CHkNeqM4o.viWAM_QEJFgIvrE39L8XAWbB016miZ._OmvLWnX1VSbinM _fnHNDhBZUnVAmQvNQZ.0CZYEwd.ckeZT4BHP6yykOiJxe1AIEv4ELNIer17 TXZ2mYmWNVTf1O1LJDWgQD3cfsvV4QXmwrnAvoNSIsPYaf1n4I91otd76LPg rcw-- Received: from [79.175.112.222] by web164601.mail.gq1.yahoo.com via HTTP; Wed, 11 Jun 2014 14:52:03 PDT X-Rocket-MIMEInfo: 002.001, T24gV2VkbmVzZGF5LCBKdW5lIDExLCAyMDE0IDY6MzMgUE0sIEFsZXNzYW5kcm8gVmVzZWx5IDx2ZXNlbHlAdGFuYS5pdD4gd3JvdGU6Cgo.IE9yIGFtIEkgbWlzc2luZyBzb21ldGhpbmc_CgpkZWxlZ2F0ZWQgZG9tYWluIGluY2x1c2lvbiBpbiBES0lNLUQgaGVhZGVyIGlzIG9wdGlvbmFsLAphbmQgY29uc2lkZXJpbmcgaXQgcmVxdWlyZXMgc29tZSBraW5kIG9mIHdoaXRlbGlzdCBmcm9tIHdoaWNoCml0cyB0byBkcmF3IGEgbGlzdCBvZiBkb21haW4gaXQgc2hvdWxkIGluY2x1ZGUsIGNvbXBhcmVkIDIgdGgBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <5392ECED.5010404@gmail.com> <1755889339.33315.1402383131643.JavaMail.zimbra@peachymango.org> <1402385033.97400.YahooMailNeo@web164602.mail.gq1.yahoo.com> <1402414911.96471.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1402431931.70928.YahooMailNeo@web164606.mail.gq1.yahoo.com> <539884A7.3030306@tana.it> Message-ID: <1402523523.93959.YahooMailNeo@web164601.mail.gq1.yahoo.com> Date: Wed, 11 Jun 2014 14:52:03 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" In-Reply-To: <539884A7.3030306@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/lWtE8KGwLRZ_QSH-UEl8CMgTkBg X-Mailman-Approved-At: Wed, 11 Jun 2014 15:41:35 -0700 Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 11 Jun 2014 21:55:01 -0000 On Wednesday, June 11, 2014 6:33 PM, Alessandro Vesely wro= te:=0A=0A> Or am I missing something?=0A=0Adelegated domain inclusion in DK= IM-D header is optional,=0Aand considering it requires some kind of whiteli= st from which=0Aits to draw a list of domain it should include, compared 2 = those=0Ait should not, it is most probably not gonna be used.=0A=0Anot to s= peak that creation of such a whitelist is whole=0Aanother problem.=0A=0Aif = u instead, make it automatic, for example, putting=0ATo: domain into DKIM-D= header automatically while message is=0Asigned, then u have an open hole o= f spoofing such message by=0Aany user of, for example, ESP which was in ori= ginal To:.=0A=0Aso, u again need 2 fall back to whitelist.=0A=0A=0Anow come= s the question of why r we doing whitelisting in headers,=0Asolving only a = small portion of the DMARC-excluded email, when=0Awe could do whitelisting = in ASL, and deal with the problem=0Ain a much broader way?=0A=0Aif we r doi= ng whitelisting, it should be done properly, not=0Awith aidband like DKIM-D= .=0A=0A=0A> Beg your pardon, but I don't think you mean age/sex/location.= =A0 What is ASL?=0A=0AAligned Sender List... or Allowed Sender List, we r s= till debating=0Aabout the name. Hector Santos introduced it some time ago, = as a 3rd party=0Asolution for DMARC. it is still being worked on, but it's = much more=0Apromising than DKIM-D.=0A=0Ai simply prefer it over any header = mumbo jumbo:=0A1. has no spoofing elements like DKIM-D,=0A2. can always sur= vive message path, unlike anything header based,=0A3. provides much wider s= upport for 3rd party than just ML.=0A=0A=0A-- =0AVlatko Salaj aka goodone= =0Ahttp://goodone.tk From nobody Wed Jun 11 15:47:56 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372941A02EE for ; Wed, 11 Jun 2014 15:47: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 nMlgvX6X7HeS for ; Wed, 11 Jun 2014 15:47:52 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53C9B1A018F for ; Wed, 11 Jun 2014 15:47:52 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hi2so6260647wib.2 for ; Wed, 11 Jun 2014 15:47: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=oykD+GSG82qFMqoSoP6YAyn3NOxydlzTdjiYmJ7MJIY=; b=GXPq1JRevxJtb11desy978WSJwLHzXxtTlpin2dkNCsT164I3hotJN4JlQJjh8U6EV X/1+GgIC26l7pFsgrLnpTMat/iXvD01tuHiRv5Ii2Nk1FjZLHZ1ehvuiLRdwwhSq4Bnz hZROiLavvWon/BoFlU6+bPy/mA8ys77KtAIY+v2z8JtHXsapYm2dpqGDpTq+0QQXcGKl u064mEOcRjkc2Jw9l+a3ITRtIHPHzqFSf+3+rb2puQi3sAWbK1ndnXwptTQxJRlu3+oc 3w2IzLTBRUcRLny9mWR8aH5zTVE+GalTfFC6S0HaSmxF7skEl3Zw+GYMhWwUpdBKk0Ga 7D/A== MIME-Version: 1.0 X-Received: by 10.180.75.212 with SMTP id e20mr961180wiw.5.1402526870820; Wed, 11 Jun 2014 15:47:50 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Wed, 11 Jun 2014 15:47:50 -0700 (PDT) In-Reply-To: <20140611222207.2338.qmail@joyce.lan> References: <20140611222207.2338.qmail@joyce.lan> Date: Wed, 11 Jun 2014 15:47:50 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=f46d043890a5ec5d2404fb973bce Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/cLHhGB0NlC70J9pOJKq8bRMNErg Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Wed, 11 Jun 2014 22:47:54 -0000 --f46d043890a5ec5d2404fb973bce Content-Type: text/plain; charset=UTF-8 On Wed, Jun 11, 2014 at 3:22 PM, John Levine wrote: > Someone sends off a message to a mailing list with the two DKIM > signatures and DKIM-Delegate. Someone else, perhaps a list > subscriber, notes that the weaker signature doesn't cover the body, so > he replaces the body with nose enlargement spam and blasts it out. > Recipient MTAs which haven't been updated since 2014 and don't know > about DKIM-Delegate see the weak but valid signature and since the > signer has a generally good reputation, delivers it. Ugh. > Right, that's the "considerable latitude" that's already mentioned in the draft. The "x=" is the current protection against that sort of abuse. It's not much, but it's what we've thought of so far. The alternative is to use an "l=" that is the length of the original rather than 0, which constrains the abuse considerably but might reduce the likelihood of this working. > This hasn't been a problem before. Although you've always been > allowed to use weak signatures, there's been no advantage to doing so, > so nobody did. Now you do, but with new semantics that you shouldn't > pay much (any?) attention to that signature unless it's paired with > the forwarder's. One could make an argument that it's not technically > a semantic change to DKIM (indeed, Dave just did), but in practical > terms, it is likely to interact poorly with existing unupgraded > software, so I'd want a version bump so that the old software ignores > the special purpose signature. > I see your point, though it seems strange to do a version bump when that's really the only change to the bits on the wire, and the only real change then is how the signatures are interpreted; syntax vs. semantics. > Bonus question: why put the author domain and target domain fields in > a new header rather than just addding ddd= and > ddt= to the signature header? > Originally it was done as a separate tag, but that meant changing DKIM in some way even if it means registering a new tag that some/most will just ignore. Using a separate header field keeps DKIM itself pristine, and just builds on top of it. Would reverting to a tag method obviate the need for a version bump? -MSK --f46d043890a5ec5d2404fb973bce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 11, 2014 at 3:22 PM, John Levine <johnl@taugh.c= om> wrote:
Someone sends off a message to a mailing list with the two DKIM
signatures and DKIM-Delegate. =C2=A0Someone else, perhaps a list
subscriber, notes that the weaker signature doesn't cover the body, so<= br> he replaces the body with nose enlargement spam and blasts it out.
Recipient MTAs which haven't been updated since 2014 and don't know=
about DKIM-Delegate see the weak but valid signature and since the
signer has a generally good reputation, delivers it. =C2=A0Ugh.

Right, that's the "considerable latitude&= quot; that's already mentioned in the draft.=C2=A0 The "x=3D"= is the current protection against that sort of abuse.=C2=A0 It's not m= uch, but it's what we've thought of so far.=C2=A0 The alternative i= s to use an "l=3D" that is the length of the original rather than= 0, which constrains the abuse considerably but might reduce the likelihood= of this working.
=C2=A0
This hasn't been a problem before. =C2=A0Although you've always bee= n
allowed to use weak signatures, there's been no advantage to doing so,<= br> so nobody did. =C2=A0Now you do, but with new semantics that you shouldn= 9;t
pay much (any?) attention to that signature unless it's paired with
the forwarder's. =C2=A0One could make an argument that it's not tec= hnically
a semantic change to DKIM (indeed, Dave just did), but in practical
terms, it is likely to interact poorly with existing unupgraded
software, so I'd want a version bump so that the old software ignores the special purpose signature.

I see yo= ur point, though it seems strange to do a version bump when that's real= ly the only change to the bits on the wire, and the only real change then i= s how the signatures are interpreted; syntax vs. semantics.
=C2=A0
Bonus question: why put the author domain and target domain fields in
a new header rather than just addding ddd=3D<author> and
ddt=3D<forwarders> to the signature header?

=
Originally it was done as a separate tag, but that meant changin= g DKIM in some way even if it means registering a new tag that some/most wi= ll just ignore.=C2=A0 Using a separate header field keeps DKIM itself prist= ine, and just builds on top of it.=C2=A0 Would reverting to a tag method ob= viate the need for a version bump?

-MSK
--f46d043890a5ec5d2404fb973bce-- From nobody Wed Jun 11 16:25:37 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674371B28CC for ; Wed, 11 Jun 2014 16:25:35 -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_32=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 ph5uHrhyQAub for ; Wed, 11 Jun 2014 16:25:34 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD091A01CA for ; Wed, 11 Jun 2014 16:25:33 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id x48so456982wes.11 for ; Wed, 11 Jun 2014 16:25: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=trKSRaFc6F7DY4UiS1UosbZOHsRInEqm4SgEAK4LeXg=; b=SPs/wDosVkfzDcLMFE1hzewxmIsNStQbjzjIUzLshHzHJlLCHwpdQHSV9VZeK4mqKy GOxDjXxlP1CXQNmNGX3850j7TmBmaQ8aOobFOZpNGFcSHhE9BKGtXsHC9vIEbvJ633zx ZR0TxxjDnbMUmQISDjnNUgHlt1tFk8DozzmW+7C+sL54CHI0gLTBL6UtR18RGljlVBgp 0QIZM+z6zhsYhrm/0P3XAAcpkX/oiOpxFDXB275Iq/IYXh3GowbOgxumCX47v1rpL3rK 4rhusVP8wMxDdu1bsmF2lCzILo+yqurolOWSrysJ1KHp42jfMntvjy73MZfccxz4cY7T ruYQ== MIME-Version: 1.0 X-Received: by 10.194.91.175 with SMTP id cf15mr56332532wjb.5.1402529132670; Wed, 11 Jun 2014 16:25:32 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Wed, 11 Jun 2014 16:25:32 -0700 (PDT) In-Reply-To: References: <20140611222207.2338.qmail@joyce.lan> Date: Wed, 11 Jun 2014 16:25:32 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=047d7bfcebc6bd74e704fb97c2d8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/BAa0UVfE4TfUQ9ve_GIXWMKhLMc Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Wed, 11 Jun 2014 23:25:35 -0000 --047d7bfcebc6bd74e704fb97c2d8 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 11, 2014 at 3:47 PM, Murray S. Kucherawy wrote: > > >> This hasn't been a problem before. Although you've always been >> allowed to use weak signatures, there's been no advantage to doing so, >> so nobody did. Now you do, but with new semantics that you shouldn't >> pay much (any?) attention to that signature unless it's paired with >> the forwarder's. One could make an argument that it's not technically >> a semantic change to DKIM (indeed, Dave just did), but in practical >> terms, it is likely to interact poorly with existing unupgraded >> software, so I'd want a version bump so that the old software ignores >> the special purpose signature. >> > > I see your point, though it seems strange to do a version bump when that's > really the only change to the bits on the wire, and the only real change > then is how the signatures are interpreted; syntax vs. semantics. > Hmm: DKIM-Signature: v=1; d=example.com; ... DKIM-Signature: v=2; l=0; d=example.com; rsf=to,cc,trusted-lists.example.org; ... "rsf" = "require signature from", with "to" and "cc" being special case keywords with the obvious meaning. You have something like that in mind? -MSK --047d7bfcebc6bd74e704fb97c2d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 11, 2014 at 3:47 PM, Murray S. Kucherawy <s= uperuser@gmail.com> wrote:
=C2=A0
This hasn't been a problem before. =C2=A0Although you've always bee= n
allowed to use weak signatures, there's been no advantage to doing so,<= br> so nobody did. =C2=A0Now you do, but with new semantics that you shouldn= 9;t
pay much (any?) attention to that signature unless it's paired with
the forwarder's. =C2=A0One could make an argument that it's not tec= hnically
a semantic change to DKIM (indeed, Dave just did), but in practical
terms, it is likely to interact poorly with existing unupgraded
software, so I'd want a version bump so that the old software ignores the special purpose signature.

I = see your point, though it seems strange to do a version bump when that'= s really the only change to the bits on the wire, and the only real change = then is how the signatures are interpreted; syntax vs. semantics.

Hmm:

DKIM-S= ignature: v=3D1; d=3Dexample.com; ...DKIM-Signature: v=3D2; l=3D0; d=3Dexample.c= om; rsf=3Dto,cc,trusted-li= sts.example.org; ...

"rsf" =3D "require signature from&= quot;, with "to" and "cc" being special case keywords w= ith the obvious meaning.

You have something like that in = mind?

-MSK
--047d7bfcebc6bd74e704fb97c2d8-- From nobody Wed Jun 11 18:12:25 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320751B2925 for ; Wed, 11 Jun 2014 18:12:25 -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 pUgHxtouRjIB for ; Wed, 11 Jun 2014 18:12:22 -0700 (PDT) Received: from secure.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7704C1B2926 for ; Wed, 11 Jun 2014 18:12:21 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=191; t=1402535537; h=Received:Received: Subject:From:Message-Id:Date:To:Organization:List-ID; bh=XgoBnsd beVccHbDLBlXNojsuZM0=; b=La4qTm7LCGq40FbW5KFkM6Ax/BiLnV64jOnT9Tk r961/LbtmLKtLaBkJwv37Owh/vBx7ByQjht0EDeyHU3TbQ77DbFHWUq0w/zXe+Mu GFg7DtyWm2+2+QvaQseVlbnGS63y03VE10gCvvkaeHr2eUJIRyKHrQcs3LH9ZVQk yuTY= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 11 Jun 2014 21:12:17 -0400 Received: from [192.168.1.67] (99-121-4-27.lightspeed.miamfl.sbcglobal.net [99.121.4.27]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2015658373.18742.3732; Wed, 11 Jun 2014 21:12:16 -0400 References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <87ppihgugl.fsf@uwakimon.sk.tsukuba.ac.jp> <5396A9B4.8000103@gmail.com> From: Hector Santos Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (11B651) In-Reply-To: <5396A9B4.8000103@gmail.com> Message-Id: <46CF7F03-AA14-4C26-A01B-226B146E1FF4@isdg.net> Date: Wed, 11 Jun 2014 21:12:14 -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: http://mailarchive.ietf.org/arch/msg/dmarc/OgNMoWHw15BlvukkVXPbKMefGB4 Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 12 Jun 2014 01:12:25 -0000 Dave wrote: > > Everything gets much easier if we specify guidance for filtering > engines, before humans come into the picture. > +1 -- Hector Santos http ://www.santronics.com From nobody Wed Jun 11 19:49:48 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBADA1A032B for ; Wed, 11 Jun 2014 19:49:45 -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 CHzcHugTJmHD for ; Wed, 11 Jun 2014 19:49:42 -0700 (PDT) Received: from catinthebox.net (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id E99C71B2997 for ; Wed, 11 Jun 2014 19:49:41 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2708; t=1402541377; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Vi65P0ugpnU2akgKfPExgytRrBI=; b=CLDM2lDyypprwci9vqt1 5w4b/8SPHyLNqrCzKb859llip75ecswIH1h0hjFOgkbQ7orxQPLCgiCy9tsluDVB QayXxdmJjk3iZuR8cjQKDguFeiX6EOFaub6kfZxLWl/d8bOSgFp8A1k1XEnJOLb2 HgDgBW6MOCbwqN5MDtGJExg= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 11 Jun 2014 22:49: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; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2021497927.18742.4324; Wed, 11 Jun 2014 22:49:35 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2708; t=1402541208; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Ul+49dG xHN5mZbRE4yE7OOdj69Ljjr8T+WYvG23HRVY=; b=htc7GT/6e8tmORoBpXcgkBi gBH5vpc4ewA87RGET9mfRDNIJJ14Pi5gy54rc6/0xwGaY0dAK6W4jw30yiCCIPKf JHFh0kcRYvLupsqAegIDYViLWAk8Nnp63gIDwD72cspDWFAklkwy3HGFQBiU+el0 DxekpwkkzgqGW0rA/E70= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Wed, 11 Jun 2014 22:46: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 2037854687.9.4848; Wed, 11 Jun 2014 22:46:46 -0400 Message-ID: <53991540.7060506@isdg.net> Date: Wed, 11 Jun 2014 22:49: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: "Murray S. Kucherawy" References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <1755889339.33315.1402383131643.JavaMail.zimbra@peachymango.org> <1019546957.39246.1402408698423.JavaMail.zimbra@peachymango.org> <699367420.39896.1402409599837.JavaMail.zimbra@peachymango.org> <5397156F.8010603@gmail.com> <3E16067A-64CB-4B84-ABBD-82873DB63E88@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/qM2UagNj0OU1uO4aRRpIHNSc5Ts Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Thu, 12 Jun 2014 02:49:46 -0000 On 6/11/2014 4:58 PM, Murray S. Kucherawy wrote: > > One thing that is missing (and there's a placeholder for it) is > examples so you can see how it works. I'll make sure that's there for > -01. Examples are good. Can we work it out here, a "software" walkthru? Save some drafting time. > The most basic protocol fault is when no signatures, no extra new > headers are available -- the legacy operation. Here the lookup is > required. If not, the bad guy loophole is simply to remain in > legacy mode. They don't need to think about trying to find a fake > signature. > > > A lookup for what, and where? The "Checking Signing Practice" (CSP) module in the DKIM architectural overview (RFC5585), the "Sender Signing Practices Query" in the DKIM Threat Analysis (RFC4686). In this case, DMARC. In general, the market is finally doing a DNS lookup for policy and we need to leverage that call for 3rd party semantics. In my view, that is the problem we are facing. So if the proposed DKIM-Delegate header or DKIM-Signature 2.0 tags offer a lower overhead, shortcut to addressing all the threats, then we need to see how that is done. I don't think it does cover the basic use cases unless there is something else in the logic I am not catching. More below on this. > But you're right, there's a risk of a legacy DKIM verifier getting > only the delegation signature for some reason. The exposure is > supposedly time-limited, and we're assuming verifiers all pay > attention to "x=", but it should also be documented. Good idea to use the x= more. Yes, the risk with the existing base DKIM verifiers, but I speak of the more primitive, basic protocol faults "holes", "use cases" that is central to all this: Restrictive 1st Party (Author Domain) Signing Policies - No Mail Expected - Signature Required, Exclusive 1st party only. - Signature Required, Any 3rd party allowed. - Signature Required, Authorized 3rd party allowed only. How will DKIM-Delegate address the above conditions? The "No Mail" policy can be folded with the others. Previous proposals SSP, DSAP I-D included "No Mail" policies. ADSP with a "dkim=discardable" policy and a null public singer key. I suppose the same can be done for DMARC "p=reject" policy and a null public signer key. I just wanted to outline it above since it is also part of the modern mail processing logic to check for. The goal is to detect the faults in the above policies. If DKIM-Delegate does address the above, then its becomes a good optimizer. However, there still need to be an "IF ELSE" DNS lookup when the DKIM-Delegate or advanced 2.0 DKIM signature is missing. -- HLS From nobody Wed Jun 11 20:07:27 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED571A03D9 for ; Wed, 11 Jun 2014 20:07:25 -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 kbkx7DThD7Kf for ; Wed, 11 Jun 2014 20:07:23 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 781D31A03B1 for ; Wed, 11 Jun 2014 20:07:23 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id q59so578636wes.40 for ; Wed, 11 Jun 2014 20:07:22 -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=aoy2sJbcPR/7QkQ44t1yvD/DcnCSPOAZpz1/U5xSQCw=; b=TgkVZnp36DRjJpL2T2ifDzWZhXD+8dILgxnYRrAdgGVGZb3vhYiwpOMMOnWZVJC6U7 hQZlMN58cuU+AsZpdOnHQo7PgUVJUu6McR4WJaEf99JjjiZmeapu1fKpjT09YdM019W3 Bq0W1tJK4qWV/HhXl5H3K+lD2u+FFEIUfkBH5TTLYPmH77lzgBxmAGQ2aKh0xSJnOh56 /BuXPRt9FaTqbmEeuGOjuhK2KGj+KgXUqBk8k367OSKm99K1GDGR7JSdq/rB7muZitI5 4gOpAyamiQ8HSU2h2vV5sBab0nvQT7iQsVjvHYJWJCHQAp1Fl6/7S/8kUZCtBdEd0Lb3 wEOg== MIME-Version: 1.0 X-Received: by 10.180.75.212 with SMTP id e20mr2098833wiw.5.1402542442143; Wed, 11 Jun 2014 20:07:22 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Wed, 11 Jun 2014 20:07:21 -0700 (PDT) In-Reply-To: <53991540.7060506@isdg.net> References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <1755889339.33315.1402383131643.JavaMail.zimbra@peachymango.org> <1019546957.39246.1402408698423.JavaMail.zimbra@peachymango.org> <699367420.39896.1402409599837.JavaMail.zimbra@peachymango.org> <5397156F.8010603@gmail.com> <3E16067A-64CB-4B84-ABBD-82873DB63E88@isdg.net> <53991540.7060506@isdg.net> Date: Wed, 11 Jun 2014 20:07:21 -0700 Message-ID: From: "Murray S. Kucherawy" To: Hector Santos Content-Type: multipart/alternative; boundary=f46d043890a50be72204fb9adc29 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/p9BWjO-3wXorNa3U9_dmxyCwswU Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Thu, 12 Jun 2014 03:07:25 -0000 --f46d043890a50be72204fb9adc29 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 11, 2014 at 7:49 PM, Hector Santos wrote: > On 6/11/2014 4:58 PM, Murray S. Kucherawy wrote: > >> >> One thing that is missing (and there's a placeholder for it) is >> examples so you can see how it works. I'll make sure that's there for >> -01. >> > > Examples are good. Can we work it out here, a "software" walkthru? Save > some drafting time. The draft already does that in Section 3.2. What's missing is an example message showing the semantics. Yes, the risk with the existing base DKIM verifiers, but I speak of the > more primitive, basic protocol faults "holes", "use cases" that is central > to all this: > > Restrictive 1st Party (Author Domain) Signing Policies > > - No Mail Expected > That's not in scope here. You could use draft-ietf-appsawg-nullmx for that if you really want. > - Signature Required, Exclusive 1st party only. > You would simply not use DKIM-Delegate if that's your policy. > - Signature Required, Any 3rd party allowed. > I don't think we're interested in that case here. Why would you want to allow arbitrary third parties to sign on your behalf and have that be meaningful? That would mean I can sign something that came from you and everyone would believe you approved it. > - Signature Required, Authorized 3rd party allowed only. > That's the exact use case for DKIM-Delegate. > If DKIM-Delegate does address the above, then its becomes a good > optimizer. However, there still need to be an "IF ELSE" DNS lookup when the > DKIM-Delegate or advanced 2.0 DKIM signature is missing. > It only addresses one of those cases, but that's the only one we need to solve here. And since one of the big benefits of this mechanism is that the policy becomes part of the message, there's no need to bring DNS (or a published whitelist of any kind) into this at all. -MSK --f46d043890a50be72204fb9adc29 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 11, 2014 at 7:49 PM, Hector Santos <hsantos@= isdg.net> wrote:
On 6/11/2014 4:58 PM, Murray= S. Kucherawy wrote:

One thing that is missing (and there's a placeholder for it) is
examples so you can see how it works. =C2=A0I'll make sure that's t= here for
-01.

Examples are good. Can we work it out here, a "software" walkthru= ? Save some drafting time.

The draft alread= y does that in Section 3.2.=C2=A0 What's missing is an example message = showing the semantics.

Yes, the risk with= the existing base DKIM verifiers, but I speak of the more primitive, basic= protocol faults "holes", "use cases" that is central t= o all this:

=C2=A0 Restrictive 1st Party (Author Domain) Signing Policies

=C2=A0 - No Mail Expected

That's no= t in scope here.=C2=A0 You could use draft-ietf-appsawg-nullmx for that if = you really want.
=C2=A0
=C2=A0 - Signature Required, Exclusive 1st party only.

You would simply not use DKIM-Delegate if that's your p= olicy.
=C2=A0
=C2=A0 - Signature Required, Any 3rd party allowed.
I don't think we're interested in that case here.=C2= =A0 Why would you want to allow arbitrary third parties to sign on your beh= alf and have that be meaningful?=C2=A0 That would mean I can sign something= that came from you and everyone would believe you approved it.
=C2=A0
=C2=A0 - Signature Required, Authorized 3rd party allowed only.

That's the exact use case for DKIM-Delegate.=C2=A0
If DKIM-Delegate does address the above, then its becomes a good optimizer.= However, there still need to be an "IF ELSE" DNS lookup when the= DKIM-Delegate or advanced 2.0 DKIM signature is missing.

It only addresses one of tho= se cases, but that's the only one we need to solve here.=C2=A0 And sinc= e one of the big benefits of this mechanism is that the policy becomes part= of the message, there's no need to bring DNS (or a published whitelist= of any kind) into this at all.

-MSK
--f46d043890a50be72204fb9adc29-- From nobody Wed Jun 11 21:21:55 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4051B29C9 for ; Wed, 11 Jun 2014 21:21:52 -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 uSY4nJx7eq6Z for ; Wed, 11 Jun 2014 21:21:42 -0700 (PDT) Received: from news.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 755261B29C6 for ; Wed, 11 Jun 2014 21:21:42 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3727; t=1402546897; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=e5+Ky/O2QFXTlUCDe12xxsbjiKk=; b=jNrBSzMEuvktACqpSlob kRSK6PZo1einyTYF0G0dQ6j0EciZf5Ysk+LOBLNYdBvaJoYiYSi5u8iw83rD02Z9 e9nq1XiaJNnlEsNsI/QNhVSTwVaFS2XH59sRoNWICQZcD4Eq9gT47R9VxGSLkuR+ kvywnXnCntu7Bw43vvPQjPs= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 12 Jun 2014 00:21: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; Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2027018132.18742.4760; Thu, 12 Jun 2014 00:21:36 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3727; t=1402546727; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=VR4oaSO nuok8hOz4IxaJzclb2OOcC7fctTWYpNXlrqU=; b=xnVFojbX0USDE0sZLAX8vWI 0RCfTElr44VXdYpOnpBSEQQz4w4Zk50UORYmlk8m+YSGH4gGf2wlX0FTe5tUnPCp ihWw0xtXGSinJB9UmPmZxGFGrN02jverwQmcYpg+C/CH0zJws0M27cuTLI7Ukt0V iTg9xDWZWU9zWKZ9ZXEM= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 12 Jun 2014 00:18:47 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2043374250.9.5900; Thu, 12 Jun 2014 00:18:46 -0400 Message-ID: <53992AD0.3080006@isdg.net> Date: Thu, 12 Jun 2014 00:21: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: "Murray S. Kucherawy" References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <1755889339.33315.1402383131643.JavaMail.zimbra@peachymango.org> <1019546957.39246.1402408698423.JavaMail.zimbra@peachymango.org> <699367420.39896.1402409599837.JavaMail.zimbra@peachymango.org> <5397156F.8010603@gmail.com> <3E16067A-64CB-4B84-ABBD-82873DB63E88@isdg.net> <53991540.7060506@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/WGc5d5dSQkNGcY-SIfySZu9xdEU Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Thu, 12 Jun 2014 04:21:52 -0000 >> Restrictive 1st Party (Author Domain) Signing Policies >> >> - No Mail Expected > > That's not in scope here. You could use draft-ietf-appsawg-nullmx for > that if you really want. The NULLMX proposal only applies on the SMTP client, sending, callout side. This one can be folded with the others, but again, its an optimizer. >> - Signature Required, Exclusive 1st party only. > > You would simply not use DKIM-Delegate if that's your policy. Again, the fault. The policy is X, but Y is seen. The payload can be DKIM-Delegate compliant but the actual policy is exclusive and doesn't allow it. You need the lookup for this or prove the assertion it will satisfy the threat analysis for this use case. >> - Signature Required, Any 3rd party allowed. > > I don't think we're interested in that case here. Why would you want > to allow arbitrary third parties to sign on your behalf and have that > be meaningful? That would mean I can sign something that came from > you and everyone would believe you approved it. Yes, it is a more relaxed policy that does require a signer trust and this was the where we last left SSP because we were trying to figure out the scaled authorized signer model. In the mean time, it helps for the resigners to exist. But again, its the fault we are detecting. The policy allow for any signer, but there meant be no valid signatures. You are probably right that DKIM-Delegate can't resolve this, but what we want is for DMARC to have the language to say: "I'm ok with any trusted valid signer" For the trust attribute, this is where either VBR comes into play or the DKIM_Trust_Assessment(SDID [,AUID) algorithm is applied, when its finally available. >> - Signature Required, Authorized 3rd party allowed only. > > That's the exact use case for DKIM-Delegate. Right, You want the fault of this case. In others, a domain may not expect the DKIM-Delegate header, but that is what you see or there is no header, and the domain expects it. >> If DKIM-Delegate does address the above, then its becomes a good >> optimizer. However, there still need to be an "IF ELSE" DNS lookup >> when the DKIM-Delegate or advanced 2.0 DKIM signature is missing. > > It only addresses one of those cases, but that's the only one we need > to solve here. But it also has to address the others too at the same time, otherwise, there have loop holes. > And since one of the big benefits of this mechanism is > that the policy becomes part of the message, there's no need to bring > DNS (or a published whitelist of any kind) into this at all. I agree. Passing the policy via 5322 was talked about in 2005/2006 between Jim Fenton and I. But if the signature and/or policy information in the payload is missing, you have to do the lookup anyway. And also, how are you going to show the the payload policy actually matches the DNS published policy? In theory, they have to be the same because you are going to need a migration path. We can do the same with the public key, piggy-back off the 5322 payload too, saving even more DNS calls. In theory, a compliant domain isn't going to commit suicide by providing faulty information. By if you don't enforce it, then it does not solve anything. Overall, the problem is the DMARC verifiers are indeed enforcing the strong policies. If you have a DKIM-Delegate to address only 3rd party resigners, then you will need a matching backward compatible DNS version of this. In this vain, I think there is a lost focus on working on dkim-delegate unless its overall functional goals comes in two flavors; a DNS and a NON-DNS version. In this case, it is an optimizer. -- HLS From nobody Wed Jun 11 21:45:14 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFED11B2980 for ; Wed, 11 Jun 2014 21:45: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 F1AUoBOoxiuG for ; Wed, 11 Jun 2014 21:45:09 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3104E1A036C for ; Wed, 11 Jun 2014 21:45:09 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x13so629221wgg.21 for ; Wed, 11 Jun 2014 21:45: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=dSRCUw6tcJfE9Ne8VCseqQHCFbA1qThh8o+hNNwCYGU=; b=knJPrdR8qMFMjRLbwwarQFcizKAp7UEt03myWXZ2SYtYugTpmL6TqWVnwM6rvex4TH xVbuYMu8lMG4WBYqXGOrON0k94W+TwOl5fUsAd6kN5C8ojxqCGkOVcDl3yAglIYIAwpa EHDRNpITP4PpZlc51QPHiSK61sRaM9RGs2pB1lq+Vssu6v+PM4opkGUNAm63VGqZoKPw +9o2+rnYvP2r1BJYeNTbrCW4ALO4l9f3XAVU2eN+RQ2MuUWo/yyqzt24KVOQzV7OjDog 9DEUEyUsv50B/ZJbB3rznZRchkANKG6gQGItVCd76CXUh4jipvf5Lfa7v2H6+GRZwBID OFzA== MIME-Version: 1.0 X-Received: by 10.194.89.168 with SMTP id bp8mr57728948wjb.73.1402548307535; Wed, 11 Jun 2014 21:45:07 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Wed, 11 Jun 2014 21:45:07 -0700 (PDT) In-Reply-To: <53992AD0.3080006@isdg.net> References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <1755889339.33315.1402383131643.JavaMail.zimbra@peachymango.org> <1019546957.39246.1402408698423.JavaMail.zimbra@peachymango.org> <699367420.39896.1402409599837.JavaMail.zimbra@peachymango.org> <5397156F.8010603@gmail.com> <3E16067A-64CB-4B84-ABBD-82873DB63E88@isdg.net> <53991540.7060506@isdg.net> <53992AD0.3080006@isdg.net> Date: Wed, 11 Jun 2014 21:45:07 -0700 Message-ID: From: "Murray S. Kucherawy" To: Hector Santos Content-Type: multipart/alternative; boundary=047d7bf10a1ca6ad1304fb9c39ed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/nmUhXWVZd93RxEzjqT6Xj2LQ34c Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Thu, 12 Jun 2014 04:45:11 -0000 --047d7bf10a1ca6ad1304fb9c39ed Content-Type: text/plain; charset=UTF-8 On Wed, Jun 11, 2014 at 9:21 PM, Hector Santos wrote: > > - Signature Required, Exclusive 1st party only. >>> >> >> You would simply not use DKIM-Delegate if that's your policy. >> > > Again, the fault. The policy is X, but Y is seen. The payload can be > DKIM-Delegate compliant but the actual policy is exclusive and doesn't > allow it. You need the lookup for this or prove the assertion it will > satisfy the threat analysis for this use case. No, there are two possibilities in the face of DMARC "p=reject": (1) There's no DKIM delegation, and therefore the From: domain's policy is automatically what you call first-party only. (2) There is DKIM delegation, and therefore the From: domain's policy is either first-party or authorized third-party, where the list of authorized third-parties is in the message (either DKIM-Delegate's "t=" field, or the To/Cc fields). > > "I'm ok with any trusted valid signer" > > For the trust attribute, this is where either VBR comes into play or the > DKIM_Trust_Assessment(SDID [,AUID) algorithm is applied, when its finally > available. "Any trusted valid signer" is not the same as "Any third party allowed" (which is the first thing you said). The minute you introduce the need to know if X trusts Y, you're basically back to a whitelist and scaling problems again. We really don't want (or need) to deal with this use case. We're only interested in specific third parties. > > - Signature Required, Authorized 3rd party allowed only. >>> >> >> That's the exact use case for DKIM-Delegate. >> > > Right, You want the fault of this case. In others, a domain may not expect > the DKIM-Delegate header, but that is what you see or there is no header, > and the domain expects it. It's never expected. It's used at the discretion of the From: domain to select one of two possible modes of verifying, described above. > > If DKIM-Delegate does address the above, then its becomes a good >>> optimizer. However, there still need to be an "IF ELSE" DNS lookup >>> when the DKIM-Delegate or advanced 2.0 DKIM signature is missing. >>> >> >> It only addresses one of those cases, but that's the only one we need >> to solve here. >> > > But it also has to address the others too at the same time, otherwise, > there have loop holes. I disagree, I claim those others are out of scope. We don't need them to solve this problem. > > And since one of the big benefits of this mechanism is >> that the policy becomes part of the message, there's no need to bring >> DNS (or a published whitelist of any kind) into this at all. >> > > I agree. Passing the policy via 5322 was talked about in 2005/2006 between > Jim Fenton and I. But if the signature and/or policy information in the > payload is missing, you have to do the lookup anyway. I don't agree; the policy is implicit in DMARC (if that's what you're using). > And also, how are you going to show the the payload policy actually > matches the DNS published policy? In theory, they have to be the same > because you are going to need a migration path. > In theory, DMARC would be amended to either allow for DKIM delegation always, or offer it as a flag in the DNS record. But ignoring DMARC for the moment, no additional lookup is needed here. > We can do the same with the public key, piggy-back off the 5322 payload > too, saving even more DNS calls. In theory, a compliant domain isn't going > to commit suicide by providing faulty information. By if you don't enforce > it, then it does not solve anything. > This seems to go off in the weeds a bit. Carrying the public key in the message adds a bunch of bulk to the message and then adds the requirement that the key be tied back to the domain somehow, otherwise you could use any old key and claim to be anyone. I don't think there's a need to drag DANE into this. > Overall, the problem is the DMARC verifiers are indeed enforcing the > strong policies. If you have a DKIM-Delegate to address only 3rd party > resigners, then you will need a matching backward compatible DNS version of > this. > I fail to see how DNS is a requirement for this beyond what DKIM already requires. The policy is implicit in the way the message is built with DKIM and DKIM-Delegate. -MSK --047d7bf10a1ca6ad1304fb9c39ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 11, 2014 at 9:21 PM, Hector Santos <hsantos@= isdg.net> wrote:

- Signature Required, Exclusive 1st party only.

You would simply not use DKIM-Delegate if that's your policy.

Again, the fault. The policy is X, but Y is seen. =C2=A0The payload can be = DKIM-Delegate compliant but the actual policy is exclusive and doesn't = allow it. =C2=A0You need the lookup for this or prove the assertion it will= satisfy the threat analysis for this use case.

No, there are two possibilities in the face of DMARC "p= =3Dreject":

(1) There's no DKIM delegation, and = therefore the From: domain's policy is automatically what you call firs= t-party only.

(2) There is DKIM delegation, and therefore the From: domain's poli= cy is either first-party or authorized third-party, where the list of autho= rized third-parties is in the message (either DKIM-Delegate's "t= =3D" field, or the To/Cc fields).
=C2=A0
<= div class=3D"">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "I'm ok with any trusted valid = signer"

For the trust attribute, this is where either VBR comes into play or the DK= IM_Trust_Assessment(SDID [,AUID) algorithm is applied, when its finally ava= ilable.

"Any trusted valid signer"= ; is not the same as "Any third party allowed" (which is the firs= t thing you said).=C2=A0 The minute you introduce the need to know if X tru= sts Y, you're basically back to a whitelist and scaling problems again.=

We really don't want (or need) to deal with this use case.=C2=A0 We= 're only interested in specific third parties.
=C2=A0

- Signature Required, Authorized 3rd party allowed only.

That's the exact use case for DKIM-Delegate.

Right, You want the fault of this case. In others, a domain may not expect = the DKIM-Delegate header, but that is what you see or there is no header, a= nd the domain expects it.

It's never ex= pected.=C2=A0 It's used at the discretion of the From: domain to select= one of two possible modes of verifying, described above.
=C2=A0

If DKIM-Delegate does address the above, then its becomes a good
optimizer. However, there still need to be an "IF ELSE" DNS looku= p
=C2=A0when the DKIM-Delegate or advanced 2.0 DKIM signature is missing.

It only addresses one of those cases, but that's the only one we need to solve here.

But it also has to address the others too at the same time, otherwise, ther= e have loop holes.

I disagree, I claim thos= e others are out of scope.=C2=A0 We don't need them to solve this probl= em.
=C2=A0

And since one of the big benefits of this mechanism is
that the policy becomes part of the message, there's no need to bring DNS (or a published whitelist of any kind) into this at all.

I agree. Passing the policy via 5322 was talked about in 2005/2006 between = Jim Fenton and I. =C2=A0But if the signature and/or policy information in t= he payload is missing, you have to do the lookup anyway.
<= br>
I don't agree; the policy is implicit in DMARC (if that'= s what you're using).
=C2=A0
And also, how are you going to show the the payload policy actually matche= s the DNS published policy? =C2=A0In theory, they have to be the same becau= se you are going to need a migration path.

<= div> In theory, DMARC would be amended to either allow for DKIM delegation alway= s, or offer it as a flag in the DNS record.=C2=A0 But ignoring DMARC for th= e moment, no additional lookup is needed here.
=C2=A0
We can do the same with the public key, piggy-back off the 5322 payload too= , saving even more DNS calls. =C2=A0In theory, a compliant domain isn't= going to commit suicide by providing faulty information. =C2=A0By if you d= on't enforce it, then it does not solve anything.

This seems to go off in the weeds a bit.= =C2=A0 Carrying the public key in the message adds a bunch of bulk to the m= essage and then adds the requirement that the key be tied back to the domai= n somehow, otherwise you could use any old key and claim to be anyone.=C2= =A0 I don't think there's a need to drag DANE into this.
=C2=A0
Overall, the problem is the DMARC verifiers are indeed enforcing the strong= policies. =C2=A0If you have a DKIM-Delegate to address only 3rd party resi= gners, then you will need a matching backward compatible DNS version of thi= s.

I fail to see how DNS is a requirement for= this beyond what DKIM already requires.=C2=A0 The policy is implicit in th= e way the message is built with DKIM and DKIM-Delegate.

-MSK
--047d7bf10a1ca6ad1304fb9c39ed-- From nobody Wed Jun 11 22:19:58 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C351B29D1 for ; Wed, 11 Jun 2014 22:19: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 0e4wL3y7J-7i for ; Wed, 11 Jun 2014 22:19:55 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC9A1A035F for ; Wed, 11 Jun 2014 22:19:54 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id y10so667660wgg.20 for ; Wed, 11 Jun 2014 22:19: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=3q++Xt0/RKTZ5oqJAZRwpyrM9g5rmjSbts7iU/rwtEk=; b=U8vCNBedzSyjv1enMZGNN2a6a3kPXnNJRbn5DfyBeKIaeg3S+L4zw7MyCZaPm2IswG 76vlINmVVaSs2Yz/OmoEZQ87rQ/nSbuue5Zms5ohFaS2Qwjt12mkpqOn6ZJCQZdIzdzC kTXzQwrewbgXD/s2Si/rV9wjSx6n1shDl7PTBEf21BUsF3m5hGLHdoQEsawaVyCIxD9q txohA0JaJOZ499bUu5Imtz8i+D0HqrqaelbYRznA6xp8WcGjySpfMnN+hqZ9hoWNeqXw s0Zvl0eSsXTD2oOTOvDI0Vs9Mc+a5tGwjJJeAOw3OjqN5z/FXAZH+NaW0RahBMQub6Nk 5oRA== X-Received: by 10.180.19.233 with SMTP id i9mr2928289wie.38.1402550393101; Wed, 11 Jun 2014 22:19:53 -0700 (PDT) Received: from ?IPv6:2a02:a03f:1405:ee00:89d6:585d:8c73:1361? ([2a02:a03f:1405:ee00:89d6:585d:8c73:1361]) by mx.google.com with ESMTPSA id m44sm2367285eeh.14.2014.06.11.22.19.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Jun 2014 22:19:52 -0700 (PDT) Message-ID: <5399383E.3060709@gmail.com> Date: Thu, 12 Jun 2014 07:18:54 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dave Warren , dmarc@ietf.org References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <87ppihgugl.fsf@uwakimon.sk.tsukuba.ac.jp> <5396E49C.2000808@isdg.net> <8738fcrhqz.fsf@uwakimon.sk.tsukuba.ac.jp> <53974C62.9050408@isdg.net> <87tx7splbb.fsf@uwakimon.sk.tsukuba.ac.jp> <998FA07D-E6D7-41FB-A143-CE7B426E6763@tnpi.net> <53978CD9.3000907@hireahit.com> In-Reply-To: <53978CD9.3000907@hireahit.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/W2cBaL0sb2SrfBVgzlKx5rd-Z8A Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 12 Jun 2014 05:19:56 -0000 On 6/11/2014 12:55 AM, Dave Warren wrote: > I've been surprised how many otherwise-technically-competent people use > subject tags to filter mailing lists. I've been surprised at how many otherwise-technically-competent people believe that techniques that have been reliably useful for decades are somehow technically incompetent to have been using, given alternatives that surfaced only more recently and weren't necessary to use. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jun 11 22:34:14 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE9C1B29D3 for ; Wed, 11 Jun 2014 22:34:13 -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 A-hYrS5aoDCK for ; Wed, 11 Jun 2014 22:34:12 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE91A1A035F for ; Wed, 11 Jun 2014 22:34:11 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id x48so680939wes.39 for ; Wed, 11 Jun 2014 22:34:10 -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=12Ku9z3/6PtkmbkjGA9YCj2BSAxictvLSN0iwn1IG+w=; b=XZ5L8vjFrx/WS+AFywywW1M5aQsOpubO8KomTNW/gzu6KBmZBJrnGYZz1xHanRytab NXqlsxpLscV3EtnJbCDfezzPXC6f30xqoORle890CVeqgRadP08gpjH+vT9VrqThmDzq 7wVvyxyIvsXQleTeyc+nfUA4jq77tRsZdAUEFjGPCzu1u+dusYHTQPsiOVaNKo09067t H6oGVZ5x4jy45sEQNZRQLUhgmvxWVrw6wyWZgH7V861CFfoSmpceUfyaFux9hY0ZKrF6 dz9kBAfWOIay95RKZXwyjykf8cvE/rf98GF1rY6xQZzIN++jgFBeOGWR20x/43Du1Quw P7rw== X-Received: by 10.195.13.79 with SMTP id ew15mr57693986wjd.19.1402551250107; Wed, 11 Jun 2014 22:34:10 -0700 (PDT) Received: from ?IPv6:2a02:a03f:1405:ee00:89d6:585d:8c73:1361? ([2a02:a03f:1405:ee00:89d6:585d:8c73:1361]) by mx.google.com with ESMTPSA id h6sm2416278eew.38.2014.06.11.22.34.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Jun 2014 22:34:09 -0700 (PDT) Message-ID: <53993B97.4040203@gmail.com> Date: Thu, 12 Jun 2014 07:33:11 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dmarc@ietf.org" References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <5392ECED.5010404@gmail.com> <1755889339.33315.1402383131643.JavaMail.zimbra@peachymango.org> <1402385033.97400.YahooMailNeo@web164602.mail.gq1.yahoo.com> <1402414911.96471.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1402431931.70928.YahooMailNeo@web164606.mail.gq1.yahoo.com> <539884A7.3030306@tana.it> <1402523523.93959.YahooMailNeo@web164601.mail.gq1.yahoo.com> In-Reply-To: <1402523523.93959.YahooMailNeo@web164601.mail.gq1.yahoo.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ee2zGGODACj4BG2Z-TvSMIIM3XA Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Thu, 12 Jun 2014 05:34:13 -0000 On 6/11/2014 11:52 PM, Vlatko Salaj wrote: > delegated domain inclusion in DKIM-D header is optional, This is a reading of the draft specification that appears to be incorrect: the DKIM-Delegate proposal always specifies target domain names for delegated operation. What is optional is the method of specifying them. They can be specified overtly, in the DKIM-Delegate header field, or they can default to the set of domain names in recipient header fields, such as To and CC: 3.2. Specification 2. ... It can also identify the specific domain(s) with which it wishes to claim an ephemeral relationship; absent this indication, the list of candidate domains is implicit from elsewhere in the message header (see below). and 3.3. Syntax ... t= Delegation target (plain-text; OPTIONAL). This value is a comma- separated list of domain names to which the authority to sign on behalf of the Author domain is being delegated. When not present, this list is inferred from the domain names present in the recipient fields (To, Cc) of the header. > and considering it requires some kind of whitelist from which > its to draw a list of domain it should include, compared 2 those > it should not, it is most probably not gonna be used. DKIM-Delegate does not need or use any externally-maintained list. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jun 11 22:40:47 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C671A035F for ; Wed, 11 Jun 2014 22:40:45 -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 3aQgRwl7yO0w for ; Wed, 11 Jun 2014 22:40:44 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C7031A0385 for ; Wed, 11 Jun 2014 22:40:43 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u57so707199wes.3 for ; Wed, 11 Jun 2014 22:40:42 -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=AUXO+48ZEnCExyinoNxJRIprg8knWfa1T4jeQ6lvwF8=; b=Z7VtPrddDQel81owm3sgefAjjeg64g2fXDja7FjgcGSZXtQEwTjxCN+dpjL/SmYIKd yhK+wP32pUOXEigJitj8EpXu3wqqhEoIz4mo85t0jKrD/MrD/HXPzj8YC+xriwJYms1C UrZZWr0Zkrw0SD0fbThzjaQAYdLK7U3DeppfJiffrxSKoJp0wZeer6h5KUzxegQHar9+ NJBRh3j1ZjCA+pjp7UqGrMKhNV8YVZxMv8c7mm7MlTnvZKoFGHYRSoTwa+7joSsJO8u6 M5pVHT+3M/S1NbhHAo/eFnJlDfZ4tvGMXXf4fTDbobe4MngwXtOU60QzaWtDvBE+iTcF VNNQ== X-Received: by 10.180.228.6 with SMTP id se6mr2964770wic.52.1402551642499; Wed, 11 Jun 2014 22:40:42 -0700 (PDT) Received: from ?IPv6:2a02:a03f:1405:ee00:89d6:585d:8c73:1361? ([2a02:a03f:1405:ee00:89d6:585d:8c73:1361]) by mx.google.com with ESMTPSA id b44sm2443968eem.45.2014.06.11.22.40.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Jun 2014 22:40:41 -0700 (PDT) Message-ID: <53993D20.7010901@gmail.com> Date: Thu, 12 Jun 2014 07:39:44 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Levine , dmarc@ietf.org References: <20140611222207.2338.qmail@joyce.lan> In-Reply-To: <20140611222207.2338.qmail@joyce.lan> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/g7Ay1YPWjG4GwnrX0pWRCoDpcvE Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Thu, 12 Jun 2014 05:40:46 -0000 On 6/12/2014 12:22 AM, John Levine wrote: > One could make an argument that it's not technically > a semantic change to DKIM (indeed, Dave just did), but in practical > terms, it is likely to interact poorly with existing unupgraded > software, so I'd want a version bump so that the old software ignores > the special purpose signature. The irony of your suggestion is that it requires having 'unupgraded' software reliably use the version number, given that they haven't needed to do that before either... > Bonus question: why put the author domain and target domain fields in > a new header rather than just addding ddd= and > ddt= to the signature header? 1. Because DKIM isn't being modified. 2. Because there is non-DKIM information that needs to be permitted, namely the list of delegated domains 3. Because layering is our friend. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jun 11 23:38:02 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBC81A009C for ; Wed, 11 Jun 2014 23:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 nAI7XzAE5M-d for ; Wed, 11 Jun 2014 23:37:56 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0CB1A0159 for ; Wed, 11 Jun 2014 23:37:55 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 715A53FA0B1E; Thu, 12 Jun 2014 15:37:54 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 638B111F0DC; Thu, 12 Jun 2014 15:37:54 +0900 (JST) From: "Stephen J. Turnbull" To: Dave Crocker In-Reply-To: <53986F24.8020404@gmail.com> References: <20140611141529.4633.qmail@joyce.lan> <53986B38.2010401@gmail.com> <53986F24.8020404@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 12 Jun 2014 15:37:54 +0900 Message-ID: <87fvjapr99.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Tju_l1IzanmIjqGwtT752L3nYm0 Cc: dmarc@ietf.org, John R Levine Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Thu, 12 Jun 2014 06:37:59 -0000 Dave Crocker writes: > Hence this is merely the case of two, competing signatures and deciding > which to choose. An invalid DKIM signature should not be treated differently from the absence of that signature. I'm not sure about the intended precise technical interpretation of that clause, but I suspect that some (many?) verifiers will simply drop it from further consideration. In spoofed messages either the content-covering DKIM signature will be invalid, or it will be missing. So the valid signature matching -Delegate is indeed weak (authenticates little content), but *there is no competing signature*. I don't know if that matters to your argument. From nobody Wed Jun 11 23:40:49 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3A61A0159 for ; Wed, 11 Jun 2014 23:40:47 -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 F26ojbL-2UuL for ; Wed, 11 Jun 2014 23:40:46 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF8A71A01F9 for ; Wed, 11 Jun 2014 23:40:45 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id n12so709134wgh.31 for ; Wed, 11 Jun 2014 23:40:44 -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=87s2BN8F/zJw6ZApRw+E3ZhY+9jDrHeZSv7vTw1440Q=; b=jKkRUkydD51QWuMhuJq3Bt7hwQmMB893htb4qDhpINLftKkTr8k5+2HRUS/pRsy1gv A0P+W/yeofpHw/8mlwF4GzvXVLmadUQIMhpoq82tQAML2IFR4ANaq5HJwZhlYbYfKA98 1kzUnmdTX+FswpOAeFPDgKnaxAPML06XUlecL28D/pI/IyD5QcGylbaUuIKerNKBseAx 8LIgD0QyWGxs+X3eSS8YvdhgQLOdQM+bsYSRI+/M6FgZ3HEy7AuCjEuaUgfZRRSWCaRY pq0/hlNIv6JGLWGQhz4R6cl0xXwOzLE1zTJb99Pyti+jEzwf4Y4cIg1rlzfANGxC1rU1 H34w== MIME-Version: 1.0 X-Received: by 10.180.83.105 with SMTP id p9mr3468019wiy.8.1402555244003; Wed, 11 Jun 2014 23:40:44 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Wed, 11 Jun 2014 23:40:43 -0700 (PDT) In-Reply-To: <53993D20.7010901@gmail.com> References: <20140611222207.2338.qmail@joyce.lan> <53993D20.7010901@gmail.com> Date: Wed, 11 Jun 2014 23:40:43 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=f46d044282de18c65004fb9dd715 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/2qZhHhIZ6lLB3uqc2NaIBsx-vd8 Cc: "dmarc@ietf.org" , John Levine Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Thu, 12 Jun 2014 06:40:47 -0000 --f46d044282de18c65004fb9dd715 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 11, 2014 at 10:39 PM, Dave Crocker wrote: > The irony of your suggestion is that it requires having 'unupgraded' > software reliably use the version number, given that they haven't needed > to do that before either... > Section 6.1.1 of DKIM makes it a MUST that unknown versions result in an error. Are you assuming here that some/many/most implementations will have ignored that? You might be right; I'm just trying to be clear. For that matter, can we assume "x=" was properly implemented? It would indeed be ideal to find a way to ensure that the delegation signature is disregarded by legacy DKIM implementations, and only used when coupled with a passing Mediator signature. -MSK --f46d044282de18c65004fb9dd715 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 11, 2014 at 10:39 PM, Dave Crocker <dcrock= er@gmail.com> wrote:
The irony of your suggestion= is that it requires having 'unupgraded'
software reliably use the version number, given that they haven't neede= d
to do that before either...

Section 6.1.1 of DKIM makes it a MUST that= unknown versions result in an error.=C2=A0 Are you assuming here that some= /many/most implementations will have ignored that?=C2=A0 You might be right= ; I'm just trying to be clear.=C2=A0 For that matter, can we assume &qu= ot;x=3D" was properly implemented?

It would indeed be ideal to find a way to ensure that the de= legation signature is disregarded by legacy DKIM implementations, and only = used when coupled with a passing Mediator signature.

-MSK
--f46d044282de18c65004fb9dd715-- From nobody Wed Jun 11 23:53:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE5C1A0397 for ; Wed, 11 Jun 2014 23:53: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 Rg15YDVhjH-5 for ; Wed, 11 Jun 2014 23:53:48 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 071BF1A0339 for ; Wed, 11 Jun 2014 23:53:47 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id q59so749223wes.40 for ; Wed, 11 Jun 2014 23:53: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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=4tMbg+sPWmYsS2FQweFVIAMw9bFP+0ytUCt1hZBWWoI=; b=OiEjXjzVq/uDDWnENSLD3uW+3AFKZJ/3+Oqif1KerOhh6y284hYyjOpvMebYUttdfF Q0axYIdVFPPN0m6QKrqXZ+mZ6Exs9bW/RLVpLlw0g1R2jXWySV8dAy2ocTodLP6ht4o6 lYKx1SB7CUkkvDlKI24D5DSGjYJtzsCEGF+6rArJ63QLmt+A5ib1pXySt+U0fhtWKjli 8HYg2LvWHktR/pvaVWP4pxWc5mGhz3/nWzSzeWLbHzmpo9Zuz+hKbK1gYEv3sEwMQapk M524ZiCplTT+8bt4yCepqWHclD58yjI6gjgmNiK5QoJ6lWEJVAf1HJNhjtzXvGclAhku Va/Q== X-Received: by 10.194.77.177 with SMTP id t17mr33214461wjw.55.1402556026538; Wed, 11 Jun 2014 23:53:46 -0700 (PDT) Received: from ?IPv6:2a02:a03f:1405:ee00:89d6:585d:8c73:1361? ([2a02:a03f:1405:ee00:89d6:585d:8c73:1361]) by mx.google.com with ESMTPSA id m1sm2869397eep.24.2014.06.11.23.53.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Jun 2014 23:53:45 -0700 (PDT) Message-ID: <53994E40.1040609@gmail.com> Date: Thu, 12 Jun 2014 08:52:48 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Stephen J. Turnbull" References: <20140611141529.4633.qmail@joyce.lan> <53986B38.2010401@gmail.com> <53986F24.8020404@gmail.com> <87fvjapr99.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87fvjapr99.fsf@uwakimon.sk.tsukuba.ac.jp> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/mikrOiBYRQEDFLO2p3NJgaGowxI Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Thu, 12 Jun 2014 06:53:50 -0000 On 6/12/2014 8:37 AM, Stephen J. Turnbull wrote: > Dave Crocker writes: > > > Hence this is merely the case of two, competing signatures and deciding > > which to choose. > > An invalid DKIM signature should not be treated differently from the > absence of that signature. I wasn't referring to any 'invalid' signatures. When DKIM-Delegate is used, there are two, valid signatures for the same domain. One is 'stronger'. The scenario being discussed is for a recipient who gets both signatures when they are valid, but who does not know about DKIM-Delegate. They only know about DKIM. Folks who are receiving this email they are reading, via the dmarc@ietf.org, would get only one valid signature, since the 'stronger' one would be broken. On the other hand you, Stephen, are a direct recipient and ought to get two valid signatures. One stronger, one weaker. So your system needs to decide which one to prefer. It ought to prefer the 'stronger' one, but the point being raised is that this is not an issue that has been at issue until now. (Or, at least, not much of an issue until now.) My own response is that implementations of security-related software that do not attend to factors that make the security weaker have deeper problems than the one we are discussing now... I'm not sure about the intended precise > technical interpretation of that clause, but I suspect that some (many?) > verifiers will simply drop it from further consideration. > > In spoofed messages either the content-covering DKIM signature will be > invalid, or it will be missing. The concern is that the weaker signature (that I call a token, given how little of the message it is likely to cover) is more easily re-used for a replay attack. > So the valid signature matching -Delegate is indeed weak > (authenticates little content), but *there is no competing signature*. except for direct recipients (and mailing list recipients for lists that don't break the 'stronger' signature...) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jun 11 23:56:34 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD1C1A04B0 for ; Wed, 11 Jun 2014 23:56:32 -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 JId-7kYZUkVD for ; Wed, 11 Jun 2014 23:56:31 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BDD51A0397 for ; Wed, 11 Jun 2014 23:56:30 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b13so746652wgh.11 for ; Wed, 11 Jun 2014 23:56: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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=W8GEWslQzg1jOXcpJnog05WUGYVVfCtemp5aQdG0gHw=; b=pQcKQEUoVcdfovbBuKvdR9q2AGpBvi6BxmxajAFbBQ5fGo5+lHyzqwXsYTaNn0PJMm ND7NnPm+QGQtQldj+VmakWxRgiZ/OISVgC64VJIiSC2Ou2t457/3mkM92H/9VBe/tigB mcQv1bjEjgQr0IbdGRACiD6zageG0Hr3i94qUoEuvB/qKQke8UKVajOOxc9TXAUiE1sw DoweVrcWC4BZiqj0mcA2nNjREpOsAONZfr++xc2uXJ52S6ISexLcju/bTyiCxU2KVFhY 0rSnLFz8ARulgLo7PNKK47b8lqwdE87G/N3UxNVl4iB1+o4ZyKBR7gJr/yF0/81yrOG1 Jc5g== X-Received: by 10.194.87.200 with SMTP id ba8mr58850468wjb.28.1402556189636; Wed, 11 Jun 2014 23:56:29 -0700 (PDT) Received: from ?IPv6:2a02:a03f:1405:ee00:89d6:585d:8c73:1361? ([2a02:a03f:1405:ee00:89d6:585d:8c73:1361]) by mx.google.com with ESMTPSA id l49sm2880554eef.27.2014.06.11.23.56.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Jun 2014 23:56:29 -0700 (PDT) Message-ID: <53994EE3.6050204@gmail.com> Date: Thu, 12 Jun 2014 08:55:31 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20140611222207.2338.qmail@joyce.lan> <53993D20.7010901@gmail.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/VVSv_ba4WrCGCNy5Nk2rEfgcdXs Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Thu, 12 Jun 2014 06:56:32 -0000 On 6/12/2014 8:40 AM, Murray S. Kucherawy wrote: > On Wed, Jun 11, 2014 at 10:39 PM, Dave Crocker > wrote: > > The irony of your suggestion is that it requires having 'unupgraded' > software reliably use the version number, given that they haven't needed > to do that before either... > > > Section 6.1.1 of DKIM makes it a MUST that unknown versions result in an > error. Are you assuming here that some/many/most implementations will > have ignored that? You might be right; I'm just trying to be clear. > For that matter, can we assume "x=" was properly implemented? It's the kind of issue that needs field verification, because it is the kind of spec detail that developers often treat casually or ignore. If they don't have to pay attention to it, to get things running, they often don't. Not YOU, of course, but lots of other developers... It's one of the reasons that version numbers tend to have little real utility. > It would indeed be ideal to find a way to ensure that the delegation > signature is disregarded by legacy DKIM implementations, and only used > when coupled with a passing Mediator signature. Well, remember that we need this to be useful even when there is no mediator signature, if the receiver can validate the identity of the mediator through other means... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Jun 12 00:25:47 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618E21A05E5 for ; Thu, 12 Jun 2014 00:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 tNVygV2mq5Dc for ; Thu, 12 Jun 2014 00:25:36 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id B28361A0641 for ; Thu, 12 Jun 2014 00:25:35 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id ED4083FA0B17; Thu, 12 Jun 2014 16:25:34 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id DF89B1A32C5; Thu, 12 Jun 2014 16:25:34 +0900 (JST) From: "Stephen J. Turnbull" To: Hector Santos In-Reply-To: <53992AD0.3080006@isdg.net> References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <1755889339.33315.1402383131643.JavaMail.zimbra@peachymango.org> <1019546957.39246.1402408698423.JavaMail.zimbra@peachymango.org> <699367420.39896.1402409599837.JavaMail.zimbra@peachymango.org> <5397156F.8010603@gmail.com> <3E16067A-64CB-4B84-ABBD-82873DB63E88@isdg.net> <53991540.7060506@isdg.net> <53992AD0.3080006@isdg.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 12 Jun 2014 16:25:34 +0900 Message-ID: <87egyupp1t.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/AZFeWP2kO0wJ29GWsEvlvhsb7ug Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Thu, 12 Jun 2014 07:25:38 -0000 Hector Santos writes: > > You would simply not use DKIM-Delegate if that's your policy. > > Again, the fault. Please define "fault". Also "lookup". I doubt I'm the only one who doesn't understand what you mean by these words. > The policy is X, but Y is seen. The payload can be > DKIM-Delegate compliant but the actual policy is exclusive and doesn't > allow it. You're thinking about a case where one or more unprivileged users at the first party have been cracked, and mail that dkim-delegate authenticates is being sent through 3rd parties but shouldn't be? If there's no inside threat I don't see how this can happen (stolen keys are an inside threat, breaking the crypto is outside of scope). > signatures. You are probably right that DKIM-Delegate can't resolve > this, but what we want is for DMARC to have the language to say: > > "I'm ok with any trusted valid signer" Why? "Trusted" by whom? If it's verifier trust, no problem. They know who they trust. If it's Author Domain trust, use dkim-delegate t= and put the intersection of your whitelist and visible and invisible addressees in there (AFAICS this handles Bcc correctly, modulo concerns with revealing Bcc addresses -- but that is something for the originator to determine). Note that AFAICS this is not subject to the "mail-privileges-only user gets cracked" issue, as presumbly the whitelist is maintained by a privileged user. If it's not, this is effectively an "any signature will do" policy. > Overall, the problem is the DMARC verifiers are indeed enforcing the > strong policies. If you have a DKIM-Delegate to address only 3rd > party resigners, then you will need a matching backward compatible DNS > version of this. Not really. The unfortunate semantics of "p=reject" will in practice be worked around by refusing to respect it when respecting it is a socially destructive thing to do (eg, if the Author Domain is Yahoo! or AOL and there's "strong enough" evidence that the message is legitimate). That's a loss of face for DMARC, of course, but no more, since it's already practiced by at least one "billion message" class mailbox provider. I suspect Yahoo! and AOL would be willing to cooperate.[1] I agree that the various issues with *absence* of DKIM-Delegate and verifiers that don't implement DKIM-Delegate need to be considered, and we need to consider the implication of cracking users limited to mail-sending privilege as described above (in which case a policy lookup by DNS would give different information). However, we can, and perhaps should, "handle" this by saying "so don't let your users get cracked if you have a 1st-party-only or no-mail policy." Footnotes: [1] Note that even if a mailbox provider allows the users to populate the whitelist, and an abuser discovers a way to exploit this, the provider can shut them down very quickly by turning off -Delegate headers in their MTA. From nobody Thu Jun 12 00:40:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E741A0259 for ; Thu, 12 Jun 2014 00:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.209 X-Spam-Level: * X-Spam-Status: No, score=1.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_22=0.6] 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 lmt61LCLALDj for ; Thu, 12 Jun 2014 00:40:49 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id B7EEB1A02AF for ; Thu, 12 Jun 2014 00:40:48 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 1E5E13FA0B1E; Thu, 12 Jun 2014 16:40:48 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 12C3E11F0DC; Thu, 12 Jun 2014 16:40:48 +0900 (JST) From: "Stephen J. Turnbull" To: Matt Simerson In-Reply-To: References: <87sing1xpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87a99n1glm.fsf@uwakimon.sk.tsukuba.ac.jp> <5394E621.2050705@isdg.net> <539532C2.9030406@isdg.net> <3905D9E1-7A82-4611-A6DE-F75D2273F650@tnpi.net> <823EE4C6E2B44F58B05FC6EDC09C303A@fgsr.local> <878up5ct4p.fsf@uwakimon.sk.tsukuba.ac.jp> <87ppihgugl.fsf@uwakimon.sk.tsukuba.ac.jp> <5396E49C.2000808@isdg.net> <8738fcrhqz.fsf@uwakimon.sk.tsukuba.ac.jp> <53974C62.9050408@isdg.net> <87tx7splbb.fsf@uwakimon.sk.tsukuba.ac.jp> <998FA07D-E6D7-41FB-A143-CE7B426E6763@tnpi.net> <87ppigowmh.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 12 Jun 2014 16:40:47 +0900 Message-ID: <87d2eepocg.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/SZGzJZpI1LrGWhHzh4iWSJiillk Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 12 Jun 2014 07:40:50 -0000 Matt Simerson writes: > That just seems to reinforce the point that the message alterations > are far more popular with list *operators* than they are with list > *users.* *shrug* List operators are my constituency. If you, as a list (site) operator, choose to do things differently, more power to you. But my mission is providing the options that "enough" of my constituents desire, and I will advocate protocols that enable those options. > I can't help but think that all this energy would be better spent > focusing on solutions that provides a consistent method for email > lists to present their decoration and admin URIs without breaking > DKIM. Me too. But Dave Crocker et al have squashed (by the weight of their arguments) discussion of that on this list because *presentation is UI*, and we don't do UI because we don't/can't do it well, and if we leave it up to the MUAs they won't do it either, because users aren't capable of using the information effectively even if it's presented to them. I'm not giving up (I'm not so pessimistic about the utility to at least a significant subset of users), but for the purpose of this list my options are restricted to third party authorization protocols and "subversion" (as Hector and Doug would say) when those aren't available and Author Domain publishes "p=reject". The rest is tl;dr for mainstream DMARC advocates. :-) > Something that: Nothing new here, people, move along! Specifically. > a) Identifies messages as list traffic (aka: List-ID) List-ID, indeed. List-Post might also be used. > b) Incorporates list info into headers (see below) We already have something pretty much equivalent, but much more general: the DKIM z= tag. Murray's concerns about "secondary validation" are inapplicable, as this would be advisory to the MUA's presentation algorithms, not part of a security mechanism for authorizing the message. > c) Requests MUA authors to identify list messages in a safe > and useful fashion** Again, this is not general. It is already done as far as "useful" goes (even moderately-skilled users can sort list mail into a separate folder or tag it), not obviously possible if "safe" means "identifying legitimate posts" (RFCs 2369 and 2919 can be easily perverted to use by the Black Hats). As several posters have pointed out, it probably can't be done at all, when you're talking about the kind of greedy and unwary user who falls for "I picked you out of a hat to make you rich" schemes. > I fully realize that c) is a can of worms, but I can't help but > think that MUA authors are equal to the task. If we provided them > with a defined set of Mailing List Actions that were enabled when > the MLM software populated the appropriate headers, we could > eliminate the vast majority of message alterations. Maybe. We could try, but the whole history of the Web shows that upstream wants to control appearance in the browser. I think an analogous desire is present in list operators, though the details are different and the degree of control desired is not so absolute. > > Removal of prohibited content is not so easily addressed, > > In such cases, don't you think it's appropriate for the list to > take ownership of the message, after applying the transformations > necessary to make it conform to site policy? No, I don't. In general, the agent that caused the content to be posted is still the original From:. That's what *she* will think, that's what *readers* will think, and I think it is wrong (and know it is confusing) to present that content as "From:" anybody else. In particular, the most common transformation removes text/html parts from multipart/alternative bodies, and I can see no justification for claiming authorship in that case. If you do, I would recommend presenting your intention accurately by encapsulating the transformed message in a rfc822/message MIME part, prefixed by a part containing text explaining the transformations applied to the message. You would not then "take ownership" of From: in the encapsulated message, would you? From nobody Thu Jun 12 01:13:01 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0724A1A03F8 for ; Thu, 12 Jun 2014 01:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.537 X-Spam-Level: X-Spam-Status: No, score=-0.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_32=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 NLiHw8IAapbE for ; Thu, 12 Jun 2014 01:12:55 -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 512241A02B3 for ; Thu, 12 Jun 2014 01:12:55 -0700 (PDT) Received: (qmail 58241 invoked from network); 12 Jun 2014 08:12:53 -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:cleverness; s=e380.53996105.k1406; bh=st+bWIygXsufD3ooah7vz9VYdY7u6EqXmEUZ/BszH/Q=; b=W6JXSgjJhKN1ATDSywXW21RRCQQo7MQ17wuvf8L9n1i3YWV2i+VKuJuFFeAFBySsr9XyuhWJ3SnNZwsiVh2o2heGn5dnDfXSX0EKtzaAKNy7HRax3rGQkIlmAw+LWlPaPiKdEa3uDtw7Wx7EDPYeAVu5KDI+4x1UsGOXFBNV7tDXvlJ5cWWOG/xqsH+5yMB03IOo9hKKWmICIGQvmHWX6m5EUKJUA0biGmc2g5ysk1uTNOzIdsoT0QRK/aOAIj5z 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:cleverness; s=e380.53996105.k1406; bh=st+bWIygXsufD3ooah7vz9VYdY7u6EqXmEUZ/BszH/Q=; b=Ioeq9s3l7IgZa+h6z6RAL4OybHfsI6QMIgCnI1bsWGbr6ecWXGE1vTQHH4eedMvzhhdKwhMzVQm0zd7TTpOLldxzNgevAQcfyTSyOAoHbvcYwY06ijZVFMoFc7W6F5wr8I/9cFWHyrvWUR7VjYaABbWQwoEph+BUV7qcmM/smU5iQ0Gbl7B9UFGap1YM38a0rSFAFaYqeF0p7Hho4PcKsRmT58xMYhVeejvyDSx5kppgwP5MDDcdmJoL3/tYH5c9 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; 12 Jun 2014 08:12:52 -0000 Date: 12 Jun 2014 10:12:48 +0200 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20140611222207.2338.qmail@joyce.lan> <53993D20.7010901@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-1399822968-1402560771=:3300" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/md_54qaVLtLKXDXQgtOUjWJ0w7M Cc: Dave Crocker , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Thu, 12 Jun 2014 08:12:57 -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. --3825401791-1399822968-1402560771=:3300 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Answering four messages at once: > > Someone sends off a message to a mailing list with the two DKIM > > signatures and DKIM-Delegate. Someone else, perhaps a list > > subscriber, notes that the weaker signature doesn't cover the body, so > > he replaces the body with nose enlargement spam and blasts it out. > > Recipient MTAs which haven't been updated since 2014 and don't know > > about DKIM-Delegate see the weak but valid signature and since the > > signer has a generally good reputation, delivers it. Ugh. > > Right, that's the "considerable latitude" that's already mentioned in the > draft. The "x=" is the current protection against that sort of abuse. > It's not much, but it's what we've thought of so far. The alternative is > to use an "l=" that is the length of the original rather than 0, which > constrains the abuse considerably but might reduce the likelihood of this > working. For this application I don't see x= as much protection. If a bad guy subscribes to the list or gets messages via something like gmane, he can do the mutate and spam in close to real time. > I see your point, though it seems strange to do a version bump when that's > really the only change to the bits on the wire, and the only real change > then is how the signatures are interpreted; syntax vs. semantics. > ... > DKIM-Signature: v=1; d=example.com; ... > DKIM-Signature: v=2; l=0; d=example.com; rsf=to,cc,trusted-lists.example.org; > ... > > "rsf" = "require signature from", with "to" and "cc" being special case > keywords with the obvious meaning. Right. This seems to me a DKIM signature with a different semantics, only pay attention to this one if there's a matching forwarding signature (give or take your inexcusable assumption that nobody at the registries in Tonga or the Cocos islands will ever use this.) Adding new tags to DKIM signatures should be no big deal. The spec has always been very clear that verifiers ignore tags that they don't understand and I know that works, since I've been adding private tags ever since the argument about what, if anything, the i= tag means. Adding a new tag doesn't need a version bump so long as it's OK for verifiers that don't understand the tag to ignore it. This needs a version bump since the intention is that the signature isn't interesting unless it's paired with a forwarder's signature so you have to undersand rsf=. You could get the same effect by defining a new signature header with the same syntax and meaning as DKIM-Signature except that the rsf= tag is mandatory and you ignore it without the second signature: DKIM-Forwarding-Signature: v=1; l=0; d=example.com; rsf=to,cc,trusted-lists.example.org; I don't see any reason to prefer this, but whatever. Re Dave's concern that DKIM verifiers don't look at the version number, that's easy enough to check since there aren't many widely used verifier libraries, and most large MSPs add A-R headers so you can send mail to your test account and see how it liked the signature. R's, John --3825401791-1399822968-1402560771=:3300 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIII7gYJKoZIhvcNAQcCoIII3zCCCNsCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBh8wggYbMIIFA6ADAgECAgMJWEYwDQYJKoZIhvcNAQELBQAw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTAeFw0xNDAzMTgxOTQ3NDdaFw0xNTAzMjAwMDU2MDBaMDoxGDAW BgNVBAMMD2pvaG5sQHRhdWdoLmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxA dGF1Z2guY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnMGH 52DBxB4jb86Sxi3VvgOjirvLveIVP7zvqxBDpJzxrF02wCYwnQuxi3S3U5ge 3iHihzhM9qP+N03frkr4KH6Spgec88YjMioVQStTQZcrogTdHweZOgT8tckg HEmHCF8uHBjD0HbfDk+9zYFtaE3QPk5aGm02Id0fNNM5WmSQSxVwF0Ddryq5 vIU0AHbB/1kok1zJpwWA06SgHenlnYngnSpNWlOn+SxboiD28m2XTWDP5ULL e1b040VtkQMzpuVXzAHWVQYQWUevJ4y8mrUsqAyGuYSb5pTU28D+NExVAYxn WD94rzgBpkXgC4Xxcp3TmyfMaLMF4M9ef0nu+QIDAQABo4IC1TCCAtEwCQYD VR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsG AQUFBwMEMB0GA1UdDgQWBBSpNAr06FueusUfmbDdecnZ1kznsTAfBgNVHSME GDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0 YXVnaC5jb20wggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIB KjAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5 LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlv biBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3Vl ZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJl bWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25s eSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0 aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmg J4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYI KwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRz c2wuY29tL3N1Yi9jbGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRw Oi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5j YS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0G CSqGSIb3DQEBCwUAA4IBAQC3OSsHtuc1se2JPbLqI1b31i0EER3UX6Ep2Zuy FkACIpk/i8mPi0KIfMWWiDlNmqeQEq8308i0/2mVcMVdgKWIUMJdZb3CmNfs 3qtTlrdXXYXT7ZLjL6a1Bbh/lKUm35JYRH8zf3rqDbLkpiA92vc7uTQcbDay 1sQ4CSTvOWuq0CIwMXqJePhHf/runG7ndDuX2yFagHlxhsvn7raw5NQuu4Sj ofwbNiszwkryB7ZYUxq2Pg2i1m2XlgMbNEfw8deAZOyHGKKGz25Ei1KvJofH 1izh0WDU+ueJum6RHm8/o/i53MbYZN4Il64aBD1HPqQow3jHQBhAc8XN85hH csS2MYIClzCCApMCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZp Y2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCVhGMAkGBSsOAwIaBQCggdgw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQw NjEyMDgxMjQ5WjAjBgkqhkiG9w0BCQQxFgQUoQNCoAsGXiRQztTU3c0IOnhm jqYweQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEW MAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN AQEBBQAEggEAGd8YwxMzIPXGUe0FB8KMY5DaFqW9Nlq5+ywnsIw4elbAhCRp QuFTz7T+VFqiBWI0Q+xNzBCvR6Ec6X33FMDZWH78exKQ7j5wB2/VyF8ksfJV cdHKyR9XP9MTAN+X6XYbFowOlXD/4BiQt9ELFEN7QWconrBoqVzbf2ZwgXi6 BvhUh+5qicCqYzEd3jN7IxfaQsgTW/WxOD6PWprzB55zPCCWt40s8zn+Olvn gz80jgZ7Vs8+XCBwOQIMu2+EXK1SN4Q9maisJsW5b18xuyQYBwTbuZ47x6L9 p/c3JFWzt4U0+Xh6MoWbE77W8X9tQ4c0YIad3K6dKHhzOZ1XZYiaXw== --3825401791-1399822968-1402560771=:3300-- From nobody Thu Jun 12 01:30:48 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87D51B2793 for ; Thu, 12 Jun 2014 01:30:44 -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 2Tr_qd_l24tf for ; Thu, 12 Jun 2014 01:30:39 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E21371A854B for ; Thu, 12 Jun 2014 01:30:38 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id k48so163395wev.20 for ; Thu, 12 Jun 2014 01:30:37 -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=l3EboBYGjA6Ovega/i7e/4M3I4w1tsChiLZ8JbIicT8=; b=DpGWgb21OUkxLdEYwhLWcmTQKYVn036hgZhd5DASxNNbw0P5pdEzSVxaPSGWBpP9t3 cGKPgx/Qvu0/pUj49wEdkY8q8ZKiOP5TpRmuNkLPQ/BbPaiVcV4oRxvS/LoWze2y1Dsm a4D1EDJ6fCt+EMyVrbkKol1U37hJrATWKy3XcYnCk4GsrQGW6RwdJgc/fEOz8hJ4Kf3t ndvV/5YEuM8hqGvwNzFHzXvp9f51IUVEIZHjhAHIzG4Zdx5hAU4wCfEL4LaeJnzWSfwz f/XnT62Po6F3nPodc2QyfJUSCUCnDDWn7YzHV5HdK3AULALkcJla41k8JIQkYq8Hj4kq 5Arw== X-Received: by 10.194.204.170 with SMTP id kz10mr59878861wjc.38.1402561837262; Thu, 12 Jun 2014 01:30:37 -0700 (PDT) Received: from ?IPv6:2001:730:40:4:3027:58a3:bb0d:9b44? ([2001:730:40:4:3027:58a3:bb0d:9b44]) by mx.google.com with ESMTPSA id a1sm3389145eep.3.2014.06.12.01.30.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 01:30:36 -0700 (PDT) Message-ID: <539964F1.7030007@gmail.com> Date: Thu, 12 Jun 2014 10:29:37 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John R Levine References: <20140611222207.2338.qmail@joyce.lan> <53993D20.7010901@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/lXPw6u6ZSYndpsSLP-fvBItG5HA Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Thu, 12 Jun 2014 08:30:46 -0000 On 6/12/2014 10:12 AM, John R Levine wrote: > Adding a new tag doesn't need a version bump so long as it's OK for > verifiers that don't understand the tag to ignore it. This needs a > version bump since the intention is that the signature isn't interesting > unless it's paired with a forwarder's signature so you have to undersand > rsf=. Sorry I wasn't clear about my core point: Changes to a protocol should involve changes to the protocol. There is nothing about DKIM-Delegate that changes DKIM. So, changing DKIM to accommodate -Delegate is artificial and merely adds complexity to the engine unnecessarily. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Jun 12 01:32:53 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCCFA1A02B3 for ; Thu, 12 Jun 2014 01:32:50 -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 2LS4Vifyib06 for ; Thu, 12 Jun 2014 01:32: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 5264C1A0199 for ; Thu, 12 Jun 2014 01:32:46 -0700 (PDT) Received: (qmail 61769 invoked from network); 12 Jun 2014 08:32:45 -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:cleverness; s=f147.539965ad.k1406; bh=LV4frDwhw6q1jzPN0AmgHjh4ZrgAroHDTEsgEHZCNCA=; b=YVNWlk4Kq2246m/NrR5cQbiWxz8NInDADYQVwNPXZRk9j39bGmQMVmhSYfmXh7M4t02PvnMckuxzOjctvihIgkGg4l6VFhpt0x7pXESaQcPLAphPlzZ3VvgkT+ZNW2Lc9eNIMsY58YLB3gLewfCY3pVeXlmqL1DxMtwlEq4FfdBHxvqJL1hqOXmHnpPKZJRlrqPZukgnqIp1dvRef5ZBiQO94i7fPc9nmnsS1Y3JCRu18eU7GXoVloOnu3tF5npm 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:cleverness; s=f147.539965ad.k1406; bh=LV4frDwhw6q1jzPN0AmgHjh4ZrgAroHDTEsgEHZCNCA=; b=lBzpVN0O1AO4V/Zc4n4yd3DPWPkXbBwnZYYdXj0dWvxKpbi25vecyi2D8Whk5BsK3n1mkrYUuMc647ms/noZMyw2SuciiMz3lEOQ+nK7irGejP7/cac1GopDxt1DYncVf9w10/MHkjMg1jokwNczHi6XNA77gnLOJm1r7Zbqvj4kVqbA5hMDAouHjK8Xky4ZN93n8wS+5jGdsIkBltAnLYGo8h2uY2KLJPnQ/hFULS1fi+A2CGa8FMDicRrqtb5e 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; 12 Jun 2014 08:32:45 -0000 Date: 12 Jun 2014 10:32:42 +0200 Message-ID: From: "John R Levine" To: "Dave Crocker" In-Reply-To: <539964F1.7030007@gmail.com> References: <20140611222207.2338.qmail@joyce.lan> <53993D20.7010901@gmail.com> <539964F1.7030007@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/vlnv45kyTBeySELNPFZiBTpXV9w Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Thu, 12 Jun 2014 08:32:51 -0000 > There is nothing about DKIM-Delegate that changes DKIM. We disagree. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Thu Jun 12 02:02:55 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB9D1B27B8 for ; Thu, 12 Jun 2014 02:02:54 -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 G7oFsoSnQh4D for ; Thu, 12 Jun 2014 02:02:53 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E89A41B279F for ; Thu, 12 Jun 2014 02:02:52 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id cc10so5222203wib.12 for ; Thu, 12 Jun 2014 02:02:51 -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=h3Wm2YVUEBfhMe+8Iuzc/4b+hOm6UI91FCSMAHOQKes=; b=tVDb2laayiOFogBIkxtDBvbIQXPS8iNyKSN9+rg+DhV7y464uOEIGxzmTFjSXAsmY5 ObDFhz28w7skBX7u7ahYCAXVQsuD9la/1EIUlrDp1xrRr05KauRV0+2tzD34trd8Cgge 2obvDnpqZZWsQZ0ybCvjcOr2oPG0F/pnAhGt+lVvcrdgONneWU2SqOFwAwegJ6mr2fPH zlAkLD2CtzDGe4yRwiLP1p46ac6sLlKTAKRnbMeYWm0aK/Bi23Zktj07MYOLdRS2pFCB +Q6Rb1v4NOTDC2le0VsT+7NwKXFGAVm55qJ1M7DBmh2IBNRyd6KU9CREmlic2HPCpHQx IbEw== X-Received: by 10.180.90.233 with SMTP id bz9mr4510992wib.42.1402563771425; Thu, 12 Jun 2014 02:02:51 -0700 (PDT) Received: from ?IPv6:2001:730:40:4:3027:58a3:bb0d:9b44? ([2001:730:40:4:3027:58a3:bb0d:9b44]) by mx.google.com with ESMTPSA id ci54sm3531066eeb.19.2014.06.12.02.02.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 02:02:50 -0700 (PDT) Message-ID: <53996C80.1090303@gmail.com> Date: Thu, 12 Jun 2014 11:01:52 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John R Levine References: <20140611222207.2338.qmail@joyce.lan> <53993D20.7010901@gmail.com> <539964F1.7030007@gmail.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/siDfHmDXC_3_DgFbQQRIy8Fl3_c Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Thu, 12 Jun 2014 09:02:54 -0000 On 6/12/2014 10:32 AM, John R Levine wrote: > We disagree. Yup. But I don't mind your being wrong... And humor aside, please state the technical changes to the existing DKIM specification that are being made with DKIM-Delegate. Keep in mind the fact that TCP uses IP, and does not change it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Jun 12 02:58:27 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E84B1B27FD for ; Thu, 12 Jun 2014 02:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 BHN8Pl-UkEgk for ; Thu, 12 Jun 2014 02:58:23 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2FD1B281F for ; Thu, 12 Jun 2014 02:58:23 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 86E153FA0B1D; Thu, 12 Jun 2014 18:58:22 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 797EE1A32C5; Thu, 12 Jun 2014 18:58:22 +0900 (JST) From: "Stephen J. Turnbull" To: Dave Crocker In-Reply-To: <53994E40.1040609@gmail.com> References: <20140611141529.4633.qmail@joyce.lan> <53986B38.2010401@gmail.com> <53986F24.8020404@gmail.com> <87fvjapr99.fsf@uwakimon.sk.tsukuba.ac.jp> <53994E40.1040609@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 12 Jun 2014 18:58:22 +0900 Message-ID: <877g4mphz5.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/nU_fIETqHVaOSAjV5g5tRQ8kpIk Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Thu, 12 Jun 2014 09:58:25 -0000 Dave Crocker writes: > The scenario being discussed is for a recipient who gets both signatures > when they are valid, but who does not know about DKIM-Delegate. I didn't understand that from previous posts. At least Hector seems to be concerned (though not exclusively so) with the case I presented. I suspect John as well. And I think that case is important. > So your system needs to decide which one to prefer. > It ought to prefer the 'stronger' one, but the point being raised > is that this is not an issue that has been at issue until now. > (Or, at least, not much of an issue until now.) If they're both valid, isn't this "no blood, no foul"? Is there a concern is that having seen a token signature, it will ignore the valid signature, and treat the message as high-risk? I think that that is a quality-of-implementation-issue that the DKIM-Delegate document itself need not worry about, except maybe a mention in the discussion section. > The concern is that the weaker signature (that I call a token, given how > little of the message it is likely to cover) is more easily re-used for > a replay attack. I don't understand what attack you have in mind, if that attack involves two valid signatures from the Author Domain, the content- covering signature has a "good" selection of headers, and doesn't use the l= tag. (The latter two conditions are consonant with current common practice, I believe, but I mention them for completeness in describing the scenario I think is relevant.) If the attack doesn't have two valid signatures from the Author Domain, then aren't we in the scenario I describedin my previous post? Steve From nobody Thu Jun 12 03:05:46 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D182F1B2831 for ; Thu, 12 Jun 2014 03:05:40 -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 AKdGu0kWxIkg for ; Thu, 12 Jun 2014 03:05:34 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44A091B2830 for ; Thu, 12 Jun 2014 03:05:34 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id l18so985873wgh.4 for ; Thu, 12 Jun 2014 03:05:32 -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=3oe/3IDxtDK7Svo1O9isKIamXslELk1RApS63OZO9Ts=; b=xuUiVm+/u0txnKzdvodCslKxI5EDoSTYMghfJlIhkP5aMmVgiTRlyeMXnszrsvdBBS A/Zinb0BrQMzpMTf7WtnUVVXGLZRoaDIUXwRnObEct3uSNuzvf1nARlbXnMuVnGvt9ZL HJMFkw1zaEaRv9UVotKo0F7SuSC1kCcUqp6f+kIkfwmDmSFk+7GMGEh7RBD3jZe3uCdi unh61zbnh0q9U/UWZpqSc5BwX/DOwRbUcMOpzRtjZInOmqh16sMCowKgwPBmuwM1x+jv Kyn22GwM6YpkvOn0iNBqtKrR9rEU2OxdtfepZV5JBdScDOpgDI9Jz/FYdDIdHCPQFSd+ MimQ== X-Received: by 10.180.99.166 with SMTP id er6mr5037358wib.48.1402567532758; Thu, 12 Jun 2014 03:05:32 -0700 (PDT) Received: from ?IPv6:2001:730:40:4:3027:58a3:bb0d:9b44? ([2001:730:40:4:3027:58a3:bb0d:9b44]) by mx.google.com with ESMTPSA id z44sm3817817eep.39.2014.06.12.03.05.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 03:05:32 -0700 (PDT) Message-ID: <53997B32.8070805@gmail.com> Date: Thu, 12 Jun 2014 12:04:34 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Stephen J. Turnbull" References: <20140611141529.4633.qmail@joyce.lan> <53986B38.2010401@gmail.com> <53986F24.8020404@gmail.com> <87fvjapr99.fsf@uwakimon.sk.tsukuba.ac.jp> <53994E40.1040609@gmail.com> <877g4mphz5.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <877g4mphz5.fsf@uwakimon.sk.tsukuba.ac.jp> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/6SXSnTjOTv8K1TZSo82fmSfW85c Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Thu, 12 Jun 2014 10:05:41 -0000 On 6/12/2014 11:58 AM, Stephen J. Turnbull wrote: > Dave Crocker writes: > > > The scenario being discussed is for a recipient who gets both signatures > > when they are valid, but who does not know about DKIM-Delegate. > > I didn't understand that from previous posts. At least Hector seems > to be concerned (though not exclusively so) with the case I presented. > I suspect John as well. And I think that case is important. Now it's my turn to not understand. Really, what scenario is involved here? > > So your system needs to decide which one to prefer. > > > It ought to prefer the 'stronger' one, but the point being raised > > is that this is not an issue that has been at issue until now. > > (Or, at least, not much of an issue until now.) > > If they're both valid, isn't this "no blood, no foul"? The concern is a a write-down attack, where the weaker signature is effectively an exploit. > Is there a concern is that having seen a token signature, it will > ignore the valid signature, and treat the message as high-risk? I > think that that is a quality-of-implementation-issue that the > DKIM-Delegate document itself need not worry about, except maybe a > mention in the discussion section. Sounds like a generic issue with receiver use of DKIM. A worthy question, but not inherent to -Delegate. > > The concern is that the weaker signature (that I call a token, given how > > little of the message it is likely to cover) is more easily re-used for > > a replay attack. > > I don't understand what attack you have in mind, if that attack > involves two valid signatures from the Author Domain, the content- > covering signature has a "good" selection of headers, and doesn't use > the l= tag. (The latter two conditions are consonant with current > common practice, I believe, but I mention them for completeness in > describing the scenario I think is relevant.) The premise is that the weaker nature of the token signature (needed to get it to survive through the mailing list) will make it more subject to some form of replay attack that includes bad content. I've no idea how serious the threat is, but it's certainly a mathematically legitimate concern. > If the attack doesn't have two valid signatures from the Author > Domain, then aren't we in the scenario I describedin my previous > post? Probably. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Thu Jun 12 03:10:40 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA471B28A9 for ; Thu, 12 Jun 2014 03:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 UUrGpXs2iYqr for ; Thu, 12 Jun 2014 03:10:38 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id B60781B2830 for ; Thu, 12 Jun 2014 03:10:38 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 1BB9D3FA0B1E; Thu, 12 Jun 2014 19:10:38 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 101801A32C5; Thu, 12 Jun 2014 19:10:38 +0900 (JST) From: "Stephen J. Turnbull" To: "John R Levine" In-Reply-To: References: <20140611222207.2338.qmail@joyce.lan> <53993D20.7010901@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 12 Jun 2014 19:10:37 +0900 Message-ID: <8761k6pheq.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/-T-JacIjlwsvq39_bo3GyalcALg Cc: Dave Crocker , "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Thu, 12 Jun 2014 10:10:39 -0000 John R Levine writes: > For this application I don't see x= as much protection. If a bad guy > subscribes to the list or gets messages via something like gmane, he > can do the mutate and spam in close to real time. Is this a practical concern, though? The levels of spam etc that drove Yahoo! and AOL to "p=reject" were *huge*, and have persisted (according to Elizabeth Zwicky of Yahoo!) for several weeks after imposition of "p=reject". The "retail" spams you describe are still going to have to run the obstacle course of content filtering, I would suppose, and x= means they have to use substantial resources to continually harvest new signatures. Do-able, of course, but how much of a threat? From nobody Thu Jun 12 04:30:05 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91AE91B2849 for ; Thu, 12 Jun 2014 04:30:03 -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 fnBRSqmILLAB for ; Thu, 12 Jun 2014 04:30: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 652D21B2848 for ; Thu, 12 Jun 2014 04:30:02 -0700 (PDT) Received: (qmail 85588 invoked from network); 12 Jun 2014 11:30:00 -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:cleverness; s=14e53.53998f38.k1406; bh=whWciIPnl7qm45yOETgLeO4xr3IxzV5CVUaLKKrolxY=; b=sx4BqquOGsPqwZIiu9tetK6Etu7OKJgFsDu7ZTGNE6ECtmIkM8d3dEHgxQUmm/x5rfvenERZBpYsQ1znJjDOa+Lz/agY++riLMZre9CyNGS2YqeIlW1DGR8U8SRIW2UtmyWrsvvigCvI+zjz/ThG+rs76Ml47yzhVEwnpj7cKlm1yeqliOVg0zQpGwTtAclEnpiSdX7ghdU0iWV+9RlBEPjq0P5bWxKAj3uAOGdHj9G0LdH5K54OA9DX6TEamE/Z 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:cleverness; s=14e53.53998f38.k1406; bh=whWciIPnl7qm45yOETgLeO4xr3IxzV5CVUaLKKrolxY=; b=KvYaM/Nc2ELo6lDGzELYSJkIZgXJSYz3yGIFba8t3muEpLC5GEcklpWKGqOiHEvJ7ORnnIs4jwO+3UcrkRFnVxNxF2Ls+Iw8kyY5lWvSvcX2BQtmEjWF60+Tz80IAP3wZH5Vvwo6WOinpdNLjuMsO2Kr7SRYUTjkvVa1xcDgDLytiP9G7Rbug0OOeAkRcTXAHIL7m0d9v92nkK3B448/F9wiZ9ZXVPe0SjcxnyzhKCCbbezs643IubkTN54IRuqw 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; 12 Jun 2014 11:29:59 -0000 Date: 12 Jun 2014 13:29:58 +0200 Message-ID: From: "John R Levine" To: "Dave Crocker" In-Reply-To: <53996C80.1090303@gmail.com> References: <20140611222207.2338.qmail@joyce.lan> <53993D20.7010901@gmail.com> <539964F1.7030007@gmail.com> <53996C80.1090303@gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/oeYVVp7F7lAhAlCj4ZYLrJgr-Og Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Thu, 12 Jun 2014 11:30:03 -0000 > And humor aside, please state the technical changes to the existing DKIM > specification that are being made with DKIM-Delegate. If a signature has an rsf= tag, verifiers ignore it unless there's a matching signature from a domain the rsf= points to. This is not backward compatible, since verifiers that don't understand rsf= will often get the wrong answer, so it needs a version bump. R's, John From nobody Thu Jun 12 04:30:38 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B901B2858 for ; Thu, 12 Jun 2014 04:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.921 X-Spam-Level: X-Spam-Status: No, score=-16.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] 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 po37clSLRYKe for ; Thu, 12 Jun 2014 04:30:34 -0700 (PDT) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B7901B2848 for ; Thu, 12 Jun 2014 04:30:34 -0700 (PDT) Received: from GQ1-EX10-CAHT14.y.corp.yahoo.com (gq1-ex10-caht14.corp.gq1.yahoo.com [10.73.119.195]) by mrout3.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id s5CBTtr7071265 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Jun 2014 04:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1402572597; bh=+E9E5nVi3DPtmbCtgDD+SViHb2eqqi5W09sFofEIAFw=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=JLyI9JBrmVAV+u6/7uN5Xtyvl1isxbb5sgpZm8GVioizsvxfXZcgh/3VZr9mtch6J 6JcYp6x9866OO1vCEcAjyF3ZJf9LUOs2aOJ02JytNBTJUgpU8acUSIUtVwaNqCo0M5 CaDTECSt9vsWPmSsSNlcIq8hp/GtRCtypWFxqvo0= Received: from GQ1-MB01-02.y.corp.yahoo.com ([fe80::a049:b5af:9055:ada6]) by GQ1-EX10-CAHT14.y.corp.yahoo.com ([fe80::798d:a9eb:e873:311b%12]) with mapi id 14.03.0181.006; Thu, 12 Jun 2014 04:29:55 -0700 From: Elizabeth Zwicky To: "Stephen J. Turnbull" , John R Levine Thread-Topic: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt Thread-Index: AQHPhLY++mTI+c+YV0i1NvX2PrPbLZtq2dmAgAAB1YCAAY9wgIAAceGAgAAWFYCAAHpFAIAAEQqAgAAZugCAACDrgP//oMkA Date: Thu, 12 Jun 2014 11:29:55 +0000 Message-ID: References: <20140611222207.2338.qmail@joyce.lan> <53993D20.7010901@gmail.com> <8761k6pheq.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <8761k6pheq.fsf@uwakimon.sk.tsukuba.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.72.117.39] Content-Type: text/plain; charset="us-ascii" Content-ID: <7242957F9A22FB4BBE66C87F60D96AA9@yforest.corp.yahoo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 572596001 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/72DafI-tEnVhLRtnhJMlCzTMTo4 Cc: Dave Crocker , "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Thu, 12 Jun 2014 11:30:35 -0000 On 6/12/14, 3:10 AM, "Stephen J. Turnbull" wrote: >John R Levine writes: > > > For this application I don't see x=3D as much protection. If a bad guy > > subscribes to the list or gets messages via something like gmane, he > > can do the mutate and spam in close to real time. > >Is this a practical concern, though? The levels of spam etc that >drove Yahoo! and AOL to "p=3Dreject" were *huge*, and have persisted >(according to Elizabeth Zwicky of Yahoo!) for several weeks after >imposition of "p=3Dreject". The "retail" spams you describe are still >going to have to run the obstacle course of content filtering, I would >suppose, and x=3D means they have to use substantial resources to >continually harvest new signatures. Do-able, of course, but how much >of a threat? I did not say that the levels were the same; I said the attackers have not gone away. They are not at high volume, but they're sure sitting there checking to see whether or not it's working. x=3D is a weak protection here; spammers can and do move millions of messages a minute to us. Then again we are well placed to implement special handling here, as are most if not all sites receiving mail at this kind of scale. So the problem is at small and intermediate sites. Elizabeth > >_______________________________________________ >dmarc mailing list >dmarc@ietf.org >https://www.ietf.org/mailman/listinfo/dmarc From nobody Thu Jun 12 04:51:22 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62601B2856 for ; Thu, 12 Jun 2014 04:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 zrddJjRCFCTo for ; Thu, 12 Jun 2014 04:51:15 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39A881B2854 for ; Thu, 12 Jun 2014 04:51:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1402573872; bh=1vH9q/ynmJf9gH3KR7i/O1X66KWE99zx+ftWR8jJVog=; l=7832; h=Date:From:To:CC:References:In-Reply-To; b=dlOeEvtxDSt6N3JgYFEEGAWEPVAjNhxJH9euydjJhHe9IExCZM+SGn+Ggq2qtfbRN HiO5H69s+h1zxuK7YWye65daW9idE9k0h5h1Ws97yoVAr7tfw/X9ySq6rd9FZhA1C1 VAN+SPVAjH5wRIpTeS3Kxl1bqcpoAx0TWIqGk64g= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [192.168.1.47] ([176.65.80.110]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by wmail.tana.it with ESMTPSA; Thu, 12 Jun 2014 13:51:12 +0200 id 00000000005DC03F.0000000053999430.00006DD6 Message-ID: <53999429.3030509@tana.it> Date: Thu, 12 Jun 2014 13:51:05 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <5392ECED.5010404@gmail.com> <539720F2.2060801@tana.it> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/JcxOBnzh8Z_TVtazPGOfZLQkSCE Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Thu, 12 Jun 2014 11:51:17 -0000 Hi Murray, On Tue 10/Jun/2014 19:56:30 +0200 Murray S. Kucherawy wrote: > On Tue, Jun 10, 2014 at 8:14 AM, Alessandro Vesely wrote: > >> First, weak signatures which are not part of a chain should be ignored >> by verifiers. An authentication chain can be defined as a set of >> valid DKIM signatures and possibly an SPF authentication of delegated >> domains ("D" set), ordered such that: >> >> * the first one is an author domain signature, >> * each signature covers more header fields than the preceding one, >> * the last authentication is a full (i.e. not weak) DKIM signature, or >> an SPF "pass" authentication. > > The first one might fail. In fact, for the use case of interest, we might > as well assume it always does. Well, a chain is valid only if all of its signatures are valid. > Why the second requirement? The chain gets extracted from the available signatures. They need to be ordered. In an A->B->C->D scenario, where B and C are mediators, the receiver D has to extract A, B, C, in that order. The set of signatures is not totally ordered, just partially. That formulation of the second rule is handy to code a comparison function for sorting. > We already have the third requirement, minus the SPF tie-in. I'm not sure > I see the benefit of the latter, since DKIM and SPF evaluate different > things in the first place. The doc says "if the receiver can otherwise determine that the message was handled through a delegated domain". I just clarified it, adding that only the last authentication in a chain can be handled that way. >> That way, by adding DKIM-Delegate: and/or Resent-To: as needed, it is >> possible to have a mailing list send to another one. > > Isn't that already possible? No, the doc doesn't mention multiple instances of DKIM-Delegate:. BTW, you should probably specify it has to be treated as a trace field. >> The sentence starting this point is stronger than the wording in the >> document. The latter talks about satisfying "this profile", which may >> sound like allowing those verifiers who used to validate weak >> signatures to continue their practices so long as other profiles are >> concerned. Instead, since we encourage signers to produce weak >> signatures, we ought to tell verifiers to ignore them unless they are >> part of a chain. > > The "profile" language comes from an earlier version of the draft. I'll > clean it up in the next version. > > I agree, there should be language warning about the delegation signature on > its own. However, we also have to realize that if that happens and a > receiver doesn't even know about this proposal, such text isn't going to > help any either. You're right. It is both an advantage and a disadvantage. At first, such DMARC receivers will "magically" accept mailing list traffic by verifying only the first (weak) signature in a chain. Then they'll learn --the hard way, if they're out of luck-- how verifications should be carried out. >> Second, Section 3 and its subsections overstate the meaning of adding >> a DKIM-Delegate: field. AIUI, it serves when the To:/Cc: fields >> contain more domains than those which are meant to be delegated. > > That's not correct. DKIM-Delegate serves when there's a desire to delegate > to one or more of the domains listed in To:/Cc:, and not beyond that. The > "t=" tag is provided in case there's a need to further expand that list, > such as when there's a Mediator in the envelope recipients but not in the > recipient fields. (That, actually, needs to be called out in Security > Considerations; the "t=" tag reveals envelope information that might not be > intended to go anywhere.) The spec allows using t= to both contract or expand the delegation list (as well as to leave it as is, redundantly). Author's domains who don't expand that list are more respectful of that principle of header field visibility which inspired DMARC. In the multi-intermediary scenario above, A->B->C->D, B knows that C is an intermediary and trusts it. Most likely, B must extend the original delegation list. It can do so by adding a Resend-To:, a DKIM-Delegate:, or both; neither is visible. >> Bullet 2 of Section 3.2 could characterize that better. Bullets 3 and >> 7 should not assume the field is always there. I suggest to define >> weak signatures and then characterize the method independently of the >> presence of any DKIM-Delegate: field. > > Doesn't RFC6376 already talk at some length about what should be > considered when deciding what content should get hashed? I'm also > worried about using languages like "weak" and "strong" as it relates > to signatures, because those are pretty subjective terms. How about "partial" and "full"? The problem with "primary" and "secondary" is that they are not so obvious. >> Third, weakly signing should be limited to messages destined to known >> mediators of trusted domains. This point is just implied in the >> document. A discussion about the correspondence between envelope >> recipients and signed destination addresses may be appropriate too. > > By "weak" I think you're referring to the delegation signature. Yes, > that's a good suggestion, though it still imposes a requirement on the > originator to know what domains contain trusted Mediators, which is > something that has been a stalling point for things like ATPS. The Yahoo!s > of the world would have to create some process by which they either > determine what those domains are by observing their own traffic, or have a > registration process for them. Alternatively, mediators can be the first movers, flanked by their users. I proposed an online demonstration. > What correspondence are you referring to? DKIM has always been completely > independent of the envelope, and it should remain so. Formally, yes. In practice, users trust the header addresses. If a message is authenticated, that trust ought to be warranted, up to acceptable changes, or the authenticated entity must be willing to give explanations in case questions arise. Isn't that what authentication is all about? >> Fourth, a full author domain signature seems to be useless if the only >> recipient is a ML. > > Why? If it's gonna get broken, it can only be useful for the MLM itself. Now that you put the question, I realize that it is a clever idea for a MLM to use it, but I think none do. MLMs who want the full author domain signature could ask for it in their how-to-sign record (oh, well...) >> As a fifth and last point, I'd mention quotation marks (RFC 2045 token >> vs quoted-string) among the uses of z= in Section 5.1. >> >> Using z= is easier and probably more effective than trying to specify >> a list of admissible, innocuous message alterations, but looks ugly. >> Anyway, it may help having MLMs publish a how-to-sign DNS record. The >> record says what subject-tag the MLM adds, for which fields it wants >> z=, in which cases it applies which encoding transformation, and the >> like. By itself, the existence of such record will confirm that a >> given recipient expects weak signatures. Just mumbling. > > We're specifically hoping to avoid adding still more lookups here. This one would occur on sending, only when the recipient is one of those trusted intermediaries. And can also be used to gauge how this proposal is doing... > I'm also not much of a fan of the proposed "z=" hacks, for the same > reasons that we abandoned that idea during the DKIM working group > years. "z=" should be used to identify what got modified, but not to > report a different result. Agreed. If it serves just the few cases mentioned above, case-specific workarounds are much better. Ale From nobody Thu Jun 12 05:07:11 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1BFE1B2824 for ; Thu, 12 Jun 2014 05:07:06 -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 wpAYFWvf_g93 for ; Thu, 12 Jun 2014 05:07:04 -0700 (PDT) Received: from smtp-4.01.com (adminr.01.com [162.209.88.187]) by ietfa.amsl.com (Postfix) with ESMTP id C0C3C1B285B for ; Thu, 12 Jun 2014 05:07:04 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [192.254.77.197]) by smtp-4.01.com (Postfix) with ESMTP id EACED4C841; Thu, 12 Jun 2014 07:07:01 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id B091860235; Thu, 12 Jun 2014 07:07:01 -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 Jopdb0Dl7bzM; Thu, 12 Jun 2014 07:07:01 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 897D0601BA; Thu, 12 Jun 2014 07:07:01 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 7213F60235; Thu, 12 Jun 2014 07:07:01 -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 mJlIB3CvcZXR; Thu, 12 Jun 2014 07:07:01 -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 2EDEC601BA; Thu, 12 Jun 2014 07:07:01 -0500 (CDT) Date: Thu, 12 Jun 2014 07:06:45 -0500 (CDT) From: Franck Martin To: Matt Simerson Message-ID: <1614404651.90556.1402574805512.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <8738fcrhqz.fsf@uwakimon.sk.tsukuba.ac.jp> <53974C62.9050408@isdg.net> <87tx7splbb.fsf@uwakimon.sk.tsukuba.ac.jp> <998FA07D-E6D7-41FB-A143-CE7B426E6763@tnpi.net> <87ppigowmh.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF29 (Mac)/8.0.5_GA_5839) Thread-Topic: Change the mailing list protocol, not DMARC. Thread-Index: dxQKsqqaFVwUtmOwBK4AknBZ+ZWlgg== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/wZFjQvJzimNiXHBHQ_PRlPeveiI Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 12 Jun 2014 12:07:07 -0000 ----- Original Message ----- > From: "Matt Simerson" > To: dmarc@ietf.org > Sent: Wednesday, June 11, 2014 11:13:55 PM > Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. > > > On Jun 10, 2014, at 10:15 PM, Stephen J. Turnbull wrote: > > > Matt Simerson writes: > > > >> If message headers and footers are so popular, how do you explain > >> the continued "please unsubscribe me posts" sent to practically > >> every mailing list? > > > > Bell curve. Some people are 2-sigma self-centered, and others are > > 2-sigma clueless. What else is new?[1] > > > > Note that the kind of people who answer FAQs do like having the footer > > so they can say "just click on the link in the footer of any message, > > including this one." > > That just seems to reinforce the point that the message alterations are far > more popular with list *operators* than they are with list *users.* > > I can't help but think that all this energy would be better spent focusing on > solutions that provides a consistent method for email lists to present their > decoration and admin URIs without breaking DKIM. Something that: > > a) Identifies messages as list traffic (aka: List-ID) > b) Incorporates list info into headers (see below) > c) Requests MUA authors to identify list messages in a safe and useful > fashion** I found that to build the override list for mailing list, I could log DMARC rejected emails that contained a List-Id or List-Post header. Once reviewing the logs (once a week, or once a month), you can make an easy decision if you want to add the found IPs into your override list. you can see the code at: https://github.com/linkedin/dmarc-msys/blob/master/dmarc.lua#L820 From nobody Thu Jun 12 09:52:36 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D211B27BA for ; Thu, 12 Jun 2014 09:52:27 -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 m7J1RoLSEwHY for ; Thu, 12 Jun 2014 09:52:24 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.94]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A830E1B27B6 for ; Thu, 12 Jun 2014 09:52:24 -0700 (PDT) Received: from BY2SR01MB608.namsdf01.sdf.exchangelabs.com (10.255.93.167) by BY2SR01MB608.namsdf01.sdf.exchangelabs.com (10.255.93.167) with Microsoft SMTP Server (TLS) id 15.0.974.2; Thu, 12 Jun 2014 16:36:56 +0000 Received: from BY2SR01MB608.namsdf01.sdf.exchangelabs.com ([169.254.5.56]) by BY2SR01MB608.namsdf01.sdf.exchangelabs.com ([169.254.5.56]) with mapi id 15.00.0974.002; Thu, 12 Jun 2014 16:36:56 +0000 From: Terry Zink To: Franck Martin , Matt Simerson Thread-Topic: Change the mailing list protocol, not DMARC. Thread-Index: AQHPhjbbooZUptifmEiZaUdkmtXPmpttq9HA Date: Thu, 12 Jun 2014 16:36:55 +0000 Message-ID: <1a3d6beda2014edf92f936963cd1635e@BY2SR01MB608.namsdf01.sdf.exchangelabs.com> References: <8738fcrhqz.fsf@uwakimon.sk.tsukuba.ac.jp> <53974C62.9050408@isdg.net> <87tx7splbb.fsf@uwakimon.sk.tsukuba.ac.jp> <998FA07D-E6D7-41FB-A143-CE7B426E6763@tnpi.net> <87ppigowmh.fsf@uwakimon.sk.tsukuba.ac.jp> <1614404651.90556.1402574805512.JavaMail.zimbra@peachymango.org> In-Reply-To: <1614404651.90556.1402574805512.JavaMail.zimbra@peachymango.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.192.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(189002)(199002)(24454002)(51704005)(74706001)(74502001)(97336001)(97186001)(76796001)(47976003)(56816006)(76786001)(47736002)(95666003)(85852003)(53806002)(77982001)(47446003)(49866002)(51856002)(54316003)(56776002)(81686001)(54356002)(33646001)(93886003)(83072002)(80022001)(93136001)(76482001)(92566001)(63696004)(99396002)(93516002)(85306002)(69226001)(98676001)(66066001)(83322001)(65816002)(59766002)(81816001)(81342001)(94316002)(50986002)(90146001)(79102001)(46102001)(87936001)(74366001)(74876001)(77096001)(2656002)(87266001)(74662001)(101416001)(81542001)(64706001)(4396001)(20776003)(31966008)(94946001)(95416001)(21056001)(24736002)(223123001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2SR01MB608; H:BY2SR01MB608.namsdf01.sdf.exchangelabs.com; FPR:; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/7GNsOic73uYkLlIm4d_O1JPVm_Q Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 12 Jun 2014 16:52:27 -0000 > Franck Martin wrote: >=20 > I found that to build the override list for mailing list, I could log DMA= RC rejected=20 > emails that contained a List-Id or List-Post header. Once reviewing the l= ogs=20 > (once a week, or once a month), you can make an easy decision if you want= to=20 > add the found IPs into your override list. That was my thinking, too.=20 I like the idea of DKIM-Delegate but if I had to choose between doing Franc= k's whitelist [1] suggestion above, or DKIM-Delegate, I'd probably do the w= hitelist because it's less code to implement and maintain; as someone who f= ights spam we're already in the business of checking logs looking for patte= rns and doing overrides and so this would simply be one more pattern to loo= k for. -- Terry [1] whitelist =3D override the DMARC p=3Dreject/quarantine action, not skip= all filtering From nobody Thu Jun 12 10:09:45 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA3C1A0601 for ; Thu, 12 Jun 2014 10:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.48 X-Spam-Level: X-Spam-Status: No, score=-100.48 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_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 RA2WW3H6yQCh for ; Thu, 12 Jun 2014 10:09:40 -0700 (PDT) Received: from catinthebox.net (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5C01A018A for ; Thu, 12 Jun 2014 10:09:40 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4949; t=1402592973; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=pVUFCs9aLTMSfS+AdM0/z7i1bRc=; b=thfwnAjSdvL1kEetSrz6 shf1ll82o/5QdZIPQ9dbjVuKgGMFQkpEFtN32kIhogdJtvsq8dXe6oEO8nqcEjkK fZaEv+IADgXWHV9cFwxLnTxlu+fct1KqgBIK0XaheUwIhKk3IGu5e/zAQijtQpH9 UvpSXIftLjpV+ZgKrnp4ExI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 12 Jun 2014 13:09:33 -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; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2073093682.20968.2500; Thu, 12 Jun 2014 13:09:32 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4949; t=1402592802; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=OFXkNIv YWuKBQgDLF2BwZ1dtUAybwyoPtDZykrd/X1I=; b=uiPhbadkLtfCNhJU9hRocwT tZj+mq6vKaH8tAMlwEybOUy6Be8vG/QiC+h2uEKwjizGKzdx447WtLNqBARvFcl0 uG9FDg1CH8WTLT2AnFm/la8up+9eItiSplZxxJdRe6Zm2+5pUwHSU5QSugoEKwsl xyAry+GVotleuWoRcJbY= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 12 Jun 2014 13:06: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 2089449625.9.4064; Thu, 12 Jun 2014 13:06:41 -0400 Message-ID: <5399DECD.7090004@isdg.net> Date: Thu, 12 Jun 2014 13:09: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 CC: "dmarc@ietf.org" References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <1019546957.39246.1402408698423.JavaMail.zimbra@peachymango.org> <699367420.39896.1402409599837.JavaMail.zimbra@peachymango.org> <5397156F.8010603@gmail.com> <3E16067A-64CB-4B84-ABBD-82873DB63E88@isdg.net> <53991540.7060506@isdg.net> <53992AD0.3080006@isdg.net> <87egyupp1t.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87egyupp1t.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: dmarc@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/8PmkaSNo9U_8kAb3aOc38B0hubk Subject: [dmarc-ietf] Checking Signing Practices (CSP) 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, 12 Jun 2014 17:09:43 -0000 > Please define "fault". Also "lookup". I doubt I'm the only one who > doesn't understand what you mean by these words. A lookup is a callout, a shim, a hook, a "blackbox" query, a "function generator" and so on. In this case, the lookup is a DNS-based query. We can today offer a practical functional process model as so: Result = CheckSigningPractice(ADID [, SDID]) where ADID is the required Author Domain Identity, and SDID is the optional Signer Domain Identity. Note, I used the optional parameter prologue definition since that is what we have today and we are trying to get SDID back into the lookup algorithm which MAY be a non-DNS algorithm as well. That is what you are trying to do. I am saying you need a fallback with the DKIM-Delegate idea, so at best, it a short circuiting optimization concept. The functional concepts are described and outlined in various documents developed over the years, including the RFC documents referenced in DKIM RFC6376 section 1.1: 1.1. DKIM Architecture Documents Readers are advised to be familiar with the material in [RFC4686], [RFC5585], and [RFC5863], which provide the background for the development of DKIM, an overview of the service, and deployment and operations guidance and advice, respectively. The three documents are: RFC4686 Analysis of Threats Motivating DKIM RFC5585 DKIM Service Overview RFC5863 DKIM Development, Deployment, and Operations Review the documents to get a functional understanding of the entire DKIM layered framework. Fundamentally, the lookup in RFC4686 was conceptualized as "Sender Signing Practices Query" (SSP): +---------------------------------+ | SIGNATURE CREATION | | (Originating or Relaying AU) | | | | Sign (Message, Domain, Key) | | | +---------------------------------+ | - Message (Domain, Key) | [Internet] | V +---------------------------------+ +-----------+ | SIGNATURE VERIFICATION | | | | (Relaying or Delivering AU) | | KEY | | | | QUERY +--->| Verify (Message, Domain, Key) | | | | | +-----------+ +----------------+----------------+ | - Verified Domain +-----------+ V - [Report] | SENDER | +----------------+----------------+ | SIGNING | | | | PRACTICES +--->| SIGNER EVALUATION | | QUERY | | | | | +---------------------------------+ +-----------+ This model still applies as well as the model in RFC5585 where it was conceptualized as a "Check Signing Practices" (CSP) module, component, "blackbox" concept: |- RFC5322 Message V +--------------------------------+ | Message Signed? | +-----+--------------------+-----+ |yes |no | | | | | | V | +-------------+ | | Verify +---------+ | | Signature | | | +------+------+ | | pass| fail| | V | | +-------------+ | | | Assessments | | | | | V V +-----+--+----+ +-------+ | | / Check \ | +-------->/ Signing \ | / Practices \ | +-------+-------+ | | V V For describing "fault," it is semantically more complex since its a system level security concept but also a well understood concept among industry peers across various technical and communications fields including automated process control concepts, artificial intelligence concepts like expert systems, fuzzy logic, neural networking, robotics and yes IETF protocol client/server engineering. If you have a "series of steps" for an operation, you look for faults, holes, inconsistencies, "errors" in that operation -- in short, protocol faults would be threat entry points. They become threat entry points if you don't watch for these basic conditions: - no mail expected, - only 1st party signature expected, - any valid signature is expected, - only 1st party or authorized 3rd party. At best, DKIM-Delegate allows a reduction for lookups, but not eliminating them. This mean that verifiers must now have fallback and migration complexities, more coding. It might be worth to explore as an optimizer. Definitely, not a replacement. >> The policy is X, but Y is seen. The payload can be >> DKIM-Delegate compliant but the actual policy is exclusive >> and doesn't allow it. > > You're thinking about a case where one or more unprivileged users at > the first party have been cracked, and mail that dkim-delegate > authenticates is being sent through 3rd parties but shouldn't be? Its below all that. The logic is detecting a fault in the domain policy declaration and mail operation expectation compared to what is actually detected. A condition expected did not happen. What will be done about it? The power of the DKIM+POLICY framework since its invention comes from the detection of these enforceable failure points and taking enforcement action when the domain has declared such enforcement. If not enforced, then we have reduced payoff, increase security problems, high processing wastes. -- HLS From nobody Thu Jun 12 11:35:29 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7113D1B2A04; Thu, 12 Jun 2014 05:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LOTS_OF_MONEY=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 nrl5sNzxTSs3; Thu, 12 Jun 2014 05:47:30 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C55F1B2A02; Thu, 12 Jun 2014 05:47:29 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id n3so7115115wiv.15 for ; Thu, 12 Jun 2014 05:47:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/IKTZAy4/7/22q6xWKTe/C9reX88LKT9H6rq28a4uXs=; b=GRSjAR8QTEs6oTgKr9JapJw+X8Hma8qcXDr3ZxvpX2esrGprAZiEJhl9QhpxeqUXqJ AHjhjufrqCxVCJxpZXEWfUyLzYQ6LCVv6bBqkeFCUlc2usyURAPTvpRVB3cGb8KsNgYf D9G+igUV1xLg5bPWoCODb86zZhOe6p3hCqpE6AkqMTNY2nlxxgcSJRElefg6Vc1drSch X6AjVKYwfNpCXJ3YvIJoIPDgiuYiUyIwNfDI9TQ48tP6Ocn4UfMffc4vB0SjG817esUf Wcw9LyadxUUtboQICe6GaKNsqyZQTsEftidSEkXn/4vQprzvCk5jasUjfv8Bz/mA4y04 m9IQ== MIME-Version: 1.0 X-Received: by 10.194.62.176 with SMTP id z16mr42136734wjr.76.1402577247984; Thu, 12 Jun 2014 05:47:27 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.79.136 with HTTP; Thu, 12 Jun 2014 05:47:27 -0700 (PDT) In-Reply-To: <20140611170004.5D75E1AD4D@ld9781.wdf.sap.corp> References: <20140611170004.5D75E1AD4D@ld9781.wdf.sap.corp> Date: Thu, 12 Jun 2014 08:47:27 -0400 X-Google-Sender-Auth: 3AHxoAiqZetEY3mLGDYPA_OO74k Message-ID: From: Phillip Hallam-Baker To: Martin Rex Content-Type: multipart/alternative; boundary=047d7ba979c2a2e2e104fba2f6c4 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/u5r5tXcozhUao4KrvC9sVwfWxOE X-Mailman-Approved-At: Thu, 12 Jun 2014 11:35:08 -0700 Cc: "dmarc@ietf.org" , Hector Santos , IETF , Dave Crocker Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 12 Jun 2014 12:47:31 -0000 --047d7ba979c2a2e2e104fba2f6c4 Content-Type: text/plain; charset=UTF-8 On Wed, Jun 11, 2014 at 1:00 PM, Martin Rex wrote: > Phillip Hallam-Baker wrote: > > Hector Santos wrote: > >> > >> Let me ask, what if a fedex.com employee use this email domain for > >> subscribing to the IETF list? > > > > Any subsequent problems are irrelevant unless FedEx, the owner of > > fedex.com considers them to be relevant. > > > > That is what folk complaining don't get: you don't have the right to > > use your employers email or a public email provider's email any way > > you want. The domain name owner makes the rules. > > > > As Craster insists: My domain, my rules. > > Strange concept! > > Does your jurisdiction allow your landlord to interfere with > postal/snail mail that is delivered from or to your rented appartment? > Absent specific government action to protect the tenant, the landlord can abuse them in almost any way they choose. Which is why we have voluminous legislative protections for tenants. There is an entire field of law concerning that. The reason that is necessary is that the alternative to renting is very expensive and requires a large amount of capital. But if houses were $6 then it would be perfectly reasonable for society to tell tenants that they are on their own because they should become freeholders. > > In the medium term, lets kill the stupidity of mailing lists with a > > protocol that works. NNTP was originally designed to replace mailing > > lists. It actually works quite well at that. The only problem was the > > IT-Dictator mindset that underlies it: newsgroups have to be approved > > by the Commune! > > Set up your own mail2news gateway. > > /usr/lib/aliases http://www.tldp.org/LDP/nag/node213.html > main2news script http://www.sirlab.de/linux/descr_m2n.html My point is that mail is an old protocol and people who expect that it can be kept going unaltered in its original form serving all the purposes that it was never designed for but have emerged over time are going to be upset no matter what. Spam is an attack. The people who send spam are hardened criminals who have murdered at least two people in the past five years. It is futile to expect that the mail system can continue to operate without changes. The major ISPs can and will and SHOULD consider the interests of the majority of their customers as they move forward. If they don't, open email systems based on SMTP will go the same way as USENET and die because people don't want to put up with them any more. The possibility that SAP might force you to subscribe to IETF lists through a different address does not worry me in the slightest. That is not one of the uses of email that I consider any sort of priority. I am quite happy making you change your mail config. But looking further ahead, it is becoming clear that maintaining mailing list capabilities is going to become increasingly difficult in the face of escalating anti-spam controls. Which is why I suggest that rather than the IETF community reacting to DMARC by refusing to consider any change that inconveniences members of its club, IETF instead designs a protocol that addresses the actual needs. In the SMTP/IMAP model the message is pushed to the sender outbound MTA, pushed to the receiver outbound MTA and pulled by the client from the outbound MTA. The SMTP/IMAP model is thus PUSH/PUSH/PULL The model of NNTP and Dropbox and many of the blogging comments apps is PUSH/PULL/PULL. That is a message pattern that we can and should support in IETF protocols. Because when someone is sending 10Gb of data, the PUSH/PUSH model is not viable. Better to leave that data siting on the outbound server rather than have it clog up hundreds of inbound servers and sit unread. US6192407 has a priority date of Oct 24, 1996, now would be a good time to work on such a protocol. --047d7ba979c2a2e2e104fba2f6c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Jun 11, 2014 at 1:00 PM, Martin Rex <<= a href=3D"mailto:mrex@sap.com" target=3D"_blank">mrex@sap.com> wrote:
Phillip Hallam-Baker wrote:
> Hector Santos <hsantos@isdg.net= > wrote:
>>
>> Let me ask, what if a fedex.com employee use this email domain for
>> subscribing to the IETF list?
>
> Any subsequent problems are irrelevant unless FedEx, the owner of
> fedex.com considers= them to be relevant.
>
> That is what folk complaining don't get: you don't have the ri= ght to
> use your employers email or a public email provider's email any wa= y
> you want. The domain name owner makes the rules.
>
> As Craster insists: My domain, my rules.

Strange concept!

Does your jurisdiction allow your landlord to interfere with
postal/snail mail that is delivered from or to your rented appartment?
<= /blockquote>

Absent specific government action to protec= t the tenant, the landlord can abuse them in almost any way they choose. Wh= ich is why we have voluminous legislative protections for tenants. There is= an entire field of law concerning that.

The reason that is necessary is that the alternative to= renting is very expensive and requires a large amount of capital. But if h= ouses were $6 then it would be perfectly reasonable for society to tell ten= ants that they are on their own because they should become freeholders.

=C2=A0
> In the medium term, lets kill the stupidity of mailing lists with a > protocol that works. NNTP was originally designed to replace mailing > lists. It actually works quite well at that. The only problem was the<= br> > IT-Dictator mindset that underlies it: newsgroups have to be approved<= br> > by the Commune!

Set up your own mail2news gateway.

/usr/lib/aliases =C2=A0http://www.tldp.org/LDP/nag/node213.html
main2news script =C2=A0http://www.sirlab.de/linux/descr_m2n.html

My point is that mail is an old protocol and people = who expect that it can be kept going unaltered in its original form serving= all the purposes that it was never designed for but have emerged over time= are going to be upset no matter what.

Spam is an attack. The people who send spam are hardene= d criminals who have murdered at least two people in the past five years. I= t is futile to expect that the mail system can continue to operate without = changes.

The major ISPs can and will and SHOULD consider the int= erests of the majority of their customers as they move forward. If they don= 't, open email systems based on SMTP will go the same way as USENET and= die because people don't want to put up with them any more.=C2=A0


The possibility that SAP might force you= to subscribe to IETF lists through a different address does not worry me i= n the slightest. That is not one of the uses of email that I consider any s= ort of priority. I am quite happy making you change your mail config.

But looking further ahead, it is becoming clear that ma= intaining mailing list capabilities is going to become increasingly difficu= lt in the face of escalating anti-spam controls. Which is why I suggest tha= t rather than the IETF community reacting to DMARC by refusing to consider = any change that inconveniences members of its club, IETF instead designs a = protocol that addresses the actual needs.


In the SMTP/IMAP model the message is pu= shed to the sender outbound MTA, pushed to the receiver outbound MTA and pu= lled by the client from the outbound MTA.

The SMTP= /IMAP model is thus PUSH/PUSH/PULL

The model of NNTP and Dropbox and many of the blogging = comments apps is PUSH/PULL/PULL. That is a message pattern that we can and = should support in IETF protocols. Because when someone is sending 10Gb of d= ata, the PUSH/PUSH model is not viable. Better to leave that data siting on= the outbound server rather than have it clog up hundreds of inbound server= s and sit unread.
=C2=A0

US6192407 has a priority date of=C2=A0Oct 24, 1996, now would be a good time to work on = such a protocol.
--047d7ba979c2a2e2e104fba2f6c4-- From nobody Thu Jun 12 11:46:26 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8171A035B for ; Thu, 12 Jun 2014 00:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 Rn9uzxULhQSQ for ; Thu, 12 Jun 2014 00:56:58 -0700 (PDT) Received: from nm31.bullet.mail.gq1.yahoo.com (nm31.bullet.mail.gq1.yahoo.com [98.136.217.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C0841A02B3 for ; Thu, 12 Jun 2014 00:56:58 -0700 (PDT) Received: from [127.0.0.1] by nm31.bullet.mail.gq1.yahoo.com with NNFMP; 12 Jun 2014 07:56:58 -0000 Received: from [98.137.12.60] by nm31.bullet.mail.gq1.yahoo.com with NNFMP; 12 Jun 2014 07:53:57 -0000 Received: from [98.137.12.51] by tm5.bullet.mail.gq1.yahoo.com with NNFMP; 12 Jun 2014 07:53:57 -0000 Received: from [127.0.0.1] by omp1066.mail.gq1.yahoo.com with NNFMP; 12 Jun 2014 07:53:57 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 595419.20341.bm@omp1066.mail.gq1.yahoo.com Received: (qmail 77711 invoked by uid 60001); 12 Jun 2014 07:53:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1402559637; bh=4awdKneoaGExiqsY92nyNlzrOcVAFFD2ptwVo1D+N2w=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=6tJeH05n9UdJguQDA5jSjCJ10WlrfSVyo1vyEjf40HJa0g/AALYjnP5Pa26Zq0FoEIDoSIFjVirBKn4gtmTbkPJfgOH/DIXIaJy6SdKlyr0K5tDiDSpZZCXgrI/qCEWIoE9rG+VuaxQYH4uYeYd4xkEI/a7ghwC39THa9+ZkTS4= X-YMail-OSG: IPr_UMUVM1lMfMJN_uVturMOOOAL.ofFYTE_nQAM3maOJ1U lbzMkGiVO.eBxAx5gv8eUyenQ.722hpNl9zJCPph5SQ4olJCQ7nBwoBZyOSf Dn3mbQsv0URZrQBnNKVLk1aVwRc29a3fFCOAwc5KQDdbB_de1_OO0_5NHd26 u07MXjwWzcsY1V4faMomM__tzJ1VzwBsmfWlCYg.im.s_qRuLhCENY99Jmvh l8ylzHpFkepK9HH_RVOXFOkhaP0R_O6OCMB1AdUkIitDnQYM_PahWZrCq.FI mvnvAzAEtQnbMOxHWaKwYC0USHWbjtbq6M1KjdAWJZs4mC_kGxvTcgB7lGf6 V0Lh.Zx6xL2Hi3a9GTSXfs58Hladn.6zfTrJ3UwI9AVFD56GqphS1skbl54J rlZpMm6piE0.a_IC.eeRXDFa2G.YCrYXsUHCh1B0DAObBXfiG7bIMSFUWArB UZ6dyU6pDbQ4DKJZQJGdXYaCdJAfB2GC6DiW_nhPpU.bQSikNawUlPAW6yA6 1j2FUTw1On6Omp8P5fhr3j.eDbG2QK.kyg9h2yQ8z0YkHam4JkxSO1Ll26ra kP0CL.9mniI4WcCuKwPxL.dBVfskML8cYUSYTrvgleGMomfkZrWYSdePPZDm G Received: from [79.175.112.222] by web164606.mail.gq1.yahoo.com via HTTP; Thu, 12 Jun 2014 00:53:57 PDT X-Rocket-MIMEInfo: 002.001, PiBES0lNLURlbGVnYXRlIGRvZXMgbm90IG5lZWQgb3IgdXNlIGFueSBleHRlcm5hbGx5LW1haW50YWluZWQgbGlzdC4KCgpwbGVhc2UsIHNvbHZlIHRoaXMgc3Bvb2ZpbmcgZXhhbXBsZToKCjEuIHNvLCBhIHNlbmRlciBzZW5kcyBES0lNLUQgd2l0aCBldmVyeSBlbWFpbCwgcmVnYXJkbGVzcyB3aGV0aGVyCsKgwqAgaXQgaXMgbWVhbnQgZm9yIGEgbWFpbGluZyBsaXN0IG9yIG5vdCwgY2F1c2UgdGhleSBtYWludGFpbiBubwrCoMKgIHdoaXRlbGlzdCB0byBtYWtlIGEgZGlmZmVyZW5jZSwKCjIuIHNlbmRlciABMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.190.668 References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <5392ECED.5010404@gmail.com> <1755889339.33315.1402383131643.JavaMail.zimbra@peachymango.org> <1402385033.97400.YahooMailNeo@web164602.mail.gq1.yahoo.com> <1402414911.96471.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1402431931.70928.YahooMailNeo@web164606.mail.gq1.yahoo.com> <539884A7.3030306@tana.it> <1402523523.93959.YahooMailNeo@web164601.mail.gq1.yahoo.com> Message-ID: <1402559637.20685.YahooMailNeo@web164606.mail.gq1.yahoo.com> Date: Thu, 12 Jun 2014 00:53:57 -0700 (PDT) From: Vlatko Salaj To: "dmarc@ietf.org" In-Reply-To: <1402523523.93959.YahooMailNeo@web164601.mail.gq1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/IedlPUTESJcN94sFgh-1HsctHWg X-Mailman-Approved-At: Thu, 12 Jun 2014 11:46:24 -0700 Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 12 Jun 2014 07:57:00 -0000 > DKIM-Delegate does not need or use any externally-maintained list.=0A=0A= =0Aplease, solve this spoofing example:=0A=0A1. so, a sender sends DKIM-D w= ith every email, regardless whether=0A=A0=A0 it is meant for a mailing list= or not, cause they maintain no=0A=A0=A0 whitelist to make a difference,=0A= =0A2. sender sends an email to me. mind u, i'm not a mailing list.=0A=A0=A0= sender added me in DKIM-D "t=3D" tag [there's no whitelist,=0A=A0=A0 so an= y receiver is a candidate, whether defined by "t=3D" or=0A=A0=A0 implicitly= ],=0A=0A3. i see there's DKIM-D in ur email, i copy it for my message, sign= =0A=A0=A0 that message using my DKIM [i AM a delegated entity], and=0A=A0= =A0 send away an email satisfying DKIM-D profile, caring whatever=0A=A0=A0 = i'm interested transmitting to my victims.=0A=0A=0Aor am i missing somethin= g?=0Aa whitelist, perhaps?=0A=0Athis is a common issue with any weak DKIM.= =0A=0A=0A-- =0AVlatko Salaj aka goodone=0Ahttp://goodone.tk From nobody Thu Jun 12 11:50:14 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E5A1A0254 for ; Thu, 12 Jun 2014 11:50: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 nDD_YG-5jb0D for ; Thu, 12 Jun 2014 11:50:07 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA7CF1A0241 for ; Thu, 12 Jun 2014 11:50:06 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id cc10so6192341wib.6 for ; Thu, 12 Jun 2014 11:50: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 :content-type; bh=R1ailakT6Tg3SlntAW9xslfr+lxwAVwqWcwTtOLhMkk=; b=Y7ZxVqAnoeHZejxy2Q0/Sh+BL099JCvn9zglg/ezaAhwIEh8w7q7gWTgurkINr8LtJ ela0AuhIXB3Mc9Cvd0GrTcuuQ6KqaVwqA2V6k98Y49AYNbTcAkA42+GdKA8DpBlG3mAJ SMBrS4y0ivH4VgCyus2PleJ/7sPC/u3LFswDED1JrdQAViULYT5B4D2leRT+pW/J6/wm DbQ33Pcs0NTtJG47mcW7ZTYC5bXr6Aff+fRPW8s9iv4ZAxgL6FTQGmbO+CqUwed28zlq AsaANpCujgFXvkLJ3CsiU3DcKBYk1SB4I7qNbaKF3QKvS5d914XvzCNdeUi0mwAf1ADj GOZQ== MIME-Version: 1.0 X-Received: by 10.194.161.168 with SMTP id xt8mr64803944wjb.35.1402599004804; Thu, 12 Jun 2014 11:50:04 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Thu, 12 Jun 2014 11:50:04 -0700 (PDT) In-Reply-To: <1402559637.20685.YahooMailNeo@web164606.mail.gq1.yahoo.com> References: <20140607081534.11199.82547.idtracker@ietfa.amsl.com> <5392ECED.5010404@gmail.com> <1755889339.33315.1402383131643.JavaMail.zimbra@peachymango.org> <1402385033.97400.YahooMailNeo@web164602.mail.gq1.yahoo.com> <1402414911.96471.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1402431931.70928.YahooMailNeo@web164606.mail.gq1.yahoo.com> <539884A7.3030306@tana.it> <1402523523.93959.YahooMailNeo@web164601.mail.gq1.yahoo.com> <1402559637.20685.YahooMailNeo@web164606.mail.gq1.yahoo.com> Date: Thu, 12 Jun 2014 11:50:04 -0700 Message-ID: From: "Murray S. Kucherawy" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=089e01419c6a719b5c04fba807f7 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/T2Aujnk-B3u56nRGhWMwbDkkQEc Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Thu, 12 Jun 2014 18:50:12 -0000 --089e01419c6a719b5c04fba807f7 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 12, 2014 at 12:53 AM, Vlatko Salaj wrote: > > DKIM-Delegate does not need or use any externally-maintained list. > > please, solve this spoofing example: > Asked and answered already, here (and elsewhere): http://www.ietf.org/mail-archive/web/dmarc/current/msg01250.html There's no need to beat a dead horse. We're discussing what we could do about this, because we know it's a weakness with the current proposal. One good suggestion was made later in the same thread. > or am i missing something? > a whitelist, perhaps? > Is there some reason a queryable whitelist is better than an implicit (and very small) one, which is the design here? It seems like there's quite a lot of overhead in making that work. this is a common issue with any weak DKIM. > Obviously. -MSK --089e01419c6a719b5c04fba807f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 12, 2014 at 12:53 AM, Vlatko Salaj <v= latko.salaj@goodone.tk> wrote:
=
> DKIM= -Delegate does not need or use any externally-maintained list.

please, solve this spoofing example:

<= div>Asked and answered already, here (and elsewhere): http://www.ietf.org= /mail-archive/web/dmarc/current/msg01250.html

There's no need to beat a dead horse.=C2=A0 We're discussing wh= at we could do about this, because we know it's a weakness with the cur= rent proposal.=C2=A0 One good suggestion was made later in the same thread.=
=C2=A0
or am i missing something?
a whitelist, perhaps?

Is there some rea= son a queryable whitelist is better than an implicit (and very small) one, = which is the design here?=C2=A0 It seems like there's quite a lot of ov= erhead in making that work.

this is a common issue with any weak DKIM.

<= div>Obviously.

-MSK
--089e01419c6a719b5c04fba807f7-- From nobody Thu Jun 12 12:03:23 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C641B2AF7; Thu, 12 Jun 2014 12:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.881 X-Spam-Level: X-Spam-Status: No, score=-2.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, MISSING_HEADERS=1.021, 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 iAnX-LtYL2cA; Thu, 12 Jun 2014 12:03:20 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA5E1B2AE9; Thu, 12 Jun 2014 12:03:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id A4FEECC094; Thu, 12 Jun 2014 15:03:19 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id avliuCg1VV6Q; Thu, 12 Jun 2014 15:03:15 -0400 (EDT) Received: from new-host-3.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 1FF56CC087; Thu, 12 Jun 2014 15:03:15 -0400 (EDT) Message-ID: <5399F971.8010605@meetinghouse.net> Date: Thu, 12 Jun 2014 15:03:13 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 References: <20140611170004.5D75E1AD4D@ld9781.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/r344CAMvHQwj74hfj0CauZ_H5L0 Cc: "dmarc@ietf.org" , IETF Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 12 Jun 2014 19:03:22 -0000 Phillip Hallam-Baker wrote: > > > > On Wed, Jun 11, 2014 at 1:00 PM, Martin Rex > wrote: > > Phillip Hallam-Baker wrote: > > Hector Santos > wrote: > >> > >> Let me ask, what if a fedex.com employee use > this email domain for > >> subscribing to the IETF list? > > > > Any subsequent problems are irrelevant unless FedEx, the owner of > > fedex.com considers them to be relevant. > > > > That is what folk complaining don't get: you don't have the right to > > use your employers email or a public email provider's email any way > > you want. The domain name owner makes the rules. > > > > As Craster insists: My domain, my rules. > > Strange concept! > > Does your jurisdiction allow your landlord to interfere with > postal/snail mail that is delivered from or to your rented appartment? > > > Absent specific government action to protect the tenant, the landlord > can abuse them in almost any way they choose. Which is why we have > voluminous legislative protections for tenants. There is an entire > field of law concerning that. > > Though, in the case of mail, it's Federal law that prevents "mail tampering" and other unauthorized interference with US mail. I'm not 100% sure, but I expect that an employer might not be legally allowed to interfere with a letter addressed to you, at your workplace. When it comes to email - there are (or at least used to be) the Email Privacy Act - which forbid employers from reading your mail, in the absence of a clearly stated policy that reserved the right to do so. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Thu Jun 12 12:20:31 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F6F1B27D4 for ; Thu, 12 Jun 2014 12:20:29 -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 bMI8PvBDE7AA for ; Thu, 12 Jun 2014 12:20:26 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.93]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52A1F1B27B7 for ; Thu, 12 Jun 2014 12:20:26 -0700 (PDT) Received: from BY2SR01MB608.namsdf01.sdf.exchangelabs.com (10.255.93.167) by BY2SR01MB607.namsdf01.sdf.exchangelabs.com (10.255.93.166) with Microsoft SMTP Server (TLS) id 15.0.974.2; Thu, 12 Jun 2014 18:45:38 +0000 Received: from BY2SR01MB608.namsdf01.sdf.exchangelabs.com ([169.254.5.56]) by BY2SR01MB608.namsdf01.sdf.exchangelabs.com ([169.254.5.56]) with mapi id 15.00.0974.002; Thu, 12 Jun 2014 18:45:38 +0000 From: Terry Zink To: Phillip Hallam-Baker Thread-Topic: [dmarc-ietf] Change the mailing list protocol, not DMARC. Thread-Index: AQHPgml9Mbn8fQMPJEeb54da2StdxJtt156A Date: Thu, 12 Jun 2014 18:45:37 +0000 Message-ID: References: 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.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02408926C4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(189002)(199002)(51704005)(97336001)(21056001)(76796001)(76786001)(77096001)(80022001)(92566001)(66066001)(97186001)(98676001)(74876001)(87936001)(2656002)(101416001)(74706001)(87266001)(81342001)(81542001)(76482001)(85306002)(46102001)(77982001)(47736002)(50986002)(47976003)(54356002)(54316003)(47446003)(95416001)(4396001)(20776003)(53806002)(94946001)(90146001)(85852003)(558084003)(83072002)(94316002)(64706001)(81816001)(95666003)(33646001)(83322001)(19580405001)(56816006)(63696004)(56776002)(59766002)(65816002)(79102001)(99396002)(49866002)(51856002)(19580395003)(74366001)(93136001)(31966008)(74662001)(74502001)(93516002)(81686001)(69226001)(24736002)(223123001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2SR01MB607; H:BY2SR01MB608.namsdf01.sdf.exchangelabs.com; FPR:; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Co2mZml4FhsIKYm3oq_J-87QcaA Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 12 Jun 2014 19:20:29 -0000 > Phillip Hallam-Baker writes: > > As Craster insists: My domain, my rules. True. But Craster gets killed by getting stabbed in the neck. -- Terry From nobody Thu Jun 12 12:22:32 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A681B2799 for ; Thu, 12 Jun 2014 12:22:30 -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, 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 N77UUkME0nMx for ; Thu, 12 Jun 2014 12:22:28 -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 AE3FF1A023D for ; Thu, 12 Jun 2014 12:22:28 -0700 (PDT) Received: from USCLES544.agna.amgreetings.com ([fe80::f5de:4c30:bc26:d70a]) by USCLES532.agna.amgreetings.com ([::1]) with mapi id 14.03.0158.001; Thu, 12 Jun 2014 15:22:27 -0400 From: "MH Michael Hammer (5304)" To: Terry Zink , Franck Martin , Matt Simerson Thread-Topic: Change the mailing list protocol, not DMARC. Thread-Index: AQHPhjbZJP0bmnyMSEa8Dt8vO7vgD5tt76uA///rDwA= Date: Thu, 12 Jun 2014 19:22:25 +0000 Message-ID: References: <8738fcrhqz.fsf@uwakimon.sk.tsukuba.ac.jp> <53974C62.9050408@isdg.net> <87tx7splbb.fsf@uwakimon.sk.tsukuba.ac.jp> <998FA07D-E6D7-41FB-A143-CE7B426E6763@tnpi.net> <87ppigowmh.fsf@uwakimon.sk.tsukuba.ac.jp> <1614404651.90556.1402574805512.JavaMail.zimbra@peachymango.org> <1a3d6beda2014edf92f936963cd1635e@BY2SR01MB608.namsdf01.sdf.exchangelabs.com> In-Reply-To: <1a3d6beda2014edf92f936963cd1635e@BY2SR01MB608.namsdf01.sdf.exchangelabs.com> 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: http://mailarchive.ietf.org/arch/msg/dmarc/0Q0LaykE-qr0kokxPsP8xmVD2so Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 12 Jun 2014 19:22:30 -0000 > -----Original Message----- > From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of Terry Zink > Sent: Thursday, June 12, 2014 12:37 PM > To: Franck Martin; Matt Simerson > Cc: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. >=20 > > Franck Martin wrote: > > > > I found that to build the override list for mailing list, I could log > > DMARC rejected emails that contained a List-Id or List-Post header. > > Once reviewing the logs (once a week, or once a month), you can make > > an easy decision if you want to add the found IPs into your override li= st. >=20 > That was my thinking, too. >=20 > I like the idea of DKIM-Delegate but if I had to choose between doing > Franck's whitelist [1] suggestion above, or DKIM-Delegate, I'd probably d= o > the whitelist because it's less code to implement and maintain; as someon= e > who fights spam we're already in the business of checking logs looking fo= r > patterns and doing overrides and so this would simply be one more pattern > to look for. >=20 > -- Terry >=20 > [1] whitelist =3D override the DMARC p=3Dreject/quarantine action, not sk= ip all > filtering >=20 And this fits squarely within the DMARC local policy space. From nobody Thu Jun 12 12:33:50 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDC161A025A for ; Thu, 12 Jun 2014 12:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.921 X-Spam-Level: X-Spam-Status: No, score=-16.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] 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 6VxxcsMs2knC for ; Thu, 12 Jun 2014 12:33:48 -0700 (PDT) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D4FD1A0219 for ; Thu, 12 Jun 2014 12:33:48 -0700 (PDT) Received: from GQ1-EX10-CAHT02.y.corp.yahoo.com (gq1-ex10-caht02.corp.gq1.yahoo.com [10.73.118.81]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id s5CJX4mM002124 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Jun 2014 12:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1402601586; bh=/vi88FBpblaEQssBGrjZ5aHZbhEC8Bi4GOzffRzwN9k=; h=From:To:CC:Subject:Date; b=rksIBUegh3+Qqg9OeJ+ntRwxdv0OHhLH+KPwYonC6A6xRigmygFV2iMM7Sj0RKeTK OalHQIqAd5heARlCEzAA2C8qiR6K20pKwDqYCaGPbF4Mm8NmuQhDyUmamKZCGgBfus +Jl6GywevUr8WbGTiNucMC736TN66o+PdLAGr/1s= Received: from GQ1-MB01-02.y.corp.yahoo.com ([fe80::a049:b5af:9055:ada6]) by GQ1-EX10-CAHT02.y.corp.yahoo.com ([fe80::35be:ca2f:4da2:1e90%12]) with mapi id 14.03.0181.006; Thu, 12 Jun 2014 12:33:04 -0700 From: Elizabeth Zwicky To: Terry Zink , Franck Martin , Matt Simerson Thread-Topic: [dmarc-ietf] Change the mailing list protocol, not DMARC. Thread-Index: AQHPhnUg1aXYd5Tvh0G4uvcepbQG7A== Date: Thu, 12 Jun 2014 19:33:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.72.119.223] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 601585002 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ur2QWC8RUAUXorykbVELaRb728o Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 12 Jun 2014 19:33:50 -0000 On 6/12/14, 9:36 AM, "Terry Zink" wrote: >> Franck Martin wrote: >>=20 >> I found that to build the override list for mailing list, I could log >>DMARC rejected=20 >> emails that contained a List-Id or List-Post header. Once reviewing the >>logs=20 >> (once a week, or once a month), you can make an easy decision if you >>want to=20 >> add the found IPs into your override list. > >That was my thinking, too. > >I like the idea of DKIM-Delegate but if I had to choose between doing >Franck's whitelist [1] suggestion above, or DKIM-Delegate, I'd probably >do the whitelist because it's less code to implement and maintain; as >someone who fights spam we're already in the business of checking logs >looking for patterns and doing overrides and so this would simply be one >more pattern to look for. Building your whitelist is a fine thing, but it doesn't replace a real solution to allowing mail to be forwarded. DKIM-Delegate gives you a hope of controlling whether your mail gets accepted at other sites. Figuring out who to whitelist at your site doesn't. And using List-Id or List-Post only lets you whitelist mailing lists, which are only part of the forwarder problem -- there are also all the non-transparent forwarders (for instance, enterprise systems which do malware filtering on mail). Elizabeth > >-- Terry > >[1] whitelist =3D override the DMARC p=3Dreject/quarantine action, not ski= p >all filtering > >_______________________________________________ >dmarc mailing list >dmarc@ietf.org >https://www.ietf.org/mailman/listinfo/dmarc From nobody Thu Jun 12 12:53:56 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0487C1A01C4 for ; Thu, 12 Jun 2014 12:53:49 -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 mm3D9vaD7u9k for ; Thu, 12 Jun 2014 12:53:46 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0807F1A0110 for ; Thu, 12 Jun 2014 12:53:45 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hi2so8242785wib.5 for ; Thu, 12 Jun 2014 12:53:44 -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=Vw1+ii62n7ASCHjOtI7D6lwe1YhLROQ0+ZhhHLUDPTE=; b=TmJw302UuKO9HQ1kYLqQKqi0zFKohSiOrqHBADlSgIf07xSNJm7Fx6ZWpVxFtx5Hhw +0zNUDZaGqMrfp2gwFsIW+TaXzteJ/nMcbQyIDG0BNvUUSTFDW+vw3JZUSWkiBTXM0DP XdSJct9/n/0roGXoxC8WijytDsItUya9OpxyL/Jcpv1vYscA1qUOcgLYYeOIVvT/4eX4 /8DFDewEadDG6mtdGTadKzOBBt7k9mCHmnBf+tkaiSbHnkpN4Jikp9luVMPxf3CvUjRe lLXhlq3tYLGlDo43jT3wStWV5rNYyGB6M46y4bkGmfouK/AskNc8MbvY8u2nMhhC0BSN lzEw== MIME-Version: 1.0 X-Received: by 10.180.75.212 with SMTP id e20mr9332641wiw.5.1402602824216; Thu, 12 Jun 2014 12:53:44 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Thu, 12 Jun 2014 12:53:44 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Jun 2014 12:53:44 -0700 Message-ID: From: "Murray S. Kucherawy" To: Elizabeth Zwicky Content-Type: multipart/alternative; boundary=f46d043890a519557b04fba8ebeb Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/u9NGxF1swJgCUVhXX_Qr3eCfv_8 Cc: "dmarc@ietf.org" , Matt Simerson , Terry Zink , Franck Martin Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 12 Jun 2014 19:53:49 -0000 --f46d043890a519557b04fba8ebeb Content-Type: text/plain; charset=UTF-8 On Thu, Jun 12, 2014 at 12:33 PM, Elizabeth Zwicky wrote: > > > On 6/12/14, 9:36 AM, "Terry Zink" wrote: > > >> Franck Martin wrote: > >> > >> I found that to build the override list for mailing list, I could log > >>DMARC rejected > >> emails that contained a List-Id or List-Post header. Once reviewing the > >>logs > >> (once a week, or once a month), you can make an easy decision if you > >>want to > >> add the found IPs into your override list. > The problem there is that not all lists use the List-* fields. You also have a period of time between which a user wants to start using a list and the whitelisting of the list (once a week, or once a month); in between, you get the problem we have now. It also presumes the list sends at least weekly or monthly; many don't. (For example, how many ietf.org lists exist but are largely dormant?) -MSK --f46d043890a519557b04fba8ebeb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 12, 2014 at 12:33 PM, Elizabeth Zwicky <zw= icky@yahoo-inc.com> wrote:


On 6/12/14, 9:36 AM, "Terry Zink" <tzink@exchange.microsoft.com> wrote:

>> Franck Martin wrote:
>>
>> I found that to build the override list for mailing list, I could = log
>>DMARC rejected
>> emails that contained a List-Id or List-Post header. Once reviewin= g the
>>logs
>> (once a week, or once a month), you can make an easy decision if y= ou
>>want to
>> add the found IPs into your override list.
The problem there is that not all lists use the List-* fields.=

You also have a period of time between which a user wants to start = using a list and the whitelisting of the list (once a week, or once a month= ); in between, you get the problem we have now.

It also presumes the list sends at least weekly or monthly; many don= 9;t.=C2=A0 (For example, how many ietf.org = lists exist but are largely dormant?)

-MSK
--f46d043890a519557b04fba8ebeb-- From nobody Thu Jun 12 13:05:16 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794801B280A for ; Thu, 12 Jun 2014 13:05:13 -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 xYg_Okj-i7AT for ; Thu, 12 Jun 2014 13:05:11 -0700 (PDT) Received: from mail.theartfarm.com (mail.theartfarm.com [66.128.51.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4725A1B2809 for ; Thu, 12 Jun 2014 13:05:11 -0700 (PDT) Received: (qmail 11198 invoked by uid 89); 12 Jun 2014 20:05:10 -0000 Received: from unknown (HELO mail.theartfarm.com) (127.0.0.30) by mail.theartfarm.com with SMTP; 12 Jun 2014 20:05:10 -0000 Received-SPF: Pass (mail.theartfarm.com: domain of tnpi.net designates 50.159.99.59 as permitted sender) receiver=mail.theartfarm.com; identity=mailfrom; client-ip=50.159.99.59; helo=imac27.simerson.net; envelope-from= Received-SPF: None (mail.theartfarm.com: domain of imac27.simerson.net does not designate 50.159.99.59 as permitted sender) receiver=mail.theartfarm.com; identity=helo; client-ip=50.159.99.59; helo=imac27.simerson.net; envelope-from= Received: from imac27.simerson.net (c-50-159-99-59.hsd1.wa.comcast.net [50.159.99.59]) by mail.theartfarm.com (Haraka/2.5.0-toaster) with ESMTPSA id 87E7D092-27AE-4DBC-8A37-E2071F0237CA.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=AES128-SHA verify=FAIL); Thu, 12 Jun 2014 16:05:09 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Matt Simerson In-Reply-To: Date: Thu, 12 Jun 2014 13:05:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <44C34E47-C588-4714-B27A-4856E68D3F4D@tnpi.net> References: To: "dmarc@ietf.org" X-Mailer: Apple Mail (2.1878.2) X-Haraka-p0f: os="MacOS X 10.9 or newer (sometimes iPhone " link_type="Ethernet or modem" distance=11 total_conn=1 shared_ip=N X-Haraka-GeoIP: US, WA, Seattle, 2699km X-Haraka-GeoIP-Received: 50.159.99.59:US X-Haraka-ASN: 7922 50.128.0.0/9 X-Haraka-ASN-MONKEY: asn=7922 net=50.128.0.0/9 org=Comcast Cable Communications, Inc. date=1997-02-14 country=US X-Haraka-FCrDNS: c-50-159-99-59.hsd1.wa.comcast.net X-Spam-ASN: X-Spam-DCC: x.dcc-servers: spamassassin.tnpi.net 104; Body=1 Fuz1=1 Fuz2=1 X-Spam-SNF-Result: 0 (Standard White Rules) X-Spam-MessageSniffer-Scan-Result: 0 X-MessageSniffer-Rules: 0-0-0-3243-c X-MessageSniffer-Clean: Yes X-Spam-MessageSniffer-Rules: 0-0-0-3243-c X-MessageSniffer-Clean: Yes X-Spam-GBUdb-Analysis: 0, 50.159.99.59, Ugly c=0.264319 p=-1 Source Normal X-MessageSniffer-Scan-Result: 0 X-MessageSniffer-Rules: 0-0-0-3243-c X-MessageSniffer-Clean: Yes X-Haraka-Karma: connect: 5, history: 465, total_connects: 496, neighbors: -5531, pass:fcrdns.fcrdns, relaying, auth_user, fail:fcrdns.fail, neighbors, dnsbl.fail, helo.checks.fail, skip:penalty DKIM-Signature: v=1; a=rsa-sha256; bh=C8hVfsvIXxTfhsU8j/nt50ynnL50GfOmLcRz2ZaMsQ8=; c=relaxed/simple; d=tnpi.net; h=from:subject:date:message-id:to:mime-version; s=mar2013; b=P58dpsKOuXv3glt6mC/y8duTCA9SSmzsTo7eb2RbmbJ7878qVM7r89SlPX6S1FxvPC0u1lskeaoSuxHlMZjbGbkd0HpJKkhiyToVElMocdFzBh2uB0pUBqb1E4Dtd2Kmznb3CF7umXZpISXxQsNiwnaA709fU+usynQ/GrN4HQ7b3fj2KNZt8z3mrWB2POOyyrqcIyL7wsBfRXhoJUKM7t2ZUs+sjo3KrmjAYoqjaAHuhIJUCWsUxeav2GDvxh9qMeyVYpFEyzvBXFCiC003H5m2OqiPUUDeKQ/Nqs63VA5Uh/KtV7zGeL1JL9RlQgCuaLGeIwf9UntjMwp/EuzBwg== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/rBUkRld8YEThZvJZ6OWvMcQtXrk Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 12 Jun 2014 20:05:13 -0000 On Jun 12, 2014, at 12:33 PM, Elizabeth Zwicky = wrote: > On 6/12/14, 9:36 AM, "Terry Zink" = wrote: >=20 > -- there are also all the non-transparent forwarders (for instance, > enterprise systems which do malware filtering on mail). And those system are going to do malware filtering on the message *body* = and then expect to pass along the message to the recipient? /cough cough. I'm not sure we need to be considerate of such behavior. If it's = malware, reject it outright. If it contains forbidden content, reject = the message outright and let the recipient know why. I know this is = exactly how [at least portions of] the DoD handle it. Matt= From nobody Thu Jun 12 15:19:25 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9151A028A for ; Thu, 12 Jun 2014 15:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 BV3qXauGBFLn for ; Thu, 12 Jun 2014 15:19:23 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id C7B441A0276 for ; Thu, 12 Jun 2014 15:19:22 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id F06443FA0B1E; Fri, 13 Jun 2014 07:19:21 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id E28B81A32C5; Fri, 13 Jun 2014 07:19:21 +0900 (JST) From: "Stephen J. Turnbull" To: Dave Crocker In-Reply-To: <53997B32.8070805@gmail.com> References: <20140611141529.4633.qmail@joyce.lan> <53986B38.2010401@gmail.com> <53986F24.8020404@gmail.com> <87fvjapr99.fsf@uwakimon.sk.tsukuba.ac.jp> <53994E40.1040609@gmail.com> <877g4mphz5.fsf@uwakimon.sk.tsukuba.ac.jp> <53997B32.8070805@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 13 Jun 2014 07:19:21 +0900 Message-ID: <871tutpy8m.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/P5J0rJVYNoYcVGP67aPmFeEtopg Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Thu, 12 Jun 2014 22:19:24 -0000 Dave Crocker writes: > On 6/12/2014 11:58 AM, Stephen J. Turnbull wrote: > > Dave Crocker writes: > > > > > The scenario being discussed is for a recipient who gets both signatures > > > when they are valid, but who does not know about DKIM-Delegate. > > > > I didn't understand that from previous posts. At least Hector seems > > to be concerned (though not exclusively so) with the case I presented. > > I suspect John as well. And I think that case is important. > > Now it's my turn to not understand. Really, what scenario is involved here? Any situation where the token signature is the only valid signature from the Author Domain. > > > It ought to prefer the 'stronger' one, but the point being raised > > > is that this is not an issue that has been at issue until now. > > > (Or, at least, not much of an issue until now.) > > > > If they're both valid, isn't this "no blood, no foul"? > > The concern is a a write-down attack, where the weaker signature is > effectively an exploit. We're talking about verification by the destination MTA (no mention of mediators anywhere. If there *is* an attack involving two valid signatures from the Author Domain, I don't see how either DKIM or DKIM-delegate can do anything about it. > > Is there a concern is that having seen a token signature, it will > > ignore the valid signature, and treat the message as high-risk? > > Sounds like a generic issue with receiver use of DKIM. A worthy > question, but not inherent to -Delegate. That's part of what I meant by "quality-of-implementation issue". Sorry it wasn't clear. > > > The concern is that the weaker signature (that I call a token, > > > given how little of the message it is likely to cover) is more > > > easily re-used for a replay attack. > > > > I don't understand what attack you have in mind, if that attack > > involves two valid signatures from the Author Domain, the > > content-covering signature has a "good" selection of headers, > > and doesn't use the l= tag. > > The premise is that the weaker nature of the token signature (needed to > get it to survive through the mailing list) will make it more subject to > some form of replay attack that includes bad content. > > I've no idea how serious the threat is, but it's certainly a > mathematically legitimate concern. Yes, I understand that, but I don't see mathematical legitimacy without an invalid/missing content-coveting signature in the picture (unless users at the Author Domain have been suborned by the abusers). So I don't understand why your analysis is limited to the two-valid- signatures case, which doesn't have an "interesting" failure mode as far as I can see. Mathematically, a crappy implementation could indeed choose to reject because of the presence of a token signature, despite the presence of a valid content-covering signature. But the answer is "Well, if that hurts, don't do it." From nobody Thu Jun 12 15:59:43 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBEF61A02CB for ; Thu, 12 Jun 2014 15:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 ZTNHKjpu9DeY for ; Thu, 12 Jun 2014 15:59:38 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 477341A02C4 for ; Thu, 12 Jun 2014 15:59:38 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 732253FA0B1E; Fri, 13 Jun 2014 07:59:37 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 6534F1A32C5; Fri, 13 Jun 2014 07:59:37 +0900 (JST) From: "Stephen J. Turnbull" To: Elizabeth Zwicky In-Reply-To: References: <20140611222207.2338.qmail@joyce.lan> <53993D20.7010901@gmail.com> <8761k6pheq.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 13 Jun 2014 07:59:37 +0900 Message-ID: <87y4x1oht2.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/uZNeWdU8TmGT33gz_jZr4noDCbw Cc: Dave Crocker , "Murray S. Kucherawy" , "dmarc@ietf.org" , John R Levine Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Thu, 12 Jun 2014 22:59:39 -0000 Elizabeth Zwicky writes: > I did not say that the levels were the same; I said the attackers > have not gone away. They are not at high volume, but they're sure > sitting there checking to see whether or not it's working. What you said, exactly, is But I do, in fact, have data, and that data tells me that the attackers forging our users based on stolen addressbooks have never stopped; we are still blocking them now. What they were doing was sending millions, perhaps billions, of spoofed messages. "Never stopped" implies they are still sending millions, perhaps billions, of spoofed messages. As does "we are still." Do you really mean to invoke "plausible deniability"? N.B. I've already embarrassed myself twice by citing your message as support for my belief (expressed in my own words, not a quote or paraphrase) that the spammers are still attacking Yahoo! (in volume, vs. probing for weaknesses). I resent that. > x= is a weak protection here; spammers can and do move millions of > messages a minute to us. Then again we are well placed to implement > special handling here, as are most if not all sites receiving mail > at this kind of scale. So the problem is at small and intermediate > sites. Implementation of DKIM-Delegate is a site-by-site decision. I don't see why you would know better than the site admins for other sites. If you're worried about them, document the issues and let them decide. In any case, filtering by 3rd parties has to be presumed weak, and lists are obvious targets for spammers (as amplification devices). Anybody who doesn't check incoming list traffic for spam should fold up shop and send their users to Yahoo! IMO. From nobody Thu Jun 12 16:05:37 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24EA41A0341 for ; Thu, 12 Jun 2014 16:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 VZOg0Y1nS9tN for ; Thu, 12 Jun 2014 16:05:16 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4751A02E5 for ; Thu, 12 Jun 2014 16:05:16 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id BBD723FA0B1D; Fri, 13 Jun 2014 08:05:15 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id ADF451A32C5; Fri, 13 Jun 2014 08:05:15 +0900 (JST) From: "Stephen J. Turnbull" To: "John R Levine" In-Reply-To: References: <20140611222207.2338.qmail@joyce.lan> <53993D20.7010901@gmail.com> <539964F1.7030007@gmail.com> <53996C80.1090303@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 13 Jun 2014 08:05:15 +0900 Message-ID: <87wqclohjo.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/dUy7ckbVnPhEUzUd1x8CzWgJUkQ Cc: Dave Crocker , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Thu, 12 Jun 2014 23:05:17 -0000 John R Levine writes: > > And humor aside, please state the technical changes to the existing DKIM > > specification that are being made with DKIM-Delegate. > > If a signature has an rsf= tag, verifiers ignore it unless there's a > matching signature from a domain the rsf= points to. > > This is not backward compatible, since verifiers that don't understand > rsf= will often get the wrong answer, so it needs a version bump. Can't both the version bump issue and the token signature issue be ameliorated by incorporating the token signature in the DKIM-Delegate field? There's a protocol collision on the t= tag which would need to be addressed, but otherwise I don't see a problem. From nobody Thu Jun 12 16:47:58 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3751A1A02FA for ; Thu, 12 Jun 2014 16:47:56 -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 PsdNyfV-nR-W for ; Thu, 12 Jun 2014 16:47:54 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECB7A1A02EF for ; Thu, 12 Jun 2014 16:47:53 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id n15so6009wiw.11 for ; Thu, 12 Jun 2014 16:47:52 -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=hKm+YVMVbdGzEKeE3qISgewoYeHEst7WScyIqDP5hIY=; b=SKb+N1frdPH/GA0beC+JZXrb/EwC/bshQQl6CP7rk4FiFnkguBvoGHKOm2vMxwVGhl xpqxxl4jk4z9x373ypA+mDgf2UJIA11FZ1n/50MtaxNre7D6rsnPPBpR3Q8rooS/7/iD VmMJFjrze9/7u8LMq6ARdUcf+xABAElVQaChWiaqiNVJcGaGeqX19qdMFzJmcHDZ6itH HhyFHRtbiDwLKXIetMLN6kk2omIxd7x7YpUFZxmNmFji/+o4TLhulcOqdFf+/Qv0DNAU KmHbzL+vuQ94Pc24FVcRiPpz3DtepoSuQFVv8MunIsaDbQz1sNGs7wSBDI2wVEyd90Ko GaXQ== MIME-Version: 1.0 X-Received: by 10.194.87.200 with SMTP id ba8mr66412011wjb.28.1402616872382; Thu, 12 Jun 2014 16:47:52 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Thu, 12 Jun 2014 16:47:52 -0700 (PDT) In-Reply-To: <87wqclohjo.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20140611222207.2338.qmail@joyce.lan> <53993D20.7010901@gmail.com> <539964F1.7030007@gmail.com> <53996C80.1090303@gmail.com> <87wqclohjo.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Thu, 12 Jun 2014 16:47:52 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=089e010d8afe6f37c904fbac30a6 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/r8K4qPStK_rXjduWsoE-joUmfWg Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Thu, 12 Jun 2014 23:47:56 -0000 --089e010d8afe6f37c904fbac30a6 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 12, 2014 at 4:05 PM, Stephen J. Turnbull wrote: > Can't both the version bump issue and the token signature issue be > ameliorated by incorporating the token signature in the DKIM-Delegate > field? > > There's a protocol collision on the t= tag which would need to be > addressed, but otherwise I don't see a problem. > > Interesting. So DKIM-Delegate is syntactically the same as DKIM-Signature, but with augmented semantics? Or did you have something else in mind? -MSK --089e010d8afe6f37c904fbac30a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 12, 2014 at 4:05 PM, Stephen J. Turnbull <st= ephen@xemacs.org> wrote:
Can't both the version bump issue and th= e token signature issue be
ameliorated by incorporating the token signature in the DKIM-Delegate
field?

There's a protocol collision on the t=3D tag which would need to be
addressed, but otherwise I don't see a problem.

<= br>
Interesting.=C2=A0 So DKIM-Delegate is syntactically the same= as DKIM-Signature, but with augmented semantics?=C2=A0 Or did you have som= ething else in mind?

-MSK

--089e010d8afe6f37c904fbac30a6-- From nobody Thu Jun 12 16:57:12 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763E61A02EF for ; Thu, 12 Jun 2014 16:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 YCqSkPm8bzHh for ; Thu, 12 Jun 2014 16:57:09 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 20A581A02FA for ; Thu, 12 Jun 2014 16:57:09 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 6C7D73FA0B1D; Fri, 13 Jun 2014 08:57:08 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 5ED431A32C5; Fri, 13 Jun 2014 08:57:08 +0900 (JST) From: "Stephen J. Turnbull" To: Terry Zink In-Reply-To: <1a3d6beda2014edf92f936963cd1635e@BY2SR01MB608.namsdf01.sdf.exchangelabs.com> References: <8738fcrhqz.fsf@uwakimon.sk.tsukuba.ac.jp> <53974C62.9050408@isdg.net> <87tx7splbb.fsf@uwakimon.sk.tsukuba.ac.jp> <998FA07D-E6D7-41FB-A143-CE7B426E6763@tnpi.net> <87ppigowmh.fsf@uwakimon.sk.tsukuba.ac.jp> <1614404651.90556.1402574805512.JavaMail.zimbra@peachymango.org> <1a3d6beda2014edf92f936963cd1635e@BY2SR01MB608.namsdf01.sdf.exchangelabs.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 13 Jun 2014 08:57:08 +0900 Message-ID: <87vbs5of57.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/WNSlzBszSzTX5Pkd9CJCDTTSrXs Cc: "dmarc@ietf.org" , Matt Simerson , Franck Martin Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 12 Jun 2014 23:57:10 -0000 Terry Zink writes: > > Franck Martin wrote: > > > > I found that to build the override list for mailing list, I could > > log DMARC rejected emails that contained a List-Id or List-Post > > header. Once reviewing the logs (once a week, or once a month), > > you can make an easy decision if you want to add the found IPs > > into your override list. > > That was my thinking, too. Sure, but as soon as the spammers adapt and start spoofing lists, you need to check the list's signature anyway. And I don't think customers who sign up for a list will be happy with losing mail for a month. From nobody Thu Jun 12 17:04:29 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4A01A031F for ; Thu, 12 Jun 2014 17:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 HuR-IaZiEbH8 for ; Thu, 12 Jun 2014 17:04:26 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id A1BE31A030C for ; Thu, 12 Jun 2014 17:04:26 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id E36A93FA0B1D; Fri, 13 Jun 2014 09:04:25 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id D564F1A32C5; Fri, 13 Jun 2014 09:04:25 +0900 (JST) From: "Stephen J. Turnbull" To: Matt Simerson In-Reply-To: <44C34E47-C588-4714-B27A-4856E68D3F4D@tnpi.net> References: <44C34E47-C588-4714-B27A-4856E68D3F4D@tnpi.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 13 Jun 2014 09:04:25 +0900 Message-ID: <87tx7poet2.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/u0PPvEv1Kwc23La3FtaLW_mqMMc Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 13 Jun 2014 00:04:27 -0000 Matt Simerson writes: > I'm not sure we need to be considerate of such behavior. If it's > malware, reject it outright. Can't do that. Many viruses attach themselves to legitimate messages. If the author is the boss, rejecting it would be, uh, bad. Steve From nobody Thu Jun 12 17:11:57 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303911A035E; Thu, 12 Jun 2014 17:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 sFeT6DW-myWv; Thu, 12 Jun 2014 17:11:49 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 815A71A0328; Thu, 12 Jun 2014 17:11:49 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id BC7363FA0B1E; Fri, 13 Jun 2014 09:11:48 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id AE94E1A32C5; Fri, 13 Jun 2014 09:11:48 +0900 (JST) From: "Stephen J. Turnbull" To: Phillip Hallam-Baker In-Reply-To: References: <20140611170004.5D75E1AD4D@ld9781.wdf.sap.corp> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 13 Jun 2014 09:11:48 +0900 Message-ID: <87sin9oegr.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/I0I9zzanFvHM22TMaXDsERx6OjQ Cc: "dmarc@ietf.org" , Martin Rex , Hector Santos , IETF , Dave Crocker Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 13 Jun 2014 00:11:55 -0000 Phillip Hallam-Baker writes: > My point is that mail is an old protocol and people who expect that > it can be kept going unaltered in its original form serving all the > purposes that it was never designed for but have emerged over time > are going to be upset no matter what. True, as far as it goes. However, there is need for a push protocol that allows you to receive contacts from authors you don't know yet, in other words, a medium that is designed to be flexible enough to accomodate new modes of communication. It's not obvious to me that this need can be satisfied while at the same time denying spam. If it is indeed impossible, I don't see why that purpose can't continue to be served by email, while most mail (which is correspondence among acquaintances) gets redirected into authenticated channels. From nobody Thu Jun 12 17:23:11 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC2F1A03A7 for ; Thu, 12 Jun 2014 17:23:09 -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 Bn-jSwj4IJUy for ; Thu, 12 Jun 2014 17:23:07 -0700 (PDT) Received: from mail.theartfarm.com (mail.theartfarm.com [66.128.51.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21D7E1A035F for ; Thu, 12 Jun 2014 17:23:07 -0700 (PDT) Received: (qmail 21478 invoked by uid 89); 13 Jun 2014 00:23:06 -0000 Received: from unknown (HELO mail.theartfarm.com) (127.0.0.30) by mail.theartfarm.com with SMTP; 13 Jun 2014 00:23:06 -0000 Received-SPF: Pass (mail.theartfarm.com: domain of tnpi.net designates 50.159.99.59 as permitted sender) receiver=mail.theartfarm.com; identity=mailfrom; client-ip=50.159.99.59; helo=imac27.simerson.net; envelope-from= Received-SPF: None (mail.theartfarm.com: domain of imac27.simerson.net does not designate 50.159.99.59 as permitted sender) receiver=mail.theartfarm.com; identity=helo; client-ip=50.159.99.59; helo=imac27.simerson.net; envelope-from= Received: from imac27.simerson.net (c-50-159-99-59.hsd1.wa.comcast.net [50.159.99.59]) by mail.theartfarm.com (Haraka/2.5.0-toaster) with ESMTPSA id 3E4B84D7-51E6-4A43-AB48-04DC95F1D799.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=AES128-SHA verify=FAIL); Thu, 12 Jun 2014 20:23:04 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Matt Simerson In-Reply-To: <87tx7poet2.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Thu, 12 Jun 2014 17:22:55 -0700 Content-Transfer-Encoding: 7bit Message-Id: <6E7710AD-51EE-4B0A-A2AC-4239576D6683@tnpi.net> References: <44C34E47-C588-4714-B27A-4856E68D3F4D@tnpi.net> <87tx7poet2.fsf@uwakimon.sk.tsukuba.ac.jp> To: "dmarc@ietf.org" X-Mailer: Apple Mail (2.1878.2) X-Haraka-p0f: os="MacOS X 10.9 or newer (sometimes iPhone " link_type="Ethernet or modem" distance=11 total_conn=1 shared_ip=N X-Haraka-GeoIP: US, WA, Seattle, 2699km X-Haraka-GeoIP-Received: 50.159.99.59:US X-Haraka-ASN: 7922 50.128.0.0/9 X-Haraka-ASN-MONKEY: asn=7922 net=50.128.0.0/9 org=Comcast Cable Communications, Inc. date=1997-02-14 country=US X-Haraka-FCrDNS: c-50-159-99-59.hsd1.wa.comcast.net X-Spam-ASN: X-Spam-DCC: sonic.net: spamassassin.tnpi.net 1117; Body=1 Fuz1=1 Fuz2=1 X-Spam-SNF-Result: 0 (Standard White Rules) X-Spam-MessageSniffer-Scan-Result: 0 X-MessageSniffer-Rules: 0-0-0-2745-c X-MessageSniffer-Clean: Yes X-Spam-MessageSniffer-Rules: 0-0-0-2745-c X-MessageSniffer-Clean: Yes X-Spam-GBUdb-Analysis: 0, 50.159.99.59, Ugly c=0.279065 p=-1 Source Normal X-MessageSniffer-Scan-Result: 0 X-MessageSniffer-Rules: 0-0-0-2745-c X-MessageSniffer-Clean: Yes X-Haraka-Karma: connect: 5, history: 467, total_connects: 498, neighbors: -5535, pass:fcrdns.fcrdns, relaying, auth_user, fail:fcrdns.fail, neighbors, dnsbl.fail, helo.checks.fail, skip:penalty DKIM-Signature: v=1; a=rsa-sha256; bh=L5LCkt0muABnynIXq0ZvpYbRiCS6TEeIoeunyU7azYM=; c=relaxed/simple; d=tnpi.net; h=from:subject:date:message-id:to:mime-version; s=mar2013; b=z0g2ioW0fQZ1rLJXLuC2LbjoQ+8RNoIti0SaY2FDGquVFNRGJj+e66FFXmXqScdJULoabb2sy+YjgkaBHd+3ppLIgFCRSCXZSdntbhtnvpMJvRNx2XHqQZ/4udD9oIlSy+7uQ9lBt1xMqkQKtUatt5BlN0oOR8Oq4rK9cQeI+25BVHu7Q0Hepe0vSQI+ow5pMh20k436ttVI/gQMSxVVOdZpqEJQzRY0hlW7Lj6JjuABCyWDLOwOP0tqeifOcMMNFhp/XRes2bzv9ueQdJW/0nq/tsM6XFzWvuGkLCHuQs0KK+0vY4hl0jYJvo3TmMLAXaSHod4u4IATFjxND+ff4A== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/nr_znkPpAAgP3BDt2jiPWszCY6E Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 13 Jun 2014 00:23:09 -0000 On Jun 12, 2014, at 5:04 PM, Stephen J. Turnbull wrote: > Matt Simerson writes: > >> I'm not sure we need to be considerate of such behavior. If it's >> malware, reject it outright. > > Can't do that. Many viruses attach themselves to legitimate messages. > If the author is the boss, rejecting it would be, uh, bad. Wow. We live in very different worlds. Matt From nobody Thu Jun 12 17:34:40 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649AB1A03A7 for ; Thu, 12 Jun 2014 17:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 wMnhQHn1bDnl for ; Thu, 12 Jun 2014 17:34:37 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 293ED1B279D for ; Thu, 12 Jun 2014 17:34:36 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 72A0F3FA0B21; Fri, 13 Jun 2014 09:34:35 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 64BF21A32C5; Fri, 13 Jun 2014 09:34:35 +0900 (JST) From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: <20140611222207.2338.qmail@joyce.lan> <53993D20.7010901@gmail.com> <539964F1.7030007@gmail.com> <53996C80.1090303@gmail.com> <87wqclohjo.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 13 Jun 2014 09:34:35 +0900 Message-ID: <87ppidodes.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/PpqeyQVtSFD7f2Iua26HBectA0w Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 13 Jun 2014 00:34:38 -0000 Murray S. Kucherawy writes: > Interesting. So DKIM-Delegate is syntactically the same as DKIM-Signature, > but with augmented semantics? Or did you have something else in mind? That's what I had in mind. But the semantics are not merely augmented, they're conceptually different. DKIM-Delegate attests only to the authenticity of the delegate list, not to the content of the message. It occurs to me that that means that in the case of use of an explicit delegate list, the DKIM-Delegate field needs to contain a signature for itself. Not a conceptual problem AFAIK, but the creation and verification of the field get fussy. I think that in general use of an explicit delegate list should be recommended, and that where the Originator can identify lists with good reputations, it should restrict to them rather than allow random mailboxes. I'm not sure how to make precise enough to go into the I-D, though. From nobody Thu Jun 12 18:31:54 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0239C1B2814 for ; Thu, 12 Jun 2014 18:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 z92furl_qsXh for ; Thu, 12 Jun 2014 18:31:51 -0700 (PDT) Received: from smtp-4.01.com (adminr.01.com [162.209.88.187]) by ietfa.amsl.com (Postfix) with ESMTP id 1411D1B280D for ; Thu, 12 Jun 2014 18:31:51 -0700 (PDT) Received: from smtp.01.com (smtp.01.com [192.254.77.197]) by smtp-4.01.com (Postfix) with ESMTP id 22F0ACBE4A3; Thu, 12 Jun 2014 20:31:48 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id E611FA04D4; Thu, 12 Jun 2014 20:31:47 -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 rV2u4upK0Nid; Thu, 12 Jun 2014 20:31:47 -0500 (CDT) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id C340DA04E4; Thu, 12 Jun 2014 20:31:47 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id AD4CBA04D4; Thu, 12 Jun 2014 20:31:47 -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 2oLZxrxBxQHm; Thu, 12 Jun 2014 20:31:47 -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 8A8B6A04C4; Thu, 12 Jun 2014 20:31:47 -0500 (CDT) Content-Type: multipart/alternative; boundary=Apple-Mail-740BDE27-1D68-4979-B052-F27DE5C39F36 From: Franck Martin Mime-Version: 1.0 Message-Id: <6FFCAC7C-A633-40C8-BF02-F7E93A7105D5@peachymango.org> Date: Thu, 12 Jun 2014 20:31:47 -0500 (CDT) References: To: "Murray S. Kucherawy" In-Reply-To: X-Mailer: Zimbra 8.0.5_GA_5839 (MobileSync - Apple-iPad4C1/1104.201) Thread-Topic: Change the mailing list protocol, not DMARC. Thread-Index: 3gpAZEa/mscGfidhHoDciDqp9/pGnQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Hu4iFF3sdBqGmyJi-MpAaKWh2YU Cc: "dmarc@ietf.org" , Matt Simerson , Terry Zink , Elizabeth Zwicky Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 13 Jun 2014 01:31:53 -0000 --Apple-Mail-740BDE27-1D68-4979-B052-F27DE5C39F36 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Printed on recycled paper! > On Jun 12, 2014, at 21:54, "Murray S. Kucherawy" wro= te: >=20 >> On Thu, Jun 12, 2014 at 12:33 PM, Elizabeth Zwicky = wrote: >>=20 >>=20 >> On 6/12/14, 9:36 AM, "Terry Zink" wrote: >>=20 >> >> Franck Martin wrote: >> >> >> >> I found that to build the override list for mailing list, I could log >> >>DMARC rejected >> >> emails that contained a List-Id or List-Post header. Once reviewing th= e >> >>logs >> >> (once a week, or once a month), you can make an easy decision if you >> >>want to >> >> add the found IPs into your override list. >=20 > The problem there is that not all lists use the List-* fields. Well, if they don't use these headers, I don't think they would make any oth= er modification for any upcoming scheme. >=20 > You also have a period of time between which a user wants to start using a= list and the whitelisting of the list (once a week, or once a month); in be= tween, you get the problem we have now. >=20 > It also presumes the list sends at least weekly or monthly; many don't. (= For example, how many ietf.org lists exist but are largely dormant?) >=20 > -MSK >=20 Sure, this is a stop gap. A solution for today, useable today. Better scalable solution seems to emerge...= --Apple-Mail-740BDE27-1D68-4979-B052-F27DE5C39F36 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


Printed on recycled paper!

On Jun 12, 2014, at 21:54, "Murray S. Kucherawy" <superuser@gmail.com> wrote:

On Thu, Jun 12, 2014 at 12:33 PM, Elizabeth Zwicky <zwicky@yahoo-inc.com> wrote:


On 6/12/14, 9:36 AM, "Terry Zink" <tzink@exchange.microsoft.com> wrote:

>> Franck Martin wrote:
>>
>> I found that to build the override list for mailing list, I could log
>>DMARC rejected
>> emails that contained a List-Id or List-Post header. Once reviewing the
>>logs
>> (once a week, or once a month), you can make an easy decision if you
>>want to
>> add the found IPs into your override list.

The problem there is that not all lists use the List-* fields.

Well, if they don't use these headers, I don't think they would make any other modification for any upcoming scheme.


You also have a period of time between which a user wants to start using a list and the whitelisting of the list (once a week, or once a month); in between, you get the problem we have now.

It also presumes the list sends at least weekly or monthly; many don't.  (For example, how many ietf.org lists exist but are largely dormant?)

-MSK

Sure, this is a stop gap. A solution for today, useable today.

Better scalable solution seems to emerge...
--Apple-Mail-740BDE27-1D68-4979-B052-F27DE5C39F36-- From nobody Thu Jun 12 19:31:43 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480561B28A1 for ; Thu, 12 Jun 2014 19:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 5LZi39ITCl7m for ; Thu, 12 Jun 2014 19:31:38 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 02FA31B2896 for ; Thu, 12 Jun 2014 19:31:37 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id A77A43FA09FA; Fri, 13 Jun 2014 11:31:36 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 9A6151A32C5; Fri, 13 Jun 2014 11:31:36 +0900 (JST) From: "Stephen J. Turnbull" To: Franck Martin In-Reply-To: <6FFCAC7C-A633-40C8-BF02-F7E93A7105D5@peachymango.org> References: <6FFCAC7C-A633-40C8-BF02-F7E93A7105D5@peachymango.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 13 Jun 2014 11:31:36 +0900 Message-ID: <87k38lo7zr.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/5183pDLCxTB2KO_3iU6RNMfy6e0 Cc: Matt Simerson , "dmarc@ietf.org" , "Murray S. Kucherawy" , Terry Zink , Elizabeth Zwicky Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 13 Jun 2014 02:31:42 -0000 Franck Martin writes: > > The problem there is that not all lists use the List-* fields. > > Well, if they don't use these headers, I don't think they would > make any other modification for any upcoming scheme. I don't think that's a good heuristic. Most of the schemes we're talking about here are implemented in the MTA, and the MTA is often administered by somebody different from the mailing list. From nobody Thu Jun 12 21:24:32 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591C21A0552 for ; Thu, 12 Jun 2014 21:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.921 X-Spam-Level: X-Spam-Status: No, score=-16.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] 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 6sEckTDEUr5s for ; Thu, 12 Jun 2014 21:24:29 -0700 (PDT) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1919A1A04B7 for ; Thu, 12 Jun 2014 21:24:29 -0700 (PDT) Received: from GQ1-EX10-CAHT06.y.corp.yahoo.com (gq1-ex10-caht06.corp.gq1.yahoo.com [10.73.118.85]) by mrout2.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id s5D4O48D070434 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Jun 2014 21:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1402633444; bh=4nXjqtuLPkae6YJgDFlGv7EhU3ic9O64mcS4NWO/gIQ=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=J+5B5uywv3rOAeCrWx9dLwxO76HiCe/jZTTYGsoHZ7GY7wE1gm9uAHLBK0pB4qOmE B6g7qRJrVY0lvEvomcQwKRlS7WbE+y0nkcGgT+o+c10cthMasKhAkWMeGr37tNy10I d1ft5jFO1U2dIuM3MTA/xcNvOqW4BgWr+IEEKkwI= Received: from GQ1-MB01-02.y.corp.yahoo.com ([fe80::a049:b5af:9055:ada6]) by GQ1-EX10-CAHT06.y.corp.yahoo.com ([fe80::d160:3f30:42ad:8619%12]) with mapi id 14.03.0181.006; Thu, 12 Jun 2014 21:24:03 -0700 From: Elizabeth Zwicky To: "Stephen J. Turnbull" Thread-Topic: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.txt Thread-Index: AQHPhLY++mTI+c+YV0i1NvX2PrPbLZtq2dmAgAAB1YCAAY9wgIAAceGAgAAWFYCAAHpFAIAAEQqAgAAZugCAACDrgP//oMkAgAE2EoD//+VJAA== Date: Fri, 13 Jun 2014 04:24:03 +0000 Message-ID: References: <20140611222207.2338.qmail@joyce.lan> <53993D20.7010901@gmail.com> <8761k6pheq.fsf@uwakimon.sk.tsukuba.ac.jp> <87y4x1oht2.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87y4x1oht2.fsf@uwakimon.sk.tsukuba.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.72.118.47] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/hHK85Lma8cB6T8hTorXUdGNBZ0Q Cc: Dave Crocker , John R Levine , "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 13 Jun 2014 04:24:31 -0000 On 6/12/14, 3:59 PM, "Stephen J. Turnbull" wrote: >Elizabeth Zwicky writes: > > > I did not say that the levels were the same; I said the attackers > > have not gone away. They are not at high volume, but they're sure > > sitting there checking to see whether or not it's working. > >What you said, exactly, is > > But I do, in fact, have data, and that data tells me that the > attackers forging our users based on stolen addressbooks have never > stopped; we are still blocking them now. > >What they were doing was sending millions, perhaps billions, of spoofed >messages. "Never stopped" implies they are still sending millions, >perhaps billions, of spoofed messages. As does "we are still." >Do you really mean to invoke "plausible deniability"? No, I mean to say that "never stopped" does not mean "never slowed down", it means "never stopped". And we are still blocking them now, every day, possibly every minute. The volumes are for the most part down to the levels they were after this attack started being used but before the onslaught began, although they go up considerably from time to time. Your argument was that we should turn off blocking to see what would happen. That only makes sense if the attackers have actually fully gone away. If you are still blocking them every day, at any level, there's really no need to find out what will happen if you stop blocking them. You don't unlock the door when somebody is still standing outside it rattling it to see if it will open. Elizabeth zwicky@yahoo-inc.com > From nobody Thu Jun 12 23:18:41 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A87C1A036C for ; Thu, 12 Jun 2014 23:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 hgQJjD6wQskQ for ; Thu, 12 Jun 2014 23:18:37 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 764621A0361 for ; Thu, 12 Jun 2014 23:18:35 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 0F10F3FA09FA; Fri, 13 Jun 2014 15:18:35 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 015D811F0DC; Fri, 13 Jun 2014 15:18:34 +0900 (JST) From: "Stephen J. Turnbull" To: Elizabeth Zwicky In-Reply-To: References: <20140611222207.2338.qmail@joyce.lan> <53993D20.7010901@gmail.com> <8761k6pheq.fsf@uwakimon.sk.tsukuba.ac.jp> <87y4x1oht2.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 13 Jun 2014 15:18:34 +0900 Message-ID: <87fvj9nxhh.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/vrFFuiysYWOeb67xE6My_ANf6zs Cc: Dave Crocker , "Murray S. Kucherawy" , "dmarc@ietf.org" , John R Levine Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 13 Jun 2014 06:18:39 -0000 Elizabeth Zwicky writes: > No, I mean to say that "never stopped" does not mean "never slowed > down", it means "never stopped". OK. I'll remember that. In any case, now I wonder what they're really trying to do. They can check for "p=reject" without sending *any* mail. (I know, you're not in a position to speculate publicly.) > Your argument was that we should turn off blocking to see what > would happen. That only makes sense if the attackers have actually > fully gone away. Getting to that conclusion requires a lot of assumptions, all implicit. The way I see it, the attackers are doing this as a business. If they think they can make enough money in 1 minute (or however long it takes the defense to react, 2X DNS resource TTL I'd guess), they will come back in force, and soon. On the other hand, suppose they do and you shut them down in one minute. How does that look to *their clients*? AOL's graph showed more than a week of the torrent. If you cut that off in 1 minute, the fraction that gets through is 1/(7x24x3600) = 0.00000165, and presumably their revenues will be reduced in that proportion. Heck, they might even consider getting a real job! Is that argument a justification for Yahoo! experimenting? I doubt it, and of course you know a lot more than I do. But it's not the "beyond obvious" conclusion that your phrasing makes it appear. From nobody Thu Jun 12 23:47:47 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBFC1B28D8 for ; Thu, 12 Jun 2014 23:47:46 -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 x1h04BGSe48U for ; Thu, 12 Jun 2014 23:47:42 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA221B28DA for ; Thu, 12 Jun 2014 23:47:39 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id n15so296676wiw.10 for ; Thu, 12 Jun 2014 23:47:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=secondlook.com; s=google120824; h=from:content-type:content-transfer-encoding:mime-version:subject :message-id:date:references:in-reply-to:to; bh=9L2llYAqi5MsrozdRmG6Sfsc/fP5whInMwZgp9fEnmU=; b=izmhHOS6f0N/Jf2lhErxSWquRDe3r3IoxjTxa4hveWgMFwV8bOz7FiTMEuwWYyZ1PI /MG27T0ToOHIcqY27fqnyiA9NuD7MTkePv0Lr7GAZ7Zm+/z6k0OceAaMkcIk7cP/yzE/ V76UGUzT5RTTLjzCyyh8u06aGweihmxfLgkhE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :mime-version:subject:message-id:date:references:in-reply-to:to; bh=9L2llYAqi5MsrozdRmG6Sfsc/fP5whInMwZgp9fEnmU=; b=Pq4YJiTMa+hhzmJDPLpBuSPsim/D4fLnZxMZglIbVIjeCeyKTByV8IJeXj8eQLNYDF OETyEGaRewX+3FXaMJhJ6pAz+5X+khPbjfObpors+katJLt14l0dqTFk7uT2KIl63E+E av3cn1KBWbe6LMXVZt+dIrW+JcBYmBxYYIy1KjePk7ksnKzdbuodTF3MBDx+jdtAxPr7 WrStG7ukdGePg+BE7ZfcA3UAvLqFynak+zPN7mOgJCqcArfO4kMS42ZfPIjcOPJY+v/7 db28RB+JWl26X4K5gzz0tVXWQNXWU4VPoH2psefGTH+IiYwNC5B2tKGSAwm13oA9hSM7 FS9A== X-Gm-Message-State: ALoCoQkgPHeo+AYmYL+bU+xQI7Qd12EgVqfcijjDOvRBRM47eDhhIxGm7F9kfowOYRCt+1oufCTB X-Received: by 10.194.77.2 with SMTP id o2mr1271100wjw.68.1402642058172; Thu, 12 Jun 2014 23:47:38 -0700 (PDT) Received: from [172.16.0.197] ([81.108.110.48]) by mx.google.com with ESMTPSA id l5sm702161wif.22.2014.06.12.23.47.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 23:47:36 -0700 (PDT) From: John Sweet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Message-Id: <9B0EC050-6E8E-443A-B79B-083FA3710DA0@secondlook.com> Date: Fri, 13 Jun 2014 07:47:36 +0100 References: <20140611222207.2338.qmail@joyce.lan> <53993D20.7010901@gmail.com> <8761k6pheq.fsf@uwakimon.sk.tsukuba.ac.jp> <87y4x1oht2.fsf@uwakimon.sk.tsukuba.ac.jp> <87fvj9nxhh.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87fvj9nxhh.fsf@uwakimon.sk.tsukuba.ac.jp> To: "dmarc@ietf.org" X-Mailer: iPhone Mail (11D201) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/vIAhTrte0ZsloJIcgvqcjiOMjLc Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 13 Jun 2014 06:47:46 -0000 On Jun 13, 2014, at 7:18 AM, "Stephen J. Turnbull" wrot= e: > In any case, now I wonder what they're really trying to do. They can > check for "p=3Dreject" without sending *any* mail.=20 That's not an integration test. It's all automated. The answer you want is, "= Can I make money now?" This is how you get the answer. The DMARC record is o= nly part of the story, whether recipients act on it or not is just as import= ant. The source code for spamming tools isn't hard to find, or to read. There are= tutorials. It's a competitive market. Every single AS technology we've written over the years to block an exploit s= ees constant, low-traffic probing continue indefinitely. It works. > The way I see it, the attackers are doing this as a business. And not a small one.=20 J= From nobody Fri Jun 13 00:46:59 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA441A01CE for ; Fri, 13 Jun 2014 00:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 vqApjdrwxBrC for ; Fri, 13 Jun 2014 00:46:56 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id D87681A014E for ; Fri, 13 Jun 2014 00:46:55 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id CDFB73FA0B21; Fri, 13 Jun 2014 16:46:54 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id C22631A32C5; Fri, 13 Jun 2014 16:46:54 +0900 (JST) From: "Stephen J. Turnbull" To: John Sweet In-Reply-To: <9B0EC050-6E8E-443A-B79B-083FA3710DA0@secondlook.com> References: <20140611222207.2338.qmail@joyce.lan> <53993D20.7010901@gmail.com> <8761k6pheq.fsf@uwakimon.sk.tsukuba.ac.jp> <87y4x1oht2.fsf@uwakimon.sk.tsukuba.ac.jp> <87fvj9nxhh.fsf@uwakimon.sk.tsukuba.ac.jp> <9B0EC050-6E8E-443A-B79B-083FA3710DA0@secondlook.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 13 Jun 2014 16:46:54 +0900 Message-ID: <87d2ednte9.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/iEaNNcACn-g8HKdWFqlubyHZP10 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 13 Jun 2014 07:46:57 -0000 John Sweet writes: > That's not an integration test. It's all automated. The answer you > want is, "Can I make money now?" This is how you get the > answer. The DMARC record is only part of the story, whether > recipients act on it or not is just as important. Well, for Author Domains publishing "p=reject", we can certainly confuse the issue dramatically. Change the protocol to advocate "silent discard" instead of "return to sender", and then probing gives spammers no idea whether domains are discarding or delivering, and they have no data on their conversion rate for spams received. They don't want to report what they see (victims/sent, much lower than victims/(sent - rejected)), and any numbers they have to support higher estimates are for other domains or growing stale. Author Domains receive a report, they can see if their users are losing mail and let them know. Keep a copy for a few hours until the report gets back if they don't trust their users to do so. From nobody Fri Jun 13 04:55:39 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECAA1B279B; Fri, 13 Jun 2014 04:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.881 X-Spam-Level: X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, 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 pMs05pgpkE-9; Fri, 13 Jun 2014 04:55:36 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id 10CB51A024D; Fri, 13 Jun 2014 04:55:35 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id CF867CC07F; Fri, 13 Jun 2014 07:55:34 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id lv2S47jkz7xf; Fri, 13 Jun 2014 07:55:26 -0400 (EDT) Received: from new-host-3.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id EA6DFCC081; Fri, 13 Jun 2014 07:55:25 -0400 (EDT) Message-ID: <539AE6AD.9090601@meetinghouse.net> Date: Fri, 13 Jun 2014 07:55:25 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 References: <20140611170004.5D75E1AD4D@ld9781.wdf.sap.corp> <87sin9oegr.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87sin9oegr.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/PZCZmHCPir0syg35YQwiHhM5F04 Cc: "dmarc@ietf.org" , IETF Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 13 Jun 2014 11:55:37 -0000 Stephen J. Turnbull wrote: > Phillip Hallam-Baker writes: > > > My point is that mail is an old protocol and people who expect that > > it can be kept going unaltered in its original form serving all the > > purposes that it was never designed for but have emerged over time > > are going to be upset no matter what. > > True, as far as it goes. However, there is need for a push protocol > that allows you to receive contacts from authors you don't know yet, > in other words, a medium that is designed to be flexible enough to > accomodate new modes of communication. > > It's not obvious to me that this need can be satisfied while at the > same time denying spam. If it is indeed impossible, I don't see why > that purpose can't continue to be served by email, while most mail > (which is correspondence among acquaintances) gets redirected into > authenticated channels. > Just a quick reminder here: Postal mail is still going strong, after 100s of years. -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Fri Jun 13 05:46:32 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4541B2854 for ; Fri, 13 Jun 2014 05:46:30 -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 2xGek_ITGNiA for ; Fri, 13 Jun 2014 05:46:28 -0700 (PDT) Received: from winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 950A61B2851 for ; Fri, 13 Jun 2014 05:46:28 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1194; t=1402663584; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=h92vvC3eke4pju86r0/JkWOKdSA=; b=ZnX/nbtDpfne9aB8KxMB QDLYwCtbmZZQpXpxnXxyVZHW6LbnWYnBLeExTixAwZVTR3fV6FBYjGliX2br4hdI mUeIgN3UG7alv8XzrtnhOwAapdF3ra/yA88UT46+hf5/0TiELbA9/3RiNmlxLcVJ +GLnuZwCYipjbiHxk1DLIqU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 13 Jun 2014 08:46: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; Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2143704664.23705.5196; Fri, 13 Jun 2014 08:46:23 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1194; t=1402663414; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=6ZBmdqx ypSvJEelKiQiNUYsaIU9Cds/+IPoumUrxYe0=; b=BwQJZSZXuRifFGghu67exIl RE995tMKld+2zMk/Hcig9BjfnN0fIxoL+RKD36FXt/shsE3OwrrcPeBjErq8XllA bWbpNMgpWSaP3Pv2TZo44h13uam/cjNJGpjKHLpvk+fjS+4QHdDXKC0X7ByboKzm tOFR07Cz8A8lZaDytDi4= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 13 Jun 2014 08:43: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 2160061562.9.4268; Fri, 13 Jun 2014 08:43:33 -0400 Message-ID: <539AF2A3.9090200@isdg.net> Date: Fri, 13 Jun 2014 08:46:27 -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 CC: "dmarc@ietf.org" References: <8738fcrhqz.fsf@uwakimon.sk.tsukuba.ac.jp> <53974C62.9050408@isdg.net> <87tx7splbb.fsf@uwakimon.sk.tsukuba.ac.jp> <998FA07D-E6D7-41FB-A143-CE7B426E6763@tnpi.net> <87ppigowmh.fsf@uwakimon.sk.tsukuba.ac.jp> <1614404651.90556.1402574805512.JavaMail.zimbra@peachymango.org> <1a3d6beda2014edf92f936963cd1635e@BY2SR01MB608.namsdf01.sdf.exchangelabs.com> <87vbs5of57.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87vbs5of57.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: dmarc@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Iz_m5AQb2hKPytF7W87_BfuEiFY Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 13 Jun 2014 12:46:31 -0000 On 6/12/2014 7:57 PM, Stephen J. Turnbull wrote: > Sure, but as soon as the spammers adapt and start spoofing lists, you > need to check the list's signature anyway. > > And I don't think customers who sign up for a list will be happy with > losing mail for a month. > RECOMMENDATION: In principle, the LSP SHOULD do be denying any new subscriptions from restrictive domains. If the LSP decides to have exceptions and ignore the restrictive security policies, it MUST warn the user with a confirmation or welcome notification message. It SHOULD also regulate subscription attempts during the online initial subscription process, i.e, describe what will happen, have a TOS, some "red" highlighters, etc. In all cases, it MUST warn the users of any tampering will be taking place with the authorship which may have a "scratch your head" negative effect on readers of any 5322.From tampered mail. It should consider documentation verbiage that explains the reason: "This is not normal practice, and readers SHOULD NEVER expect authorships to be display with any invalid indicators. However, __{explain your reasons here for the drastic exception}__." -- HLS From nobody Fri Jun 13 10:50:07 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2071B284E; Fri, 13 Jun 2014 05:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.277 X-Spam-Level: X-Spam-Status: No, score=-3.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, 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 5UOR4UcIl2nE; Fri, 13 Jun 2014 05:18:05 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C00A1A04CA; Fri, 13 Jun 2014 05:18:05 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id l18so2615687wgh.28 for ; Fri, 13 Jun 2014 05:18:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=WDor3paAr6+TJGv7JUsvwwyiHWNDu+5cktNfEQtJ7Fo=; b=yWTZ7fekYyDNNxy/yGSjGvZvIzXYu2PoDFmQvUiJO1LNUXLGeNzeYHLMxfrjjuuB6T N2HOizvmaQZj2vAgelWdJx1SHaJE4yMEqwaSsXN/HECNekDVpn7+eJeexbdI6pfkzr0Z KnG5pr+xJR4XGvugmf/ECY50gnfXclbS/+4/I/0JJRQ1A/H0i3bj08umfzpKNy80SDK4 B3utii1O87pzVi/tK3qISBO/aXLMmSktiQkQDqTqOLdFF5iu2aysIzWivCaMkP1Tvu/h JJ91C3Vzd2yMPy599xgKMnMMrKStzdGMiFEXfrNza++eI0rdFbiqxSEqke4KiVgkYUeG GPkg== MIME-Version: 1.0 X-Received: by 10.180.105.72 with SMTP id gk8mr4338623wib.32.1402661883841; Fri, 13 Jun 2014 05:18:03 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.194.79.136 with HTTP; Fri, 13 Jun 2014 05:18:03 -0700 (PDT) In-Reply-To: <539AE6AD.9090601@meetinghouse.net> References: <20140611170004.5D75E1AD4D@ld9781.wdf.sap.corp> <87sin9oegr.fsf@uwakimon.sk.tsukuba.ac.jp> <539AE6AD.9090601@meetinghouse.net> Date: Fri, 13 Jun 2014 08:18:03 -0400 X-Google-Sender-Auth: 1phTXN4sPs0lPvSanjwbTmPCtH0 Message-ID: From: Phillip Hallam-Baker To: Miles Fidelman Content-Type: multipart/alternative; boundary=f46d0442685a53946404fbb6abed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/AIQOXODIW3Ck_NHvTeMLh1c8rec X-Mailman-Approved-At: Fri, 13 Jun 2014 10:50:05 -0700 Cc: "dmarc@ietf.org" , IETF Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 13 Jun 2014 12:18:07 -0000 --f46d0442685a53946404fbb6abed Content-Type: text/plain; charset=UTF-8 On Fri, Jun 13, 2014 at 7:55 AM, Miles Fidelman wrote: > Stephen J. Turnbull wrote: > >> Phillip Hallam-Baker writes: >> >> > My point is that mail is an old protocol and people who expect that >> > it can be kept going unaltered in its original form serving all the >> > purposes that it was never designed for but have emerged over time >> > are going to be upset no matter what. >> >> True, as far as it goes. However, there is need for a push protocol >> that allows you to receive contacts from authors you don't know yet, >> in other words, a medium that is designed to be flexible enough to >> accomodate new modes of communication. >> >> It's not obvious to me that this need can be satisfied while at the >> same time denying spam. If it is indeed impossible, I don't see why >> that purpose can't continue to be served by email, while most mail >> (which is correspondence among acquaintances) gets redirected into >> authenticated channels. >> >> Just a quick reminder here: Postal mail is still going strong, after > 100s of years. > > Only because we haven't got email security properly sorted. I can't remember the last time I received a real letter. All I get is junk mail and bills. And the bills arrive because we haven't got the standards for doing it electronically established yet. Within a decade postal mail and the telephone will have become as functionally obsolete as fax. It will take a lot longer for them to disappear, the telegram only stopped last year, about a hundred years after it was utterly obsolete. The postal service will continue of course until Bezos works out how to get his drones to work. Technology does change over time. There is a very clear demand for an open Dropbox like solution. There is a clear need for a protocol that allows email like subscriptions to blog comments without the mailbox clog that results. --f46d0442685a53946404fbb6abed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jun 13, 2014 at 7:55 AM, Miles Fidelman &= lt;mfidelma= n@meetinghouse.net> wrote:
Step= hen J. Turnbull wrote:
Phillip Hallam-Baker writes:

=C2=A0 > My point is that mail is an old protocol and people who expect = that
=C2=A0 > it can be kept going unaltered in its original form serving all= the
=C2=A0 > purposes that it was never designed for but have emerged over t= ime
=C2=A0 > are going to be upset no matter what.

True, as far as it goes. =C2=A0However, there is need for a push protocol that allows you to receive contacts from authors you don't know yet, in other words, a medium that is designed to be flexible enough to
accomodate new modes of communication.

It's not obvious to me that this need can be satisfied while at the
same time denying spam. =C2=A0If it is indeed impossible, I don't see w= hy
that purpose can't continue to be served by email, while most mail
(which is correspondence among acquaintances) gets redirected into
authenticated channels.

Just a quick reminder here: =C2=A0Postal mail is still going strong, after = 100s of years.


Only because we haven't got email security = properly sorted.

I can't remember the last time I received a real le= tter. All I get is junk mail and bills. And the bills arrive because we hav= en't got the standards for doing it electronically established yet.

Within a decade postal mail and the telephone will have= become as functionally obsolete as fax. It will take a lot longer for them= to disappear, the telegram only stopped last year, about a hundred years a= fter it was utterly obsolete.=C2=A0

The postal service will continue of course until Bezos = works out how to get his drones to work.


Technology does change over time. There is a very clear demand for an= open Dropbox like solution. There is a clear need for a protocol that allo= ws email like subscriptions to blog comments without the mailbox clog that = results.
=C2=A0
--f46d0442685a53946404fbb6abed-- From nobody Fri Jun 13 11:06:34 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB351A0201; Fri, 13 Jun 2014 11:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.881 X-Spam-Level: X-Spam-Status: No, score=-2.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, MISSING_HEADERS=1.021, 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 L_12thP06tOl; Fri, 13 Jun 2014 11:06:28 -0700 (PDT) Received: from server1.neighborhoods.net (server1.neighborhoods.net [207.154.13.48]) by ietfa.amsl.com (Postfix) with ESMTP id D20A71B293A; Fri, 13 Jun 2014 11:06:28 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by server1.neighborhoods.net (Postfix) with ESMTP id E746FCC0AD; Fri, 13 Jun 2014 14:06:27 -0400 (EDT) X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at neighborhoods.net Received: from server1.neighborhoods.net ([127.0.0.1]) by localhost (server1.neighborhoods.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KQJPbT39TDms; Fri, 13 Jun 2014 14:06:19 -0400 (EDT) Received: from new-host-3.home (pool-173-76-155-14.bstnma.fios.verizon.net [173.76.155.14]) by server1.neighborhoods.net (Postfix) with ESMTPSA id 17CF2CC08E; Fri, 13 Jun 2014 14:06:19 -0400 (EDT) Message-ID: <539B3D9A.7040104@meetinghouse.net> Date: Fri, 13 Jun 2014 14:06:18 -0400 From: Miles Fidelman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:29.0) Gecko/20100101 Firefox/29.0 SeaMonkey/2.26 MIME-Version: 1.0 References: <20140611170004.5D75E1AD4D@ld9781.wdf.sap.corp> <87sin9oegr.fsf@uwakimon.sk.tsukuba.ac.jp> <539AE6AD.9090601@meetinghouse.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/TaX_xGz_gCl7YSWnnA4aUiYDuV0 Cc: "dmarc@ietf.org" , IETF Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 13 Jun 2014 18:06:31 -0000 Phillip Hallam-Baker wrote: > > > > On Fri, Jun 13, 2014 at 7:55 AM, Miles Fidelman > > wrote: > > Stephen J. Turnbull wrote: > > Phillip Hallam-Baker writes: > > > My point is that mail is an old protocol and people who > expect that > > it can be kept going unaltered in its original form > serving all the > > purposes that it was never designed for but have emerged > over time > > are going to be upset no matter what. > > True, as far as it goes. However, there is need for a push > protocol > that allows you to receive contacts from authors you don't > know yet, > in other words, a medium that is designed to be flexible enough to > accomodate new modes of communication. > > It's not obvious to me that this need can be satisfied while > at the > same time denying spam. If it is indeed impossible, I don't > see why > that purpose can't continue to be served by email, while most mail > (which is correspondence among acquaintances) gets redirected into > authenticated channels. > > Just a quick reminder here: Postal mail is still going strong, > after 100s of years. > > > Only because we haven't got email security properly sorted. > > I can't remember the last time I received a real letter. All I get is > junk mail and bills. And the bills arrive because we haven't got the > standards for doing it electronically established yet. Bills are "real" - they're transactional. So are checks. Some of us actually do things like send proposals, signed contracts, and so forth. And, of course, packages. And the higher the value, the more likely that they'll be sent via physical mail. It ain't going away anytime soon. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra From nobody Fri Jun 13 12:13:17 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA79C1B29DC for ; Fri, 13 Jun 2014 12:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.029 X-Spam-Level: X-Spam-Status: No, score=-4.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 Oz9Ecd8kDyvk for ; Fri, 13 Jun 2014 12:13:15 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A2DE1A01FF for ; Fri, 13 Jun 2014 12:13:14 -0700 (PDT) Received: by mail-ig0-f173.google.com with SMTP id r2so889807igi.0 for ; Fri, 13 Jun 2014 12:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o2m5DbvBh1vGGHaUYNbLS9gy0ifLc2lBFCIuAjlwTwc=; b=Mh8kxvHy1lPh97Ri8Qq8xJhwJyhdiTWUTqMTabN/jG10r+PJa9N8zAdnQ72//aUM2U w9UM4OtUtja2SVPDjrV2coKMStKTqYJI+ijyR6diECcRhIyRFvbBiT1Oql0VD5AYpmCz QQwxRX2pDAIHtS3zz3RO6TDlR2zFYQX1IyJxG7w2ouUvsmkkH4p7DHUMm4jXMEYVA9XB hdY4R7XfGNxRjWTNuiY6hMUrsOaVn2C72YAYmIm487ZJmzUR1GGc4DNZDILByziAbgHe qpZlKOJkMsBXkuAUsL/+QoZf6U4zS3lQB6G0RqsiLc73mziprMDHJC2jpgfCZmOrxceM IcfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=o2m5DbvBh1vGGHaUYNbLS9gy0ifLc2lBFCIuAjlwTwc=; b=caM42pC/YbpLaVxRXVzUsnq93iih5uiT17vNB8FhV6zx6g3eXNg9ncsfPePrA4Qkd0 Ed9Vh1tV3/+B+bPyN5pmPXvd/jiM6KUtWXBC2EFHAgl393n/+o29zaQ2kE+XlFczAWnl x5qEAXbTIDjzZao3bebd1bTVJDGPMr22/P8umpYw65tBR1cEM7MU5Jksw6BNiLQhOEug NtBsQPeTnLupLlD9qcNTAxiqR+NXcJuYkO/gwQz1/lGVml09XRTfK5+pSpQsJOOjmX1X GQdnI6WdXt4Jy9BQEe3lrKU4c7qYAI5JaJ0sM+ouFkUkBkNomBtTKUfw++hVx5JlfKUD +9XQ== X-Gm-Message-State: ALoCoQmAhoyqUaqss09td8qDM6o59I4ncUlpMJtBOUNhQIiIZ1HPq7CPyycDX8OwE+w/KGfXDPua MIME-Version: 1.0 X-Received: by 10.42.212.18 with SMTP id gq18mr5428000icb.48.1402686794412; Fri, 13 Jun 2014 12:13:14 -0700 (PDT) Received: by 10.64.136.202 with HTTP; Fri, 13 Jun 2014 12:13:14 -0700 (PDT) In-Reply-To: <539B3D9A.7040104@meetinghouse.net> References: <20140611170004.5D75E1AD4D@ld9781.wdf.sap.corp> <87sin9oegr.fsf@uwakimon.sk.tsukuba.ac.jp> <539AE6AD.9090601@meetinghouse.net> <539B3D9A.7040104@meetinghouse.net> Date: Fri, 13 Jun 2014 12:13:14 -0700 Message-ID: From: Brandon Long To: Miles Fidelman Content-Type: multipart/alternative; boundary=20cf303e9d821cea1804fbbc7812 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/lxmQNh_DP0iud4Y7WKpd_4KQB5U Cc: "dmarc@ietf.org" , IETF Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 13 Jun 2014 19:13:16 -0000 --20cf303e9d821cea1804fbbc7812 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 13, 2014 at 11:06 AM, Miles Fidelman wrote: > Phillip Hallam-Baker wrote: > > >> >> >> On Fri, Jun 13, 2014 at 7:55 AM, Miles Fidelman < >> mfidelman@meetinghouse.net > wrote: >> >> Stephen J. Turnbull wrote: >> >> Phillip Hallam-Baker writes: >> >> > My point is that mail is an old protocol and people who >> expect that >> > it can be kept going unaltered in its original form >> serving all the >> > purposes that it was never designed for but have emerged >> over time >> > are going to be upset no matter what. >> >> True, as far as it goes. However, there is need for a push >> protocol >> that allows you to receive contacts from authors you don't >> know yet, >> in other words, a medium that is designed to be flexible enough to >> accomodate new modes of communication. >> >> It's not obvious to me that this need can be satisfied while >> at the >> same time denying spam. If it is indeed impossible, I don't >> see why >> that purpose can't continue to be served by email, while most mail >> (which is correspondence among acquaintances) gets redirected into >> authenticated channels. >> >> Just a quick reminder here: Postal mail is still going strong, >> after 100s of years. >> >> >> Only because we haven't got email security properly sorted. >> >> I can't remember the last time I received a real letter. All I get is >> junk mail and bills. And the bills arrive because we haven't got the >> standards for doing it electronically established yet. >> > > Bills are "real" - they're transactional. So are checks. Some of us > actually do things like send proposals, signed contracts, and so forth. > And, of course, packages. And the higher the value, the more likely that > they'll be sent via physical mail. It ain't going away anytime soon. If I had spam filtering on postal mail that was as good as I've got on email, regular postal mail would already be gone. That isn't to say that high value postal mail at FedEx/UPS/etc prices would be gone, just that current first class mail and daily deliveries would be. In the US, the USPS is already on rough ground (which isn't entirely due to failing rates of mail, granted), so "going strong" would not be what I'd use. Holding out for another 100 years in some form... maybe. Brandon --20cf303e9d821cea1804fbbc7812 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Fri, Jun 13, 2014 at 11:06 AM, Miles Fidelman = <mfidelm= an@meetinghouse.net> wrote:
Phillip Hallam-Baker wrote:




On Fri, Jun 13, 2014 at 7:55 AM, Miles Fidelman <mfidelman@meetinghouse.net <= ;mailto:mfi= delman@meetinghouse.net>> wrote:

=C2=A0 =C2=A0 Stephen J. Turnbull wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phillip Hallam-Baker writes:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > My point is that mail is an old pro= tocol and people who
=C2=A0 =C2=A0 =C2=A0 =C2=A0 expect that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > it can be kept going unaltered in i= ts original form
=C2=A0 =C2=A0 =C2=A0 =C2=A0 serving all the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > purposes that it was never designed= for but have emerged
=C2=A0 =C2=A0 =C2=A0 =C2=A0 over time
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > are going to be upset no matter wha= t.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 True, as far as it goes. =C2=A0However, there i= s need for a push
=C2=A0 =C2=A0 =C2=A0 =C2=A0 protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 that allows you to receive contacts from author= s you don't
=C2=A0 =C2=A0 =C2=A0 =C2=A0 know yet,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 in other words, a medium that is designed to be= flexible enough to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 accomodate new modes of communication.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 It's not obvious to me that this need can b= e satisfied while
=C2=A0 =C2=A0 =C2=A0 =C2=A0 at the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 same time denying spam. =C2=A0If it is indeed i= mpossible, I don't
=C2=A0 =C2=A0 =C2=A0 =C2=A0 see why
=C2=A0 =C2=A0 =C2=A0 =C2=A0 that purpose can't continue to be served by= email, while most mail
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (which is correspondence among acquaintances) g= ets redirected into
=C2=A0 =C2=A0 =C2=A0 =C2=A0 authenticated channels.

=C2=A0 =C2=A0 Just a quick reminder here: =C2=A0Postal mail is still going = strong,
=C2=A0 =C2=A0 after 100s of years.


Only because we haven't got email security properly sorted.

I can't remember the last time I received a real letter. All I get is j= unk mail and bills. And the bills arrive because we haven't got the sta= ndards for doing it electronically established yet.

Bills are "real" - they're transactional. =C2=A0So are checks= . =C2=A0Some of us actually do things like send proposals, signed contracts= , and so forth. =C2=A0And, of course, packages. =C2=A0And the higher the va= lue, the more likely that they'll be sent via physical mail. =C2=A0It a= in't going away anytime soon.

If I had spam filtering on postal mail that was as good= as I've got on email, regular postal mail would already be gone.
=

That isn't to say that high value postal mail at Fe= dEx/UPS/etc prices would be gone, just that current first class mail and da= ily deliveries would be.

In the US, the USPS is already on rough ground (which i= sn't entirely due to failing rates of mail, granted), so "going st= rong" would not be what I'd use. =C2=A0Holding out for another 100= years in some form... maybe.

Brandon=C2=A0

--20cf303e9d821cea1804fbbc7812-- From nobody Fri Jun 13 18:38:46 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFA61B2AEA for ; Fri, 13 Jun 2014 18:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.601 X-Spam-Level: X-Spam-Status: No, score=-100.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 m_TEGvJR1khq for ; Fri, 13 Jun 2014 18:38:41 -0700 (PDT) Received: from groups.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id C29311B2AE3 for ; Fri, 13 Jun 2014 18:38:40 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1962; t=1402709909; h=Received:Received: Message-Id:From:Subject:Date:To:Organization:List-ID; bh=n2lvLc5 2SJl6Q93ZibI3b8E/OkY=; b=JMk4kqN0uFITQBPLnkX0k8DpwGCAlLKC9pu4Tsz bzttlmRkCKAhVNq/czMu0GDC3gOQfTwDqsQEd12BRiTeuWg5Qp72b9G5aFxLaMCp voZxONVq3OokOkBMfnrGAJ42OqC/HNuPuYTe/1SMCF9keCrtl4rA5/ob0A05a8b0 uwpI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 13 Jun 2014 21:38:29 -0400 Received: from [192.168.1.67] (99-121-4-27.lightspeed.miamfl.sbcglobal.net [99.121.4.27]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2190029754.23705.3848; Fri, 13 Jun 2014 21:38:29 -0400 References: <1402212310.40987.YahooMailNeo@web164605.mail.gq1.yahoo.com> <5394CB79.3010908@isdg.net> <1402263120639.86327@exchange.microsoft.com> Mime-Version: 1.0 (1.0) In-Reply-To: <1402263120639.86327@exchange.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2B544D1A-9D50-4C41-B6E0-B815D95CC6DE@isdg.net> X-Mailer: iPad Mail (11B651) From: Hector Santos Date: Fri, 13 Jun 2014 21:38:28 -0400 To: Terry Zink Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/41MBHmBd5rr_cmBRyrCjw8ynn1c Cc: Vlatko Salaj , "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: Re: [dmarc-ietf] advice to MTAs 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, 14 Jun 2014 01:38:44 -0000 On Jun 8, 2014, at 5:31 PM, Terry Zink wrote:= >> Hector Santos wrote: >>=20 >>> It is mentioned in Section 6, but the mention there doesn't even say >>> that it's the DMARC result that's supposed to be recorded. That bit >>> at least needs to be fixed. >>>=20 >>> Anyone else have a comment? >=20 >> Only that it goes back to the similar SPF thing regarding dynamic >> rejections. So to be consistent for DMARC: >>=20 >> DMARC POLICY A-R Trace Guideline >>=20 >> REJECT --> N/A see 55x reply codes. >> QUARANTINE --> SHOULD record with A-R. >> NONE --> SHOULD record with A-R. >=20 > In our implementation, we also plan to indicate the following scenarios: >=20 > 1. DMARC fails but the pct value indicated not to take action (i.e., pct=3D= 80, this message failed but is in the 20% of cases not to take action) at wh= ich point we would stamp "dmarc=3Dfail action=3Dpct.quarantine" >=20 Sounds reasonable. Haven't implemented DMARC yet, but I got the fast read u= nderstanding "pct" was for reporting triggers. It is not factored in when a r= eject is triggered?=20 > 2. DMARC fails and the action is reject but we overrode the requested acti= on (i.e., for a mailing list) at which point we would stamp "dmarc=3Dfail ac= tion=3Do.reject" Is "action" is a registered tag? > Others may feel that this is not necessary (of think this syntax is not cl= ear enough) but we do it for troubleshooting -- "This domain's DMARC action i= s reject. Why is it in my junk folder?" For ADSP, the same level of diagnostic consideration was done because we wer= e still in recording mode, not yet enabling honoring the discard policy yet.= DMARC changes all this now. FedEx.com and other high value domains use both= ADSP discard and now DMARC rejects, so when DMARC is added, both will have a= common handling engine. -- Hector Santos http://www.santronics.com From nobody Fri Jun 13 19:36:06 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956461B2866 for ; Fri, 13 Jun 2014 19:36:03 -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 uLEUyDfnFlvL for ; Fri, 13 Jun 2014 19:36:01 -0700 (PDT) Received: from groups.winserver.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id ABDD71B2819 for ; Fri, 13 Jun 2014 19:36:00 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=567; t=1402713350; h=Received:Received: Subject:From:Message-Id:Date:To:Organization:List-ID; bh=CQ45U9l Fmof7ncRJ49V0YtT2xVI=; b=AjPAL9OXO6AVpjmiUC6WHxRE6kXcV/lFQSQIOJ0 ewYeB4YXCQpjWd35fBCf0zkkX3DW069Gen2IKz0Qro7DSAq2/wc9hNFxZZv8wdjc 2jFHtR9AKc9IVAY743AYofUqBH065NzwDa/FY3xSjWj614cTBcmVyN+LYLaXbHZw TFCA= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 13 Jun 2014 22:35:50 -0400 Received: from [192.168.1.67] (99-121-4-27.lightspeed.miamfl.sbcglobal.net [99.121.4.27]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2193469654.23705.3708; Fri, 13 Jun 2014 22:35:49 -0400 References: <1402212310.40987.YahooMailNeo@web164605.mail.gq1.yahoo.com> <597dc384-7907-4a14-acaa-cd527650758b@email.android.com> <4588977.sc8XK00kAI@scott-latitude-e6320> From: Hector Santos Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (11B651) In-Reply-To: <4588977.sc8XK00kAI@scott-latitude-e6320> Message-Id: Date: Fri, 13 Jun 2014 22:35:48 -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: http://mailarchive.ietf.org/arch/msg/dmarc/jhWhSteIFzkGb6k7GZgS6_pHyM8 Subject: Re: [dmarc-ietf] advice to MTAs 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, 14 Jun 2014 02:36:03 -0000 > On Jun 9, 2014, at 11:17 PM, Scott Kitterman wrote:= >=20 > Perhaps I'm oversimplifying, but it has seemed self-evident that you need a= =20 > single identifier that is displayed to the end user and 5322.=46rom is the= only=20 > identifier that even comes close to being the right one. And that comes from two key concepts, it was historically never expected to b= e altered (for any communication system past and present) and its the minimu= m default identity for replying.=20 -- Hector Santos http://www.santronics.com From nobody Fri Jun 13 21:27:51 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531171A0418 for ; Fri, 13 Jun 2014 17:02:18 -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, LOTS_OF_MONEY=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 m5WLwzYr56tT for ; Fri, 13 Jun 2014 17:02:17 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E76F1B29C0 for ; Fri, 13 Jun 2014 17:02:17 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id x19so3107448ier.2 for ; Fri, 13 Jun 2014 17:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HKWIP61bonfWmUhLRG1Rn/8MtARy0rY+nJ7+z7f85xg=; b=kvYBO7Aey5INDKLmMobFLZ0e5hKvtaCq7elYGUXf26IwrhAp52m7veMusKINHzcOvm i2vujEvEH1KNJsXCAcaYAl4/iqcPYrkPCAD1YkU+8u8xWFikZCN68tA3zpG45zsMRF2O J9Ijftt1GDEeeWf/YTNfMDOkKgmS+HfIDoZcY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=HKWIP61bonfWmUhLRG1Rn/8MtARy0rY+nJ7+z7f85xg=; b=BeUZfFl0iHVZ65/Zs8pG1kusuNjBy5mgoGusn7se9Cna/dAgr1cr1ifhAHj9Cf5KTa hcVd5i1iJPTx+GRi/qF4e6nWbE9G5ht59Y8o1O9FJM3iY+FJD9oYN0plzUhROACWKRZB zFtPs2Rk63E2dYyMG+uUeu5drWFKiwRXCO3dc4kAr+L72oyp+ZVWIsxt6Cy7iWBK2Ls6 dWYzxRd8GSYsZOm3nq+iRvomo+va2zaZUz10zMvyo20oT/l5WABbbKHavBuVtWAPaYoi zlpP0FGU4XC7yF/0y3eRag1djIFB9WnoPGwrJ2nj/DmKEwQAlJUQdzD4yiFAG9TroRry z9ug== X-Gm-Message-State: ALoCoQmgVu2XMgLUjuuDwgDjvGuYci+Qvh63wgGCxRas7AZo3Tk/KqGe4zaaFAp30wpCSR/WFLSk X-Received: by 10.42.68.204 with SMTP id y12mr6678812ici.16.1402704136661; Fri, 13 Jun 2014 17:02:16 -0700 (PDT) Received: from [199.212.90.59] (24-52-234-221.cable.teksavvy.com. [24.52.234.221]) by mx.google.com with ESMTPSA id m1sm6886681ige.22.2014.06.13.17.02.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Jun 2014 17:02:15 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Joe Abley In-Reply-To: <539AE6AD.9090601@meetinghouse.net> Date: Fri, 13 Jun 2014 20:02:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1747C4BD-F9E3-4D91-981D-27F38F86E672@hopcount.ca> References: <20140611170004.5D75E1AD4D@ld9781.wdf.sap.corp> <87sin9oegr.fsf@uwakimon.sk.tsukuba.ac.jp> <539AE6AD.9090601@meetinghouse.net> To: Miles Fidelman X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/16gncS_xZ-bbC-b7CVgzBH_MQk4 X-Mailman-Approved-At: Fri, 13 Jun 2014 21:27:47 -0700 Cc: "dmarc@ietf.org" , IETF Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 14 Jun 2014 00:02:18 -0000 On 13 Jun 2014, at 7:55, Miles Fidelman = wrote: > Just a quick reminder here: Postal mail is still going strong, after = 100s of years. I don't know what it's like where you live, but here the only thing that = is keeping the post office afloat is being paid by advertisers to = deliver unsolicited junk. "Canada Post has hiked postal rates for regular mail and plans to cut up = to 8,000 jobs as it phases out urban mail delivery over the next five = years -- all in a bid to reverse the tide of red ink at the money-losing = Crown corporation." "The Crown Corporation predicted this year that Canada Post and its = subsidiaries would lose $274 million before tax in 2014." "Still going strong" is not a phrase that resonates with me. Joe From nobody Fri Jun 13 21:43:38 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA5D1B2B4B for ; Fri, 13 Jun 2014 21:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOTS_OF_MONEY=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 TNhoEdiJGy8R for ; Fri, 13 Jun 2014 21:43:35 -0700 (PDT) Received: from mail.theartfarm.com (mail.theartfarm.com [66.128.51.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6C231A0342 for ; Fri, 13 Jun 2014 21:43:34 -0700 (PDT) Received: (qmail 23394 invoked by uid 89); 14 Jun 2014 04:43:34 -0000 Received: from unknown (HELO mail.theartfarm.com) (127.0.0.30) by mail.theartfarm.com with SMTP; 14 Jun 2014 04:43:34 -0000 Received-SPF: Pass (mail.theartfarm.com: domain of tnpi.net designates 50.159.99.59 as permitted sender) receiver=mail.theartfarm.com; identity=mailfrom; client-ip=50.159.99.59; helo=[10.0.1.141]; envelope-from= Received: from [10.0.1.141] (c-50-159-99-59.hsd1.wa.comcast.net [50.159.99.59]) by mail.theartfarm.com (Haraka/2.5.0-toaster) with ESMTPSA id 630DD6B5-7E44-4A17-83C2-54F6AFE73BAE.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=AES128-SHA verify=FAIL); Sat, 14 Jun 2014 00:43:32 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Matt Simerson In-Reply-To: <1747C4BD-F9E3-4D91-981D-27F38F86E672@hopcount.ca> Date: Fri, 13 Jun 2014 21:43:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1D4BB02D-5E9C-4400-B748-D61428A58048@tnpi.net> References: <20140611170004.5D75E1AD4D@ld9781.wdf.sap.corp> <87sin9oegr.fsf@uwakimon.sk.tsukuba.ac.jp> <539AE6AD.9090601@meetinghouse.net> <1747C4BD-F9E3-4D91-981D-27F38F86E672@hopcount.ca> To: "dmarc@ietf.org" X-Mailer: Apple Mail (2.1878.2) X-Haraka-p0f: os="MacOS X 10.9 or newer (sometimes iPhone " link_type="Ethernet or modem" distance=11 total_conn=4 shared_ip=N X-Haraka-GeoIP: US, WA, Seattle, 2699km X-Haraka-GeoIP-Received: X-Haraka-ASN: 7922 50.128.0.0/9 X-Haraka-ASN-MONKEY: asn=7922 net=50.128.0.0/9 org=Comcast Cable Communications, Inc. date=1997-02-14 country=US X-Haraka-FCrDNS: c-50-159-99-59.hsd1.wa.comcast.net X-Spam-ASN: X-Spam-DCC: sonic.net: spamassassin.tnpi.net 1117; Body=1 Fuz1=1 Fuz2=1 X-Spam-SNF-Result: 0 (Standard White Rules) X-Spam-MessageSniffer-Scan-Result: 0 X-MessageSniffer-Rules: 0-0-0-4605-c X-MessageSniffer-Clean: Yes X-Spam-MessageSniffer-Rules: 0-0-0-4605-c X-MessageSniffer-Clean: Yes X-Spam-GBUdb-Analysis: 0, 10.0.1.141, Ugly c=0.226425 p=-0.777778 Source Normal X-MessageSniffer-Scan-Result: 0 X-MessageSniffer-Rules: 0-0-0-4605-c X-MessageSniffer-Clean: Yes X-Haraka-Karma: connect: 4, history: 476, total_connects: 508, neighbors: -5549, pass:fcrdns.fcrdns, relaying, auth_user, fail:fcrdns.fail, neighbors, dnsbl.fail, helo.checks.fail, helo.checks.fail, skip:penalty DKIM-Signature: v=1; a=rsa-sha256; bh=1Sup+7fZCRA2R2w4OBrBceH3ebHDRlFBpmyqGF2WhTI=; c=relaxed/simple; d=tnpi.net; h=from:subject:date:message-id:to:mime-version; s=mar2013; b=lYf282HiXm911l7yMHuUcjGPQXq9P3WpmrWqL6B1OCPA4QNsWVYxaZPyrYkQbPxP42feZZOW7KzZVXWAzu3Dmwh0CEDQ9voQCQN26MsIIMuCBC7TzZx2DOXo8VZY8nAgPmk5Z+8NMfqlYLylHBhV9DdTwZm0HVirWr3kPFEcp+6jauoT2F29X2roOdjT6jDEk9sAa/BLht70Gct7MfNw0AcexARuarYtje8S2Y2QC2WnLyM/ME5DP5JpHv9+dy6WoK89EbPmeF9pbYmckBe/do4qCXTDOMB15FIFoT9hCw9a0cqdmLXyN+mZAhtxg3HWobT41EY3p8wGp8KN70LWew== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/g90-ag3Orly_A4jaZfwuGU9hV3A Subject: Re: [dmarc-ietf] Change the mailing list protocol, not DMARC. 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, 14 Jun 2014 04:43:36 -0000 On Jun 13, 2014, at 5:02 PM, Joe Abley wrote: > On 13 Jun 2014, at 7:55, Miles Fidelman = wrote: >=20 >> Just a quick reminder here: Postal mail is still going strong, after = 100s of years. >=20 > I don't know what it's like where you live, but here the only thing = that is keeping the post office afloat is being paid by advertisers to = deliver unsolicited junk. >=20 > "Canada Post has hiked postal rates for regular mail and plans to cut = up to 8,000 jobs as it phases out urban mail delivery over the next five = years -- all in a bid to reverse the tide of red ink at the money-losing = Crown corporation." >=20 > "The Crown Corporation predicted this year that Canada Post and its = subsidiaries would lose $274 million before tax in 2014." >=20 > "Still going strong" is not a phrase that resonates with me. >=20 > Joe Canada Post lost $274 million EBITA? Let us Yanks show you how it's = done: http://about.usps.com/news/national-releases/2014/pr14_031.htm WASHINGTON =97 The U.S. Postal Service ended the second quarter = of its 2014 fiscal year (Jan. 1, 2014 =96 March 31, 2014) with a net = loss of $1.9 billion. This marks the 20th of the last 22 quarters it has = sustained a loss. =95 First-Class Mail Volume Declines by 4.1 percent =95 Approximately $64 Billion in Liabilities Exceed Assets by = $42 Billion /end tongue in cheek Matt= From nobody Sat Jun 14 02:25:37 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B2E1B2C01 for ; Sat, 14 Jun 2014 02:25:35 -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 AFsPaVtL71rS for ; Sat, 14 Jun 2014 02:25:34 -0700 (PDT) Received: from rajesh.ohai.su (rajesh.ohai.su [IPv6:2a01:4f8:150:3ffd:5054:ff:fef6:2ee1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 357311B2C02 for ; Sat, 14 Jun 2014 02:25:33 -0700 (PDT) Received: from s4459.dyn.hrz.tu-darmstadt.de (s4459.dyn.hrz.tu-darmstadt.de [130.83.217.203]) (Authenticated sender: listen@prauscher.de) by rajesh.ohai.su (Postfix) with ESMTPSA id 1EE091FF7A for ; Sat, 14 Jun 2014 09:25:30 +0000 (UTC) Message-ID: <1402737923.29198.7.camel@ariadne.ohai.su> From: Patrick Rauscher To: dmarc@ietf.org Date: Sat, 14 Jun 2014 11:25:23 +0200 In-Reply-To: References: <1402212310.40987.YahooMailNeo@web164605.mail.gq1.yahoo.com> <597dc384-7907-4a14-acaa-cd527650758b@email.android.com> <4588977.sc8XK00kAI@scott-latitude-e6320> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ucv7pzCNo8YWJ4hjW0d6-OymDvs Subject: Re: [dmarc-ietf] advice to MTAs 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, 14 Jun 2014 09:25:36 -0000 Hey, On Fri, 2014-06-13 at 22:35 -0400, Hector Santos wrote: > > Perhaps I'm oversimplifying, but it has seemed self-evident that you need a > > single identifier that is displayed to the end user and 5322.From is the only > > identifier that even comes close to being the right one. (I don't have Scotts original mail here, so I reply to this. Sorry!) Imho 5322.Sender is relevant too. Yes, MUAs usually don't respect this Header (and it's used not very often :-( ), but most don't show DKIM-Validation (which could be included together). Also this allows Mailinglists to interact with DMARC/DKIM correctly (hint hint) Greetings, prauscher From nobody Sat Jun 14 10:13:07 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038CC1A0151 for ; Sat, 14 Jun 2014 10:13:06 -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, MIME_QP_LONG_LINE=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 V0d63vXnMXzp for ; Sat, 14 Jun 2014 10:13:03 -0700 (PDT) Received: from secure.winserver.com (dkim.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id E552C1A0147 for ; Sat, 14 Jun 2014 10:13:02 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3821; t=1402765979; h=Received:Received: Message-Id:From:Subject:Date:To:Organization:List-ID; bh=7ujVtaQ zFujAuIvzO98cp5aVBqI=; b=r4a44ikINXQ8NCN6kvfN9ksodzfgfBXy5p5aio+ t79BIQYekRwN/1R8AYmews6ICnv34KQTCpBVQUp2fyJGM4iOLyscPliAPycHcBGX 7HL0pxKZiRCx3WW5VP+EoayoTusIFihve1eBBFZQV44h3y49mZSEXHeCDXSK2R8g by5g= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 14 Jun 2014 13:12:59 -0400 Received: from [192.168.1.221] (99-72-160-212.lightspeed.miamfl.sbcglobal.net [99.72.160.212]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2246097840.27610.2592; Sat, 14 Jun 2014 13:12:58 -0400 References: <1402212310.40987.YahooMailNeo@web164605.mail.gq1.yahoo.com> <597dc384-7907-4a14-acaa-cd527650758b@email.android.com> <4588977.sc8XK00kAI@scott-latitude-e6320> <1402737923.29198.7.camel@ariadne.ohai.su> Mime-Version: 1.0 (1.0) In-Reply-To: <1402737923.29198.7.camel@ariadne.ohai.su> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <05ED9305-0F15-45E4-9FC7-134FD917B515@isdg.net> X-Mailer: iPad Mail (11B651) From: Hector Santos Date: Sat, 14 Jun 2014 13:12:59 -0400 To: Patrick Rauscher Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/dj5PwkUDc8696Gf_bys6xuovx2Y Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] advice to MTAs 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, 14 Jun 2014 17:13:06 -0000 > On Jun 14, 2014, at 5:25 AM, Patrick Rauscher wrote:= >=20 > Hey, >=20 > On Fri, 2014-06-13 at 22:35 -0400, Hector Santos wrote: >>> Perhaps I'm oversimplifying, but it has seemed self-evident that you nee= d a=20 >>> single identifier that is displayed to the end user and 5322.=46rom is t= he only=20 >>> identifier that even comes close to being the right one. >=20 > (I don't have Scotts original mail here, so I reply to this. Sorry!) > Imho 5322.Sender is relevant too. Yes, MUAs usually don't respect this > Header (and it's used not very often :-( ), but most don't show > DKIM-Validation (which could be included together). Some do have new display logic for the sender. However, unless you (the bac= kend) have control of the mail reading process, both online and offline/offl= oaded, in general you don't, we can only be pretty confident of what would b= e displayed with the four basic messaging fields common in all communication= s as a common denominator: =20 o Date o From o To o Subject In other words, if you were to start tomorrow to write a mail reader/writer,= you must begin with the above for the minimum display rendering. Remember,= not everything is or requires a mail network. It can be an online forum whi= ch many systems are heading back to (or just starting with successfully beca= use they are not bogged down like many older established systems are where c= hange is not always a luxury). You really have two sets of headers: the above messaging headers and network= ing headers. Networking control lines, as old FidoNet folks called them, o= nly came into play when you connected a heterogenous network of hosting node= s. For internet mail format networking, the Sender, Reply-to, Return-Path, m= ost of the trace lines, did not apply until you had a network. When you gate= d a network, generally, they would be use just to make sure you can respond= back and they would be hidden, transparent to the user. Sometimes the user m= ay only interested in them to go a different route, reply directly or have i= t travel via some path that was either less costly or more timely, i.e., net= work routing methods. Subject is not always filled, but is expected to be part of the message. So= me MUAs enforce it, others don't. In fact, RFC 822 only required Date, =46rom= and To. RFC 2822/5322 relaxed it to only Date and From. Date can always b= e filled as the local or system post time. So at a minimum, via RFC 821 532= 1, if a client doesn't enter the headers during, depending on how strict the= deployment is set at, it doesn't need them when receiving the DATA payload a= nd can recreate the 822/5322 headers from the SMTP envelope fields: 5322.=46rom <=3D=3D=3D 5321.MAIL FROM 5322.Date <=3D=3D=3D system timestamp 5322.To <=3D=3D=3D 5321.RCPT TO And you really don't need to fill in the 5322.To because for local direct ma= il pointers, indexes, this is done using a different control/meta method/fil= e/line from the 5321.RCPT TO lines. You don't rely on the 5322.To or cc to m= ake direct mail references. > Also this allows Mailinglists to interact with DMARC/DKIM correctly > (hint hint) Operators will have philosophical differences with developers. Always have. I= n my product development experience, it is good to get practical functional o= perational guidelines established and bad when sound technical engineering p= rogress is impeded. The ML needs to fit in with the mail network like every= thing does with the few known long time acceptable exceptions. DKIM did high= light the body integrity issues, not the 5322 headers. We don't want to add a= broken 5322.=46rom to the security exception list. -- Hector Santos http://www.santronics.com From nobody Sat Jun 14 11:41:09 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3D01B2957 for ; Sat, 14 Jun 2014 11:41:07 -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 rVBAIYvgu9g6 for ; Sat, 14 Jun 2014 11:41: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 55B4B1A058E for ; Sat, 14 Jun 2014 11:41:06 -0700 (PDT) Received: (qmail 95562 invoked from network); 14 Jun 2014 18:41:04 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 14 Jun 2014 18:41:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=da7.539c9740.k1406; i=johnl@user.iecc.com; bh=5QlwYAUfLGfowHSZJ3m4wfx1X0r81AYJX4Uhzjd3h0U=; b=ew27GDHCeeY+s9XgSS6UL8FQgO1DRr4rtfFnHw23hpllgktxCZPDzOBaZZ1y49FL06mrKeice8Py63TyE4I3YhMzU/c3kA+qiZrOc/ATRhgRpCIJcO0wuL5eKbJqJ6rGNsspNXnZCnubsWn+8QNaxO8PUCoZXL3E+VqOM8UVeuf4cGZHfTd20BIiYuN5Enk3IKLj6cvMyNiu9gLtqfjayhUXaIbtG++qtqorvfPweRKQPFPx1dZuLOCvrjv/QzF0 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=da7.539c9740.k1406; olt=johnl@user.iecc.com; bh=5QlwYAUfLGfowHSZJ3m4wfx1X0r81AYJX4Uhzjd3h0U=; b=awhb5gQr3s3X6wdTjq1vcyqxke4Sx8M8ARdrda/8bVFmJKLLijs1X0xvC89v4XbVH1MzYsUzZSy/2jtiE2w5FVbER/OD2HG+8F4cuN8H/ss2UbJVSi99pWX1P4nejqbi1VyiK0istWf85ZWZLaPINNLBpZsd25MI4xFWl70eifUj9UQlgEYqXevMfhj6fQM9HIv8YdP+3Ue1Nmv6VEm+EnxgPVEavM/3ifHXqR+RnDAEmBhtTz6SYupfnfUn2Bde Date: 14 Jun 2014 18:40:40 -0000 Message-ID: <20140614184040.3494.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <87tx7poet2.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: http://mailarchive.ietf.org/arch/msg/dmarc/Xaf1m5cXyHZQ8VBSBLPg15y_3Rk Cc: stephen@xemacs.org Subject: Re: [dmarc-ietf] malware cleaning, was Change the mailing list protocol, not DMARC. 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, 14 Jun 2014 18:41:07 -0000 > > I'm not sure we need to be considerate of such behavior. If it's > > malware, reject it outright. > >Can't do that. Many viruses attach themselves to legitimate messages. >If the author is the boss, rejecting it would be, uh, bad. I don't think I've seen malware attached to a real message in the past decade. When's the last one you got? On the other hand, there are certainly plenty of mailing lists that strip out attachments, which poses the same problem. R's, John From nobody Sat Jun 14 11:46:37 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41441B27CA for ; Sat, 14 Jun 2014 11:46:35 -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 am1H_RflX5lQ for ; Sat, 14 Jun 2014 11:46:35 -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 F3AEB1A0223 for ; Sat, 14 Jun 2014 11:46:34 -0700 (PDT) Received: (qmail 96216 invoked from network); 14 Jun 2014 18:46:34 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 14 Jun 2014 18:46:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=dcb.539c9889.k1406; i=johnl@user.iecc.com; bh=quqy1mpyfHw7AIU1cBZ2RbTtrkB+I2k1eqSgMsk1iNE=; b=MwX7b+KX5cNwcT3lwhqU/4NbBDkjZsKUxOpPDTfPc6EuZ353wb6CMyBDpCBCa5xEWwNpy8AeLt5WgUS8QCrg/ulywKr/SOFfrmQTBk4qePLc8vxFEu4RCUB9X19AhpwCG6auZooCcG1qtL4SOccnNxowa5ETPs1xqxV8ziLuHhpgc+vGd+pc91BBS7HPT0FR/zG59m8eN4VoiEss04/u81NVD4nqBi/naqQ8OCbkNOORpbjsCkamRWsyrxOuYPuV DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=dcb.539c9889.k1406; olt=johnl@user.iecc.com; bh=quqy1mpyfHw7AIU1cBZ2RbTtrkB+I2k1eqSgMsk1iNE=; b=HTkdqL/ySUhp35kC9SIvhk39rfR9Ro6lGwxzdvz8mTDBqnM94Rr3K2x2XeOQXoCOV1AFKgeqJKzkuZspj9W92igQET59Dp7iPukXMA1ASLzhpJwxMTd3c1skSLqt+vvpEPPW1NDLKXr19W8mrsdbLoUtEjDNiD9cxD1jkMXt4/mfz/4wRdVtjK/vjffKv9vzX6KITo5RSeh3a6hHE1POE+W9+nyWDFNSTu/XBMscfLVDIoxBp3VHvZVLpurNGesw Date: 14 Jun 2014 18:46:11 -0000 Message-ID: <20140614184611.3530.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <53994E40.1040609@gmail.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/0qnZsFz12xUHYq7Y9XW4FiKVc0E Cc: dcrocker@gmail.com Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 14 Jun 2014 18:46:36 -0000 >When DKIM-Delegate is used, there are two, valid signatures for the same >domain. One is 'stronger'. > >The scenario being discussed is for a recipient who gets both signatures >when they are valid, but who does not know about DKIM-Delegate. They >only know about DKIM. That's not a problem -- if it has both signatures it is presumably the real message and it doesn't matter which one the recipient uses. The problem is when the message arrives with only the weak signature. If the recipient doesn't know that the weak signature is supposed to be paired with a strong signature from the forwarder, it will treat the weak signature as a regular signature, which is, as I understand it, undesirable, since that likely means that the message has had its body replaced by a bad guy. Perhaps there are DKIM validators that look at the signature to decide how strong it is, but I don't think I've ever seen one. Either they pass or they fail. R's, John From nobody Sat Jun 14 11:47:58 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE091A0201 for ; Sat, 14 Jun 2014 11:47:55 -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 UYv1jxqPFdEp for ; Sat, 14 Jun 2014 11:47:54 -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 795D71A01F3 for ; Sat, 14 Jun 2014 11:47:54 -0700 (PDT) Received: (qmail 96374 invoked from network); 14 Jun 2014 18:47:53 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 14 Jun 2014 18:47:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=de1.539c98d9.k1406; i=johnl@user.iecc.com; bh=+71pC8+ZeCgUQQPjXWVJQfIz0M+I5fgWvunZ+1NuXeA=; b=hd2t9uTfaV+NOY1NAJkUi2AcNDv/KvloAStwBZVqoMPTccxAdXvkWVUAcHbbrJ4wg9lmAKMaWW0DhZmIdlQl6mlv7sZwsoDZyLm0kBpZepkEZ1axhlPAdpZ4eWqPIsqv14An/fEzS85zeQsy7HyppwlGXLZoFevLIzMt0Xt9tHBO6WgXiUq2sHbQhjr9WU4TfBHleam4BcMxQVl8RlmwSBe0ZkW5CTKRQXx/MyZC0/iOEgKxWS6TwYEFpfn4lCtD DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=de1.539c98d9.k1406; olt=johnl@user.iecc.com; bh=+71pC8+ZeCgUQQPjXWVJQfIz0M+I5fgWvunZ+1NuXeA=; b=pT6Yu2QZPc9ZZ1dR1YFLbkpF5TmPi5vdD9eOBNu3818cuL/Ssc8pk9DKQyN/APomNv6PpmuJFb58cN/38DGt2E/2VfAC8wS/yEOmgainDkD5uhtB93GNRahTYhxpMh6vcLwtDnuu6e26P8PKnaqNnL8uQFgJQEO3ivfJpNWpsHirziv1a02nyHKkBh8EAfI/9uJY8mqDs3ev1huz/L0fTnOO+juVA52Y1rj4i7QfSPX3uTcgsEaX16NJJ40aeMgQ Date: 14 Jun 2014 18:47:31 -0000 Message-ID: <20140614184731.3552.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <87wqclohjo.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: http://mailarchive.ietf.org/arch/msg/dmarc/ZUvX2tUiYd5aKunOFzLXlSOXpZU Cc: stephen@xemacs.org Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 14 Jun 2014 18:47:55 -0000 > > If a signature has an rsf= tag, verifiers ignore it unless there's a > > matching signature from a domain the rsf= points to. > > > > This is not backward compatible, since verifiers that don't understand > > rsf= will often get the wrong answer, so it needs a version bump. > >Can't both the version bump issue and the token signature issue be >ameliorated by incorporating the token signature in the DKIM-Delegate >field? Yes, you could do the equivalent of the version bump by changing the name of the header, but I don't see the point. From nobody Sat Jun 14 12:44:11 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA1B1B29A6 for ; Sat, 14 Jun 2014 12:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, 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 eodFvS1_fzl7 for ; Sat, 14 Jun 2014 12:44:09 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 029981B299E for ; Sat, 14 Jun 2014 12:44:09 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P905HXCI68005QO8@mauve.mrochek.com> for dmarc@ietf.org; Sat, 14 Jun 2014 12:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1402774748; bh=MtRdIhiNwIBXotMpcK49U1jEg9pkvrfHsqRJC2pAR8k=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=eZYv0Ob7yzLAwjkW41FB3gvhLo59MilTW27okM3iaCvaM4GA7i30YaKB22yQ84zbF MihXEXA76GoR/0b4dMtWmzr/bhJ2ijrUpTjGC3IaqxLyoh9UuBjVwfD3tPVqXjUjs1 hD8OLJwvK6lnCOrvKRJvBZoTf2v3fdwm30PyGnP8= 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 <01P8UD4AOU8W0049PU@mauve.mrochek.com>; Sat, 14 Jun 2014 12:38:55 -0700 (PDT) Message-id: <01P905HVYGEM0049PU@mauve.mrochek.com> Date: Sat, 14 Jun 2014 12:35:24 -0700 (PDT) From: ned+dmarc@mrochek.com In-reply-to: "Your message dated Sat, 14 Jun 2014 18:47:31 +0000" <20140614184731.3552.qmail@joyce.lan> Sender: Ned Freed References: <87wqclohjo.fsf@uwakimon.sk.tsukuba.ac.jp> <20140614184731.3552.qmail@joyce.lan> To: John Levine Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/AzVe5OPZXvYrd3d6CcRBZjBFhn4 Cc: stephen@xemacs.org, dmarc@ietf.org Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 14 Jun 2014 19:44:10 -0000 > > > If a signature has an rsf= tag, verifiers ignore it unless there's a > > > matching signature from a domain the rsf= points to. > > > > > > This is not backward compatible, since verifiers that don't understand > > > rsf= will often get the wrong answer, so it needs a version bump. > > > >Can't both the version bump issue and the token signature issue be > >ameliorated by incorporating the token signature in the DKIM-Delegate > >field? > Yes, you could do the equivalent of the version bump by changing the > name of the header, but I don't see the point. If you're going to bump the version, you need to use the opportunity to solve the more general underlying problem. I'm not sure I can completely characterize that problem, but it's something along the times of there need to be some way to state the intention behind this particular signature. Is this a signature tied to use by third parties? Whitelisting? Something else? Ned From nobody Sat Jun 14 13:10:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1E2B1B29BA for ; Sat, 14 Jun 2014 13:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_21=0.6, 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 g-lM2hKUQWK2 for ; Sat, 14 Jun 2014 13:10:49 -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 B9E331B29BC for ; Sat, 14 Jun 2014 13:10:47 -0700 (PDT) Received: (qmail 7865 invoked from network); 14 Jun 2014 20:10:46 -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:cleverness; s=1eb8.539cac46.k1406; bh=yVykCdmgc6rkfNh02uS4vN1GZeWqsQ3Vw1XizH97+U0=; b=YUh4AIrWR02cRzOrt7JEtlqmxd+XSzb8wStc8thBWyaxGB6UzLzp3UmHY9kXmagiwjUSCIrif412T7Ckr11LWiAhi84O1tXv0L13C0GU7P/fnMsyQzFfEujB2mcgVvph7Hs0bFr5GrCiBW+S3EiUDO7FqFvv2hlv+4JW9jC8qr4Qd9w67y6X6ubTIIg1c8xXQnHO3dNxEfpWqgpHFH0arj2IHYCyvNHd2n2a3udl1kJBzHOkmIogJtQCJm59O+fk 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:cleverness; s=1eb8.539cac46.k1406; bh=yVykCdmgc6rkfNh02uS4vN1GZeWqsQ3Vw1XizH97+U0=; b=CdM6iDopyyMfYP1d7j+yYIpREJlEQeXndxKPHZ0HWbUHRBcU8G0sVVW+f8rcEdU/QNDX/5ogqGKMBq685+W/PXMhyinBzPR84UsfSUQx4vYHKYgGgdvjOpRMfIeOE8MJonXolQ7zfpwFwST/EjsyyWLMsSrw/1INXTXkf7zkgske9HhAta18S/Bka/u8/U0ViN7zCGNgLS78Hwur15mWRf5tOz6igi6tVGkCRaEHr8JW/MtDwFuurxS18gFlAZXa 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; 14 Jun 2014 20:10:46 -0000 Date: 14 Jun 2014 16:10:45 -0400 Message-ID: From: "John R Levine" To: ned+dmarc@mrochek.com In-Reply-To: <01P905HVYGEM0049PU@mauve.mrochek.com> References: <87wqclohjo.fsf@uwakimon.sk.tsukuba.ac.jp> <20140614184731.3552.qmail@joyce.lan> <01P905HVYGEM0049PU@mauve.mrochek.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Zm8X2FRgg8rscsnGwRp9_MQvfT4 Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 14 Jun 2014 20:10:51 -0000 >>>> If a signature has an rsf= tag, verifiers ignore it unless there's a >>>> matching signature from a domain the rsf= points to. ... > If you're going to bump the version, you need to use the opportunity to > solve the more general underlying problem. > > I'm not sure I can completely characterize that problem, but it's something > along the times of there need to be some way to state the intention behind this > particular signature. Is this a signature tied to use by third parties? > Whitelisting? Something else? That's what the rsf is supposed to mean. I suppose we could factor it out and do a version bump and add a new "conditional signature" cs= field, which means that a verifier only uses this signature if the conditions are met. There's a registry of cs field values, and if there is a cs field whose condition isn't satisfied, or that the verifier doesn't know about, the verification fails. So it'd be something like this: DKIM-Signature: v=2; ... cs=fwd; ... ft=t,c,foo.example That is, the condition is that it's also signed by one of the targets in the forwarding target "ft=" field. ("t" and "c" are the to and cc headers, on the perhaps overoptimistic theory that there will never be single letter TLDs.) You can safely add new cs values without a version bump, since the verifiers will fail until they've been upgraded to understand them. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Sat Jun 14 13:24:32 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5301B29C2 for ; Sat, 14 Jun 2014 13:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.053 X-Spam-Level: X-Spam-Status: No, score=-4.053 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, J_CHICKENPOX_21=0.6, RP_MATCHES_RCVD=-0.651, 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 SXlpNp-zg8GC for ; Sat, 14 Jun 2014 13:24:28 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 157341B29C7 for ; Sat, 14 Jun 2014 13:24:28 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P906WX97AO005346@mauve.mrochek.com> for dmarc@ietf.org; Sat, 14 Jun 2014 13:19:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1402777168; bh=OMn1dGMSFEfyYwPGVrSTE0mu9Y/8ylYhwpGtLgHun/Y=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=dYOJ66TbYhsmvdBjiju+aSAdZzqR36dNvvSC9TxFx+eCSB6o1g1le0zsAJB36Socw O0VnPN9fbFJmVi7DZI6stdxvDaPELA3KtJVod4I+jBVCMjfUkXysSOMjIa7YLNoXDL rnr0o8izNcy5CSOmLCVA6EEgE7qX2sO9RMKiGucE= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P8UD4AOU8W0049PU@mauve.mrochek.com>; Sat, 14 Jun 2014 13:19:15 -0700 (PDT) Message-id: <01P906WVHGOU0049PU@mauve.mrochek.com> Date: Sat, 14 Jun 2014 13:12:39 -0700 (PDT) From: ned+dmarc@mrochek.com In-reply-to: "Your message dated Sat, 14 Jun 2014 16:10:45 -0400" Sender: Ned Freed References: <87wqclohjo.fsf@uwakimon.sk.tsukuba.ac.jp> <20140614184731.3552.qmail@joyce.lan> <01P905HVYGEM0049PU@mauve.mrochek.com> To: John R Levine Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/hE-9QZkJpyPEhpVwyULd1zSM3VQ Cc: dmarc@ietf.org, ned+dmarc@mrochek.com Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 14 Jun 2014 20:24:29 -0000 > >>>> If a signature has an rsf= tag, verifiers ignore it unless there's a > >>>> matching signature from a domain the rsf= points to. ... > > If you're going to bump the version, you need to use the opportunity to > > solve the more general underlying problem. > > > > I'm not sure I can completely characterize that problem, but it's something > > along the times of there need to be some way to state the intention behind this > > particular signature. Is this a signature tied to use by third parties? > > Whitelisting? Something else? > That's what the rsf is supposed to mean. I understand that. The question is what happens when another, similar proposal comes along. Unless I'm missing something, rsf is quite specific to this delegation proposal. > I suppose we could factor it out and do a version bump and add a new > "conditional signature" cs= field, which means that a verifier only uses > this signature if the conditions are met. There's a registry of cs field > values, and if there is a cs field whose condition isn't satisfied, or > that the verifier doesn't know about, the verification fails. That's one of the axes we could proceed along. The other would be to focus instead on the purpose of the signature, and make the conditions part of that. I don't know which is better. There's a serious design decision to make here. > So it'd be something like this: > DKIM-Signature: v=2; ... cs=fwd; ... ft=t,c,foo.example > That is, the condition is that it's also signed by one of the targets in > the forwarding target "ft=" field. ("t" and "c" are the to and cc > headers, on the perhaps overoptimistic theory that there will never be > single letter TLDs.) > You can safely add new cs values without a version bump, since the > verifiers will fail until they've been upgraded to understand them. Yes, that's the general idea. But I'm not sure this is the right way to do it. From nobody Sat Jun 14 13:34:26 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8A61B29D0 for ; Sat, 14 Jun 2014 13:34:25 -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 m5uZN_-d3WHe for ; Sat, 14 Jun 2014 13:34:23 -0700 (PDT) Received: from dkim.winserver.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id DAFA71B29CC for ; Sat, 14 Jun 2014 13:34:22 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1914; t=1402778058; h=Received:Received: Message-Id:From:Subject:Date:To:Organization:List-ID; bh=unVk5lg 4Wtg6WFI/XwzV3JSpOQ8=; b=usAiODkdt12rRGOZClawtllcv69cw/jnV39GKTy Co6IXkPU4OdS7b3DNqEJF4Jp8v5bOnuw90pU1kkdEYk527yZmX+7qLvbuRFlUYPR 8kQropa5GWCbdL2r/je5RoY5Q/KCBgqfUVr0FhABtnDtFGqhtjbesqD6w1yUB9MJ CthM= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 14 Jun 2014 16:34:18 -0400 Received: from [192.168.1.82] (99-122-208-31.lightspeed.miamfl.sbcglobal.net [99.122.208.31]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2258177231.27610.5260; Sat, 14 Jun 2014 16:34:17 -0400 References: <87wqclohjo.fsf@uwakimon.sk.tsukuba.ac.jp> <20140614184731.3552.qmail@joyce.lan> <01P905HVYGEM0049PU@mauve.mrochek.com> Mime-Version: 1.0 (1.0) In-Reply-To: <01P905HVYGEM0049PU@mauve.mrochek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9796D1EB-54BE-4234-8752-4244807DDA65@isdg.net> X-Mailer: iPad Mail (11B651) From: Hector Santos Date: Sat, 14 Jun 2014 16:34:19 -0400 To: "ned+dmarc@mrochek.com" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/--ob5ZJqD3xYM3rKLVYO-5S0HFQ Cc: "stephen@xemacs.org" , "dmarc@ietf.org" , John Levine Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 14 Jun 2014 20:34:25 -0000 On Jun 14, 2014, at 3:35 PM, ned+dmarc@mrochek.com wrote: >>>> If a signature has an rsf=3D tag, verifiers ignore it unless there's a >>>> matching signature from a domain the rsf=3D points to. >>>>=20 >>>> This is not backward compatible, since verifiers that don't understand >>>> rsf=3D will often get the wrong answer, so it needs a version bump. >>>=20 >>> Can't both the version bump issue and the token signature issue be >>> ameliorated by incorporating the token signature in the DKIM-Delegate >>> field? >=20 >> Yes, you could do the equivalent of the version bump by changing the >> name of the header, but I don't see the point. >=20 > If you're going to bump the version, you need to use the opportunity to > solve the more general underlying problem. +1 ... And then some.=20 > I'm not sure I can completely characterize that problem, but it's somethin= g > along the times of there need to be some way to state the intention behind= this > particular signature. Is this a signature tied to use by third parties? > Whitelisting? Something else? The theoretical solution is a DNS-based lookup with an in-band optimizer, li= ke a DKIM-Delegate. I say it is the only practical and most cost effective s= olution based on implementation experience (minus the optimizer). The probl= em I sense is learning who to whitelist automatically out of the box and the= management for the whitelist. Yahoo says they need 30k whitelist records. = I don't see why that is a problem for them. They got the money to manage it= . No? It's not going to be problem for me, you and most domains. Most domain= s are not going to need such scale or expect to be authorizing anyone else b= ut themselves. Besides, we are talking software -- let it do the work. =20 Personally, it's getting ridiculous. So much time being wasted. -- Hector Santos http://www.santronics.com From nobody Sat Jun 14 19:03:08 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591C31B29BE for ; Sat, 14 Jun 2014 19:03:06 -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 bHffhv9eMB7Q for ; Sat, 14 Jun 2014 19:03:05 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF49E1B27C2 for ; Sat, 14 Jun 2014 19:03:04 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id y10so4094020wgg.8 for ; Sat, 14 Jun 2014 19:03: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=ItZl3h1pAc48HpSqNy6CWntnPC0liX3zkQNFL65BkzY=; b=v4ks1BT6SCtdHg1DN/nESF/3gHdJDSiAHookCKKw/1bNgMxMA7qofIiummSMUxSVZB 8+5zFbPvCf5oK2E/kJMLagG3vRljwArZ3JeTX+1vRgt9JggMQ9vByzBin4IKu+A2yR8R pXGIniRA6EWLxUfpuZgrXPpybjjb2pxZV4XDz8vn39tQITfaTpJJ1juKk1BAqNMmggCS ItaZyqwRBj7dhn+f7FEkk4azCco7qhdRs3UO8AjKbtHQhoGg/YH6lMBycNfPX98EaYoa +vGzcPumUWedwaa4lpSmUjdktVJJ6yY9VYuRYa2zReNDtJ9bpiPJWS1gLyvZ3KkfTCdA w9lw== MIME-Version: 1.0 X-Received: by 10.180.228.39 with SMTP id sf7mr16041065wic.26.1402797782976; Sat, 14 Jun 2014 19:03:02 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Sat, 14 Jun 2014 19:03:02 -0700 (PDT) In-Reply-To: <20140614184611.3530.qmail@joyce.lan> References: <53994E40.1040609@gmail.com> <20140614184611.3530.qmail@joyce.lan> Date: Sat, 14 Jun 2014 19:03:02 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=001a1134d18a8bcdde04fbd64fb3 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/VgVqponaPkdapE9r5p-HXVvS1ys Cc: Dave Crocker , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Sun, 15 Jun 2014 02:03:06 -0000 --001a1134d18a8bcdde04fbd64fb3 Content-Type: text/plain; charset=UTF-8 On Sat, Jun 14, 2014 at 11:46 AM, John Levine wrote: > Perhaps there are DKIM validators that look at the signature to decide > how strong it is, but I don't think I've ever seen one. Either they > pass or they fail. > OpenDKIM has all sorts of hooks for doing that kind of thing, but I don't know if anyone actually uses them. -MSK --001a1134d18a8bcdde04fbd64fb3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Jun 14, 2014 at 11:46 AM, John Levine <johnl@taugh.= com> wrote:
Perhaps there are DKIM validators that look at the signature to decide
how strong it is, but I don't think I've ever seen one. =C2=A0Eithe= r they
pass or they fail.

OpenDKIM has all sor= ts of hooks for doing that kind of thing, but I don't know if anyone ac= tually uses them.

-MSK
--001a1134d18a8bcdde04fbd64fb3-- From nobody Sat Jun 14 19:08:26 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADBBC1B2A70 for ; Sat, 14 Jun 2014 19:08:23 -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 8EPJaWcvbaEY for ; Sat, 14 Jun 2014 19:08:22 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E46A91B2A6D for ; Sat, 14 Jun 2014 19:08:21 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u57so4298511wes.3 for ; Sat, 14 Jun 2014 19:08: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=xq9UgevzSDaW7g4CJxjXcvQqOLiJBBng1BZOMCzeWdc=; b=Vco2dy2FfT/7pyMVlSYsMiEI1THHUbQGeYSM9beQEwEP49lMYbidRSmXGl8XPmg+uo 8D2pvvpCaaE2mn5BZJ16w11bk7o2Opw3LKHL8SlcmnzdE1WfdUPrr8zdPxHuAl1FnSch bFjWVmYLpKVAb/knkkwvN6uHqZzqbMl0rGjODOMjhIM56s7UXAv45LdBSm348yjsvUso sXGgMHIRCNBd2G5r5aY80JWbkeN1IIolPiN5tz7zhGNpaoUruaHHxiLUfF6ATo/5G7S0 qjYEf+Lc4kMhQVnXc8D7EgpUWjgUMRd07aHmYUWeeMW5XPyRNE0j/HhcCC3PXom09TAM 3Zfw== MIME-Version: 1.0 X-Received: by 10.194.7.36 with SMTP id g4mr16479832wja.37.1402798100497; Sat, 14 Jun 2014 19:08:20 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Sat, 14 Jun 2014 19:08:20 -0700 (PDT) In-Reply-To: <01P905HVYGEM0049PU@mauve.mrochek.com> References: <87wqclohjo.fsf@uwakimon.sk.tsukuba.ac.jp> <20140614184731.3552.qmail@joyce.lan> <01P905HVYGEM0049PU@mauve.mrochek.com> Date: Sat, 14 Jun 2014 19:08:20 -0700 Message-ID: From: "Murray S. Kucherawy" To: ned+dmarc@mrochek.com Content-Type: multipart/alternative; boundary=047d7b450a7c78cdd304fbd66227 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/I81Hkoz_BuHK4jChcG_DXec1Ngw Cc: Stephen Turnbull , "dmarc@ietf.org" , John Levine Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Sun, 15 Jun 2014 02:08:23 -0000 --047d7b450a7c78cdd304fbd66227 Content-Type: text/plain; charset=UTF-8 On Sat, Jun 14, 2014 at 12:35 PM, wrote: > > Yes, you could do the equivalent of the version bump by changing the > > name of the header, but I don't see the point. > > If you're going to bump the version, you need to use the opportunity to > solve the more general underlying problem. > > I'm not sure I can completely characterize that problem, but it's something > along the times of there need to be some way to state the intention behind > this > particular signature. Is this a signature tied to use by third parties? > Whitelisting? Something else? > What about a new canonicalization, which is largely the same as the existing ones but carries with it the additional semantic that "This can only pass when accompanied by a Mediator signature"? Current verifiers don't know what this is and thus wouldn't know what to do with it, so unless they do something abysmally stupid like "I don't know what this canonicalization is, so let's just call it a 'pass' to be on the safe side", this might be a path forward without a version bump. -MSK --047d7b450a7c78cdd304fbd66227 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Jun 14, 2014 at 12:35 PM, <<= a href=3D"mailto:ned+dmarc@mrochek.com" target=3D"_blank">ned+dmarc@mrochek= .com> wrote:
> Yes, you could do the e= quivalent of the version bump by changing the
> name of the header, but I don't see the point.

If you're going to bump the version, you need to use the opportun= ity to
solve the more general underlying problem.

I'm not sure I can completely characterize that problem, but it's s= omething
along the times of there need to be some way to state the intention behind = this
particular signature. Is this a signature tied to use by third parties?
Whitelisting? Something else?

What abou= t a new canonicalization, which is largely the same as the existing ones bu= t carries with it the additional semantic that "This can only pass whe= n accompanied by a Mediator signature"?

Current verifiers don't know what this is and thus would= n't know what to do with it, so unless they do something abysmally stup= id like "I don't know what this canonicalization is, so let's = just call it a 'pass' to be on the safe side", this might be a= path forward without a version bump.

-MSK
--047d7b450a7c78cdd304fbd66227-- From nobody Sat Jun 14 19:12:27 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6F11B2A77 for ; Sat, 14 Jun 2014 19:12: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 GcHD5pG2ENjg for ; Sat, 14 Jun 2014 19:12: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 1550A1B2A70 for ; Sat, 14 Jun 2014 19:12:21 -0700 (PDT) Received: (qmail 64386 invoked from network); 15 Jun 2014 02:12:20 -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:cleverness; s=fb81.539d0104.k1406; bh=wkAxABtKDSA4s+SwzF1blB5Vz9h5umGZYzhI74B5JgA=; b=c/+O+8pYNkjH50HQ9qeC78zaRY4w3U4x6XKwfArinQ8rF6YdHZqJYiqOB1gTHlD0ZmhVtdlgZjl7ME3OBe5HnTMmaYZwgYA+IbbYbe5JO+YgNdRwAh3RzULu2GAwSAcNyogsVWvzU5RT24LK8gsMKXC5snZv3kRR6Jkz/ptj7Ymh4oF3jx7R5u/skMRFXVbccBsNa/MB6K991jvelr2nmTi8xv9X7GWO+UEIuVnQMFmIjBqboLnwzuLU4YTWhMzB 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:cleverness; s=fb81.539d0104.k1406; bh=wkAxABtKDSA4s+SwzF1blB5Vz9h5umGZYzhI74B5JgA=; b=nMGhlS7+ujDpqpxBNco3pdkAOWgUqZkjXCRrfeb+FTKzfsKc5GMqmAZdQMj6ybE2b26OoWU6/OG6K6to6OLKiNvOaAkoQqGYUrJ6fM7MGssKgknp0HpjDWpzjHoyZYXaB9ZJ/gbmelGnsYrQ1ZsNnoxb2obcCChzVaKbC8S/JNbVM509kAdvi+toEl9SpaFRDMrbzgI8Q7zvE/AIQGMCEHezBhDjRV1jh0oEXyBRRbVZCYWge1CFpGwkBtw5yUXU 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; 15 Jun 2014 02:12:20 -0000 Date: 14 Jun 2014 22:12:19 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <87wqclohjo.fsf@uwakimon.sk.tsukuba.ac.jp> <20140614184731.3552.qmail@joyce.lan> <01P905HVYGEM0049PU@mauve.mrochek.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/r1VGLlAwI4nqKWq38uBwxAfdiGI Cc: "dmarc@ietf.org" , ned+dmarc@mrochek.com Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Sun, 15 Jun 2014 02:12:23 -0000 >> I'm not sure I can completely characterize that problem, but it's something >> along the times of there need to be some way to state the intention behind >> this particular signature. Is this a signature tied to use by third parties? >> Whitelisting? Something else? > What about a new canonicalization, which is largely the same as the > existing ones but carries with it the additional semantic that "This can > only pass when accompanied by a Mediator signature"? That would work, but it seems more kludgy than usual to tie the new loose canonicalization to the second signature. Those are both features that seem like they could be useful on their own. R's, John From nobody Sat Jun 14 20:58:30 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11ED31B29D1 for ; Sat, 14 Jun 2014 20:58:28 -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 3CK17ry5tZlK for ; Sat, 14 Jun 2014 20:58:26 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23F3F1B2899 for ; Sat, 14 Jun 2014 20:58:25 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id n3so2524993wiv.9 for ; Sat, 14 Jun 2014 20:58:24 -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=vnRjedsFDcveDbMKWN/jjQZyhdjvd2GxIm7Ex0Ut/WY=; b=Z4GdRTcp3swhwolW7ZWcZ8FSV8vTDZ9OY0xBY/LLBP90XrBKEv4M/TV1WfXrfR2LJw YKFAbU1330oM7InxOfRfKzsqLy+99W0Rw1uA3KOqzYpqYsArdEycklgnf0eic4yBe9zL SUYdzfiP7qy1p5WjE/2AUGj1JFdkPBJzWsA/NaJ19TgD0NfDL2jkYpqmtXQHwHmZt6Wz sHqaijpqtM+qKNZ2Y80bv6/D6qWqhd+9ch4zm8HAJ1BsvChQh9l0Orz/86OQUrbAWW6m VTR7VJIqnUvxoHOS/xjknTqZFOiFrAy2/g00slYWSo6Js2huoOS+gOKzagV5DvSU8rtn w3cQ== X-Received: by 10.194.62.104 with SMTP id x8mr16695636wjr.15.1402804704615; Sat, 14 Jun 2014 20:58:24 -0700 (PDT) Received: from ?IPv6:2a02:a03f:1461:bd00:c02c:3ec2:1924:2bd? ([2a02:a03f:1461:bd00:c02c:3ec2:1924:2bd]) by mx.google.com with ESMTPSA id d2sm23684488eeo.12.2014.06.14.20.58.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Jun 2014 20:58:23 -0700 (PDT) Message-ID: <539D19A1.7070503@gmail.com> Date: Sun, 15 Jun 2014 05:57:21 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , ned+dmarc@mrochek.com References: <87wqclohjo.fsf@uwakimon.sk.tsukuba.ac.jp> <20140614184731.3552.qmail@joyce.lan> <01P905HVYGEM0049PU@mauve.mrochek.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/nd967SRZAsrMLel7vGb97hw22mU Cc: Stephen Turnbull , "dmarc@ietf.org" , John Levine Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Sun, 15 Jun 2014 03:58:28 -0000 On 6/15/2014 4:08 AM, Murray S. Kucherawy wrote: > What about a new canonicalization, which is largely the same as the > existing ones but carries with it the additional semantic that "This can > only pass when accompanied by a Mediator signature"? > > Current verifiers don't know what this is and thus wouldn't know what to > do with it, so unless they do something abysmally stupid like "I don't > know what this canonicalization is, so let's just call it a 'pass' to be > on the safe side", this might be a path forward without a version bump. The suggestion I made in an offlist discussion was a new header canonicalization, but it hadn't occurred to me to include the contingency of a mediator signature. It's an interesting idea, but does seem like some sort of layer violation. (i wanted some phrase other than 'kludgy' just so i didn't echo john...) Surely there are enough details we could vary in a header canonicalization that are legitimate so that we don't need to toss in odd 'policy' characteristics to the of the algorithm? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Jun 14 23:01:08 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2EE21B2D3D for ; Sat, 14 Jun 2014 23:01:05 -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 xtGxWOerxinc for ; Sat, 14 Jun 2014 23:01:03 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86BCB1B2D3C for ; Sat, 14 Jun 2014 23:01:03 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id bs8so2565386wib.3 for ; Sat, 14 Jun 2014 23:01:02 -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=e0NSbNbGmwYsy/yucJJ3ID6OzxznbS7Rk+IACWV5pWs=; b=JpyHGfS15y3SL8kZBQsCe9gogO0j7jQX0+zIg2GDCwihA1HV/rLkTcH2bt4hcBIb8P QnV/z8jkp6q0f0FeHq16BPa1ntM/eEe8bA5Jcm0DWnG8pmiUv6v46NG4wjYqkaiuaIBD 5trQq8IIBtW7GOA1CxRrOi7JCuaQ8LjiDtXggxRYihJ2aITrClWXOJ4/Iv6ZPzMAMpxx 5ZICvivpCOQ6Qy7f+zTkwLQcQLXAxRL4UbFUIv+g4J7Ucrgqk3+OpzAITdMgr3KWrjpD bA08djy7g1nXrxBCJV0onIgAAubIkCp6SSKUFVxOPJ6+4acIsjAuiVr3E+1+JBa+U9kv NI2g== MIME-Version: 1.0 X-Received: by 10.181.8.67 with SMTP id di3mr17010158wid.8.1402812062021; Sat, 14 Jun 2014 23:01:02 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Sat, 14 Jun 2014 23:01:01 -0700 (PDT) In-Reply-To: <539D19A1.7070503@gmail.com> References: <87wqclohjo.fsf@uwakimon.sk.tsukuba.ac.jp> <20140614184731.3552.qmail@joyce.lan> <01P905HVYGEM0049PU@mauve.mrochek.com> <539D19A1.7070503@gmail.com> Date: Sat, 14 Jun 2014 23:01:01 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=001a1134d244a4bedd04fbd9a235 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Y_lf1tTGimxvWHXiEQGCfGU7fwk Cc: Stephen Turnbull , "dmarc@ietf.org" , John Levine , ned+dmarc@mrochek.com Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Sun, 15 Jun 2014 06:01:05 -0000 --001a1134d244a4bedd04fbd9a235 Content-Type: text/plain; charset=UTF-8 On Sat, Jun 14, 2014 at 8:57 PM, Dave Crocker wrote: > It's an interesting idea, but does seem like some sort of layer > violation. (i wanted some phrase other than 'kludgy' just so i didn't > echo john...) > > Surely there are enough details we could vary in a header > canonicalization that are legitimate so that we don't need to toss in > odd 'policy' characteristics to the of the algorithm? > Hmm. How about a new tag, "shf=" (special header fields). Ignored by legacy verifiers, as required; otherwise, contains a colon-separated list of fields that get special handling by verifiers. "Special handling" depends on the header field and would need to be documented in each case. For DKIM-Delegate, for example, it is always canonicalized in a special way that would cause the signature never to validate for a legacy verifier. Or maybe "shf=" header fields are only canonicalized by verifiers that know that they're special and why; they're a separate list than "h=". Somewhat less bogus than a new canonicalization that imparts new semantics; a new tag would, one would think, always impart new semantics in the first place. -MSK --001a1134d244a4bedd04fbd9a235 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Jun 14, 2014 at 8:57 PM, Dave Crocker <dcrocker@= gmail.com> wrote:
It's an interesting idea, but does seem = like some sort of layer
violation. =C2=A0(i wanted some phrase other than 'kludgy' just so = i didn't
echo john...)

Surely there are enough details we could vary in a header
canonicalization that are legitimate so that we don't need to toss in odd 'policy' characteristics to the of the algorithm?

Hmm.

How about a new tag, "shf=3D" = (special header fields).=C2=A0 Ignored by legacy verifiers, as required; ot= herwise, contains a colon-separated list of fields that get special handlin= g by verifiers.=C2=A0 "Special handling" depends on the header fi= eld and would need to be documented in each case.=C2=A0 For DKIM-Delegate, = for example, it is always canonicalized in a special way that would cause t= he signature never to validate for a legacy verifier.

Or maybe "shf=3D" header fields are only canonicalized by ver= ifiers that know that they're special and why; they're a separate l= ist than "h=3D".

Somewhat less bogus than a new canonicali= zation that imparts new semantics; a new tag would, one would think, always= impart new semantics in the first place.

-MSK
--001a1134d244a4bedd04fbd9a235-- From nobody Sat Jun 14 23:17:21 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81FE1B2D47 for ; Sat, 14 Jun 2014 23:16:45 -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 A6w9dLH6fTQ9 for ; Sat, 14 Jun 2014 23:16:36 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C089E1B2D49 for ; Sat, 14 Jun 2014 23:16:22 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id u56so4277330wes.22 for ; Sat, 14 Jun 2014 23:16:21 -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=NgMG/RjF+z8oXpLZLCtqcHmvmakgMP/l6Clj2DP4QF8=; b=n7FJsTcQO6oYHHquhINvF12057cPvPfOrwepN9TSu9CPnWxQjjVFxLGnrD61KGmW5N gol92Xw5S3vCVti9B+7Jglt7GnoW0gcetyQj7j03gLxsh8faMUn5toBmlqOuyi/HfNaH ImELTnbXzijlDOntGdJBltIANdRimlE8xovTAbc+OtpXmvdOaTyckcPw7INttpBXgcv9 xpdj8BiugNUSTppqH1cKiU3/2ueLz+6+FkzWXj9Q76XMVhUF67IIB9R09/6T/7RbAOaQ iwyhKja3oSqTifVDQcTDl3ECd2kx5AUEug4rAkBGWmQlin+rrqfrYK9I4oUTpZLfDT+i fX9w== X-Received: by 10.194.76.212 with SMTP id m20mr17423514wjw.30.1402812981419; Sat, 14 Jun 2014 23:16:21 -0700 (PDT) Received: from ?IPv6:2a02:a03f:1461:bd00:c02c:3ec2:1924:2bd? ([2a02:a03f:1461:bd00:c02c:3ec2:1924:2bd]) by mx.google.com with ESMTPSA id 47sm16263381eed.35.2014.06.14.23.16.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Jun 2014 23:16:20 -0700 (PDT) Message-ID: <539D39F6.3080006@gmail.com> Date: Sun, 15 Jun 2014 08:15:18 +0200 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <87wqclohjo.fsf@uwakimon.sk.tsukuba.ac.jp> <20140614184731.3552.qmail@joyce.lan> <01P905HVYGEM0049PU@mauve.mrochek.com> <539D19A1.7070503@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/mC3zaLmjRanDd1fdk-HQiAkZko0 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Sun, 15 Jun 2014 06:16:46 -0000 X-List-Received-Date: Sun, 15 Jun 2014 06:16:46 -0000 On 6/15/2014 8:01 AM, Murray S. Kucherawy wrote: > How about a new tag, "shf=" (special header fields). Ignored by legacy > verifiers, as required; otherwise, contains a colon-separated list of > fields that get special handling by verifiers. "Special handling" > depends on the header field and would need to be documented in each > case. For DKIM-Delegate, for example, it is always canonicalized in a > special way that would cause the signature never to validate for a > legacy verifier. > > Or maybe "shf=" header fields are only canonicalized by verifiers that > know that they're special and why; they're a separate list than "h=". > > Somewhat less bogus than a new canonicalization that imparts new > semantics; a new tag would, one would think, always impart new semantics > in the first place. I do not understand this predilection for trying to change the DKIM base engine. It doesn't need it. I also don't understand the construct of 'special handling', nevermind not liking the idea of it, especially since it explicitly creates the complexity of "depends on the header field". What I was suggesting was merely registering a new canonicalization algorithm. Legacy DKIM implementations won't understand it. New ones (presumably also modified to know about DMARC) will. The new canonicalization should have actual differences from the current ones that are deemed worthy for general use. For example, how about 'very-relaxed' which is like relaxed but eliminates all WSP from the calculation rather than just compressing it? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Jun 14 23:36:26 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C601B2B65 for ; Sat, 14 Jun 2014 23:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 64QRptaxbXT2 for ; Sat, 14 Jun 2014 23:36:24 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 4A64A1B2D56 for ; Sat, 14 Jun 2014 23:36:23 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 0A5F43FA0A40; Sun, 15 Jun 2014 15:36:23 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id F0B3A1A32C5; Sun, 15 Jun 2014 15:36:22 +0900 (JST) From: "Stephen J. Turnbull" To: "John Levine" In-Reply-To: <20140614184040.3494.qmail@joyce.lan> References: <87tx7poet2.fsf@uwakimon.sk.tsukuba.ac.jp> <20140614184040.3494.qmail@joyce.lan> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Sun, 15 Jun 2014 15:36:22 +0900 Message-ID: <87vbs2n0gp.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/M_Jt3Qkwty3Zq4E72mswxcw1mAQ Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] malware cleaning, was Change the mailing list protocol, not DMARC. 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, 15 Jun 2014 06:36:25 -0000 John Levine writes: > I don't think I've seen malware attached to a real message in the past > decade. When's the last one you got? Mid-March or so, from a Chinese student returned home for the spring holiday. China's Internet is still pretty woolley, my students tell me. > On the other hand, there are certainly plenty of mailing lists that > strip out attachments, which poses the same problem. Sure, but that's easier for the hard-core "don't touch the message" types to justify changing list practice (see subject). I wanted to cover several use cases for stripping MIME parts, not just traditional list practice. From nobody Sat Jun 14 23:45:19 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC311B2B7D for ; Sat, 14 Jun 2014 23:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 buKBqxJdEf91 for ; Sat, 14 Jun 2014 23:45:17 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 021B51B2B6A for ; Sat, 14 Jun 2014 23:45:16 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 59B983FA0B1F; Sun, 15 Jun 2014 15:45:16 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 4DEDB11F0DC; Sun, 15 Jun 2014 15:45:16 +0900 (JST) From: "Stephen J. Turnbull" To: "John Levine" In-Reply-To: <20140614184731.3552.qmail@joyce.lan> References: <87wqclohjo.fsf@uwakimon.sk.tsukuba.ac.jp> <20140614184731.3552.qmail@joyce.lan> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Sun, 15 Jun 2014 15:45:16 +0900 Message-ID: <87tx7mn01v.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/og-lmBL7cBjPwJFv2SR89HV04aw Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Sun, 15 Jun 2014 06:45:17 -0000 John Levine writes: > >Can't both the version bump issue and the token signature issue be > >ameliorated by incorporating the token signature in the DKIM-Delegate > >field? > > Yes, you could do the equivalent of the version bump by changing the > name of the header, but I don't see the point. There are two points. First, all the new semantics ends up supported by the new header; it gets completely ignored by existing MUAs, which means that there's no reason at all for a version bump. Second, a version bump means screwing with your existing, presumably working DKIM code because you need to produce a backward compatible v1 signature where possible, and a new v2 signature for the token signature and any other new semantics that gets piggy-backed on it. From nobody Sat Jun 14 23:53:49 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE8C1B2B6E for ; Sat, 14 Jun 2014 23:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 s2ox70rj6i0z for ; Sat, 14 Jun 2014 23:53:46 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAF01B2B6F for ; Sat, 14 Jun 2014 23:53:46 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id A569C3FA0B1C; Sun, 15 Jun 2014 15:53:45 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 977301A32C5; Sun, 15 Jun 2014 15:53:45 +0900 (JST) From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: <87wqclohjo.fsf@uwakimon.sk.tsukuba.ac.jp> <20140614184731.3552.qmail@joyce.lan> <01P905HVYGEM0049PU@mauve.mrochek.com> <539D19A1.7070503@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Sun, 15 Jun 2014 15:53:45 +0900 Message-ID: <87sin6mznq.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/dt-CmMNMxbSwXc-29hURyAy0mPw Cc: Dave Crocker , "dmarc@ietf.org" , John Levine , ned+dmarc@mrochek.com Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Sun, 15 Jun 2014 06:53:47 -0000 Murray S. Kucherawy writes: > How about a new tag, "shf=" (special header fields). Ignored by legacy > verifiers, as required; otherwise, contains a colon-separated list of > fields that get special handling by verifiers. "Special handling" depends > on the header field and would need to be documented in each case. For > DKIM-Delegate, for example, it is always canonicalized in a special way > that would cause the signature never to validate for a legacy > verifier. This seems to have it backwards though, because it's the presence of the DKIM-Delegate field that means one or more of the DKIM-Signature fields require special handling. From nobody Sun Jun 15 03:06:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5CE1B2BDC for ; Sun, 15 Jun 2014 03:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.073 X-Spam-Level: X-Spam-Status: No, score=-3.073 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 Dpg3J78rdxWR for ; Sun, 15 Jun 2014 03:06:40 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92E9F1B2BE0 for ; Sun, 15 Jun 2014 03:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1402826770; bh=2szkK1HwoSSdmT0p+Ov/JnCnYXWE82fnt0OWv68NlMY=; l=1233; h=Date:From:To:CC:References:In-Reply-To; b=gfKiLE7qI2WnFe6tYQiIvChnGQvi9JxSpid9KQZquxj4RiqZaZgdNMqEoNjoMEwPv OWGhn14sA4NRR7Z97LTBou4KpXwz8rEcfUyfnla7RiKUeTU5hfJ4Af8Syx4gXtgbX0 hOEPzzfLcAMIp0Oq05H8bX3cAf/0m1FKFOLW3KLk= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Sun, 15 Jun 2014 12:06:10 +0200 id 00000000005DC039.00000000539D7012.00004854 Message-ID: <539D7012.2060607@tana.it> Date: Sun, 15 Jun 2014 12:06:10 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: Dave Crocker , "Murray S. Kucherawy" References: <87wqclohjo.fsf@uwakimon.sk.tsukuba.ac.jp> <20140614184731.3552.qmail@joyce.lan> <01P905HVYGEM0049PU@mauve.mrochek.com> <539D19A1.7070503@gmail.com> <539D39F6.3080006@gmail.com> In-Reply-To: <539D39F6.3080006@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/XSIFDhpf8S0-5H8V_Lc2wn4bnRA Cc: "dmarc@ietf.org" , DKIM List Subject: [dmarc-ietf] New DKIM canonicalization, was dkim-delegate-00 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, 15 Jun 2014 10:06:43 -0000 On Sun 15/Jun/2014 08:15:18 +0200 Dave Crocker wrote: > On 6/15/2014 8:01 AM, Murray S. Kucherawy wrote: >> >> Somewhat less bogus than a new canonicalization that imparts new >> semantics; a new tag would, one would think, always impart new semantics >> in the first place. > > I do not understand this predilection for trying to change the DKIM base > engine. It doesn't need it. > > I also don't understand the construct of 'special handling', nevermind > not liking the idea of it, especially since it explicitly creates the > complexity of "depends on the header field". > > What I was suggesting was merely registering a new canonicalization > algorithm. Legacy DKIM implementations won't understand it. New ones > (presumably also modified to know about DMARC) will. > > The new canonicalization should have actual differences from the current > ones that are deemed worthy for general use. > > For example, how about 'very-relaxed' which is like relaxed but > eliminates all WSP from the calculation rather than just compressing it? Let's take the occasion to also have it eliminate quotation marks. See http://mipassoc.org/pipermail/ietf-dkim/2011q2/016518.html and following discussions. Ale From nobody Sun Jun 15 09:43:59 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9861B295A for ; Sun, 15 Jun 2014 09:43:56 -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 zWPT6H-zJwm0 for ; Sun, 15 Jun 2014 09:43:51 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D20541B2958 for ; Sun, 15 Jun 2014 09:43:50 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id n15so2936348wiw.16 for ; Sun, 15 Jun 2014 09:43: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=QZBRzkPOcTWvaFQXY2Exf5L5hB4fBMAQJpmLeEclv/I=; b=qaPf1eW+CRn4YSL8Omhl9h0kTOhL68zIIzsUeLUy9HRR3CnloX3xY/EJsSCrZqFceY ii2ITmNXDdEZb48isTVySsd71dVBZYo+So24FnFhZsrRwqBcHHJ5fl1fWXOShTtQIXit yCjs2ygR16t3j5ccDR5j4VAs3GarsChJk4kG++enMV4sQYNQ9VsFF5rvlAPqH04E3ecQ KCI6AeB+JA8u4RTGEEmmRzsL6LE3GbHWb/KEForOIOlheDH0hheElz5zw0DlTPyHr0kH 2JGswwLPTuVG6NiGDBHWjy3t46eEFpxMbKOwvtaaHlFlztiDtrkWPXj5Mq1T8frEWBlg XISg== MIME-Version: 1.0 X-Received: by 10.181.8.67 with SMTP id di3mr20450385wid.8.1402850629152; Sun, 15 Jun 2014 09:43:49 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Sun, 15 Jun 2014 09:43:48 -0700 (PDT) In-Reply-To: <539D39F6.3080006@gmail.com> References: <87wqclohjo.fsf@uwakimon.sk.tsukuba.ac.jp> <20140614184731.3552.qmail@joyce.lan> <01P905HVYGEM0049PU@mauve.mrochek.com> <539D19A1.7070503@gmail.com> <539D39F6.3080006@gmail.com> Date: Sun, 15 Jun 2014 09:43:48 -0700 Message-ID: From: "Murray S. Kucherawy" To: Dave Crocker Content-Type: multipart/alternative; boundary=001a1134d2446c7b5b04fbe29d3e Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/gFyK2tJeKfvNT_N3PnjcHjxpjvs Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Sun, 15 Jun 2014 16:43:56 -0000 --001a1134d2446c7b5b04fbe29d3e Content-Type: text/plain; charset=UTF-8 On Sat, Jun 14, 2014 at 11:15 PM, Dave Crocker wrote: > > What I was suggesting was merely registering a new canonicalization > algorithm. Legacy DKIM implementations won't understand it. New ones > (presumably also modified to know about DMARC) will. > > The new canonicalization should have actual differences from the current > ones that are deemed worthy for general use. > > For example, how about 'very-relaxed' which is like relaxed but > eliminates all WSP from the calculation rather than just compressing it? > > The reason I don't like this approach -- assuming I am not missing something from this idea -- is because then we are, directly or not, tying verification semantics outside of DKIM to a canonicalization. In essence the change is to add this new canonicalization and at the same time teach verifiers that the token signature, in the absence of DKIM-Delegate and a passing Mediator signature, is to be ignored. I would much rather it be more explicit than that. Adding a new tag that introduces this is fully backward compatible with the installed base, and isn't piggybacked on a new header canonicalization that (as far as I know) we don't actually need. I'm happy to be corrected on that if there's actual data about it, of course. -MSK --001a1134d2446c7b5b04fbe29d3e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Jun 14, 2014 at 11:15 PM, Dave Crocker <dcrock= er@gmail.com> wrote:

What I was suggesting was merely registering a new canonicalization algorithm. =C2=A0Legacy DKIM implementations won't understand it. =C2= =A0New ones
(presumably also modified to know about DMARC) will.

The new canonicalization should have actual differences from the current ones that are deemed worthy for general use.

For example, how about 'very-relaxed' which is like relaxed but
eliminates all WSP from the calculation rather than just compressing it?

<= br>
The reason I don't like this approach -- assuming I am no= t missing something from this idea -- is because then we are, directly or n= ot, tying verification semantics outside of DKIM to a canonicalization.=C2= =A0 In essence the change is to add this new canonicalization and at the sa= me time teach verifiers that the token signature, in the absence of DKIM-De= legate and a passing Mediator signature, is to be ignored.=C2=A0 I would mu= ch rather it be more explicit than that.

Adding a new tag that introduces this is fully backward comp= atible with the installed base, and isn't piggybacked on a new header c= anonicalization that (as far as I know) we don't actually need.=C2=A0 I= 'm happy to be corrected on that if there's actual data about it, o= f course.

-MSK
--001a1134d2446c7b5b04fbe29d3e-- From nobody Sun Jun 15 09:47:23 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5B91B2958 for ; Sun, 15 Jun 2014 09:47:21 -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 jkDnlaPIjpgI for ; Sun, 15 Jun 2014 09:47:20 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5DEA1B295A for ; Sun, 15 Jun 2014 09:47:19 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hi2so4246888wib.4 for ; Sun, 15 Jun 2014 09:47: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=h5gw+EKKgpDBzPaXBqUHLwiLJ45MXvrJQ1gb30goisg=; b=TdRosH6NgnPoDSTVTQPQ6iNrFX6t77cWWjXi0d+Rj02Asz0xCyK66aps7K24KVQ8tn z/nsBSr2nPf5FG9VPA2cACZJYUhKLiHBh98aAzUlKGFTDaTRo9z8iAmSDtSzwm9NStkW Mq2Daop0M+X9zC7akl/rHgVN7/T1f34omZrSEQv4GlBz+5MXbeCPrgvy2E+5pFxmiagw K87GlTOuelk5ePnWM/bCegHEUeuKgWvJput2MuYdoTi7PQIj5uIV7fDRmwEXE+Gs6XPE gG9rNNkzkrSQr5WvgwzOgyi3wLIEVsfqlkRCIH/CfceYDzKyqf8tP3lJOa7fdDWSQH73 +b9Q== MIME-Version: 1.0 X-Received: by 10.180.94.163 with SMTP id dd3mr20475532wib.26.1402850838114; Sun, 15 Jun 2014 09:47:18 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Sun, 15 Jun 2014 09:47:17 -0700 (PDT) In-Reply-To: <87sin6mznq.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87wqclohjo.fsf@uwakimon.sk.tsukuba.ac.jp> <20140614184731.3552.qmail@joyce.lan> <01P905HVYGEM0049PU@mauve.mrochek.com> <539D19A1.7070503@gmail.com> <87sin6mznq.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Sun, 15 Jun 2014 09:47:17 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=f46d04462e5ee118ef04fbe2a919 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/BduuAR_g_FxMBYLYC-f6hu5MFU8 Cc: Dave Crocker , "dmarc@ietf.org" , John Levine , ned+dmarc@mrochek.com Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Sun, 15 Jun 2014 16:47:22 -0000 --f46d04462e5ee118ef04fbe2a919 Content-Type: text/plain; charset=UTF-8 On Sat, Jun 14, 2014 at 11:53 PM, Stephen J. Turnbull wrote: > > How about a new tag, "shf=" (special header fields). Ignored by legacy > > verifiers, as required; otherwise, contains a colon-separated list of > > fields that get special handling by verifiers. "Special handling" > depends > > on the header field and would need to be documented in each case. For > > DKIM-Delegate, for example, it is always canonicalized in a special way > > that would cause the signature never to validate for a legacy > > verifier. > > This seems to have it backwards though, because it's the presence of > the DKIM-Delegate field that means one or more of the DKIM-Signature > fields require special handling. > > True, but I think that small bit of weirdness is fine in the face of the token signature that would be misinterpreted and possibly abused by legacy DKIM installations that don't know about new tags or header fields. -MSK --f46d04462e5ee118ef04fbe2a919 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Jun 14, 2014 at 11:53 PM, Stephen J. Turnbull <s= tephen@xemacs.org> wrote:
=C2=A0> How about a new t= ag, "shf=3D" (special header fields). =C2=A0Ignored by legacy
=C2=A0> verifiers, as required; otherwise, contains a colon-separated li= st of
=C2=A0> fields that get special handling by verifiers. =C2=A0"Speci= al handling" depends
=C2=A0> on the header field and would need to be documented in each case= . =C2=A0For
=C2=A0> DKIM-Delegate, for example, it is always canonicalized in a spec= ial way
=C2=A0> that would cause the signature never to validate for a legacy =C2=A0> verifier.

This seems to have it backwards though, because it's the presence= of
the DKIM-Delegate field that means one or more of the DKIM-Signature
fields require special handling.


True, but I think t= hat small bit of weirdness is fine in the face of the token signature that = would be misinterpreted and possibly abused by legacy DKIM installations th= at don't know about new tags or header fields.

-MSK
--f46d04462e5ee118ef04fbe2a919-- From nobody Sun Jun 15 10:01:22 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3561B2BAB for ; Sun, 15 Jun 2014 10:01:21 -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 C42QkuOB_FhY for ; Sun, 15 Jun 2014 10:01: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 4FDE41B2B66 for ; Sun, 15 Jun 2014 10:01:19 -0700 (PDT) Received: (qmail 42859 invoked from network); 15 Jun 2014 17:01:18 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 15 Jun 2014 17:01:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=ed6c.539dd15e.k1406; i=johnl@user.iecc.com; bh=btONQCAkwOZf3AQJFZ1yxi5EscHNJH8MtNmUAvT/bac=; b=tXWZTCOL9QSmdprzUnD9V0BSWcZxPtrhx1tgCSzhAfs2jNKhEx13g74eMOPyQlg+bvnoPPWBCPjtudbWfR4ipVTsMXzPKp5a96Rc3bq2wSkVGkbdDmNtEYAzddztVv7xrvoZeem59nLIxjHLVzXk/6KFz27wKU85y8igCqEBUoS/c5N1Xcw/+0x9PXcgmf7TBYb14X1qAXpv0XZ+tQ9ZVFub7Pj7kwtiUYQPK1xRul1rW0iQhl3ouphgrm2zMzSZ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=ed6c.539dd15e.k1406; olt=johnl@user.iecc.com; bh=btONQCAkwOZf3AQJFZ1yxi5EscHNJH8MtNmUAvT/bac=; b=R4WaDisodorNDq6DlrujeMMSTqWWIEZYaYPWdEP6/Ui7gmLEPWATzIQlZ3CG8Exx8oofBdslt7DqWw1voteIsylmhkFhW/xY4lU+AkEs/d8uvDD2sHORRlB7pNsjvz5AE+/mK4RJ2vYVWeSR+DOjik01DSnUMAKxQW7EpFFjdIGpowZrpkeLsqcvL74LPTULTxO1NId5GRx5i9BdC/XCHMCjWl3Lt1H/3rw2aG5qRbXaGdsghPhB4ew/n9lsOFRO Date: 15 Jun 2014 17:00:55 -0000 Message-ID: <20140615170055.60779.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <539D39F6.3080006@gmail.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/OcddrRCyaGruMZKEad901tjor-M Cc: dcrocker@gmail.com Subject: Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version 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, 15 Jun 2014 17:01:21 -0000 >I do not understand this predilection for trying to change the DKIM base >engine. It doesn't need it. Actually, I claim that a version bump is the approach least likely to break existing clients. >I also don't understand the construct of 'special handling', never mind >not liking the idea of it, especially since it explicitly creates the >complexity of "depends on the header field". I think we agree that the goal here is to have a weak signature that verifiers disregard unless it's associated with a delegated signature. Your plan, as I understand it, was that verifiers will ignore a signature that is too weak. One might argue clients that accept weak signatures are already broken, but in that case there are an awful lot of broken clients, starting with spamassassin. (I just checked.) Until now there's been no reason other than playing games to use weak signatures, so in practice it hasn't mattered. Now it does, so clients have to change their code to check for "too weak", probably in inconsistent ways, to check for l= and what headers are signed and so forth. Murray's trick, add a new canonicalization that's only valid if there's a paired signature, many not require a version bump, but to be useful it does require a change to the verifier library interfaces. Libraries and clients are not upgraded in sync, so there will be old clients calling upgraded libraries. The libraries can't just accept the new canon and return "valid", since old clients won't know to look for the paired signature. They can't return "conditionally valid", since clients won't know what to do with it. So the libraries will need a new entry point, or at least a new option, for the client to say that it understands a conditionally valid result. A few moments thought should confirm that's semantically the same as an option for a client to say it understands v2 signatures, just kludgier. With respect to Stephen's concern about libraries knowing when to construct v1 or v2 signatures, really, that's no big deal. We've been doing that sort of stuff for version bumps since approximately forever, and it's a nit compared to the other stuff it'll have to do to interpret the conditional signatures. It also occurs to me that there are all sorts of ways that a conditionally valid signature would be useful. For example: * valid if this DNS lookup resolves, for per-signature revocation * valid if the body has this S/MIME signature, to allow for list software that reformats the message but keeps the signed body part (mailman and mj2, for example) or that resigns with its own S/MIME signature (sympa) * valid if the body has this PGP signature (mailman's working on it) Some of these can be done with kludges, but most can't. R's, John From nobody Sun Jun 15 12:11:45 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10CD51B285B for ; Sun, 15 Jun 2014 12:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, 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 dhCDGB2yRONV for ; Sun, 15 Jun 2014 12:11:41 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 205C61A0645 for ; Sun, 15 Jun 2014 12:11:41 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P91IO0U5OG005Q9F@mauve.mrochek.com> for dmarc@ietf.org; Sun, 15 Jun 2014 12:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1402859202; bh=i0npqYTwE6AEKyHbrU6TFOMt5XLGuKbEHyTiEokHZB0=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=Bdjk4mm/PjWiiSdb616B4uiKJC/xwAIe84T9QPgYynaws6TPqViYVWz1xh4bqgcfh 5+3ibIILkx8yhbfDfbfhstmJeGRXIt8AJi8Ol67cEb/aGt+FMbYgRoInKouiydpkkZ kCrC4F56Y8ibzBOKYvPZ4TLF7VFb395aYvcr6gWE= 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 <01P8UD4AOU8W0049PU@mauve.mrochek.com>; Sun, 15 Jun 2014 12:06:29 -0700 (PDT) Message-id: <01P91INZVKK80049PU@mauve.mrochek.com> Date: Sun, 15 Jun 2014 11:58:42 -0700 (PDT) From: ned+dmarc@mrochek.com In-reply-to: "Your message dated Sun, 15 Jun 2014 17:00:55 +0000" <20140615170055.60779.qmail@joyce.lan> Sender: Ned Freed References: <539D39F6.3080006@gmail.com> <20140615170055.60779.qmail@joyce.lan> To: John Levine Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/IuXlO8f0AYigv9FYmOtbErwnzkQ Cc: dcrocker@gmail.com, dmarc@ietf.org Subject: Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version 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, 15 Jun 2014 19:11:43 -0000 > >I do not understand this predilection for trying to change the DKIM base > >engine. It doesn't need it. > Actually, I claim that a version bump is the approach least likely to > break existing clients. > >I also don't understand the construct of 'special handling', never mind > >not liking the idea of it, especially since it explicitly creates the > >complexity of "depends on the header field". > I think we agree that the goal here is to have a weak signature that > verifiers disregard unless it's associated with a delegated signature. > Your plan, as I understand it, was that verifiers will ignore a > signature that is too weak. One might argue clients that accept weak > signatures are already broken, but in that case there are an awful lot > of broken clients, starting with spamassassin. (I just checked.) Out of curiousity, did you try having two signatures in various different orders and combinations of validity? Mind you, even if this leads to a way of structuring these things that "works" for the current crop of clients, I would not be inclined to trust it. I'm just curious. > Until now there's been no reason other than playing games to use weak > signatures, so in practice it hasn't mattered. Now it does, so > clients have to change their code to check for "too weak", probably in > inconsistent ways, to check for l= and what headers are signed and so > forth. Agreed. Like it or not, this calls for, let's call it a "clarification" of existing DKIM semantics. And to do that you either bump the version or overload some other existing field in the protocol. > Murray's trick, add a new canonicalization that's only valid if > there's a paired signature, many not require a version bump, but to be > useful it does require a change to the verifier library interfaces. Six of one, half a dozen of the other. > Libraries and clients are not upgraded in sync, so there will be old > clients calling upgraded libraries. The libraries can't just accept > the new canon and return "valid", since old clients won't know to look > for the paired signature. They can't return "conditionally valid", > since clients won't know what to do with it. So the libraries will > need a new entry point, or at least a new option, for the client to > say that it understands a conditionally valid result. A few moments > thought should confirm that's semantically the same as an option for a > client to say it understands v2 signatures, just kludgier. Exactly. > With respect to Stephen's concern about libraries knowing when to > construct v1 or v2 signatures, really, that's no big deal. We've been > doing that sort of stuff for version bumps since approximately > forever, and it's a nit compared to the other stuff it'll have to do > to interpret the conditional signatures. > It also occurs to me that there are all sorts of ways that a > conditionally valid signature would be useful. For example: > * valid if this DNS lookup resolves, for per-signature revocation > * valid if the body has this S/MIME signature, to allow for list > software that reformats the message but keeps the signed body part > (mailman and mj2, for example) or that resigns with its own S/MIME > signature (sympa) > * valid if the body has this PGP signature (mailman's working on it) > Some of these can be done with kludges, but most can't. Exactly why I think that as long as we're bumping the version, building in some additional extensibility seems like a really good idea. The only question is how much and in what form. Ned From nobody Sun Jun 15 12:24:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312521B2918 for ; Sun, 15 Jun 2014 12:24: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 Z92NIlKDYbwn for ; Sun, 15 Jun 2014 12:24: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 0AA7D1B285B for ; Sun, 15 Jun 2014 12:24:49 -0700 (PDT) Received: (qmail 63069 invoked from network); 15 Jun 2014 19:24: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:cleverness; s=f65c.539df301.k1406; bh=Q/1RxTJ3fYm7V30lVfgN0lckYBaNr98bsLg863wNqG0=; b=l9VBimqV7B7Cy+8d/e/bxbtPNm3Ai3qeAPzYlwejXQG60TMaL8rhaBXg2AfmfzdF5FALE+lnQ5KlJn6j/ax4aYsX6rygIrDFmVQZpqieSUcp2RMOf6IGJTUjbBqe/4mNYuj/4gXszBNyNKPk7r5ca5zVdyj68Vu4shqeC7/DmkGifhpruAMOCIZy+Nh6/qvSUiPnAPsNplrUrXdAirXIOyUo40uB4e/w59Pt2kXTtwp+Dv4SweFxmACDlj0Hk6d4 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:cleverness; s=f65c.539df301.k1406; bh=Q/1RxTJ3fYm7V30lVfgN0lckYBaNr98bsLg863wNqG0=; b=cjteXAQNBvdf/RDJ4D8H2YqhYpEpKIJx7MS5KEkENqDnq1LXSr/jmCCd54mh0moNkY0byiKwZ3C8Cc9/uDJMRyoTVIuiJQch7DqE+suooGuvgU8XPuMs3R28KxPM9/Wsy6TPSDkGFa6uH8uEshuRdraN7nDZ6d+YjSfuKE6QeFnOx48Npzq4r/iHxwNDc16bBI68Xe+Xiqhfa2uILnw56xn4oWIlE3Z4SJfPq+zNKeBzbEtkHV5QcNHfIJirZv6r 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; 15 Jun 2014 19:24:48 -0000 Date: 15 Jun 2014 15:24:48 -0400 Message-ID: From: "John R Levine" To: ned+dmarc@mrochek.com In-Reply-To: <01P91INZVKK80049PU@mauve.mrochek.com> References: <539D39F6.3080006@gmail.com> <20140615170055.60779.qmail@joyce.lan> <01P91INZVKK80049PU@mauve.mrochek.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/cvRnVGhulavugeJxOzlgr25bAg8 Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version 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, 15 Jun 2014 19:24:51 -0000 >> signatures are already broken, but in that case there are an awful lot >> of broken clients, starting with spamassassin. (I just checked.) > > Out of curiousity, did you try having two signatures in various different > orders and combinations of validity? No, but from looking at the code, I don't think that would matter. It makes a table of the signatures (just the valid ones, I believe) and then applies various rules about signers and pseudo-ADSP. > Exactly why I think that as long as we're bumping the version, building in some > additional extensibility seems like a really good idea. The only question > is how much and in what form. Suggestions welcome. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Sun Jun 15 17:25:09 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7121B2987 for ; Sun, 15 Jun 2014 17:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 M2Ud1e93lAIe for ; Sun, 15 Jun 2014 17:25:06 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 76A041B2988 for ; Sun, 15 Jun 2014 17:25:06 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 61A073FA0AF4; Mon, 16 Jun 2014 09:25:05 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 23EC71A32C5; Mon, 16 Jun 2014 09:25:05 +0900 (JST) From: "Stephen J. Turnbull" To: "John Levine" In-Reply-To: <20140615170055.60779.qmail@joyce.lan> References: <539D39F6.3080006@gmail.com> <20140615170055.60779.qmail@joyce.lan> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Mon, 16 Jun 2014 09:25:04 +0900 Message-ID: <87wqchk8f3.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/mMxmY59Ya0WldRpmUitX_PXdGHE Cc: dcrocker@gmail.com, dmarc@ietf.org Subject: Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version 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, 16 Jun 2014 00:25:08 -0000 John Levine writes: > >I do not understand this predilection for trying to change the DKIM base > >engine. It doesn't need it. > > Actually, I claim that a version bump is the approach least likely to > break existing clients. The point is to avoid breaking the anti-spam *system*. If the system continues to work (in some appropriate sense) in the presence of clients "broken" in some sense, that's a win. > I think we agree that the goal here is to have a weak signature that > verifiers disregard unless it's associated with a delegated signature. > Your plan, as I understand it, was that verifiers will ignore a > signature that is too weak. One might argue clients that accept weak > signatures are already broken, but in that case there are an awful lot > of broken clients, starting with spamassassin. (I just checked.) Spamassassin does not pretend to be a DKIM (or DMARC) policy engine, so of course it "accepts" weak signatures. It accepts invalid and nonexistent signatures, too. By this I suppose you mean that spamassassin does not distinguish among levels of content coverage of signatures it detects and verifies, so different spamminess coefficients can't be assigned? From nobody Sun Jun 15 17:37:14 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB7D1B298C for ; Sun, 15 Jun 2014 17:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 gof3CZjNsPgP for ; Sun, 15 Jun 2014 17:37:10 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 37EBD1B298A for ; Sun, 15 Jun 2014 17:37:10 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 622803FA0AF4; Mon, 16 Jun 2014 09:37:09 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 544151A32C5; Mon, 16 Jun 2014 09:37:09 +0900 (JST) From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: <87wqclohjo.fsf@uwakimon.sk.tsukuba.ac.jp> <20140614184731.3552.qmail@joyce.lan> <01P905HVYGEM0049PU@mauve.mrochek.com> <539D19A1.7070503@gmail.com> <87sin6mznq.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Mon, 16 Jun 2014 09:37:09 +0900 Message-ID: <87vbs1k7uy.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/oXWn7_F0W_bLKNHpkXGGMkSErrY Cc: Dave Crocker , "dmarc@ietf.org" , John Levine , ned+dmarc@mrochek.com Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Mon, 16 Jun 2014 00:37:11 -0000 Murray S. Kucherawy writes: > On Sat, Jun 14, 2014 at 11:53 PM, Stephen J. Turnbull > wrote: > > > > How about a new tag, "shf=" (special header fields). Ignored > > > by legacy verifiers, as required; otherwise, contains a > > > colon-separated list of fields that get special handling by > > > verifiers. "Special handling" depends on the header field and > > > would need to be documented in each case. For DKIM-Delegate, > > > for example, it is always canonicalized in a special way that > > > would cause the signature never to validate for a legacy > > > verifier. > > This seems to have it backwards though, because it's the presence of > > the DKIM-Delegate field that means one or more of the DKIM-Signature > > fields require special handling. > True, but I think that small bit of weirdness is fine in the face > of the token signature that would be misinterpreted and possibly > abused by legacy DKIM installations that don't know about new tags > or header fields. I don't understand. My point is that in the case of a token signature and one or more content-covering signatures, it is a nonempty proper subset of fields of the same DKIM-Signature type that need "special" treatment. How do you reliably distinguish a subset of fields with the same tag? Am I missing something? The DKIM-Delegate field is a different type. Of course its handling is special. From nobody Sun Jun 15 18:03:04 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4291B29A1 for ; Sun, 15 Jun 2014 18:03:03 -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 4TLnTUDou4hc for ; Sun, 15 Jun 2014 18:03: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 03A411B2998 for ; Sun, 15 Jun 2014 18:03:01 -0700 (PDT) Received: (qmail 5581 invoked from network); 16 Jun 2014 01:02:59 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 16 Jun 2014 01:02:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=12e95.539e4243.k1406; i=johnl@user.iecc.com; bh=oEAPD7+7fjwItdWoRAbsTvxK8V/i4WlHHDZG1Hhk9cg=; b=RD3y0OhJjlvZ5k6B5PN/aUkEE13GZDTMi6YagfsMSJfB4JI1MjsdLrCWa/axcgT+WlxKDA8m2ACk1h1VsXL0eN4QSiEmnlLHLssl2RgLVSNso2LcRJKQybFursUMmM9QJij2EQENUgGCKEsn+r5/SqcpIqtsvB7MHhpa9W//e70+KSJo7EX3KWWmuW5U82VjdFKAlD6YLkf3OBEFzxbGBp63AJKR3UvhPlaJvtDccpBIStg9BRKyh3ky6pisDmv3 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=12e95.539e4243.k1406; olt=johnl@user.iecc.com; bh=oEAPD7+7fjwItdWoRAbsTvxK8V/i4WlHHDZG1Hhk9cg=; b=m8RxZZRo2jS5jOPLQ5z+aoVZswVaHMzVy7D57WZoD/zygs/y1uNVNl6nMoBuxwjByobV47EngJ4Kano/5B4CJS/muKRqq9BaYUUTJfAuyYp0Nf9gyfDc7RrN3ehoPJ3+uoiap8XQlgMEzEXx6XsLyshRWYOazReVTO1yATmPwSFPBOOdF1Uxpy61MQ7aZx/sIXm4WzX6dcBKAPO47sgXzv/pJz+qZAYK9rXEvH0h5usW2deQpLRJhLYEOapCIcjT Date: 16 Jun 2014 01:02:37 -0000 Message-ID: <20140616010237.77460.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <87wqchk8f3.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: http://mailarchive.ietf.org/arch/msg/dmarc/dTlHx5o7Yuct3kbK3z3g3baZ_ok Subject: Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version 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, 16 Jun 2014 01:03:03 -0000 > > Your plan, as I understand it, was that verifiers will ignore a > > signature that is too weak. One might argue clients that accept weak > > signatures are already broken, but in that case there are an awful lot > > of broken clients, starting with spamassassin. (I just checked.) > >Spamassassin does not pretend to be a DKIM (or DMARC) policy engine, >so of course it "accepts" weak signatures. It accepts invalid and >nonexistent signatures, too. No, it doesn't. It calls Mail::DKIM to validate the signatures. R's, John From nobody Sun Jun 15 18:58:58 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AD31B29CB for ; Sun, 15 Jun 2014 18:58:55 -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 ppN7ngZ755Z7 for ; Sun, 15 Jun 2014 18:58:54 -0700 (PDT) Received: from mail.theartfarm.com (mail.theartfarm.com [66.128.51.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54DC71B29C2 for ; Sun, 15 Jun 2014 18:58:54 -0700 (PDT) Received: (qmail 43212 invoked by uid 89); 16 Jun 2014 01:58:53 -0000 Received: from unknown (HELO mail.theartfarm.com) (127.0.0.30) by mail.theartfarm.com with SMTP; 16 Jun 2014 01:58:53 -0000 Received-SPF: Pass (mail.theartfarm.com: domain of tnpi.net designates 50.159.99.59 as permitted sender) receiver=mail.theartfarm.com; identity=mailfrom; client-ip=50.159.99.59; helo=[10.0.1.141]; envelope-from= Received: from [10.0.1.141] (c-50-159-99-59.hsd1.wa.comcast.net [50.159.99.59]) by mail.theartfarm.com (Haraka/2.5.0-toaster) with ESMTPSA id 36A03931-BC46-4880-BE72-022800D3D3F9.1 envelope-from (authenticated bits=0) (version=TLSv1/SSLv3 cipher=AES128-SHA verify=FAIL); Sun, 15 Jun 2014 21:58:52 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Matt Simerson In-Reply-To: <20140616010237.77460.qmail@joyce.lan> Date: Sun, 15 Jun 2014 18:58:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1611380D-2178-4116-9583-EC1086942825@tnpi.net> References: <20140616010237.77460.qmail@joyce.lan> To: dmarc@ietf.org X-Mailer: Apple Mail (2.1878.2) X-Haraka-p0f: os="MacOS X 10.9 or newer (sometimes iPhone " link_type="Ethernet or modem" distance=11 total_conn=1 shared_ip=N X-Haraka-GeoIP: US, WA, Seattle, 2699km X-Haraka-GeoIP-Received: X-Haraka-ASN: 7922 50.128.0.0/9 X-Haraka-ASN-MONKEY: asn=7922 net=50.128.0.0/9 org=Comcast Cable Communications, Inc. date=1997-02-14 country=US X-Haraka-FCrDNS: c-50-159-99-59.hsd1.wa.comcast.net X-Spam-ASN: X-Spam-DCC: sonic.net: spamassassin.tnpi.net 1156; Body=1 Fuz1=1 Fuz2=1 X-Spam-SNF-Result: 0 (Standard White Rules) X-Spam-MessageSniffer-Scan-Result: 0 X-MessageSniffer-Rules: 0-0-0-3424-c X-MessageSniffer-Clean: Yes X-Spam-MessageSniffer-Rules: 0-0-0-3424-c X-MessageSniffer-Clean: Yes X-Spam-GBUdb-Analysis: 0, 10.0.1.141, Ugly c=0.200527 p=-1 Source Normal X-MessageSniffer-Scan-Result: 0 X-MessageSniffer-Rules: 0-0-0-3424-c X-MessageSniffer-Clean: Yes X-Haraka-Karma: connect: 4, history: 480, total_connects: 512, neighbors: -5550, pass:fcrdns.fcrdns, relaying, auth_user, fail:fcrdns.fail, neighbors, dnsbl.fail, helo.checks.fail, helo.checks.fail, skip:penalty DKIM-Signature: v=1; a=rsa-sha256; bh=RqN/6wV1rTxxh5B5K8Un0+Piq/zMWosrj+dFcJh/cQQ=; c=relaxed/simple; d=tnpi.net; h=from:subject:date:message-id:to:mime-version; s=mar2013; b=I/TgQ/NWvlc5qb71+8uWHMWAO9XoHyVlmmC6pZTcZtfZ9OkamOwnkshcZLsbOxg9eQC9iBwPu2ADsBAcp6X91yXe1k/EG/MHXq/v0oRrC1Z/02LZETgoVvYr0FGZQz3C/rIJiAw4gA2RGHLcE/XPVSEuFyF2KI00G7PpV5NYLp7O+70xnv5AOQjJhSbQw8j9UXMqq80x9Y++/tjAs2ZZd2SEh5KUi/OuWFs9yNICnff50dVaU0T/nUh2fqcRw3G6RHPtDB/xOfV8vMsuyRzwEvvTISzl8ISD7yCDNhtG9ToO6at8WCxr6ep++x2cNKabOBMpeA7GSlAt5qcrWhXV5w== Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/rfDgeW8SMx84TUQaasxK6y0e6r0 Subject: Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version 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, 16 Jun 2014 01:58:56 -0000 On Jun 15, 2014, at 6:02 PM, John Levine wrote: >>> Your plan, as I understand it, was that verifiers will ignore a >>> signature that is too weak. One might argue clients that accept = weak >>> signatures are already broken, but in that case there are an awful = lot >>> of broken clients, starting with spamassassin. (I just checked.) >>=20 >> Spamassassin does not pretend to be a DKIM (or DMARC) policy engine, >> so of course it "accepts" weak signatures. It accepts invalid and >> nonexistent signatures, too. >=20 > No, it doesn't. Yes, SpamAssassin does "accept" weak, invalid, and nonexistent = signatures.=20 > It calls Mail::DKIM to validate the signatures. Yes, it does. But SA uses the results of Mail::DKIM heuristically and a = DKIM failure is frequently not a sufficient basis for rejection. = http://spamassassin.apache.org/full/3.4.x/doc/Mail_SpamAssassin_Plugin_DKI= M.html Matt= From nobody Sun Jun 15 19:58:16 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF1B1B29EF for ; Sun, 15 Jun 2014 19:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 DO6c85nJayCo for ; Sun, 15 Jun 2014 19:58:12 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id A3EB31B29ED for ; Sun, 15 Jun 2014 19:58:12 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id A2DD83FA0AF4; Mon, 16 Jun 2014 11:58:11 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 646911A397E; Mon, 16 Jun 2014 11:58:11 +0900 (JST) From: "Stephen J. Turnbull" To: "John Levine" In-Reply-To: <20140616010237.77460.qmail@joyce.lan> References: <87wqchk8f3.fsf@uwakimon.sk.tsukuba.ac.jp> <20140616010237.77460.qmail@joyce.lan> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Mon, 16 Jun 2014 11:58:10 +0900 Message-ID: <87r42pk1bx.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/kP6HHy7aDvtZ6HeQKt46jzLqZ_A Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version 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, 16 Jun 2014 02:58:15 -0000 John Levine writes: > >Spamassassin does not pretend to be a DKIM (or DMARC) policy engine, > >so of course it "accepts" weak signatures. It accepts invalid and > >nonexistent signatures, too. > > No, it doesn't. It calls Mail::DKIM to validate the signatures. Indeed, it validates the signatures. I should have written "'accept' and 'reject' are not appropriate for use in discussing SpamAssassin's processing at the level of message features". The question I'd like to ask is "how hard would it be to get SpamAssassin to evaluate the features it knows about (eg, 'valid DKIM signature') in conformance with each of the proposals?" That is, is it possible for SpamAssassin to independently assign a score (presumably a fairly large negative one) to the specific feature - This field is DKIM-Delegate to example.com, AND - there is a valid DKIM signature from example.com for the whole message body and appropriate headers, AND - the DKIM-Delegate field is signed with a valid signature, AND - RFC5322.From is aligned with the valid signature on DKIM-Delegate and other such (complex) features? Is it more straightforward if DKIM-Delegate is self-signed as I proposed? Etc. From nobody Sun Jun 15 20:36:15 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA31D1B2BEE for ; Sun, 15 Jun 2014 20:36:13 -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 kEj6rJkq6Wtb for ; Sun, 15 Jun 2014 20:36:13 -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 9D74E1B2BB1 for ; Sun, 15 Jun 2014 20:36:12 -0700 (PDT) Received: (qmail 30587 invoked from network); 16 Jun 2014 03:36:11 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 16 Jun 2014 03:36:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1308f.539e662a.k1406; i=johnl@user.iecc.com; bh=7X5FsEsx5c/qUOyZ0dOkRd43kiHCykTyU8AFf+VvCgM=; b=IQWK81WtqgWGmXkXyLffA76UceH6RIMx6p9qZVHd7a7CYKHvi5YrMURQiS/vlbPHHhULQD1C7eeudLPZYor6ar0tzt1DwDHPnk5hogPFeUeC7liK3XyZxrHInbUkRY4v2Go1cIilDbGKrpG+Z0BF2JAmMVCKzOCe1ikQRw4pGThkd2sS8uEaw1EFiOKLC9dQRSMP5mf7AhwMngoHF5Toop7ttlZybV6oukvOmsDbjdra6Zp8EFaFwZx8BcjnwSMa DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1308f.539e662a.k1406; olt=johnl@user.iecc.com; bh=7X5FsEsx5c/qUOyZ0dOkRd43kiHCykTyU8AFf+VvCgM=; b=NUjVZL+R5HI3Kmrq93j9zIJhSAonUtHu4Pawl8GQ/X4q/3yehp0H6IXnWxio1VZ8WmN1QvodrzE15lmgU5vFWWkXduAP0r+at+oLqMOPELvkpPqHmK7d4BAzZXYS6lb270ORZ5Qm00+Stso0RTLk9x8s9Qk01E+93EruW0oN+sFbsZaEfWXOuelxgUnCOY4US2GN6rxPFRp41yrzAkpETGzXcDCJR67uh2jBAb78xT1qf8t+aYrU1PJMx0eyF20I Date: 16 Jun 2014 03:35:48 -0000 Message-ID: <20140616033548.77966.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <1611380D-2178-4116-9583-EC1086942825@tnpi.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/s7vOBlLIsbPWaGxD7qcWPP9v_V4 Cc: matt@tnpi.net Subject: Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version 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, 16 Jun 2014 03:36:13 -0000 >Yes, it does. But SA uses the results of Mail::DKIM heuristically and a DKIM failure is frequently not a >sufficient basis for rejection. I should hope not. The DKIM spec is crystal clear that an invalid signature is equivalent to no signature. R's, John From nobody Sun Jun 15 23:35:06 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1A71B2BF6 for ; Sun, 15 Jun 2014 23:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 MPvnhTrQarmQ for ; Sun, 15 Jun 2014 23:35:01 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D7581B2B54 for ; Sun, 15 Jun 2014 23:35:01 -0700 (PDT) Received: by mail-ig0-f180.google.com with SMTP id h18so2575891igc.13 for ; Sun, 15 Jun 2014 23:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tJy3O8gqQsUSUEaAzErOnV7VHq/PUxltR9OfJ6ulFqs=; b=I/UAL6NfLl5pxNeYwW19djpAmMnXMHYE2fpOpaNRXZJQsq6Rh0y8eRPykVg9RexLHz HUWmriselaTjikBwR2BTaQGeGZ6vItLd3jCQ25RZ1hF3tw54fVvaFpT+5z/QkfWXnk+F iLUC/NwncC4KVvoLY6iCy4LmpleIYD9zZjOSZDdLJzLZtVinTuzNxnVLZJ3bC+RL6tj7 bqtTB0OOryaEJ9X3DlZJctzg3+PPn0CIQaoSiQ8FN4nl6WBFOpZDmQcp7iXWJ/aRJrfe q84RVV8eL4IkbOxl0ZFYpYDm2OOqsZvan6XkE6tyC96vkxrvTX0Se7quxs7TOAiM/hUf LIwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tJy3O8gqQsUSUEaAzErOnV7VHq/PUxltR9OfJ6ulFqs=; b=BMBGBR0cmzj5U1CAyEfiDT0FXGw1fyUf67v9thLZ8RgYNGfMbsWAaeNc3YK5E8DdGJ qgGWEb3q2L0/AswW7tL6qJTE9cjBPx/rB6jCrF+oXrWJdr0TYyyw1E1UzPU6Dkv2Vkri HoP151H5NFu8Do5dsFJFuPfCd/XBntIETPbX3SKhVqU6hPz3ROKISlVbksZ0I19MhhXl g3eMAPXmV1SJS4Rp7UsHioNwpG/2i5xD8BiKh+U6UBI6B868lRElKMfcgUXr7AtXW4Lk diki5NMPJqdBGsb+Opp5HHqhyGemFECWTh3gzg1TvR1qgefqYnh7662lw9WP07p8Aa1l byHw== X-Gm-Message-State: ALoCoQk/ruuDMqXkzinY8ThJEQjywFxYczMQv6XJIcc32BzE4VOfP16NRX6FBAGV/Z7SRgMCVZyO MIME-Version: 1.0 X-Received: by 10.42.99.10 with SMTP id u10mr19446021icn.9.1402900500927; Sun, 15 Jun 2014 23:35:00 -0700 (PDT) Received: by 10.64.136.202 with HTTP; Sun, 15 Jun 2014 23:35:00 -0700 (PDT) In-Reply-To: <9796D1EB-54BE-4234-8752-4244807DDA65@isdg.net> References: <87wqclohjo.fsf@uwakimon.sk.tsukuba.ac.jp> <20140614184731.3552.qmail@joyce.lan> <01P905HVYGEM0049PU@mauve.mrochek.com> <9796D1EB-54BE-4234-8752-4244807DDA65@isdg.net> Date: Sun, 15 Jun 2014 23:35:00 -0700 Message-ID: From: Brandon Long To: Hector Santos Content-Type: multipart/alternative; boundary=20cf30223e49037e8804fbee3a70 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/XdWEqX9sCd29w_dHOkWDIL1SWA4 Cc: "stephen@xemacs.org" , "dmarc@ietf.org" , John Levine , "ned+dmarc@mrochek.com" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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: Mon, 16 Jun 2014 06:35:04 -0000 --20cf30223e49037e8804fbee3a70 Content-Type: text/plain; charset=UTF-8 On Sat, Jun 14, 2014 at 1:34 PM, Hector Santos wrote: > > On Jun 14, 2014, at 3:35 PM, ned+dmarc@mrochek.com wrote: > > >>>> If a signature has an rsf= tag, verifiers ignore it unless there's a > >>>> matching signature from a domain the rsf= points to. > >>>> > >>>> This is not backward compatible, since verifiers that don't understand > >>>> rsf= will often get the wrong answer, so it needs a version bump. > >>> > >>> Can't both the version bump issue and the token signature issue be > >>> ameliorated by incorporating the token signature in the DKIM-Delegate > >>> field? > > > >> Yes, you could do the equivalent of the version bump by changing the > >> name of the header, but I don't see the point. > > > > If you're going to bump the version, you need to use the opportunity to > > solve the more general underlying problem. > > +1 ... And then some. > > > I'm not sure I can completely characterize that problem, but it's > something > > along the times of there need to be some way to state the intention > behind this > > particular signature. Is this a signature tied to use by third parties? > > Whitelisting? Something else? > > The theoretical solution is a DNS-based lookup with an in-band optimizer, > like a DKIM-Delegate. I say it is the only practical and most cost > effective solution based on implementation experience (minus the > optimizer). The problem I sense is learning who to whitelist automatically > out of the box and the management for the whitelist. Yahoo says they need > 30k whitelist records. I don't see why that is a problem for them. They > got the money to manage it. No? It's not going to be problem for me, you > and most domains. Most domains are not going to need such scale or expect > to be authorizing anyone else but themselves. Besides, we are talking > software -- let it do the work. > If its your personal domain, sure, there are maybe 5 domains you need to whitelist, you know them well, its all good and easy. If I have to whitelist 30k domains, what am I doing it based on? The DMARC reject report combined with maybe some reputation and proof that those domains actually perform accurate authentication (ie, existence of an AR or OAR header that's signed) and that those domains auth themselves. And do we really think all 30k domains are going to remain pure? If I list a single domain for a handful of users, I'm exposing xxxM users to that domain... more when I'm whitelisting those third parties to mimic my domains to anyone else, so its the xB users around the world who normally interact with my xxxM users. Managing the whitelist through DNS also has its issues, just how short of a TTL am I willing to live with, would anyone else actually like it if I published one with a 30s TTL? I'm sure we can come up with a mechanism for producing a whitelist, and it would be "reasonable" until something on it was compromised, and we could have mechanisms to update that whitelist in real time based on reputation and other features. I'm sure our dns team would be thrilled to delegate the sub-domain to us so we can let the world query us... but it ends up looking like a pretty leaky boat to me. I like the "in-band optimizer" since it gives me more confidence... but maybe that's being naive as well, if they compromise a domain to get on our whitelist, are they really going to be deterred in working around a weak signature? Brandon --20cf30223e49037e8804fbee3a70 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sat, Jun 14, 2014 at 1:34 PM, Hector Santos &l= t;hs= antos@isdg.net> wrote:

On Jun 14, 2014, at 3:35 PM, ned+dmarc@mrochek.com wrote:

>>>> If a signature has an rsf=3D tag, verifiers ignore it unle= ss there's a
>>>> matching signature from a domain the rsf=3D points to.
>>>>
>>>> This is not backward compatible, since verifiers that don&= #39;t understand
>>>> rsf=3D will often get the wrong answer, so it needs a vers= ion bump.
>>>
>>> Can't both the version bump issue and the token signature = issue be
>>> ameliorated by incorporating the token signature in the DKIM-D= elegate
>>> field?
>
>> Yes, you could do the equivalent of the version bump by changing t= he
>> name of the header, but I don't see the point.
>
> If you're going to bump the version, you need to use the opportuni= ty to
> solve the more general underlying problem.

+1 ... And then some.

> I'm not sure I can completely characterize that problem, but it= 9;s something
> along the times of there need to be some way to state the intention be= hind this
> particular signature. Is this a signature tied to use by third parties= ?
> Whitelisting? Something else?

The theoretical solution is a DNS-based lookup with an in-band optimizer, l= ike a DKIM-Delegate. =C2=A0I say it is the only practical and most cost eff= ective solution based on implementation experience (minus the optimizer). = =C2=A0The problem I sense is learning who to whitelist automatically out of= the box and the management for the whitelist. =C2=A0Yahoo says they need 3= 0k whitelist records. =C2=A0I don't see why that is a problem for them.= They got the money to manage it. No? It's not going to be problem for = me, you and most domains. Most domains are not going to need such scale or = expect to be authorizing anyone else but themselves. Besides, we are talkin= g software -- let it do the work.

If its your personal domain, sure, there a= re maybe 5 domains you need to whitelist, you know them well, its all good = and easy.

If I have to whitelist 30k domains, what= am I doing it based on? =C2=A0The DMARC reject report combined with maybe = some reputation and proof that those domains actually perform accurate auth= entication (ie, existence of an AR or OAR header that's signed) and tha= t those domains auth themselves. =C2=A0And do we really think all 30k domai= ns are going to remain pure? =C2=A0If I list a single domain for a handful = of users, I'm exposing xxxM users to that domain... more when I'm w= hitelisting those third parties to mimic my domains to anyone else, so its = the xB users around the world who normally interact with my xxxM users.

Managing the whitelist through DNS also has its issues,= just how short of a TTL am I willing to live with, would anyone else actua= lly like it if I published one with a 30s TTL?

I'm sure we can come up with a mechanism for producing a whitelist, and= it would be "reasonable" until something on it was compromised, = and we could have mechanisms to update that whitelist in real time based on= reputation and other features. =C2=A0I'm sure our dns team would be th= rilled to delegate the sub-domain to us so we can let the world query us...= but it ends up looking like a pretty leaky boat to me.

I like the "in-band optimizer" since it gives= me more confidence... but maybe that's being naive as well, if they co= mpromise a domain to get on our whitelist, are they really going to be dete= rred in working around a weak signature?

Brandon
--20cf30223e49037e8804fbee3a70-- From nobody Mon Jun 16 13:18:25 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D169D1A01D5 for ; Mon, 16 Jun 2014 13:18: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 QawPMXdftYBB for ; Mon, 16 Jun 2014 13:18: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 76F141A01D1 for ; Mon, 16 Jun 2014 13:18:22 -0700 (PDT) Received: (qmail 8182 invoked from network); 16 Jun 2014 20:18:21 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 16 Jun 2014 20:18:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=14aee.539f510d.k1406; i=johnl@user.iecc.com; bh=/eibc12LuKy9RdY0iKQJPCMFq/ltko8AcEy4VKR1bak=; b=FdGxgpQvpvQu9tO1EEQDB9UUOI5sk4qkbsBfv8B3VnHd89qfDKW1ahc531wPKyYVRWNI71D/7l6njRuu2vUiKBQ7qkcF7YPHK0ABeOK0ZHu6Tb4qJEWRkhW5bxCwgeQVEqI/R6L/qBIoRHw40dRKuhRhr2iJNdnpPsuJ4m0Fp0KEdi/hX/T1vyWAH4hN1cGbDEIaabuOyOCVYKHk+e2KzB19zV8mWDhlwkL980TsmMDhf1x/sUAOkRpfNEUKBc4e DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=14aee.539f510d.k1406; olt=johnl@user.iecc.com; bh=/eibc12LuKy9RdY0iKQJPCMFq/ltko8AcEy4VKR1bak=; b=yO1rllTkxqE5yUjDaSD6BbNUFkFgiuQLeLoV5HrM0ZajuN0DooimxKnT4MgRJl38XZWWz82rnJoRrs3yUf+ZnX5SDodm+WcZq6AjdFCBWxgcR70ZQFcV03BCyIym5GsdAwlBtSHWmIloQoOD4U0ToXE+LwR0RrIRY68G1gJlK7JN5SRqaRVa77EnRJfRxTpbYSlbFlYrNy5lMmTV9wcDB+yXXg2BL10E0CSsRkJVK5DIx7+J+cX9lK7VJok/Y3eh Date: 16 Jun 2014 20:17:59 -0000 Message-ID: <20140616201759.84717.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/zpus3CjzoM0qApA0FHcMAIAvlK0 Subject: [dmarc-ietf] draft-levine-dkim-conditional-00 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, 16 Jun 2014 20:18:24 -0000 Here's a draft that puts the forwarding thing into DKIM, with the dread version bump. It defines a general syntax for conditional signatures, with the forwarding signature the only condition defined so far. (Since you asked, new conditions don't need another version bump.) R's, John ----------------------------------------------------------------- A new version of I-D, draft-levine-dkim-conditional-00.txt has been successfully submitted by John Levine and posted to the IETF repository. Name: draft-levine-dkim-conditional Revision: 00 Title: DKIM Conditional Signatures Document date: 2014-06-16 Group: Individual Submission Pages: 5 URL: http://www.ietf.org/internet-drafts/draft-levine-dkim-conditional-00.txt Status: https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ Htmlized: http://tools.ietf.org/html/draft-levine-dkim-conditional-00 Abstract: The DKIM protocol applies a cryptographic signature to an e-mail message. This specification extends DKIM to allow the specification of external conditions that must be satisfied for a signature to be valid. From nobody Mon Jun 16 13:46:11 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03A11A01EB for ; Mon, 16 Jun 2014 13:45: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 5nud0SXjxXx5 for ; Mon, 16 Jun 2014 13:45:50 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E6F41A0212 for ; Mon, 16 Jun 2014 13:45:50 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id b13so6190831wgh.14 for ; Mon, 16 Jun 2014 13:45: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=mFRmoPx/Ma/LbohgAwQX5fz4NmyVNetP2TStLG2k1cQ=; b=Ca8LMA0EQi0L4cvmXy5VsYo6Y9FeXSaHzRhetBmsN3XIajx52WHTlg3e81SuYbOUFP qAJz36elSSba6sqIyc1uqw/gJrePziNB/ZtOfyvOql6wbfN/aMX0g/gJc0uk29/IkQZn eJWMH5KRWo6cluWmJ5RMXXzdxtUDaIjteUq3K83o49WcCtpcdmh9KZQC1pfUp+HSq2kV AV+pSpb4zpjMkiaVcHAopKwlK4A5F1OwgFhJQzaQZhEtvtvBnTeIOBo9DD9EVrdu7y+Y ag+jyqyjmJFjenL1fpvHKx5vksx0pWNizKSQTaS8T6ZYDz0zSPyBCMCZLlkAE53rk4L6 lrpQ== MIME-Version: 1.0 X-Received: by 10.180.212.77 with SMTP id ni13mr30333666wic.5.1402951549151; Mon, 16 Jun 2014 13:45:49 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Mon, 16 Jun 2014 13:45:48 -0700 (PDT) In-Reply-To: <20140616201759.84717.qmail@joyce.lan> References: <20140616201759.84717.qmail@joyce.lan> Date: Mon, 16 Jun 2014 13:45:48 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=001a11c23e5ab971b404fbfa1c14 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/PHMU82YlSCGZu1roFuRwfiiUb7k Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-00 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, 16 Jun 2014 20:45:54 -0000 --001a11c23e5ab971b404fbfa1c14 Content-Type: text/plain; charset=UTF-8 On Mon, Jun 16, 2014 at 1:17 PM, John Levine wrote: > Here's a draft that puts the forwarding thing into DKIM, with the > dread version bump. It defines a general syntax for conditional > signatures, with the forwarding signature the only condition defined > so far. (Since you asked, new conditions don't need another version > bump.) > I'm uneasy with an increase in version that isn't done in a complete replacement for RFC6376. We're not just registering a couple of new extension tags here. I would prefer that, if we do go decide to go down this route, we crack it open and do a proper revision document rather than just describing v2 in terms of "changes since v1". I also wonder where/how/if this would fit inside a potential DMARC charter, or if we're looking at a second WG for this, or what. -MSK --001a11c23e5ab971b404fbfa1c14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 16, 2014 at 1:17 PM, John Levine <johnl@taugh.c= om> wrote:
Here's a draft that puts the forwarding thing into DKIM, with the
dread version bump. =C2=A0It defines a general syntax for conditional
signatures, with the forwarding signature the only condition defined
so far. =C2=A0(Since you asked, new conditions don't need another versi= on
bump.)

I'm uneasy with an increase = in version that isn't done in a complete replacement for RFC6376.=C2=A0= We're not just registering a couple of new extension tags here.=C2=A0 = I would prefer that, if we do go decide to go down this route, we crack it = open and do a proper revision document rather than just describing v2 in te= rms of "changes since v1".

I also wonder where/how/if this would fit inside a potential= DMARC charter, or if we're looking at a second WG for this, or what.
-MSK
--001a11c23e5ab971b404fbfa1c14-- From nobody Mon Jun 16 14:12:49 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6BF1A0239 for ; Mon, 16 Jun 2014 14:12:49 -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 Rz5ilVikJ4eW for ; Mon, 16 Jun 2014 14:12:45 -0700 (PDT) Received: from secure.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 953FE1A0236 for ; Mon, 16 Jun 2014 14:12:44 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3573; t=1402953161; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=8vVWNoDZd83vuDZpwRZhg04XaSI=; b=bys/Hv5aPMV6ZAP4+/1r RExI721xXNOnxnzCUDkiMejOvBV4gQNDTizWnz4ryeqvcTO7bC6BeDZPzS1on5WF ynclneoyApR3dsn68p4fTlTOLSxomPiSIUfNqoL5MwDL5nr4FbGvuEda1vFi7V8X 52FXu7W3w+BoWgus7Y6PPg4= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 16 Jun 2014 17:12: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; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2433277542.30577.5308; Mon, 16 Jun 2014 17:12:40 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3573; t=1402952982; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=1oagIoF 8I8bpzC/897ldmMn3dKo9QngdjNt1SVMraN8=; b=mR0KKmv7Oq06fnPWIg6mPWl D4wUvF2sPvXh4dq7m/6nkpe5d1O3Lt03cusYCvQiGgjh2GtjUtxvsbHgBSBMAv+Q csu/dit8G58ZmyR4Nmyc/WxylnY+c/7daY2iGmdTg3ZzBYp0VCxCp0YVCU6napQs Qk3kSlTislmWyOmFuAtc= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Mon, 16 Jun 2014 17:09: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 2449629234.9.5576; Mon, 16 Jun 2014 17:09:41 -0400 Message-ID: <539F5DC4.2060006@isdg.net> Date: Mon, 16 Jun 2014 17:12: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: <20140616201759.84717.qmail@joyce.lan> In-Reply-To: <20140616201759.84717.qmail@joyce.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/GBmekIhG_mUAKsZIam_akXmOLhk Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-00 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, 16 Jun 2014 21:12:49 -0000 On 6/16/2014 4:17 PM, John Levine wrote: > Here's a draft that puts the forwarding thing into DKIM, with the > dread version bump. It defines a general syntax for conditional > signatures, with the forwarding signature the only condition defined > so far. (Since you asked, new conditions don't need another version > bump.) > > R's, > John > > > ----------------------------------------------------------------- > A new version of I-D, draft-levine-dkim-conditional-00.txt > has been successfully submitted by John Levine and posted to the > IETF repository. > > Name: draft-levine-dkim-conditional > Revision: 00 > Title: DKIM Conditional Signatures > Document date: 2014-06-16 > Group: Individual Submission > Pages: 5 > URL: http://www.ietf.org/internet-drafts/draft-levine-dkim-conditional-00.txt > Status: https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ > Htmlized: http://tools.ietf.org/html/draft-levine-dkim-conditional-00 > > > Abstract: > The DKIM protocol applies a cryptographic signature to an e-mail > message. This specification extends DKIM to allow the specification > of external conditions that must be satisfied for a signature to be > valid. John, There are many problems with this and any other complexed, additional processing idea, like DKIM-Delegate, that tries to get around a DNS Author Domain lookup -- namely, it doesn't address the main issue policy verification systems want: How to authorized a valid third party signature when nothing else exist but the two parameters: Author Domain <<--- 5322.From Signer Domain <<--- 5322.DKIM-Signature In addition, it doesn't solve what the resigner want: Do be able to resign blindly without restriction. In addition, it doesn't solve what the users want, to continue using restrictive domains EXTERNALLY from outside the restrictive domain mail machines for sending mail. In other words, the only thing a list operation will see is NON-SIGNED messages from these restrictive domains. If the MTA-receiver is not checking for this, then the new distribution is only going to have one signature. For example: From: DKIM-Signature: d=ietf.org ..... There is no primary, delegate or conditional headers, tags, overhead complexity. Lets not make it any more complex for the DKIM/DMARC verifier when all it needs to do is a simple single line DNS lookup: YesNo = IsSignerAllowed(Author.Domain, Signer.Domain) Simple. I can see where you have an short circuit optimizer (not a replacement) to help reduce the lookups, but it has to be only for strong rejection policies and it can not trusted for generating pass results purely on this basis. In other words, if an optimizer is found, then it better be correct otherwise it MUST be a REJECT condition because you don't want to force a situation where the verifier will begin to not trust this optimizer and ignore it anyway to do a lookup anyway. You will always need to do a lookup regardless of this additional complexity proposed. Note, I do see, that you also point out the uselessness of this proposal in the security section. So if it was an futile exercise in proving some technical point about BUMPing versions, fine, but it is really a waste of engineering time for folks who are highly interested in solving this problem, well that, you did have a major voice and hand in creating with your lack of support in ADSP and now DMARC. Ignoring the policy concept is no longer an option. -- HLS From nobody Mon Jun 16 20:06:08 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3601A014F for ; Mon, 16 Jun 2014 20:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 tBBZEqyInULP for ; Mon, 16 Jun 2014 20:06:03 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id AD0DC1A014D for ; Mon, 16 Jun 2014 20:06:03 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 123543FA0B00; Tue, 17 Jun 2014 12:06:02 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 0477B1A397E; Tue, 17 Jun 2014 12:06:01 +0900 (JST) From: "Stephen J. Turnbull" To: "John Levine" In-Reply-To: <20140616201759.84717.qmail@joyce.lan> References: <20140616201759.84717.qmail@joyce.lan> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 17 Jun 2014 12:06:01 +0900 Message-ID: <87egyojkva.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/n-8K1eOZp4fZ5iJLH-fjpLi02ic Cc: dmarc@ietf.org Subject: [dmarc-ietf] draft-levine-dkim-conditional-00 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, 17 Jun 2014 03:06:07 -0000 John Levine writes: > Here's a draft that puts the forwarding thing into DKIM, with the > dread version bump. I agree that this proposal needs a version bump, for the reasons given in Section 5 of the document. I still think that these semantics are better put into the -Delegate header because it's simpler and requires no version bump[1], but the version bump approach seems tenable, and is more general, I suppose. I think the requirement that To and Cc "SHOULD" be signed when "t" and "c" are present in the fs parameter should be promoted to a "MUST". It's easy to satisfy the requirement at the signing stage, adds more complexity to the verifying stage, and the flexibility is redundant. (If desired the same semantics can be achieved by specifying the addresses in To: and/or Cc: explicitly, and not signing the corresponding field.) Footnotes: [1] I don't "dread" it, I just don't think it's necessary or useful. From nobody Tue Jun 17 03:29:26 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39E81A0340 for ; Tue, 17 Jun 2014 03:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 MJ9Gb0DztLCe for ; Tue, 17 Jun 2014 03:29:23 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECA11A0336 for ; Tue, 17 Jun 2014 03:29:22 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id D6A0A3FA0975; Tue, 17 Jun 2014 19:29:21 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id A87B21A397E; Tue, 17 Jun 2014 19:29:21 +0900 (JST) From: "Stephen J. Turnbull" To: Brandon Long In-Reply-To: References: <87wqclohjo.fsf@uwakimon.sk.tsukuba.ac.jp> <20140614184731.3552.qmail@joyce.lan> <01P905HVYGEM0049PU@mauve.mrochek.com> <9796D1EB-54BE-4234-8752-4244807DDA65@isdg.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Tue, 17 Jun 2014 19:29:21 +0900 Message-ID: <87bntrkewu.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/gDBzkQ2pcWiQcrsGIfy1zPNaXVc Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 17 Jun 2014 10:29:25 -0000 Brandon Long writes: > I like the "in-band optimizer" since it gives me more > confidence... but maybe that's being naive as well, if they > compromise a domain to get on our whitelist, are they really going > to be deterred in working around a weak signature? Once they've compromised a domain on your whitelist, they can send as much spam as they like to pretty much anywhere as long as they don't care if the actual recipient is a visible addressee (they can't change To: or Cc: without breaking the signature). They can, of course, send to any visible recipient as well. You could sign From: in the token signature, which would restrict them to a specific author as well. If you're worried about that (and I think compromise of delegate domains is a genuine worry), there are a number of mitigations you could apply as a mailbox provider. 1. Sign From: in the token signature so that the abuser can't spoof arbitrary users in your domain. This may break some mailing lists, but all of the use cases I know of put a mailbox not in your domain in there anyway. 2. Make your users register the addresses they want to delegate to. (You'll actually delegate to the domain, of course, but you'll only sign for those addresses, not others at that domain.) Always use explicit delegate lists, containing only registered addresses. 3. Check that those addresses are mailing lists (you can do this in the guise of helping users register by checking for List-Post in their incoming traffic, then offering those lists at registration time). As Hector points out in a different thread, mailing lists are probably the main use case for DKIM-Delegate, since it's not possible to have a valid DKIM-Delegate field in an "on behalf of" message originating at a third party. 4. Restrict to one addressee (total) for delegated mail, to avoid providing any acquaintance information in the addressees except the list itself. Of course, this doesn't restrict abusers from spamming/phishing anybody they want (they only need one copy of message signed at the delegate domain to arrive at their botnet, then they can send it verbatim), but (1) it appears to be a specific list's post, which makes it easy for victims (or their mailbox providers) to filter in the future (To and Cc should be signed, of course), (2) for almost all recipients (ie, anybody who didn't subscribe to the list) they won't recognize any recipients, so the probability of content-based filtering becomes *much* higher, (3) the user in From: is also almost certainly unknown to anybody who isn't a genuine subscriber to the list, bumping the probability of filtering again, I would think, and (4) although your user appears in "From:", the security breach is clearly at the list domain, not your fault (this last is purely PR, of course, it doesn't make anybody who gets spam that spoofs your user feel better). Also, the token signature expires fairly quickly, so the spammers will need to be continuously harvesting list domains. But the 30,000 list-providing domains are probably much harder targets than the 3,000,000,000 user contact lists. Taken altogether, I think this raises spammer costs a lot, and probably weakens the contact-list-based attack dramatically. Steve From nobody Tue Jun 17 04:35:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A031A034D for ; Tue, 17 Jun 2014 04:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.299 X-Spam-Level: X-Spam-Status: No, score=0.299 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 swAr4wyapgHh for ; Tue, 17 Jun 2014 04:35:45 -0700 (PDT) Received: from nm8-vm0.bullet.mail.bf1.yahoo.com (nm8-vm0.bullet.mail.bf1.yahoo.com [98.139.213.95]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85DF31A034A for ; Tue, 17 Jun 2014 04:35:45 -0700 (PDT) Received: from [98.139.212.153] by nm8.bullet.mail.bf1.yahoo.com with NNFMP; 17 Jun 2014 11:35:44 -0000 Received: from [98.139.212.232] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 17 Jun 2014 11:35:44 -0000 Received: from [127.0.0.1] by omp1041.mail.bf1.yahoo.com with NNFMP; 17 Jun 2014 11:35:44 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 481275.91305.bm@omp1041.mail.bf1.yahoo.com Received: (qmail 46275 invoked by uid 60001); 17 Jun 2014 11:35:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1403004944; bh=6aJSi1m+lQ9L1U+fUhOfleN4WWKDU0cXk/FZLBTwNSM=; h=Message-ID:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XXfxX99aD6APjaZRVVS78f/que5Vh5IF1bNH5lSQ1u50RLuX1T/vFsS7zYFHdWjJm5DKIK7geFFTOkGwJKLje3I/u6+aagPRHGBs02GrRmdsvaBcro17Feow4ln0/qhEgH+qJpB585BBZemTEcpc5osxFPY+TupLXhy9sLGAfT4= X-YMail-OSG: q28lX.AVM1kb8D8jonLpKXGnt_vK0SvMghvw_QLjubumkPe .1qaOkHbQpdNGYzgZglSVbNaPQwoQS.cEem_Ro7IBDqUT8n8VaRw0y1J4o.1 y7LV0cKiPWNUtz87UKVhtEkSHsi08471ncZa7u.Gv4uOJUB11trW7XHyTvlY B47_wRkxYWp0EHIQzjxtH.H1yKvZhe0Y8AFYZQAdheEvMG8j5WPYFvXSdBVp pUgYwz_4viKMvCLUWBSKTc3yD2CRvVICswcHuVDce0IXd_ESRbWoRN6NguGG RBjn11bAOCyKc.G6WkfuHlxMFl0p9ROUayzuesMCldlvgW.K25Wfu1RBGMTH vhrcIxS0x6ArBr8r7g8R6rWC7GfzOAwmYkP9IFgVyW3KyYnF9TRkjFtIoKtE 6aouPgS0qlrHEMAHiNpzOfXkvuQ6pH3KsLYw_d6DqP4SHbzHOCqyqE9I.3P9 saX58ifuLxukVFnkRGkdH5D2rnPURkGtp.0Tzn_nyQxW1c2gogmO0OpVZV5S IGiviO8yJt4AkdI.UbZGk67RV0liP8.J_aAMQcVOfJjV9fUc9xeXIbfZPPlx 52PKCII.xARcjKFMtdNUjzLwFHdLrB2ClE7_HgRMARnhBpbZAksDQtXHKY0W tEn.v0iyuSx1O7nO6bWBESV372rzOKba9dTw_NiU67i1BcW8FNYttqpu8KAD fmrqlSJRcly4AoSGsyyDLn1SaV.FoypshkRI- Received: from [76.247.130.226] by web160502.mail.bf1.yahoo.com via HTTP; Tue, 17 Jun 2014 04:35:44 PDT X-Rocket-MIMEInfo: 002.001, J1RoZSBmdW4gYW5kIGdhbWVzIG5ldmVyIHN0b3AuJyAgJ1RpbWUgdG8gZ28gYmFjayB0byBIb3RtYWlsIHVudGlsIEkgZ2V0IGtpY2tlZCBvZmYgYWdhaW4sIGFuZCB0aGVuIGl0IGlzIGJhY2sgdG8gWWFob28gdG8gYXdhaXQgYmVpbmcga2lja2VkIG9mZi4nIA0KDQoNCi0tLSBPbiBUdWUsIDYvMTcvMTQsIExJU1RTRVJWLkxPQy5HT1YgTElTVFNFUlYgU2VydmVyICgxNC41KSA8TElTVFNFUlZATElTVFNFUlYuTE9DLkdPVj4gd3JvdGU6DQoNCj4gRnJvbTogTElTVFNFUlYuTE9DLkdPViBMSVNUU0VSViBTZXIBMAEBAQE- X-Mailer: YahooMailClassic/625 YahooMailWebService/0.8.190.668 Message-ID: <1403004944.10734.YahooMailBasic@web160502.mail.bf1.yahoo.com> Date: Tue, 17 Jun 2014 04:35:44 -0700 From: eugene hayhoe To: dmarc@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/qf-vlAjKfowkjS9kzOBn-21uo0c Subject: [dmarc-ietf] dmarc from a mailing list USER'S perspective: Fw: Your removal from the ARSCLIST list 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, 17 Jun 2014 11:35:50 -0000 'The fun and games never stop.' 'Time to go back to Hotmail until I get ki= cked off again, and then it is back to Yahoo to await being kicked off.'=20 --- On Tue, 6/17/14, LISTSERV.LOC.GOV LISTSERV Server (14.5) wrote: > From: LISTSERV.LOC.GOV LISTSERV Server (14.5) > Subject: Your removal from the ARSCLIST list > To: "Eugene Hayhoe" > Date: Tuesday, June 17, 2014, 12:00 AM > Tue, 17 Jun 2014 00:00:28 >=20 > You have been=A0 automatically removed from the=A0 > ARSCLIST list (Association > for=A0 Recorded Sound=A0 Discussion List)=A0 as > a=A0 result of=A0 repeated delivery > error=A0 reports from=A0 your mail=A0 system. > This=A0 decision was=A0 based on=A0 the > automatic error=A0 monitoring policy in=A0 effect > for=A0 the list, and=A0 has not > been reviewed=A0 or otherwise confirmed=A0 by a=A0 > human being. If=A0 you receive > this message, it=A0 means that something is wrong: > while=A0 you are obviously > able to receive mail, your mail=A0 system has been > regularly reporting that > your account did not exist, or that you were otherwise > permanently unable > to receive=A0 mail. Here is some=A0 information which > may assist=A0 you or your > local help desk in determining the cause of the problem: >=20 > - The failing address is jazzme48912@YAHOO.COM. >=20 > - The first error was reported on 2014-06-09. >=20 > - Since then, a total of 6 delivery errors have been > received. >=20 > - The last=A0 reported error was: 5.0.0 554 5.7.9=A0 > Message not accepted for > policy reasons. See http://postmaster.yahoo.com/errors/postmaster-28.html >=20 > PLEASE DO NOT=A0 IGNORE THIS MESSAGE. While you can=A0 > of course re-subscribe > to the list, it is important for=A0 you to report this > problem to your mail > administrator so that=A0 it can be solved. This > problem=A0 is not specific to > the ARSCLIST=A0 list, and also affects=A0 your private > mail. This=A0 means that > YOU HAVE PROBABLY LOST SOME PRIVATE=A0 MAIL AS WELL. > Anyone trying to write > to you=A0 during the same time=A0 frame will probably > have=A0 received the same > errors for=A0 the same=A0 reason. The ARSCLIST=A0 > list is but=A0 one of=A0 the many > people who=A0 may have=A0 tried to write=A0 to you > while=A0 your mail=A0 system was > malfunctioning. >=20 > DO NOT LET TECHNICAL PEOPLE CONVINCE YOU THAT THIS IS > NORMAL. It is never > normal for a mail system to claim=A0 that a valid, > working account does not > exist, just as it would not be=A0 normal for the post > office to return some > of=A0 your mail=A0 with=A0 "addressee=A0 > unknown" when=A0 the=A0 address was=A0 written > correctly.=A0 It is=A0 true that=A0 some mail=A0 > systems are=A0 less reliable=A0 than > others, and your technical people may be doing the best they > can with the > tools=A0 they have.=A0 But, ultimately,=A0 the > level=A0 of service=A0 that you=A0 are > receiving is the result of a=A0 business decision, and > not something due to > a universal technical limitation that=A0 one can only > accept. Reliable mail > systems do exist, and=A0 it is ultimately up to you=A0 > to decide whether this > level of service is acceptable or not. > From nobody Thu Jun 19 10:23:09 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C617F1A006E for ; Thu, 19 Jun 2014 10:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, T_DKIM_INVALID=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 WX-Px64yUeb8 for ; Thu, 19 Jun 2014 10:23:06 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A72071A0083 for ; Thu, 19 Jun 2014 10:23:06 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.129.190]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s5JHMqMx027059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jun 2014 10:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1403198585; x=1403284985; bh=L2oWwG3oofsOYnGyqCR57MtRK/2X9yF4xzAu2R3Y1GE=; h=Date:To:From:Subject:In-Reply-To:References; b=e1MFicAo2RhIutMeyePYuTT3g9xixweWBw0jsTQfPH+zfDImkkwF/BNWwJTylin+l kUyNKjKnVULH7thU7ZF2XS0PYPkoWaXeLetWaNkGbBs/5zbEmjJxc4PcdPHkgZvgNO v4hre/6TPMPKEN0F73gdDYvXcAiWCmYeTqPvcBc8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1403198585; x=1403284985; i=@elandsys.com; bh=L2oWwG3oofsOYnGyqCR57MtRK/2X9yF4xzAu2R3Y1GE=; h=Date:To:From:Subject:In-Reply-To:References; b=i/B8ei9rB076nr3DndqoQ6LqzabUM+w07gPqV2G0uqWRvHFUnKQW+/oaldqL9nqvq KmIQvGaksai77LMYVg4L/DFwii+9qgDHHrJ+y18OaqycH1a71Jp2th8E1kDyK8kHUe oe1QQ89mlCFLH4ue+m6kVxo5G/WeT0QawWIYnR0o= Message-Id: <6.2.5.6.2.20140619093658.0c118da0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 19 Jun 2014 09:49:37 -0700 To: Matt Simerson , dmarc@ietf.org From: S Moonesamy In-Reply-To: <1611380D-2178-4116-9583-EC1086942825@tnpi.net> References: <20140616010237.77460.qmail@joyce.lan> <1611380D-2178-4116-9583-EC1086942825@tnpi.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/K4zHdvwGHFi-FYv1jInJTil64kc Subject: Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version 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, 19 Jun 2014 17:23:07 -0000 Hi Matt, At 18:58 15-06-2014, Matt Simerson wrote: >Yes, it does. But SA uses the results of Mail::DKIM heuristically >and a DKIM failure is frequently not a sufficient basis for rejection. During the (old) DKIM discussions there was a view that the result of a DKIM verification was to be used as input for policy decisions. That is similar to the above. This was also discussed on a SMTP mailing list [1]. There is the following recommendation in RFC 6376: "Therefore, a Verifier SHOULD NOT treat a message that has one or more bad signatures and no good signatures differently from a message with no signature at all." Regards, S. Moonesamy 1. http://www.ietf.org/mail-archive/web/ietf-smtp/current/msg01487.html From nobody Thu Jun 19 11:15:21 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA811A0249 for ; Thu, 19 Jun 2014 11:15:19 -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_46=0.6, J_CHICKENPOX_66=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 NrsX_9wnQV7D for ; Thu, 19 Jun 2014 11:15:17 -0700 (PDT) Received: from news.winserver.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B22131A00B1 for ; Thu, 19 Jun 2014 11:15:16 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2295; t=1403201711; h=Received:Received: Message-Id:From:Subject:Date:To:Organization:List-ID; bh=5XRxgHY kcGQOHA9kjUU+qTB9khA=; b=cp3DjPV71fQ+ixD4cW64eWaR0DyQI1NGZOf8CXz j52kXlUAz82uwjDBNhn2CITDCVMr2Z7jIu6YhDMYoQ2QPGP2x9vvo9rWGRxsOs6b Es29P5GoGNZnJsEb+Gd1uR0zGLejRTFw+PJ9gMLvDGhobQ/VRg+LfE/J+ZRzvv3k GsLQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 19 Jun 2014 14:15:11 -0400 Received: from [192.168.1.162] (99-72-160-212.lightspeed.miamfl.sbcglobal.net [99.72.160.212]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2681825730.35763.4172; Thu, 19 Jun 2014 14:15:11 -0400 References: <20140616010237.77460.qmail@joyce.lan> <1611380D-2178-4116-9583-EC1086942825@tnpi.net> <6.2.5.6.2.20140619093658.0c118da0@resistor.net> Mime-Version: 1.0 (1.0) In-Reply-To: <6.2.5.6.2.20140619093658.0c118da0@resistor.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (11B651) From: Hector Santos Date: Thu, 19 Jun 2014 14:15:09 -0400 To: S Moonesamy Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Echc1PtKOE8pvRSdu-PXP_JSgT0 Cc: "dmarc@ietf.org" , Matt Simerson Subject: Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version 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, 19 Jun 2014 18:15:19 -0000 Let us remember that DKIM+Policy were separated into two protocols; a DKIM-= BASE layer and a secondary domain signing practice layer (SSP which evolved t= o ADSP). Making an invalid signature equal to a missing signature concept w= as a security logic which allowed for the exclusive or strict signing domain= policies to exist and work with one single short circuiting policy handling= state/event condition: If policy.strict and signature.missing or invalid then negatively classif= y; You must make invalid be the same as missing from a rejection or functional e= quivalent negative classification standpoint otherwise you have a security l= oophole. While DKIM-BASE tried to clean up this separation of the author domain polic= y, it could not because of all the past existing ADSP or SSP references in t= he many DKIM related RFCs, see RFC6376, section 1.1. But conceptually, it d= idn't matter what you called it. It was an author domain signing policy pro= tocol and today, it's called DMARC. DKIM has no payoff with just base sign= ing analysis . It was separated but with all the intentions of sticking seco= ndary author policy and signer trust layers on it before a payoff was realiz= ed. =20 -- Hector Santos http://www.santronics.com > On Jun 19, 2014, at 12:49 PM, S Moonesamy wrote: >=20 > Hi Matt, > At 18:58 15-06-2014, Matt Simerson wrote: >> Yes, it does. But SA uses the results of Mail::DKIM heuristically and a D= KIM failure is frequently not a sufficient basis for rejection. >=20 > During the (old) DKIM discussions there was a view that the result of a DK= IM verification was to be used as input for policy decisions. That is simil= ar to the above. This was also discussed on a SMTP mailing list [1]. There= is the following recommendation in RFC 6376: >=20 > "Therefore, a Verifier SHOULD NOT treat a message that has one or more > bad signatures and no good signatures differently from a message with > no signature at all." >=20 > Regards, > S. Moonesamy >=20 > 1. http://www.ietf.org/mail-archive/web/ietf-smtp/current/msg01487.html=20= > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >=20 From nobody Thu Jun 19 11:45:08 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162031A00B1 for ; Thu, 19 Jun 2014 11:45:06 -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 hl1vVmHA_lox for ; Thu, 19 Jun 2014 11:45:04 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A84F61A0249 for ; Thu, 19 Jun 2014 11:45:03 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id u56so2708628wes.7 for ; Thu, 19 Jun 2014 11:45:02 -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=4yHjtWnwzcq7N1mrXl/5IVhf4hWwcKZUpdc4vp57lUE=; b=LAe+INvzqD5eVhIz62+ptXl6NtGI/BmJ9AOL8Xa6Ue/FAKJuUoKwsr7swe9lFHTnJD 0iwdKM7js23TPnoeL7b3pF8CplAQHAe9fUxAWGap8JUzWmUOkIo60DcPA+mqwxy1q+lL kIMJpwnEE4EKPDgKvSnziaew6UojSDWvsseofX64VMDU0W6yucCFk+34wmY7Olq8wC7Z CKrT8dyDaMwgbSZ8LvSiu5BiB0XgCPpAfx8am/Rxt9gKNJR6ylgEZgusoCYhZ9IDPDNc hfyG2FYTtVvjRibuT0CMMN19HedCOV4EVLUesM1Yn7IGj0fCJR4oMlhWQSqcKmoe5oht y3cw== MIME-Version: 1.0 X-Received: by 10.194.186.178 with SMTP id fl18mr6720639wjc.83.1403203502229; Thu, 19 Jun 2014 11:45:02 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Thu, 19 Jun 2014 11:45:02 -0700 (PDT) In-Reply-To: References: <20140616010237.77460.qmail@joyce.lan> <1611380D-2178-4116-9583-EC1086942825@tnpi.net> <6.2.5.6.2.20140619093658.0c118da0@resistor.net> Date: Thu, 19 Jun 2014 11:45:02 -0700 Message-ID: From: "Murray S. Kucherawy" To: Hector Santos Content-Type: multipart/alternative; boundary=047d7bb04dd24c4e5804fc34c663 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/wHIIEKmeQekKzgTk16PxpoaJFkg Cc: Matt Simerson , "dmarc@ietf.org" , S Moonesamy Subject: Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version 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, 19 Jun 2014 18:45:06 -0000 --047d7bb04dd24c4e5804fc34c663 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 19, 2014 at 11:15 AM, Hector Santos wrote: > While DKIM-BASE tried to clean up this separation of the author domain > policy, it could not because of all the past existing ADSP or SSP > references in the many DKIM related RFCs, see RFC6376, section 1.1. But > conceptually, it didn't matter what you called it. It was an author domain > signing policy protocol and today, it's called DMARC. DKIM has no payoff > with just base signing analysis . It was separated but with all the > intentions of sticking secondary author policy and signer trust layers on > it before a payoff was realized. > There are reputation systems -- I built one, and I know others exist -- that use DKIM as the identifier on which reputation is built, and they've been effective in experimental environments at identifying what's good and what's outside of "good". The difference here is between active and passive determination of what's good and what's not good. If you want active, I agree that DKIM by itself isn't enough. But I disagree, with evidence, that DKIM "has no payoff with just base signing analysis". If that's not convincing enough, consider that IP reputation has been largely successful, and the input to such systems is a verified identifier, which is the same class of output DKIM provides. -MSK --047d7bb04dd24c4e5804fc34c663 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 19, 2014 at 11:15 AM, Hector Santos <hsantos@= isdg.net> wrote:
While DKIM-BASE tried to clean up this separ= ation of the author domain policy, it could not because of all the past exi= sting ADSP or SSP references in the many DKIM related RFCs, see RFC6376, se= ction 1.1. =C2=A0 But conceptually, it didn't matter what you called it= . =C2=A0It was an author domain signing policy protocol and today, it's= called DMARC. =C2=A0 DKIM has no payoff with just base signing analysis . = It was separated but with all the intentions of sticking secondary author p= olicy and signer trust layers on it before a payoff was realized.

There are reputation systems -- I built on= e, and I know others exist -- that use DKIM as the identifier on which repu= tation is built, and they've been effective in experimental environment= s at identifying what's good and what's outside of "good"= .

The difference here is between active and passive determinat= ion of what's good and what's not good.=C2=A0 If you want active, I= agree that DKIM by itself isn't enough.=C2=A0 But I disagree, with evi= dence, that DKIM "has no payoff with just base signing analysis".=

If that's not convincing enough, consider that IP reputation has be= en largely successful, and the input to such systems is a verified identifi= er, which is the same class of output DKIM provides.

-MSK
--047d7bb04dd24c4e5804fc34c663-- From nobody Thu Jun 19 12:36:36 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6FC21A03F9 for ; Thu, 19 Jun 2014 12:36:29 -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 afeE2E-qLH3J for ; Thu, 19 Jun 2014 12:36:22 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A66201A0404 for ; Thu, 19 Jun 2014 12:36:21 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id ey11so2206017pad.26 for ; Thu, 19 Jun 2014 12:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=90PDlTA56V6Gtr4/nZALQUx8NZuzn8JMDa5U0wDldRE=; b=KRXUmECy1Wfo6hHRhF/hCzLLzs4x3+xMa+kvKhTyL66Qf9gOsAgR2qidJfecU0Phly R2MfDyZTcEH9UvwmZ5CoyUkBRNoyBBiNSOiIHqedx8EpaDKhGH4shkVaBXwWLBCo7KXz o8UN9pVsqclHLslG1z9KRlXRedoQQGeMiLF1K96+Ibd4exhrUwn1DY+dMNK0LqeJ7VBH 0o3P3Hgf++99cBZGEnB964/KMnY3e4Npa+NQo9Mi+KWBHbkyiJZtcSl3MUY05x4A7cHa 5qglQsdnR0oCuOHjGbiQLqIP7qmmsxsRQhnf+/oElHMBJE0sVeDR6eMJSYPm1zraHoHB eaIw== X-Received: by 10.66.218.36 with SMTP id pd4mr8095840pac.141.1403206581370; Thu, 19 Jun 2014 12:36:21 -0700 (PDT) Received: from dhcp150.priv.bungi.com (c-76-21-122-217.hsd1.ca.comcast.net. [76.21.122.217]) by mx.google.com with ESMTPSA id is5sm9896307pbb.8.2014.06.19.12.36.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Jun 2014 12:36:20 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_8F26266B-1E47-4963-BBEC-A1C9CDF36A6F" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: Date: Thu, 19 Jun 2014 12:36:21 -0700 Message-Id: <353E8E95-9D0E-4E7A-9139-E3AEFE107D91@gmail.com> References: <20140616010237.77460.qmail@joyce.lan> <1611380D-2178-4116-9583-EC1086942825@tnpi.net> <6.2.5.6.2.20140619093658.0c118da0@resistor.net> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/gsc5eu0akmXSDsX8SQQhrCWCX2w Cc: "dmarc@ietf.org" , Matt Simerson , Hector Santos , S Moonesamy Subject: Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version 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, 19 Jun 2014 19:36:30 -0000 --Apple-Mail=_8F26266B-1E47-4963-BBEC-A1C9CDF36A6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 19, 2014, at 11:45 AM, Murray S. Kucherawy = wrote: > On Thu, Jun 19, 2014 at 11:15 AM, Hector Santos = wrote: > While DKIM-BASE tried to clean up this separation of the author domain = policy, it could not because of all the past existing ADSP or SSP = references in the many DKIM related RFCs, see RFC6376, section 1.1. = But conceptually, it didn't matter what you called it. It was an author = domain signing policy protocol and today, it's called DMARC. DKIM has = no payoff with just base signing analysis . It was separated but with = all the intentions of sticking secondary author policy and signer trust = layers on it before a payoff was realized. >=20 > There are reputation systems -- I built one, and I know others exist = -- that use DKIM as the identifier on which reputation is built, and = they've been effective in experimental environments at identifying = what's good and what's outside of "good". >=20 > The difference here is between active and passive determination of = what's good and what's not good. If you want active, I agree that DKIM = by itself isn't enough. But I disagree, with evidence, that DKIM "has = no payoff with just base signing analysis". >=20 > If that's not convincing enough, consider that IP reputation has been = largely successful, and the input to such systems is a verified = identifier, which is the same class of output DKIM provides. Dear Murray, Our company has had extensive experience dealing with email spoofing. = While reputation is able to deal with bulk spamming, it is ineffective = at dealing with a phishing problem, the intent behind DMARC. It is a = basic information issue. Those offering a reputation for a domain have = no way to judge which of their identifiers are being spoofed for = messages handled by third-parties. Only the spoofed domain can be = considered authoritative. To suggest otherwise implies the sharing of = PII, which is not acceptable in many regions. Regards, Douglas Otis --Apple-Mail=_8F26266B-1E47-4963-BBEC-A1C9CDF36A6F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On Jun 19, 2014, at 11:45 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:

On Thu, Jun 19, 2014 at 11:15 AM, Hector Santos <hsantos@isdg.net> wrote:
While DKIM-BASE tried to clean up this separation of the author domain policy, it could not because of all the past existing ADSP or SSP references in the many DKIM related RFCs, see RFC6376, section 1.1.   But conceptually, it didn't matter what you called it.  It was an author domain signing policy protocol and today, it's called DMARC.   DKIM has no payoff with just base signing analysis . It was separated but with all the intentions of sticking secondary author policy and signer trust layers on it before a payoff was realized.

There are reputation systems -- I built one, and I know others exist -- that use DKIM as the identifier on which reputation is built, and they've been effective in experimental environments at identifying what's good and what's outside of "good".

The difference here is between active and passive determination of what's good and what's not good.  If you want active, I agree that DKIM by itself isn't enough.  But I disagree, with evidence, that DKIM "has no payoff with just base signing analysis".

If that's not convincing enough, consider that IP reputation has been largely successful, and the input to such systems is a verified identifier, which is the same class of output DKIM provides.

Dear Murray,

Our company has had extensive experience dealing with email spoofing.  While reputation is able to deal with bulk spamming, it is ineffective at dealing with a phishing problem, the intent behind DMARC.  It is a basic information issue.  Those offering a reputation for a domain have no way to judge which of their identifiers are being spoofed for messages handled by third-parties.  Only the spoofed domain can be considered authoritative.  To suggest otherwise implies the sharing of PII, which is not acceptable in many regions.

Regards,
Douglas Otis

--Apple-Mail=_8F26266B-1E47-4963-BBEC-A1C9CDF36A6F-- From nobody Thu Jun 19 12:44:18 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26EEA1A03E4 for ; Thu, 19 Jun 2014 12:44:18 -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 vQlKS_cS-_Kx for ; Thu, 19 Jun 2014 12:44:16 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 628F31A0302 for ; Thu, 19 Jun 2014 12:44:16 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id x13so2692544wgg.15 for ; Thu, 19 Jun 2014 12:44:15 -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=eSlSrRVMfaMROwje5q8XJGemcA8q5+/tf9Nj1ECSrUE=; b=HbkbOrCWTSlFXuwh0fmW+qmklCxvSYAhDYO7emb1GfXS+/cR8lz5b7BXHkt9aZ/v7r LZ2tTb+7uDmuzTfa8mwcBUNlA7Qde6AAiiYTh17QoCN/b2aEC8+2jatnr3L5VUJbBYzl eXV1AwC2PF4K7YN6CR9zDtR92F2LTkNgY6EIaLQmPqnyhbceauLCkURSXAlTpKDJCXEw yhFX9RGDok6VNeTVmNz/girUouxLUFHnF04WQVHAXuVbyBoDLM1Cwj99bRhcTS3uCsmh swRWWm+9EFc7BVBNn+VqCMR4LgSfO4r55soJpQjNt3Zzrq9UlY2tAZwt570sWkjWGJq2 iKzg== MIME-Version: 1.0 X-Received: by 10.194.186.178 with SMTP id fl18mr7075971wjc.83.1403207055054; Thu, 19 Jun 2014 12:44:15 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Thu, 19 Jun 2014 12:44:14 -0700 (PDT) In-Reply-To: <353E8E95-9D0E-4E7A-9139-E3AEFE107D91@gmail.com> References: <20140616010237.77460.qmail@joyce.lan> <1611380D-2178-4116-9583-EC1086942825@tnpi.net> <6.2.5.6.2.20140619093658.0c118da0@resistor.net> <353E8E95-9D0E-4E7A-9139-E3AEFE107D91@gmail.com> Date: Thu, 19 Jun 2014 12:44:14 -0700 Message-ID: From: "Murray S. Kucherawy" To: Douglas Otis Content-Type: multipart/alternative; boundary=047d7bb04dd210200904fc359ab2 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/-ad-mXEuvYYN71TJJkc1SJG3YDE Cc: "dmarc@ietf.org" , Matt Simerson , Hector Santos , S Moonesamy Subject: Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version 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, 19 Jun 2014 19:44:18 -0000 --047d7bb04dd210200904fc359ab2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jun 19, 2014 at 12:36 PM, Douglas Otis wrote: > Our company has had extensive experience dealing with email spoofing. > While reputation is able to deal with bulk spamming, it is ineffective a= t > dealing with a phishing problem, the intent behind DMARC. It is a basic > information issue. Those offering a reputation for a domain have no way = to > judge which of their identifiers are being spoofed for messages handled b= y > third-parties. Only the spoofed domain can be considered authoritative. > To suggest otherwise implies the sharing of PII, which is not acceptable > in many regions. > =08DKIM coupled with reputation can only tell you if a given message was handled by a source with a good reputation. It doesn't evaluate any visible identifiers. I don't really understand the rest of what you're talking about here. -MSK --047d7bb04dd210200904fc359ab2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 19, 2014 at 12:36 PM, Douglas Otis <dou= g.mtview@gmail.com> wrote:
Our comp= any has had extensive experience dealing with email spoofing. =C2=A0While r= eputation is able to deal with bulk spamming, it is ineffective at dealing = with a phishing problem, the intent behind DMARC. =C2=A0It is a basic infor= mation issue. =C2=A0Those offering a reputation for a domain have no way to= judge which of their identifiers are being spoofed for messages handled by= third-parties. =C2=A0Only the spoofed domain can be considered authoritati= ve. =C2=A0To suggest otherwise implies the sharing of PII, which is not acc= eptable in many regions.

=08DKIM coupled with reputation can = only tell you if a given message was handled by a source with a good reputa= tion.=C2=A0 It doesn't evaluate any visible identifiers.=C2=A0 I don= 9;t really understand the rest of what you're talking about here.

-MSK
--047d7bb04dd210200904fc359ab2-- From nobody Thu Jun 19 13:03:51 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F9D1A0308 for ; Thu, 19 Jun 2014 13:03:47 -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 buxrHjK-Hy6Y for ; Thu, 19 Jun 2014 13:03: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 60F9D1A03EC for ; Thu, 19 Jun 2014 13:03:40 -0700 (PDT) Received: (qmail 18864 invoked from network); 19 Jun 2014 20:03:38 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 19 Jun 2014 20:03:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=10c67.53a3421a.k1406; i=johnl@user.iecc.com; bh=tft20N2cj1U2GtHjLYevSaE/KHWd8Fux6uPW65BTnRE=; b=JgqVywIZ8MB87VxR3Hav+UbfmOvBhbIwNLV45v9x8DkVJxhHQSZMji0lOe5Az4vDwdXkPGLzQg5WrGDVFuaRqe+rg+LJXrl8UCQ28S3LauuWW1tWg1ToK6FsBhWD2CjLB/TrPKy7oXMI2VgiVsyftQNsDVX2iEGoXosT3+pW6gZdDkeD6Z/Ep06hyIhJTGBcqpaiM/Df4lT/OwzYJuRl2Ec70XPCrUq9gqAzptcDEg6VUfdMEKp2qA2mk8PtQob4 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=10c67.53a3421a.k1406; olt=johnl@user.iecc.com; bh=tft20N2cj1U2GtHjLYevSaE/KHWd8Fux6uPW65BTnRE=; b=SUnSWQYd6DzUBRWWptNKn4v4jT7HzvLHSbQQnA6RcmiSr4R6BOLVqT67t9yY2vkFwfNShS1Bip4QybVs9sXcHi+vqoIYoS0BFdKrQtoKkZZH9fkGHyV6nDT7U9fFi3RBJ+WVUZvKOChkSZJDIBs2xMJxnycANNTU97ztgMVK+RhNQDX3nm6+bSdBSicNMgaGxEa7239Y8G5CGQJhds0cl7iQk+o8ljbSx1ub9dAgdAIjQ+4j+63RC5D+NEwDq0WJ Date: 19 Jun 2014 20:03:16 -0000 Message-ID: <20140619200316.68710.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/E7Ush5Ggotj9ml0IxPkxnpskPBk Subject: [dmarc-ietf] So if you don't want a DKIM version bump ... 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, 19 Jun 2014 20:03:47 -0000 Here's the exact same proposal, except done with a new header CDKIM-Signature rather than a DKIM version bump. A new version of I-D, draft-levine-cdkim-00.txt has been successfully submitted by John Levine and posted to the IETF repository. Name: draft-levine-cdkim Revision: 00 Title: CDKIM Signatures Document date: 2014-06-19 Group: Individual Submission Pages: 5 URL: http://www.ietf.org/internet-drafts/draft-levine-cdkim-00.txt Status: https://datatracker.ietf.org/doc/draft-levine-cdkim/ Htmlized: http://tools.ietf.org/html/draft-levine-cdkim-00 Abstract: The DKIM protocol applies a cryptographic signature to an e-mail message. This specification defines a DKIM-like signature that includes the specification of external conditions that must be satisfied for a signature to be valid. From nobody Thu Jun 19 13:04:23 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E87381A0415 for ; Thu, 19 Jun 2014 13:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.078 X-Spam-Level: X-Spam-Status: No, score=-101.078 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 6nWZsZEhY_YT for ; Thu, 19 Jun 2014 13:04:08 -0700 (PDT) Received: from catinthebox.net (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id AE3AE1A03EC for ; Thu, 19 Jun 2014 13:04:07 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=7556; t=1403208245; h=Received:Received: Message-Id:From:Subject:Date:To:Organization:List-ID; bh=0l4iFqw RY6yDnMhSQcuMkrhZhqQ=; b=nM9JKcAeYAmXja0hdt+Hz1U/1nTHJJzR8/cCb7V NMWtABCR//atC7bED3UY0oIE/Yt37lfmjIDLUmz/0a1Zs26HvaFnkkSXRfw1TM0q HDYgvNnHa48BcS9GZtyQJk33kZNarqIUSjpiHHYk3pzRvjSgLu+nMuEij9JBqBCa jUKM= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Thu, 19 Jun 2014 16:04:05 -0400 Received: from [192.168.1.162] (99-72-160-212.lightspeed.miamfl.sbcglobal.net [99.72.160.212]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2688358568.35763.3460; Thu, 19 Jun 2014 16:04:04 -0400 References: <20140616010237.77460.qmail@joyce.lan> <1611380D-2178-4116-9583-EC1086942825@tnpi.net> <6.2.5.6.2.20140619093658.0c118da0@resistor.net> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-B11214F7-3BFC-42C4-9AEC-24328369A936 Content-Transfer-Encoding: 7bit Message-Id: <19E404FF-228E-426B-ACDA-97EDC50F23DF@isdg.net> X-Mailer: iPad Mail (11B651) From: Hector Santos Date: Thu, 19 Jun 2014 16:04:01 -0400 To: "Murray S. Kucherawy" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Z2hIDf-CIUxiLYuDnDeX4Itkjgg Cc: "dmarc@ietf.org" , Matt Simerson , S Moonesamy Subject: Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version 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, 19 Jun 2014 20:04:13 -0000 --Apple-Mail-B11214F7-3BFC-42C4-9AEC-24328369A936 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Let me clarify it.=20 =46rom a deterministic protocol standpoint, depending only on base signing a= nalysis has no payoff, i.e. no filtering is legitimately possible with high c= onfidence and zero/low false positive. =20 What is left is non-deterministic, heuristic, classification Bayesian scorin= g, learning, "fuzzy, neural net, expert system" and similar AI-like logic m= ethods, including SA like methods. Sure, you can learn from weighting indet= erminate results. But it's not deterministic, not 1 nor 0, but in between. N= ot yes/no, but maybe.=20 I agree this method were always possible, and expected it in order to deal w= ith these unknowns "in-between" results, the ones that result from relaxed o= r no policies. The only real issue with this method is that it's not sharea= ble. It could not be a network persistent and consistent protocol method un= less there was a centralized repository concept/service everyone can check w= ith similar results. If a site depends on such a method, then the sites tha= t do no sign up for this central reputation lookup service will become targe= ts. It has long been shown that bad guys do target "weaker" sites especial= ly when it's well known a common reputation method doesn't exist in practice= for everyone to use. The DNS-based author domain defined policy is the onl= y common approach we have now.=20 -- Hector Santos http://www.santronics.com > On Jun 19, 2014, at 2:45 PM, "Murray S. Kucherawy" w= rote: >=20 >> On Thu, Jun 19, 2014 at 11:15 AM, Hector Santos wrote:= >> While DKIM-BASE tried to clean up this separation of the author domain po= licy, it could not because of all the past existing ADSP or SSP references i= n the many DKIM related RFCs, see RFC6376, section 1.1. But conceptually, i= t didn't matter what you called it. It was an author domain signing policy p= rotocol and today, it's called DMARC. DKIM has no payoff with just base si= gning analysis . It was separated but with all the intentions of sticking se= condary author policy and signer trust layers on it before a payoff was real= ized. >=20 > There are reputation systems -- I built one, and I know others exist -- th= at use DKIM as the identifier on which reputation is built, and they've been= effective in experimental environments at identifying what's good and what'= s outside of "good". >=20 > The difference here is between active and passive determination of what's g= ood and what's not good. If you want active, I agree that DKIM by itself is= n't enough. But I disagree, with evidence, that DKIM "has no payoff with ju= st base signing analysis". >=20 > If that's not convincing enough, consider that IP reputation has been larg= ely successful, and the input to such systems is a verified identifier, whic= h is the same class of output DKIM provides. >=20 > -MSK > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --Apple-Mail-B11214F7-3BFC-42C4-9AEC-24328369A936 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Let me clarify it. 
=46rom a deterministic protocol standpoint,  depending only= on base signing analysis has no payoff, i.e. no filtering is legitimately p= ossible with high confidence and zero/low false positive.  
<= br>
What is left is non-deterministic, heuristic, classification B= ayesian scoring,  learning,  "fuzzy, neural net, expert system" an= d similar AI-like logic methods, including SA like methods.  Sure, you c= an learn from weighting indeterminate results.  But it's not determinis= tic, not 1 nor 0, but in between. Not yes/no, but maybe. 
I agree this method were always possible, and expected it in ord= er to deal with these unknowns "in-between" results, the ones that result fr= om relaxed or no policies.  The only real issue with this method is tha= t it's not shareable.  It could not be a network persistent and consist= ent protocol method unless there was a centralized repository concept/servic= e everyone can check with similar results.  If a site depends on such a= method, then the sites that do no sign up for this central reputation looku= p service will become targets.   It has long been shown that bad guys d= o target "weaker" sites especially when it's well known a common reputation m= ethod doesn't exist in practice for everyone to use.  The DNS-based aut= hor domain defined policy is the only common approach we have now. 


On Jun 19, 2= 014, at 2:45 PM, "Murray S. Kucherawy" <superuser@gmail.com> wrote:

On Thu, Jun 19, 2014 at 11:15 AM, Hector Santos <hs= antos@isdg.net> wrote:
While DKIM-BASE tried to clean up this separat= ion of the author domain policy, it could not because of all the past existi= ng ADSP or SSP references in the many DKIM related RFCs, see RFC6376, sectio= n 1.1.   But conceptually, it didn't matter what you called it.  I= t was an author domain signing policy protocol and today, it's called DMARC.=   DKIM has no payoff with just base signing analysis . It was separate= d but with all the intentions of sticking secondary author policy and signer= trust layers on it before a payoff was realized.

There are reputation systems -- I built one= , and I know others exist -- that use DKIM as the identifier on which reputa= tion is built, and they've been effective in experimental environments at id= entifying what's good and what's outside of "good".

The difference here is between active and passive determinati= on of what's good and what's not good.  If you want active, I agree tha= t DKIM by itself isn't enough.  But I disagree, with evidence, that DKI= M "has no payoff with just base signing analysis".

If that's not convincing enough, consider that IP reputation has been la= rgely successful, and the input to such systems is a verified identifier, wh= ich is the same class of output DKIM provides.

-MSK
____________________= ___________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mai= lman/listinfo/dmarc
= --Apple-Mail-B11214F7-3BFC-42C4-9AEC-24328369A936-- From nobody Thu Jun 19 14:03:42 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BD91A0415 for ; Thu, 19 Jun 2014 14:03:40 -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 l2AQeZXBhKtw for ; Thu, 19 Jun 2014 14:03:38 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.88]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01A651A0083 for ; Thu, 19 Jun 2014 14:03:37 -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.0.980.1; Thu, 19 Jun 2014 20:28:51 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.12.246]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.12.246]) with mapi id 15.00.0980.000; Thu, 19 Jun 2014 20:28:51 +0000 From: Terry Zink To: John Levine , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] So if you don't want a DKIM version bump ... Thread-Index: AQHPi/mxqD0sNp7VAk23pMyMBPUvi5t431sA Date: Thu, 19 Jun 2014 20:28:51 +0000 Message-ID: <5f6bf14cdf67430ca0527477c62e0661@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> References: <20140619200316.68710.qmail@joyce.lan> In-Reply-To: <20140619200316.68710.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.160.166] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02475B2A01 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(189002)(13464003)(377454003)(377424004)(199002)(83322001)(19580395003)(19580405001)(15975445006)(4396001)(79102001)(83072002)(2656002)(85852003)(92566001)(87936001)(106116001)(76482001)(15202345003)(77982001)(33646001)(21056001)(81342001)(64706001)(20776003)(66066001)(80022001)(74662001)(46102001)(74502001)(31966008)(101416001)(50986999)(54356999)(81542001)(99396002)(105586002)(76176999)(561944003)(24736002)(106276001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2SR01MB605; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/WDVq5CBbQR_MzNUYKfg8RYrl7B0 Subject: Re: [dmarc-ietf] So if you don't want a DKIM version bump ... 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, 19 Jun 2014 21:03:40 -0000 It would be nice to have some concrete examples in the draft, I find those = easier to follow than descriptions. So, maybe something like: DKIM-Signature: v=3D1; a=3Drsa-sha1; c=3Drelaxed/relaxed; s=3Ds1024; d=3Dse= nder.example.com; h=3DFrom:To:Reply-To:Date:Subject:MIME-Version:Content-Type:List-Unsubsc= ribe:Message-ID;=20 bh=3D... b=3D DKIM-Signature: v=3D1; a=3Drsa-sha1; c=3Drelaxed/relaxed; s=3Ds1024; d=3Dse= nder.example.com; h=3DFrom:To:Reply-To:Date;=20 l=3D bh=3D... b=3D DKIM-Signature: v=3D1; a=3Drsa-sha1; c=3Drelaxed/relaxed; s=3Ds1024; d=3Ddi= scussionlists.org; h=3DFrom:To:Reply-To:Date:Subject:MIME-Version:Content-Type:List-Unsubsc= ribe:Message-ID;=20 bh=3D... b=3D From: sender@sender.example.com To: discussion@discussionlist.org CDKIM-Signature: cs=3D?; fs=3D?; -- Terry -----Original Message----- From: dmarc [mailto:dmarc-bounces@ietf.org] On Behalf Of John Levine Sent: Thursday, June 19, 2014 1:03 PM To: dmarc@ietf.org Subject: [dmarc-ietf] So if you don't want a DKIM version bump ... Here's the exact same proposal, except done with a new header CDKIM-Signature rather than a DKIM version bump. A new version of I-D, draft-levine-cdkim-00.txt has been successfully submitted by John Levine and posted to the IETF repository. Name: draft-levine-cdkim Revision: 00 Title: CDKIM Signatures Document date: 2014-06-19 Group: Individual Submission Pages: 5 URL: http://www.ietf.org/internet-drafts/draft-levine-cdkim-00.t= xt Status: https://datatracker.ietf.org/doc/draft-levine-cdkim/ Htmlized: http://tools.ietf.org/html/draft-levine-cdkim-00 Abstract: The DKIM protocol applies a cryptographic signature to an e-mail message. This specification defines a DKIM-like signature that includes the specification of external conditions that must be satisfied for a signature to be valid. _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc From nobody Thu Jun 19 14:55:07 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3651A045B for ; Thu, 19 Jun 2014 14:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, 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 tLseY0hxCfxU for ; Thu, 19 Jun 2014 14:54:58 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5381A044D for ; Thu, 19 Jun 2014 14:54:58 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P979IV9UVK004D2G@mauve.mrochek.com> for dmarc@ietf.org; Thu, 19 Jun 2014 14:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1403214604; bh=/z49L6+9aCyO9T2JOGpGFXHcre4CCI5dH3MpvNecBYY=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=Ng8hdgZwJoC2HrTuKe47DLiGEAq/PqY/uPijgBS91GOuyce8bc6KEpAglx+PBe1hF FLurTT6IptIwFojcTCIV1C5Eh5rTP4a6L1pzISIKS1euCTsZVtQSPN+hpGseRZUdlR R3YtFFOdIhaK6wYS0BKH59sgjRAK4ZNBD0+U/kJU= 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 <01P8UD4AOU8W0049PU@mauve.mrochek.com>; Thu, 19 Jun 2014 14:49:45 -0700 (PDT) Message-id: <01P979ITB1BW0049PU@mauve.mrochek.com> Date: Thu, 19 Jun 2014 14:46:04 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 19 Jun 2014 20:03:16 +0000" <20140619200316.68710.qmail@joyce.lan> Sender: Ned Freed References: <20140619200316.68710.qmail@joyce.lan> To: John Levine Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/WcDjeHrkRmJrsaJw2D9u7fc5Z7M Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] So if you don't want a DKIM version bump ... 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, 19 Jun 2014 21:55:03 -0000 So, are we going to create a new header field every time we come up with some new required semantic we want to attach to a DKIM signature? Admittedly this hasn't happened previously, but predicting the future has never been our strong suit. Why don't we fix the extensibility problem instead? Ned > Here's the exact same proposal, except done with a new header > CDKIM-Signature rather than a DKIM version bump. > A new version of I-D, draft-levine-cdkim-00.txt > has been successfully submitted by John Levine and posted to the > IETF repository. > Name: draft-levine-cdkim > Revision: 00 > Title: CDKIM Signatures > Document date: 2014-06-19 > Group: Individual Submission > Pages: 5 > URL: http://www.ietf.org/internet-drafts/draft-levine-cdkim-00.txt > Status: https://datatracker.ietf.org/doc/draft-levine-cdkim/ > Htmlized: http://tools.ietf.org/html/draft-levine-cdkim-00 > Abstract: > The DKIM protocol applies a cryptographic signature to an e-mail > message. This specification defines a DKIM-like signature that > includes the specification of external conditions that must be > satisfied for a signature to be valid. > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Thu Jun 19 15:14:50 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B78C1A02C9 for ; Thu, 19 Jun 2014 15:14:49 -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 TooUsPYeoawC for ; Thu, 19 Jun 2014 15:14:48 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0668E1A02B0 for ; Thu, 19 Jun 2014 15:14:47 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id bs8so3581676wib.3 for ; Thu, 19 Jun 2014 15:14:46 -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=Z3+V+ua2hfWwMDndSkX7BTsYMyjTp6NUSWVdsseSM4A=; b=pj6TPnNELzTD34jlHv2LHsCmw2vhcbgtxLdzO65WogsAsuTvfkp/YNaNx9x/hpptva C5ztquCJ08k6dBAKHyx4EDzG7cpFzWC4zgQepy/aM6+po1ECdzA7JOPtgfQCK+yyKza7 Tr/V490jL7VwZUJ9xiGt7FDcbcg57yXGmh29iQaOwkGQORS2ipzxHMpZH4oeTOjhQEn3 fbHfQDkH8salDGcrnnPnf7iQFLqwdOMPRRQ3TaOx61xa1fzFP2jsPVx7PeN882LzXCqg YrzqAIArP373q8nL6ZaFWn/uoudOt/c177TTEJP0k3u5qmpVitgITn7kWplT2cFdFC+Y LA6g== MIME-Version: 1.0 X-Received: by 10.180.83.105 with SMTP id p9mr10024909wiy.8.1403216086501; Thu, 19 Jun 2014 15:14:46 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Thu, 19 Jun 2014 15:14:46 -0700 (PDT) In-Reply-To: <01P979UCLT0E0049PU@mauve.mrochek.com> References: <20140616201759.84717.qmail@joyce.lan> <01P979UCLT0E0049PU@mauve.mrochek.com> Date: Thu, 19 Jun 2014 15:14:46 -0700 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=f46d044282de61129304fc37b4cd Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/hk50UtB-d4i6IpgT2Iz67TuSllM Cc: "dmarc@ietf.org" , John Levine Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-00 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, 19 Jun 2014 22:14:49 -0000 --f46d044282de61129304fc37b4cd Content-Type: text/plain; charset=UTF-8 On Thu, Jun 19, 2014 at 2:51 PM, Ned Freed wrote: > > > I'm uneasy with an increase in version that isn't done in a complete > > replacement for RFC6376. We're not just registering a couple of new > > extension tags here. I would prefer that, if we do go decide to go down > > this route, we crack it open and do a proper revision document rather > than > > just describing v2 in terms of "changes since v1". > > > There's a problem in front of us that needs solving. Part of that seems to > call > for a limited semantic extension to DKIM. Let's by all means make that one > extension in way that generalizes as much as possible. > > But using this as justification to crack open the entire specification? > That is not a good idea. I agree, mostly. I wasn't advocating for cracking open the entire specification. Assuming we go this path (rather than bolting down DKIM-Delegate's problems somehow), I would much rather publish RFC6376 again, with the "v=2" and the two new tags and maybe a paragraph about backward compatibility, but absolutely no other changes. I don't want to spend time reviewing and tweaking the whole damned thing again. -MSK --f46d044282de61129304fc37b4cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 19, 2014 at 2:51 PM, Ned Freed <ned.freed= @mrochek.com> wrote:

> I'm uneasy with an increase in version that isn't done in a co= mplete
> replacement for RFC6376. =C2=A0We're not just registering a couple= of new
> extension tags here. =C2=A0I would prefer that, if we do go decide to = go down
> this route, we crack it open and do a proper revision document rather = than
> just describing v2 in terms of "changes since v1".


There's a problem in front of us that needs solving. Part of that seems= to call
for a limited semantic extension to DKIM. Let's by all means make that = one
extension in way that generalizes as much as possible.

But using this as justification to crack open the entire specification?
That is not a good idea.

I agree, mostly.= =C2=A0 I wasn't advocating for cracking open the entire specification.= =C2=A0 Assuming we go this path (rather than bolting down DKIM-Delegate'= ;s problems somehow), I would much rather publish RFC6376 again, with the &= quot;v=3D2" and the two new tags and maybe a paragraph about backward = compatibility, but absolutely no other changes.=C2=A0 I don't want to s= pend time reviewing and tweaking the whole damned thing again.

-MSK
--f46d044282de61129304fc37b4cd-- From nobody Thu Jun 19 15:20:52 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD7C1A0460 for ; Thu, 19 Jun 2014 15:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, 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 WqzGwFNIYBsu for ; Thu, 19 Jun 2014 15:04:16 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 24A1E1A0320 for ; Thu, 19 Jun 2014 15:04:16 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P979UE6GCG005JJL@mauve.mrochek.com> for dmarc@ietf.org; Thu, 19 Jun 2014 14:59:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1403215162; bh=IjVDdulRaRWRo1GfCiFwodr37Sms5v4B1VsnBChmWvM=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=BMjNUpw7NR1VyZhGKp4QDsTN/3kc5vczuLs+2BrSkGsPthNCPB0VZsDKbrnnFqRCW NqQiXmCyy9KXiV/dH4NJSfTHPtQYUrE0sRtcDCZsVMFLgrEItmpJS4qw7xAQNHRe9y g7cP6K/T6qsmkxWWNJVN14cZQL+I1Fj6BXwfxfPQ= 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 <01P8UD4AOU8W0049PU@mauve.mrochek.com>; Thu, 19 Jun 2014 14:59:03 -0700 (PDT) Message-id: <01P979UCLT0E0049PU@mauve.mrochek.com> Date: Thu, 19 Jun 2014 14:51:10 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 16 Jun 2014 13:45:48 -0700" References: <20140616201759.84717.qmail@joyce.lan> To: "Murray S. Kucherawy" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/FDoFzr3F7xfVM-tquuOS_7PAXdY X-Mailman-Approved-At: Thu, 19 Jun 2014 15:20:51 -0700 Cc: "dmarc@ietf.org" , John Levine Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-00 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, 19 Jun 2014 22:04:17 -0000 > On Mon, Jun 16, 2014 at 1:17 PM, John Levine wrote: > > Here's a draft that puts the forwarding thing into DKIM, with the > > dread version bump. It defines a general syntax for conditional > > signatures, with the forwarding signature the only condition defined > > so far. (Since you asked, new conditions don't need another version > > bump.) > > > I'm uneasy with an increase in version that isn't done in a complete > replacement for RFC6376. We're not just registering a couple of new > extension tags here. I would prefer that, if we do go decide to go down > this route, we crack it open and do a proper revision document rather than > just describing v2 in terms of "changes since v1". Behold the main problem with version numbers in protocols - people invariably attach more significance to such values that they really deserve. This is especially true when the number is "2" - they call it *second* system syndrome for a reason. Nathaniel and I have long since agreed that the MIME-Version field is one of the biggest, if not the biggest, fuckups in MIME. And yet it's a mistake we keep on making in protocol design. Sigh. There's a problem in front of us that needs solving. Part of that seems to call for a limited semantic extension to DKIM. Let's by all means make that one extension in way that generalizes as much as possible. But using this as justification to crack open the entire specification? That is not a good idea. Ned From nobody Thu Jun 19 16:20:22 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733B61A04F6 for ; Thu, 19 Jun 2014 16:20:20 -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 AHKtHJDwALpz for ; Thu, 19 Jun 2014 16:20: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 3F9D11A04D2 for ; Thu, 19 Jun 2014 16:20:18 -0700 (PDT) Received: (qmail 52889 invoked from network); 19 Jun 2014 23:20:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:mime-version:content-type:user-agent:cleverness; s=ce98.53a37031.k1406; bh=8D1Yh51JmFPU7Dcw6aFHUnatm2wmV23VHlyn2Jymejg=; b=TPrSkn/u1TbxXcMckowhh+27ofovNLZDdn+REwLQLLpUlUh5RyEH1gHj8wGCnJcff9qTLSwT/hNsSb3m4hPAxOwfF2b/TyB2m+5mLVeA0QGjy+Rg0U0Q6iP5dvvoof68jFUqD4uY+3pDnIC68p498DOBG34QYfDb67eNSCfy6Z/PA2hNVIsRcZdlltknpUjQU5zdiLfF6kRo6CIbwOMSFU0ibSUZBh6YnEjhmETn1vsFmmqccbJsbwex50U4uICf DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:mime-version:content-type:user-agent:cleverness; s=ce98.53a37031.k1406; bh=8D1Yh51JmFPU7Dcw6aFHUnatm2wmV23VHlyn2Jymejg=; b=CUxK08xFrRMrhtadRlsX8OXrU3pk4s9k7bFH26AS2KoAzSHODr0SCcH51xX6M5cuZqzsTROvU3QTDRVHYQoYMJb3XFJzDPxJ1Ce3o/SlTMkumRCckuzDF4SftZQYvsG1R8tFl5LUpbRN+qATQGN7XbHDtnXgLgPKDgiq3PcZYEd6bgABkqUBwmqgK++t8POXG0k3oJ3xABv6U9YOTVH0FE4gym72THxG2AxtgA1EK93XCdyal/1k0FZ8w9qxPp8R 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; 19 Jun 2014 23:20:17 -0000 Date: 19 Jun 2014 19:20:17 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" User-Agent: Alpine 2.11 (BSF 23 2013-08-11) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/vKvvcQyYNrBMa7PIWM9pbfuKoNE Cc: "dmarc@ietf.org" Subject: [dmarc-ietf] The theory of DKIM versions 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, 19 Jun 2014 23:20:20 -0000 > I'm uneasy with an increase in version that isn't done in a complete > replacement for RFC6376. The problem may be that we don't agree about what DKIM versions mean. Here's what I would like them to mean: a) The lexical syntax of DKIM signatures will never change, and a v=1 parser will aways be able to find and parse all of the tags in a signature. (If you need to change the syntax, invent a new header name.) b) We will never change the meaning of defined tag. (If you want a tag that means something different, define a new one.) c) Whenever we add new tags that require that the verifier understand them to get the right answer, we increment the version number. d) Versions are cumulative. Every signature that is a valid version N signature is still a valid version N+1 signature, give or take the change in the b= hash due to the version bump. Key records don't need version numbers, since a key should only be used by signatures at a version high enough to handle whatever is in the key. This sort of versioning seems to work fine for file systems and other constructs where there's no feedback from the reader back to the writer. Either the reader can deal with it, or not. But a version bump is not a big deal, and doesn't require reissuing the whole spec. I can think of a variety of ways to get this effect by hacks that stay at v=1, e.g. R's, John From nobody Thu Jun 19 16:51:35 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 413E51A031A for ; Thu, 19 Jun 2014 16:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.762 X-Spam-Level: X-Spam-Status: No, score=0.762 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 l3RTL2yTMRnE for ; Thu, 19 Jun 2014 16:51:33 -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 42AC01A030B for ; Thu, 19 Jun 2014 16:51:33 -0700 (PDT) Received: (qmail 57043 invoked from network); 19 Jun 2014 23:51:31 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 19 Jun 2014 23:51:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=11362.53a37783.k1406; i=johnl@user.iecc.com; bh=ywmvC2CBMpmHKhSCnLA1WBHEVOuE55vlQ5GgcVa6EtQ=; b=sH/aIPQ+q8N+c/F5yxnMYR2QyfeC04G1hE5Qp7Kr9FUeZHufqrcH+P1z/eR/1Y72IDMDk2EbDsEpnoU6OpAErH02TYUZcdCBcnoa9GcFSObFAUXLdhLn7qQPTQsqwJhAnzELMDoDZTfS8LC4KNPOg/tQ9HQtvJH4SAt61v62MoChnNayjJlbIuF4o4ul1fbssdHjn8PHxTTtVpCwDkdZjFDyMEXpjPKTMwzR5dakoKZmGs6f3wKbaZUGB5jTG0/M DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=11362.53a37783.k1406; olt=johnl@user.iecc.com; bh=ywmvC2CBMpmHKhSCnLA1WBHEVOuE55vlQ5GgcVa6EtQ=; b=U6XAFZJgBfH+CncXOrBrJUSs0TwK30mTBawtLeSYFWUl71+6m0NJ+N78WO/utTqnytcokwkiSWw1lUNrzIg4DQmy6TFtMVAy93TqQVRFZrgdBdmFcfU8dqLD3smYioj2BmsQWZpSahgUWm4itukaUhQVlRDQIz5i3SL7ryMt6t2ekSVs09TlsbWPIcrmdNMRX6ZASJqIuXpHvOYFTIzTiMYmIl4L2cAG0polXe9xwJ6+z0Jkbdwx1aNvqzujy0/P Date: 19 Jun 2014 23:51:08 -0000 Message-ID: <20140619235108.70497.qmail@joyce.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: http://mailarchive.ietf.org/arch/msg/dmarc/td8QBXpmPTfmvYAdaIoV_2kUOMk Cc: johnl@taugh.com Subject: Re: [dmarc-ietf] The theory of DKIM versions 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, 19 Jun 2014 23:51:34 -0000 sigh, stupid editor. As I was saying: I can think of a variety of ways to get this effect by hacks that stay at v=1, all rather ugly. For example, we could invent pseudo-canonicalizations like c=condrelaxed/condsimple which are the same as relaxed and simple, but only are valid if the verifier also understands the cs= condition. But really, ugh. This sort of thing will doubtless come up again, and it doesn't seem hard to do an extension framework that is simple but does what we need it to do. R's, John From nobody Thu Jun 19 17:09:16 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E6F1A02E2 for ; Thu, 19 Jun 2014 17:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] 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 LatxhRuupkks for ; Thu, 19 Jun 2014 17:09:13 -0700 (PDT) Received: from egssmtp01.att.com (egssmtp01.att.com [144.160.112.12]) by ietfa.amsl.com (Postfix) with ESMTP id 299A31A02E0 for ; Thu, 19 Jun 2014 17:09:13 -0700 (PDT) Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp01.att.com ( egs 8.14.5/8.14.5) with ESMTP id s5K09AUo000740 for ; Thu, 19 Jun 2014 19:09:12 -0500 Received: from vpn-135-70-98-70.vpn.swst.att.com ([135.70.98.70]) by maillennium.att.com (mailgw1) with ESMTP id <20140620000909gw100j0caee>; Fri, 20 Jun 2014 00:09:10 +0000 X-Originating-IP: [135.70.98.70] Message-ID: <53A37BA4.7040206@att.com> Date: Thu, 19 Jun 2014 20:09:08 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ned Freed , John Levine References: <20140619200316.68710.qmail@joyce.lan> <01P979ITB1BW0049PU@mauve.mrochek.com> In-Reply-To: <01P979ITB1BW0049PU@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/_wtGPHXtgEDNWvi9s6xiC0biooE Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] So if you don't want a DKIM version bump ... 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, 20 Jun 2014 00:09:15 -0000 On 6/19/14, 5:46 PM, Ned Freed wrote: > So, are we going to create a new header field every time we come up with > some new required semantic we want to attach to a DKIM signature? > > Admittedly this hasn't happened previously, but predicting the future has > never been our strong suit. > > Why don't we fix the extensibility problem instead? +1 Tony Hansen From nobody Thu Jun 19 17:38:48 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C161A0302 for ; Thu, 19 Jun 2014 17:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.063 X-Spam-Level: X-Spam-Status: No, score=0.063 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_21=0.6, 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 qjEeps7IFTxd for ; Thu, 19 Jun 2014 17:38: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 A9C621A02A9 for ; Thu, 19 Jun 2014 17:38:38 -0700 (PDT) Received: (qmail 65972 invoked from network); 20 Jun 2014 00:38:37 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 20 Jun 2014 00:38:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=113d5.53a3828d.k1406; i=johnl@user.iecc.com; bh=7XFl6YUyGNtHY3UXd2hXIbHXeR+byT4gQMNApz+7wOA=; b=IUEdb1GjxK0Q/rddAbALGsYmUNufeo+cGYjSteTIJISVUx2jzbjDFskpw4zy1QbcPsTsbPbcMXIac63vCDDqzGPvVO5bE3Tl8CdA2e2gT7Ewq7GGu7J3qUhVhj06ZGLwe1Pb8c3gAxSazaxtOduGK3TTc12NPFU1YATUaeaIbLMigkG32bgiWgDfdMKxZL/6WQG+29rW3YU34ycz3gvsckWBJtMSYBtXV6ivRci4UzLPcJj/1Fk4hMK2KTbIUcQE DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=113d5.53a3828d.k1406; olt=johnl@user.iecc.com; bh=7XFl6YUyGNtHY3UXd2hXIbHXeR+byT4gQMNApz+7wOA=; b=VtWxIXhhDTyueBSpi7VrXzNLHY4cQqLcNYEhcEmFMRRUvDTKZAO5h/udg2XTuVfp1/pCLbH5NM7QXOJsGMvVatO4kz6Qe3PTqCf5LBSCLzjCP8zP9P+hY0O68V1v5puABwXCqq0UZcMYejna8Z+Aw+rIkTKsQFpmjTrZd1ro9ckTPdwxeEJHCEukdRQA2hpHTZe9NayVBonuJWFCfdCPxtzMgQakGJ+//i8Q52F/mEOuT0H+LgzQ0GXzlNrR+B9a Date: 20 Jun 2014 00:38:15 -0000 Message-ID: <20140620003815.70612.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <5f6bf14cdf67430ca0527477c62e0661@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/nvF33NhPFlOhvMczoFFnrl-6BzU Cc: tzink@exchange.microsoft.com Subject: Re: [dmarc-ietf] signature sample, was So if you don't want 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, 20 Jun 2014 00:38:43 -0000 Here's an example. The top signature is from the list, the second and third signatures were applied by the sender. The second is the normal signature and the third a weak conditional signature. The third has cs=fs which means it's only valid with an additional (forwarder) signature, and fs=t means that signature has to be from the domain on the To: line. When the list does its thing, it invalidates the strong signature from the original sender, but it adds its own signature which satisfies the weak signature's condition, so the weak signature becomes valid. DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=s1024; d=discussionlists.org; h=From:To:Reply-To:Date:Subject:MIME-Version:Content-Type:List-Unsubscribe:Message-ID; bh=... b= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=s1024; d=sender.example; h=From:To:Reply-To:Date:Subject:MIME-Version:Content-Type:List-Unsubscribe:Message-ID; bh=... b= DKIM-Signature: v=2; a=rsa-sha1; c=relaxed/relaxed; s=s1024; d=sender.example; h=From:To:Date; l=0; cs=fs; fs=t; bh=... b= From: sender@sender.example To: discussion@discussionlist.org Subject: [discussion-l] cat videos lol List-Id: blah blah -- This is the discussion-l list, with a beautiful message footer. From nobody Thu Jun 19 17:46:20 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8AC1A02A9 for ; Thu, 19 Jun 2014 17:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.529 X-Spam-Level: X-Spam-Status: No, score=-1.529 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] 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 45GF67IpdFHA for ; Thu, 19 Jun 2014 17:46:17 -0700 (PDT) Received: from egssmtp01.att.com (egssmtp01.att.com [144.160.112.12]) by ietfa.amsl.com (Postfix) with ESMTP id 237CD1A0126 for ; Thu, 19 Jun 2014 17:46:14 -0700 (PDT) Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp01.att.com ( egs 8.14.5/8.14.5) with ESMTP id s5K0kDBC006775 for ; Thu, 19 Jun 2014 19:46:14 -0500 Received: from vpn-135-70-98-70.vpn.swst.att.com ([135.70.98.70]) by maillennium.att.com (mailgw1) with ESMTP id <20140620004612gw100j0cahe>; Fri, 20 Jun 2014 00:46:13 +0000 X-Originating-IP: [135.70.98.70] Message-ID: <53A38454.9000507@att.com> Date: Thu, 19 Jun 2014 20:46:12 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 CC: "dmarc@ietf.org" References: <20140616201759.84717.qmail@joyce.lan> <01P979UCLT0E0049PU@mauve.mrochek.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040604010601030904090300" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/6SiFcWMF7skvSYXHVokfaQDMGyg Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-00 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, 20 Jun 2014 00:46:18 -0000 This is a multi-part message in MIME format. --------------040604010601030904090300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 6/19/14, 6:14 PM, Murray S. Kucherawy wrote: > On Thu, Jun 19, 2014 at 2:51 PM, Ned Freed > wrote: > > > > I'm uneasy with an increase in version that isn't done in a complete > > replacement for RFC6376. We're not just registering a couple of new > > extension tags here. I would prefer that, if we do go decide to > go down > > this route, we crack it open and do a proper revision document > rather than > > just describing v2 in terms of "changes since v1". > > > There's a problem in front of us that needs solving. Part of that > seems to call > for a limited semantic extension to DKIM. Let's by all means make > that one > extension in way that generalizes as much as possible. > > But using this as justification to crack open the entire > specification? > That is not a good idea. > > > I agree, mostly. I wasn't advocating for cracking open the entire > specification. Assuming we go this path (rather than bolting down > DKIM-Delegate's problems somehow), I would much rather publish RFC6376 > again, with the "v=2" and the two new tags and maybe a paragraph about > backward compatibility, but absolutely no other changes. I don't want > to spend time reviewing and tweaking the whole damned thing again. As one of the co-editors of the last version, I agree whole-heartedly. Tony Hansen --------------040604010601030904090300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 6/19/14, 6:14 PM, Murray S. Kucherawy wrote:
On Thu, Jun 19, 2014 at 2:51 PM, Ned Freed <ned.freed@mrochek.com> wrote:

> I'm uneasy with an increase in version that isn't done in a complete
> replacement for RFC6376.  We're not just registering a couple of new
> extension tags here.  I would prefer that, if we do go decide to go down
> this route, we crack it open and do a proper revision document rather than
> just describing v2 in terms of "changes since v1".


There's a problem in front of us that needs solving. Part of that seems to call
for a limited semantic extension to DKIM. Let's by all means make that one
extension in way that generalizes as much as possible.

But using this as justification to crack open the entire specification?
That is not a good idea.

I agree, mostly.  I wasn't advocating for cracking open the entire specification.  Assuming we go this path (rather than bolting down DKIM-Delegate's problems somehow), I would much rather publish RFC6376 again, with the "v=2" and the two new tags and maybe a paragraph about backward compatibility, but absolutely no other changes.  I don't want to spend time reviewing and tweaking the whole damned thing again.

As one of the co-editors of the last version, I agree whole-heartedly.

    Tony Hansen
--------------040604010601030904090300-- From nobody Thu Jun 19 18:00:55 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB461A02E9 for ; Thu, 19 Jun 2014 18:00:51 -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_00=-1.9, J_CHICKENPOX_21=0.6, 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 NSq1jLc0iVzo for ; Thu, 19 Jun 2014 18:00:50 -0700 (PDT) Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.89]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C0561A03FB for ; Thu, 19 Jun 2014 18:00:44 -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.0.980.1; Fri, 20 Jun 2014 00:45:38 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.12.246]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.12.246]) with mapi id 15.00.0980.000; Fri, 20 Jun 2014 00:45:38 +0000 From: Terry Zink To: John Levine , "dmarc@ietf.org" Thread-Topic: [dmarc-ietf] signature sample, was So if you don't want Thread-Index: AQHPjCAESbWcYMMeqUOvgFt+bs0Kjpt5KJxQ Date: Fri, 20 Jun 2014 00:45:36 +0000 Message-ID: References: <5f6bf14cdf67430ca0527477c62e0661@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <20140620003815.70612.qmail@joyce.lan> In-Reply-To: <20140620003815.70612.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.107.160.166] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 024847EE92 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(199002)(61484003)(377454003)(189002)(13464003)(80022001)(31966008)(74662001)(20776003)(64706001)(66066001)(46102001)(74502001)(81342001)(54356999)(76176999)(105586002)(81542001)(99396002)(50986999)(101416001)(92566001)(83072002)(2656002)(19580395003)(19580405001)(83322001)(4396001)(79102001)(85852003)(33646001)(77982001)(21056001)(87936001)(76482001)(106116001)(106356001)(24736002)(106276001); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2SR01MB605; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; FPR:; PTR:InfoNoRecords; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: exchange.microsoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/EuezyeUuPlI2-3EpMPZCHYAfmnU Subject: Re: [dmarc-ietf] signature sample, was So if you don't want 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, 20 Jun 2014 01:00:52 -0000 VGhhbmtzIGZvciB0aGlzLCBpdCBtYWtlcyBzZW5zZS4gU29tZSBxdWVzdGlvbnMgKG1heSBvciBt YXkgbm90IGhhdmUgYmVlbiBkaXNjdXNzZWQgYWxyZWFkeSBvciBpbiB5b3VyIEludGVybmV0IGRy YWZ0KToNCg0KMS4gVGhlIERLSU0tU2lnbmF0dXJlIHY9MiBpcyBvbmx5IGluIHRoZSBoZWFkZXJz IGluIHRoZSBlbWFpbCwgY29ycmVjdD8gT3IsIHdvdWxkIGEgREtJTSBETlMgcmVjb3JkIGFsc28g aGF2ZSB2PWRraW0yOyAgPw0KMi4gSWYgdGhlcmUgYXJlIG11bHRpcGxlIFRvOiBhZGRyZXNzZXMs IHRoZSB2ZXJpZmllciBqdXN0IGNoZWNrcyB0byBzZWUgZD0gaW4gYW55IERLSU0tU2lnbmF0dXJl IHRoYXQgdmFsaWRhdGVzIG1hdGNoZXMgYW55IGRvbWFpbiBpbiB0aGUgNTMyMi5UbzogaGVhZGVy Pw0KMy4gU2hvdWxkIHdlIHRoaW5rIGFib3V0IGhvdyB0aGlzIGludGVyYWN0cyB3aXRoIEF1dGhl bnRpY2F0aW9uLVJlc3VsdHMgc3RhbXBpbmc/DQo0LiBIb3cgZG9lcyB0aGUgc2VuZGluZyBNVEEg a25vdyB3aGVuIHRvIHN0YW1wIHRoaXMgdj0yIERLSU0gaGVhZGVyPyBQcmVzdW1hYmx5LCBpdCB3 b3VsZCBuZWVkIHRvIGhhdmUgYSBsaXN0IG9mIGtub3duIGZvcndhcmRlcnMgc3RvcmVkIHNvbWV3 aGVyZT8NCg0KLS0gVGVycnkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEpv aG4gTGV2aW5lIFttYWlsdG86am9obmxAdGF1Z2guY29tXSANClNlbnQ6IFRodXJzZGF5LCBKdW5l IDE5LCAyMDE0IDU6MzggUE0NClRvOiBkbWFyY0BpZXRmLm9yZw0KQ2M6IFRlcnJ5IFppbmsNClN1 YmplY3Q6IFJlOiBbZG1hcmMtaWV0Zl0gc2lnbmF0dXJlIHNhbXBsZSwgd2FzIFNvIGlmIHlvdSBk b24ndCB3YW50DQoNCkhlcmUncyBhbiBleGFtcGxlLiAgVGhlIHRvcCBzaWduYXR1cmUgaXMgZnJv bSB0aGUgbGlzdCwgdGhlIHNlY29uZCBhbmQNCnRoaXJkIHNpZ25hdHVyZXMgd2VyZSBhcHBsaWVk IGJ5IHRoZSBzZW5kZXIuIFRoZSBzZWNvbmQgaXMgdGhlIG5vcm1hbA0Kc2lnbmF0dXJlIGFuZCB0 aGUgdGhpcmQgYSB3ZWFrIGNvbmRpdGlvbmFsIHNpZ25hdHVyZS4gIFRoZSB0aGlyZCBoYXMNCmNz PWZzIHdoaWNoIG1lYW5zIGl0J3Mgb25seSB2YWxpZCB3aXRoIGFuIGFkZGl0aW9uYWwgKGZvcndh cmRlcikNCnNpZ25hdHVyZSwgYW5kIGZzPXQgbWVhbnMgdGhhdCBzaWduYXR1cmUgaGFzIHRvIGJl IGZyb20gdGhlIGRvbWFpbiBvbg0KdGhlIFRvOiBsaW5lLg0KDQpXaGVuIHRoZSBsaXN0IGRvZXMg aXRzIHRoaW5nLCBpdCBpbnZhbGlkYXRlcyB0aGUgc3Ryb25nIHNpZ25hdHVyZSBmcm9tDQp0aGUg b3JpZ2luYWwgc2VuZGVyLCBidXQgaXQgYWRkcyBpdHMgb3duIHNpZ25hdHVyZSB3aGljaCBzYXRp c2ZpZXMgdGhlDQp3ZWFrIHNpZ25hdHVyZSdzIGNvbmRpdGlvbiwgc28gdGhlIHdlYWsgc2lnbmF0 dXJlIGJlY29tZXMgdmFsaWQuDQoNCg0KDQpES0lNLVNpZ25hdHVyZTogdj0xOyBhPXJzYS1zaGEx OyBjPXJlbGF4ZWQvcmVsYXhlZDsgcz1zMTAyNDsgZD1kaXNjdXNzaW9ubGlzdHMub3JnOw0KICAg aD1Gcm9tOlRvOlJlcGx5LVRvOkRhdGU6U3ViamVjdDpNSU1FLVZlcnNpb246Q29udGVudC1UeXBl Okxpc3QtVW5zdWJzY3JpYmU6TWVzc2FnZS1JRDsgDQogICBiaD0uLi4NCiAgIGI9PHRoaXMgaXMg dGhlIHNpZ25hdHVyZSBhZGRlZCBieSB0aGUgbGlzdCBvbiB0aGUgd2F5IG91dD4NCkRLSU0tU2ln bmF0dXJlOiB2PTE7IGE9cnNhLXNoYTE7IGM9cmVsYXhlZC9yZWxheGVkOyBzPXMxMDI0OyBkPXNl bmRlci5leGFtcGxlOw0KICAgaD1Gcm9tOlRvOlJlcGx5LVRvOkRhdGU6U3ViamVjdDpNSU1FLVZl cnNpb246Q29udGVudC1UeXBlOkxpc3QtVW5zdWJzY3JpYmU6TWVzc2FnZS1JRDsgDQogICBiaD0u Li4NCiAgIGI9PHRoaXMgaXMgYSAic3Ryb25nIiBzaWduYXR1cmUgdGhhdCBjb3ZlcmVkIHRoZSBl bnRpcmUgbWVzc2FnZSBhbmQgaXNuJ3QgdmFsaWQgYW55IG1vcmU+DQpES0lNLVNpZ25hdHVyZTog dj0yOyBhPXJzYS1zaGExOyBjPXJlbGF4ZWQvcmVsYXhlZDsgcz1zMTAyNDsgZD1zZW5kZXIuZXhh bXBsZTsNCiAgIGg9RnJvbTpUbzpEYXRlOyBsPTA7IGNzPWZzOyBmcz10OyANCiAgIGJoPS4uLg0K ICAgYj08dGhpcyBpcyBhICJ3ZWFrIiBmb3J3YXJkaW5nIHNpZ25hdHVyZSB0aGF0IGNvdmVycyBw YXJ0IG9mIHRoZSBtZXNzYWdlPg0KRnJvbTogc2VuZGVyQHNlbmRlci5leGFtcGxlDQpUbzogZGlz Y3Vzc2lvbkBkaXNjdXNzaW9ubGlzdC5vcmcNClN1YmplY3Q6IFtkaXNjdXNzaW9uLWxdIGNhdCB2 aWRlb3MgbG9sDQpMaXN0LUlkOiA8ZGlzY3Vzc2lvbi5kaXNjdXNzaW9ubGlzdHMub3JnPg0KDQpi bGFoIGJsYWgNCg0KLS0NClRoaXMgaXMgdGhlIGRpc2N1c3Npb24tbCBsaXN0LCB3aXRoIGEgYmVh dXRpZnVsIG1lc3NhZ2UgZm9vdGVyLg0KDQoNCg== From nobody Thu Jun 19 18:34:47 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C571A03E6 for ; Thu, 19 Jun 2014 18:34:45 -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 ZGo1icCjnnC3 for ; Thu, 19 Jun 2014 18:34:44 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE3751A03DB for ; Thu, 19 Jun 2014 18:34:43 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id cc10so294392wib.5 for ; Thu, 19 Jun 2014 18:34:42 -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=Z0mT08wp9Bnfh9jSl94CJuxONLeTHnAMK/DV2552grM=; b=Te7NWiQXoUGW4qrx9C8KOIYpDyVi7sW1hjhrdHoiJMW6NWA7GgiDYeubK6LAkvMotj NC8UZa2rH3f67ja5XWOnmXu9hoqxN2HEg15o+HmksyTJG0z+z5ejuG3KXtZfzFoOr0Bn NR9rUYr2UEuliDycG8jFJ8GX10yv5v85uW12fTE8FgObK0pPEi439Q0btHApc30L/Chm /FwC1e78imEkR6HLHo0IqVW4tZ0BE668tMbP9R1o2/e0BV9Rc7lbutYwE09ZQSmVPsvq poMqoBQ8ixViDTMXC1PKXfVBWxej5x3taiQysuHSMG2VvsEDVSJ/bznidJxUeIqb5xoR 8lDw== MIME-Version: 1.0 X-Received: by 10.194.58.180 with SMTP id s20mr225370wjq.119.1403228082548; Thu, 19 Jun 2014 18:34:42 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Thu, 19 Jun 2014 18:34:42 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 Jun 2014 18:34:42 -0700 Message-ID: From: "Murray S. Kucherawy" To: John R Levine Content-Type: multipart/alternative; boundary=047d7b86cb6866382b04fc3a7fea Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/0O-0rrakwqdw_3UuWV7p7STsPv4 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] The theory of DKIM versions 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, 20 Jun 2014 01:34:46 -0000 --047d7b86cb6866382b04fc3a7fea Content-Type: text/plain; charset=UTF-8 On Thu, Jun 19, 2014 at 4:20 PM, John R Levine wrote: > I'm uneasy with an increase in version that isn't done in a complete >> replacement for RFC6376. >> > > The problem may be that we don't agree about what DKIM versions mean. > Here's what I would like them to mean: > [...] > Actually I think I agree with most or all of that. My concern has to do with where a DKIM neophyte goes to get a complete description of DKIM. If we do what your draft proposes, then the complete definition will lie in no less than two documents, plus any that register extension tags or values. So what I'm uncomfortable with is a v=2 document that is nothing more than a changes-since-v=1. Think of it as software: For big important changes where cross-version compatibility is a question, it's typical to do a vX.0 release, not just send out one or more patches that one has to be sure to collect to see the whole thing. -MSK --047d7b86cb6866382b04fc3a7fea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 19, 2014 at 4:20 PM, John R Levine <johnl@tau= gh.com> wrote:
I'm uneasy with an increase in version that isn't done in a complet= e
replacement for RFC6376.

The problem may be that we don't agree about what DKIM versions mean. H= ere's what I would like them to mean:
[...]

Actually I think I agree with mos= t or all of that.=C2=A0 My concern has to do with where a DKIM neophyte goe= s to get a complete description of DKIM.=C2=A0 If we do what your draft pro= poses, then the complete definition will lie in no less than two documents,= plus any that register extension tags or values.=C2=A0 So what I'm unc= omfortable with is a v=3D2 document that is nothing more than a changes-sin= ce-v=3D1.

Think of it as software: For big important changes where cro= ss-version compatibility is a question, it's typical to do a vX.0 relea= se, not just send out one or more patches that one has to be sure to collec= t to see the whole thing.

-MSK
--047d7b86cb6866382b04fc3a7fea-- From nobody Thu Jun 19 18:40:51 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54E31A03ED for ; Thu, 19 Jun 2014 18:40:50 -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 F2f2iVm42PTQ for ; Thu, 19 Jun 2014 18:40:49 -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 737E41A03F4 for ; Thu, 19 Jun 2014 18:40:49 -0700 (PDT) Received: (qmail 74280 invoked from network); 20 Jun 2014 01:40:48 -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:cleverness; s=12227.53a39120.k1406; bh=L3oNWP9YZ/Th4y/49PxYb4ON1WM5paikii3CevzsjZU=; b=GRh1UGwt5AzXSUyhZz1SRGvv6st6j6rRWB6GY40iIp516IDk5KE+jF/8q52eSWWgeHpzfPlPN2AvaAYEjfFFrzFxrbzpywEQ+WArbW7Ixvtf/CWTQ0AQ3Uquht6pZWTs+mDaEKkTOjAsanKEdps1008FL9e+qPIc+IzjM8p16vICj8L2dCmky/NZjkwxhhsDdsCRHOmfsbYJS5UIgRXzepD+EIN9kcvCksAH6Vw/bivFPyf3TtkQv62JAy8Q04iM 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:cleverness; s=12227.53a39120.k1406; bh=L3oNWP9YZ/Th4y/49PxYb4ON1WM5paikii3CevzsjZU=; b=cyiYauOKBDb4DrQ7N+s+zTBZ5dBBjV8QemYd8mJNk7yyKchKioWkkY5h20EJwjFH/0fYkmLSDj1hBa6i1CT+esch7N3/oYvsonIuY/d4/mtgzbRRF+Aq/UraaCdbpVSbjU4jSVx7IyNU71HgLIKcKgups4B8UfJ1qK8uG3GjzGqyc53fEpsKDZmoBOaCOjYd8TiBUqViwiudwZvkiucoqbfuoh2I4rscLfRGjSACWBstgvNElmntAG1qp9VC5YIZ 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; 20 Jun 2014 01:40:47 -0000 Date: 19 Jun 2014 21:40:47 -0400 Message-ID: From: "John R Levine" To: "Terry Zink" In-Reply-To: References: <5f6bf14cdf67430ca0527477c62e0661@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <20140620003815.70612.qmail@joyce.lan> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/mRCdeekiI_Eb1v9fSBQJOLxXOcQ Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] signature sample, was So if you don't want 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, 20 Jun 2014 01:40:51 -0000 > Thanks for this, it makes sense. Some questions (may or may not have been discussed already or in your Internet draft): > > 1. The DKIM-Signature v=2 is only in the headers in the email, correct? Or, would a DKIM DNS record also have v=dkim2; ? No need to change the keys, since the hashing and signing hasn't changed. Also see my later note about why the key records don't need version numbers. > 2. If there are multiple To: addresses, the verifier just checks to see > d= in any DKIM-Signature that validates matches any domain in the > 5322.To: header? Yes. The draft says the fs= can be a specific domain, or abbreviation "t" or "c" which should make the signing marginally easier since the signer could use the same template for many signatures without having to pick the domain out of the To: header. > 3. Should we think about how this interacts with Authentication-Results stamping? I don't see offhand how A-R would be affected. It's still a DKIM signature, the A-R report would be the same. > 4. How does the sending MTA know when to stamp this v=2 DKIM header? Presumably, it would need to have a list of known forwarders stored somewhere? When there's a cs= tag. It's in the draft. R's, John From nobody Thu Jun 19 18:45:06 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 917041A03FB for ; Thu, 19 Jun 2014 18:45:01 -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 YlsE0vz2Xmn9 for ; Thu, 19 Jun 2014 18:44: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 15A9F1A03F4 for ; Thu, 19 Jun 2014 18:44:58 -0700 (PDT) Received: (qmail 74842 invoked from network); 20 Jun 2014 01:44:58 -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:cleverness; s=12459.53a3921a.k1406; bh=EpfKXnDpH1qyPOR81L+gdHQ4SMGu4F6Fn2UkOw8ttNk=; b=qS83hDKfAGu/1R00iL8A98fBPYomDij3bOt5c2Roua2uWH/Rqi8INuDrtPNxDi2woH5IvkRclZkO0rcDuKEke2j8Zae2LNx8FLYC2UiNedhwiq1hdtIota9ULcfYHSfneGzDGLok0E2VNao23XFc2vzCFH8BUpAN4VpIGc2CZft64kqpFuTh8aA48ekBi2ivgwbgGNZfBKEFOvdmZfKQNEYsx7JeV5NVopYYIhQLjprN+no8SvnMwWZfB/6khcqt 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:cleverness; s=12459.53a3921a.k1406; bh=EpfKXnDpH1qyPOR81L+gdHQ4SMGu4F6Fn2UkOw8ttNk=; b=ZBVFjqE3Gej/naOfuKVLkayeTRha2nnDHrrZz7s5cKnMpEPaZcwZui6jX+qxHzGhA3q1nV9d7tkJrLzxjM+g6q0tR0WKDW7Es4iGrOrb09RMsGPkpwKJqUwUj1NFzdnA7WUkGxbkNZJ4QVBFHKRmeBR6RVVvvhybLmxoAkei1b+6lxGsR+aGZQ6wqSIPQFG67+EjYUryj/PgLWGUsyRA/dt4FFCYQMQRUw3zKnW6gQ8IkhH69sJCz7Ep45wGzYSD 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; 20 Jun 2014 01:44:57 -0000 Date: 19 Jun 2014 21:44:57 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/THC0fCccHKqltVW0mjCbO5PPIEo Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] The theory of DKIM versions 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, 20 Jun 2014 01:45:02 -0000 > Actually I think I agree with most or all of that. My concern has to do > with where a DKIM neophyte goes to get a complete description of DKIM. He goes to 6376, and should notice the "updated by" in the RFC index. There's a bazillion RFCs updated by later RFCs so this doesn't seem unduly difficult. As incremental RFCs go, this is pretty simple. Try and find all the RFCs you need to implement SASL for AUTH in SUBMIT, for example. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Thu Jun 19 21:13:48 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F068B1A01CB for ; Thu, 19 Jun 2014 21:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.209 X-Spam-Level: * X-Spam-Status: No, score=1.209 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] 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 60adAqeXxRx2 for ; Thu, 19 Jun 2014 21:13:44 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 94C8A1A018C for ; Thu, 19 Jun 2014 21:13:43 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 68BC53FA015E; Fri, 20 Jun 2014 13:13:42 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 53F261A3D1E; Fri, 20 Jun 2014 13:13:42 +0900 (JST) From: "Stephen J. Turnbull" To: Hector Santos In-Reply-To: <19E404FF-228E-426B-ACDA-97EDC50F23DF@isdg.net> References: <20140616010237.77460.qmail@joyce.lan> <1611380D-2178-4116-9583-EC1086942825@tnpi.net> <6.2.5.6.2.20140619093658.0c118da0@resistor.net> <19E404FF-228E-426B-ACDA-97EDC50F23DF@isdg.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 20 Jun 2014 13:13:42 +0900 Message-ID: <87egyk1amh.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/_ZNEoLbPi80LUfajjdxOwhG2o4I Cc: Matt Simerson , "dmarc@ietf.org" , "Murray S. Kucherawy" , S Moonesamy Subject: Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version 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, 20 Jun 2014 04:13:46 -0000 Hector Santos writes: > The DNS-based author domain defined policy is the only common > approach we have now. "To a man with a hammer, every problem looks like a nail." But unfortunately, use of strict policy in the current environment can be antisocial behavior, and therefore it is going to be ignored (as a policy) by socially responsible recipients. Viz, GMail.[1] And it leads to avoidance behavior (From-corruption, encapsulation) by third parties (at least mailing lists). "Avoidance" is also anti-social IMO, even though it's my constituency that's doing it. Those same socially responsible recipients will, of course, use it as an (important) input into their *heuristic, reputation-based* decisions about filtering. Viz. again, GMail. Third-party authorization just pushes the heuristic, reputation-based decision-making off onto the third parties you want to authorize, and doesn't scale to precisely the large mailbox providers who can cause widespread consternation by publishing "p=reject" policies. Footnotes: [1] While I have my reservations about the CSR of all billion-dollar companies, including Google, GMail's handling of p=reject is socially responsible behavior. IMHO YMMV. From nobody Thu Jun 19 21:42:09 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22CE1A055D for ; Thu, 19 Jun 2014 21:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 DlrKQoIm3E7P for ; Thu, 19 Jun 2014 21:41:54 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 462651A0549 for ; Thu, 19 Jun 2014 21:41:54 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 7AAA03FA0B32; Fri, 20 Jun 2014 13:41:53 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 6D5231A3C85; Fri, 20 Jun 2014 13:41:53 +0900 (JST) From: "Stephen J. Turnbull" To: "John R Levine" In-Reply-To: References: X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 20 Jun 2014 13:41:53 +0900 Message-ID: <87d2e419bi.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/-aKxIyCZZPvSnOFIWiUySnLACzk Cc: "dmarc@ietf.org" , "Murray S. Kucherawy" Subject: [dmarc-ietf] The theory of DKIM versions 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, 20 Jun 2014 04:41:57 -0000 John R Levine writes: > d) Versions are cumulative. Every signature that is a valid version N > signature is still a valid version N+1 signature, give or take the change > in the b= hash due to the version bump. I think this is unnecessarily restrictive. It's unnecessary because a verifier that wants to handle multiple versions can always incorporate a routine per version. It's restrictive because a later version might want to disavow an earlier version. For example, v2 might REQUIRE that signatures enforce the RFC 5322 limit of one on From, To, Cc, and Message-ID, which would be incompatible with v1 signatures that don't do so. (Don't take that example too seriously. Use of "cumulative versions" requires demonstrating nonexistence, or at least "nonimportance", of *any* example of desirable incompatibility.) From nobody Thu Jun 19 22:13:43 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC281A020B for ; Thu, 19 Jun 2014 22:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 EXovvfRhO-3e for ; Thu, 19 Jun 2014 22:13:38 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 8084C1A0159 for ; Thu, 19 Jun 2014 22:13:38 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id B32883FA015E; Fri, 20 Jun 2014 14:13:37 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id A5AEC1A3C85; Fri, 20 Jun 2014 14:13:37 +0900 (JST) From: "Stephen J. Turnbull" To: "Murray S. Kucherawy" In-Reply-To: References: <20140616201759.84717.qmail@joyce.lan> <01P979UCLT0E0049PU@mauve.mrochek.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 20 Jun 2014 14:13:37 +0900 Message-ID: <87bnto17um.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/PF1O1gc8MZKJ6jMJ2sQlm9t2IT4 Cc: John Levine , "dmarc@ietf.org" , Ned Freed Subject: Re: [dmarc-ietf] draft-levine-dkim-conditional-00 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, 20 Jun 2014 05:13:39 -0000 Murray S. Kucherawy writes: > I agree, mostly. I wasn't advocating for cracking open the entire > specification. Assuming we go this path (rather than bolting down > DKIM-Delegate's problems somehow), Once you put the token signature in the DKIM-Delegate field itself (a process we already do for DKIM-Signature, which implicitly MUST sign itself), I don't see any problems that don't apply equally to this proposal. Except lack of generality, if you consider that a problem. John's proposal is more general, but generality is a two-edged sword. This particular generality worries me. As I understand it, conditions become a registry matter, not an RFC matter. I fear the proliferation of conditions that nobody will implement, or worse similar conditions with slightly different semantics that somebody prefers to existing registered conditions. So I'm firmly in favor of a new specialized header field. I realize that means support in verifiers will probably need to be maintained for decades, but I'd rather seen the need for generality before opening Pandora's Box. From nobody Thu Jun 19 22:59:54 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC6101A028D for ; Thu, 19 Jun 2014 22:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 2bbKQbGnsNF7 for ; Thu, 19 Jun 2014 22:59:50 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id BB0A31A0641 for ; Thu, 19 Jun 2014 22:59:50 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id D2BB13FA0B32; Fri, 20 Jun 2014 14:59:49 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id C55BE1A3C85; Fri, 20 Jun 2014 14:59:49 +0900 (JST) From: "Stephen J. Turnbull" To: Terry Zink In-Reply-To: References: <5f6bf14cdf67430ca0527477c62e0661@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <20140620003815.70612.qmail@joyce.lan> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 20 Jun 2014 14:59:49 +0900 Message-ID: <877g4c15pm.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/tf1g-k4puCRJfavB9Up0yCVrD2M Cc: "dmarc@ietf.org" , John Levine Subject: Re: [dmarc-ietf] signature sample, was So if you don't want 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, 20 Jun 2014 05:59:53 -0000 Terry Zink writes: > 4. How does the sending MTA know when to stamp this v=2 DKIM > header? Presumably, it would need to have a list of known > forwarders stored somewhere? Maybe John's answer in his parallel post is what you're looking for, but my interpretation is that this is a matter of local policy (and MTA implementation). Eg, I'm responsible for lists etc at a couple of domains, and I have several different answers! Maybe I trust the user (eg, me). Maybe I trust a particular addressee (because it's on your "list of known forwarders"). And maybe I don't really care as long as downstream is willing to sign and put *their* reputation on the line (they are signing the whole message, I'm just making a token). Oops, there's a real question. Should these forwarding signatures be RECOMMENDED or (REQUIRED) to have "full coverage" of message contents? Or maybe that doesn't matter as "responsible" 3rd parties will want to provide full coverage, and it's no trouble for abusers to do so? If REQUIRED, should there be a way for the Author Domain to specify the meaning of "full coverage," or should the RFC do so? From nobody Thu Jun 19 23:12:50 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2C81A854B for ; Thu, 19 Jun 2014 23:12: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=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 2kKmLhnAwzYq for ; Thu, 19 Jun 2014 23:12:07 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 584A81A064A for ; Thu, 19 Jun 2014 23:11:07 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id n15so185307wiw.16 for ; Thu, 19 Jun 2014 23:11: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 :content-type; bh=vSkRE/C8GAnp3fOCwHUJzNeD9ebZz6fZ0+iRM4xS6H4=; b=xw/mkNd8N1eNv+7pyYo1Mqi7btvCtRZwbKj+ChCk/u3rXsLw0VgwlrfaVeojl9de9S tE03ec0isET3U2QITYj6pDH/+G0PnUB16YLrA3byzo5UFXbJ73blpDI5uVvCGokvks+B 3XWzYuPmzm8r5/TWn/lLCZgkSgvPkefJa27LNde1/zuzJEAwAjCRTl76A9ByQUopPiHB In9b1BdMGhyLH2PGk61RxkEo+EWPIKw8a9lfsRqMEn9wQOcoDAeAbkGCSasOCWB8N82w CL0qgBIkOC9dz5WTRL0cYGGVOhzcKCGGBtYYbPcw59qXckiP5aDZPFiyzYT1xrzxpxv2 cBfA== MIME-Version: 1.0 X-Received: by 10.194.7.36 with SMTP id g4mr1585518wja.37.1403244665856; Thu, 19 Jun 2014 23:11:05 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Thu, 19 Jun 2014 23:11:05 -0700 (PDT) In-Reply-To: <20140620060807.9569.14874.idtracker@ietfa.amsl.com> References: <20140620060807.9569.14874.idtracker@ietfa.amsl.com> Date: Thu, 19 Jun 2014 23:11:05 -0700 Message-ID: From: "Murray S. Kucherawy" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=047d7b450a7cd831ca04fc3e5b34 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/l_y-3XYHcoyQxU9rz-L9L0H0xJI Subject: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-01.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, 20 Jun 2014 06:12:39 -0000 --047d7b450a7cd831ca04fc3e5b34 Content-Type: text/plain; charset=UTF-8 Playing around with ideas here. This one removes the "l=0" signature stuff and instead makes DKIM-Delegate into a more self-contained thing, which I believe was suggested (or at least inspired) by Stephen's comments. There is still the potential for abuse during the ephemeral relationship period (i.e., prior to expiration), but it it is now an indirect attack on the author domain rather than a direct one. Perhaps that's more palatable in this scenario. Comments welcome. -MSK ---------- Forwarded message ---------- From: Date: Thu, Jun 19, 2014 at 11:08 PM Subject: New Version Notification for draft-kucherawy-dkim-delegate-01.txt To: "Murray S. Kucherawy" , Dave Crocker < dcrocker@bbiw.net> A new version of I-D, draft-kucherawy-dkim-delegate-01.txt has been successfully submitted by Murray S. Kucherawy and posted to the IETF repository. Name: draft-kucherawy-dkim-delegate Revision: 01 Title: Delegating DKIM Signing Authority Document date: 2014-06-19 Group: Individual Submission Pages: 11 URL: http://www.ietf.org/internet-drafts/draft-kucherawy-dkim-delegate-01.txt Status: https://datatracker.ietf.org/doc/draft-kucherawy-dkim-delegate/ Htmlized: http://tools.ietf.org/html/draft-kucherawy-dkim-delegate-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-kucherawy-dkim-delegate-01 Abstract: DomainKeys Identified Mail (DKIM) permits a handling agent to affix a digital signature to an email message, associating a domain name with that message using cryptographic signing techniques. The digital signature typically covers most of a message's original portions, although the specific choices for content hashing are at the discretion of the signer. DKIM signatures survive simply email relaying but typically are invalidated by processing through Mediators, such as mailing lists. For such cases, the signer needs a way to indicate that a valid signature from some third party was anticipated, and constitutes an acceptable handling of the message. This enables a receiver to conclude that the content is legitimately from that original signer, even though its original signature no longer validates. This document defines a mechanism for improving the ability to assess DKIM validity for such messages. 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. The IETF Secretariat --047d7b450a7cd831ca04fc3e5b34 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Playing around with ideas here.=C2=A0 This one remove= s the "l=3D0" signature stuff and instead makes DKIM-Delegate int= o a more self-contained thing, which I believe was suggested (or at least i= nspired) by Stephen's comments.=C2=A0 There is still the potential for = abuse during the ephemeral relationship period (i.e., prior to expiration),= but it it is now an indirect attack on the author domain rather than a dir= ect one.=C2=A0 Perhaps that's more palatable in this scenario.

Comments welcome.

-MSK

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Thu, Jun 19, 2014 at 11:08 PM
Subject: New Version Notification fo= r draft-kucherawy-dkim-delegate-01.txt
To: "Murray S. Kucherawy&quo= t; <superuser@gmail.com>, = Dave Crocker <dcrocker@bbiw.net= >



A new version of I-D, draft-kucherawy-dkim-delegate-01.txt
has been successfully submitted by Murray S. Kucherawy and posted to the IETF repository.

Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-kucherawy-dkim-delegate
Revision: =C2=A0 =C2=A0 =C2=A0 01
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Delegating DKIM Signing Authority<= br> Document date: =C2=A02014-06-19
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A011
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttp://www.ietf.org/internet-drafts/draft-kucherawy-dkim-delegate-01.txt=
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://datatracker.= ietf.org/doc/draft-kucherawy-dkim-delegate/
Htmlized: =C2=A0 =C2=A0 =C2=A0 http://tools.ietf.org/html/dr= aft-kucherawy-dkim-delegate-01
Diff: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://www.= ietf.org/rfcdiff?url2=3Ddraft-kucherawy-dkim-delegate-01

Abstract:
=C2=A0 =C2=A0DomainKeys Identified Mail (DKIM) permits a handling agent to = affix a
=C2=A0 =C2=A0digital signature to an email message, associating a domain na= me with
=C2=A0 =C2=A0that message using cryptographic signing techniques. =C2=A0The= digital
=C2=A0 =C2=A0signature typically covers most of a message's original po= rtions,
=C2=A0 =C2=A0although the specific choices for content hashing are at the =C2=A0 =C2=A0discretion of the signer. =C2=A0DKIM signatures survive simply= email
=C2=A0 =C2=A0relaying but typically are invalidated by processing through =C2=A0 =C2=A0Mediators, such as mailing lists. =C2=A0For such cases, the si= gner needs a
=C2=A0 =C2=A0way to indicate that a valid signature from some third party w= as
=C2=A0 =C2=A0anticipated, and constitutes an acceptable handling of the mes= sage.
=C2=A0 =C2=A0This enables a receiver to conclude that the content is legiti= mately
=C2=A0 =C2=A0from that original signer, even though its original signature = no
=C2=A0 =C2=A0longer validates.

=C2=A0 =C2=A0This document defines a mechanism for improving the ability to= assess
=C2=A0 =C2=A0DKIM validity for such messages.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--047d7b450a7cd831ca04fc3e5b34-- From nobody Thu Jun 19 23:22:45 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4CB51A0646 for ; Thu, 19 Jun 2014 23:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.15 X-Spam-Level: X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 emx3Fb1oAit9 for ; Thu, 19 Jun 2014 23:18:53 -0700 (PDT) Received: from nm10-vm1.bullet.mail.gq1.yahoo.com (nm10-vm1.bullet.mail.gq1.yahoo.com [98.136.218.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDF5C1A0339 for ; Thu, 19 Jun 2014 23:18:52 -0700 (PDT) Received: from [216.39.60.180] by nm10.bullet.mail.gq1.yahoo.com with NNFMP; 20 Jun 2014 06:18:52 -0000 Received: from [216.39.60.198] by tm16.bullet.mail.gq1.yahoo.com with NNFMP; 20 Jun 2014 06:18:52 -0000 Received: from [127.0.0.1] by omp1085.mail.gq1.yahoo.com with NNFMP; 20 Jun 2014 06:18:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 623138.5317.bm@omp1085.mail.gq1.yahoo.com Received: (qmail 86519 invoked by uid 60001); 20 Jun 2014 06:18:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1403245132; bh=vOMr9nlCrL2sOoRUIxxKmDxJoOzPr0vz2Tp4nJZjLuI=; h=Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=zcGCHITPNsobcJbui49OF+8mZcpSWXlaTEPsOU5INNzIJnPs0wmyy4dwyEqriOz5qE05AoPjeWAkwJeJI11XP+HlqHZWoSgYcd0+DXAt8qMXXf8/RXMRLG1uwTDNzFcDxVuZ7M0RB+oMIVkHfRguRIGW31uUmthYkyHAZCs6B4Q= X-YMail-OSG: cd37dm0VM1mDxC.5F.8IIi6Nv2WDNTE.7nNxOs.fJb.rWHI dl9C.Ls5t2_flmneTm7eQSkB8agz.C7jXnpX_TNZznE6iuqc4XTZIpOsLjCV ahW9xQgb3uibCjAO7QmDkKVdgFuM7X7gDtyT_lL1juXn5pc6FHCIMWPObqxA RP9hWVzY5YYsVY4S7A3xyxUMBP5F3SLX.ZdbbY9iNeDf.eOnnP2XMEexcMyt zTMqActC_eeTAb52PH25fZtNY6n31._OYqdpxir2stoEHgFVVaZUzDVk6aLg 36Ir1CnlliQlHDGtwaT1OeQ6_Dr7iX75UJQEWJo6sm8URuPvn7SUnF7oyCO6 b4z7e95tJQu6eB.Cb25ZXM0Iapt4.xyqJn5u5ZasUi5u1cRI8QXjcVFxDuTR 2rMGdrmQiZgMAR5CoTPdzRijbQ_eGgXpDKfl.35q3LKzeACjpqdwDnRiSi4b ssrGoOUzzL4sqJ2c3XqcVN.C2ct8A9aDuBiPzApDAh4KbMWvP8L5L66E6DnU ewQHmVHaxfueulJu5iumSWym66hp7HqkX7KkKG7FWelNf5M3lXYw_eO4J70Y z1gBKQCrcrpnnzLNAVdbkflsToLJIZDdX5aBoS4I23oech1FP7Qk- Received: from [109.121.39.102] by web164606.mail.gq1.yahoo.com via HTTP; Thu, 19 Jun 2014 23:18:52 PDT X-Rocket-MIMEInfo: 002.001, PiA0LiBIb3cgZG9lcyB0aGUgc2VuZGluZyBNVEEga25vdyB3aGVuIHRvIHN0YW1wIHRoaXMgdj0yIERLSU0gaGVhZGVyPwo.IFByZXN1bWFibHksIGl0IHdvdWxkIG5lZWQgdG8gaGF2ZSBhIGxpc3Qgb2Yga25vd24gZm9yd2FyZGVycyBzdG9yZWQgc29tZXdoZXJlPwoKeWVhaCwgQ0RLSU0gc3VmZmVycyBmcm9tIHRoZSBzYW1lIHNwb29maW5nIGlzc3VlIERLSU0tRCBkb2VzLgoKMS4gYWthLCBpZiB1IGRvbid0IGNyZWF0ZSBhIHdoaXRlbGlzdCBmb3IgdXIgc2VuZGluZyBNVEEgdG8ga25vdyB3aGVuIHRvIHUBMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.191.1 Message-ID: <1403245132.31456.YahooMailNeo@web164606.mail.gq1.yahoo.com> Date: Thu, 19 Jun 2014 23:18:52 -0700 From: Vlatko Salaj To: "dmarc@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/GCL3pmkSgDQxmJv3GVOrmP_N2O4 X-Mailman-Approved-At: Thu, 19 Jun 2014 23:22:39 -0700 Subject: Re: [dmarc-ietf] signature sample, was So if you don't want X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 20 Jun 2014 06:18:55 -0000 > 4. How does the sending MTA know when to stamp this v=3D2 DKIM header?=0A= > Presumably, it would need to have a list of known forwarders stored somew= here?=0A=0Ayeah, CDKIM suffers from the same spoofing issue DKIM-D does.=0A= =0A1. aka, if u don't create a whitelist for ur sending MTA to know when to= use=0A=A0=A0 CDKIM or DKIM-D, and when it should not,=0A=0A2. but instead = choose to verbatim include either with every messages u send,=0A=0A3. any o= f ur non-ML receivers can just misuse ur CDKIM/DKIM-D,=0A=0A4. copying it t= o their email,=0A=0A5. and signing with their own domain [which was, origin= ally, allowed with=0A=A0=A0 ur CDKIM/DKIM-D, as it appears in To:].=0A=0A= =0Aso, to solve this spoofing hole, u fallback to whitelisting, making sure= =0Aur MTA uses CDKIM/DKIM-D only on email u know will go through legitimate= =0A3rd party munging and resigning.=0A=0A=0Ahowever, all that work with imp= lementing new header protocol, and creating=0Aa whitelist, while still worr= ying if ur CDKIM/DKIM-D will get through to=0Afinal receiver intact and fun= ctional, all while u have no solution for other=0A3rd party sending on ur b= ehalf, makes me believe these r half-baked solutions,=0Aand i would choose = to specify alignment exemption policy through DNS instead,=0Awhich does req= uire u make a whitelist, ofc, but other than inputing it into=0ADNS, doesn'= t require u do anything else with it, meaning ur MTA is unchanged,=0Aur DKI= M software is the same, and any additional work is on DMARC receiver which= =0Ahas to upgrade its DMARC verifier to handle 3rd party alignment, but whi= ch it=0Ahas to do anyway, as DMARC is still new and changing, and making ch= anges to=0Asomething new is much easier than changing something old and wid= espread as DKIM.=0A=0A=0A-- =0AVlatko Salaj aka goodone=0Ahttp://goodone.tk From nobody Fri Jun 20 01:46:47 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786E71B2798 for ; Fri, 20 Jun 2014 01:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.073 X-Spam-Level: X-Spam-Status: No, score=-3.073 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 ZIoig-EuHHiH for ; Fri, 20 Jun 2014 01:46:44 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EFA21A0351 for ; Fri, 20 Jun 2014 01:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1403254001; bh=0qo/qRISgbh6e4CWdLOByZd8M4vGZ0cU4L3/SA6X0dA=; l=1302; h=Date:From:To:CC:References:In-Reply-To; b=DybE6wVBLRfjmkuVa1exwfUzPIOfXD6Of0aKd8MwjiqDFXR6ukkbg4+5Gw+fyeXZq fCU4u2DGtf1xWEwAj6TpvCDn6xT5BdUaBeNWDWw8tF7gjHOpJP7Lqy2/hbPZb3bvYd mb2C2KFzJ3hL8FjluytPwWh6bAP8UKgqw5bCETmc= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Fri, 20 Jun 2014 10:46:41 +0200 id 00000000005DC03F.0000000053A3F4F1.00000B66 Message-ID: <53A3F4F1.3080808@tana.it> Date: Fri, 20 Jun 2014 10:46:41 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , John R Levine References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/2yb7wLgytI4ZqzWhbqwAnfmNW88 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] The theory of DKIM versions 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, 20 Jun 2014 08:46:45 -0000 On Fri 20/Jun/2014 03:34:42 +0200 Murray S. Kucherawy wrote: > > Actually I think I agree with most or all of that. My concern has to > do with where a DKIM neophyte goes to get a complete description of > DKIM. If we do what your draft proposes, then the complete definition > will lie in no less than two documents, plus any that register > extension tags or values. So what I'm uncomfortable with is a v=2 > document that is nothing more than a changes-since-v=1. As I understand it, the reason we'd like to associate DKIM-Delegate with a version bump is to guard those verifiers who don't expect weak signatures. OTOH, Dave's "very-relaxed" canonicalization does have some real grounds. DKIM verifications can fail unexpectedly, albeit infrequently, which is why DKIM-Delegate-00 offered to overload z=. As Dave's proposal implied, new c14ns are part of the extensibility already provided for. Section 3.4 says: Further canonicalization algorithms MAY be defined in the future; Verifiers MUST ignore any signatures that use unrecognized canonicalization algorithms. The document defining the new c14n is formally separated from the one which defines weak signatures. The latter can simply recommend using the former, thereby achieving the desired protection. Ale From nobody Fri Jun 20 01:49:36 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817AB1B2798 for ; Fri, 20 Jun 2014 01:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 1N9cfzDP-7I0 for ; Fri, 20 Jun 2014 01:49:33 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 99FD21A0351 for ; Fri, 20 Jun 2014 01:49:33 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 112653FA015E; Fri, 20 Jun 2014 17:49:33 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 03A5F1A3C85; Fri, 20 Jun 2014 17:49:32 +0900 (JST) From: "Stephen J. Turnbull" To: Vlatko Salaj In-Reply-To: <1403245132.31456.YahooMailNeo@web164606.mail.gq1.yahoo.com> References: <1403245132.31456.YahooMailNeo@web164606.mail.gq1.yahoo.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Fri, 20 Jun 2014 17:49:32 +0900 Message-ID: <8738f00xur.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/8OkJjdCgTbx-d141O84p9-WTV1A Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] signature sample 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, 20 Jun 2014 08:49:35 -0000 Vlatko Salaj writes: > [A DNS-based whitelist] does require u make a whitelist, ofc, but > other than inputing it into DNS, doesn't require u do anything else > with it, Inputting it into DNS is a *very* big deal, however. First, it's not at all clear that it scales to precisely the sites I (at least) care about most: the "> 1 million users" mailbox providers. Several people have commented here that they expect pushback from their DNS teams on any DNS-based solution. Also, both populating the list and culling it of "undesirables" have no good solutions yet (admittedly, nobody has really tried, there probably *are* "pretty good" solutions, but are they good enough for Yahoo!?) Most of us control MTAs (or are close buddies with those who do) -- "let's try it and see, then fix what ain't so great" will fly for MTA changes. DNS experiments are less likely, perhaps much less likely, to fly if DNS is in a different department. Second, DNS entries almost automatically provide a reasonably long window where they are cached downstream (or you greatly increase the DNS load at the Author Domain). Eg, right now the TXT resource for _dmarc.yahoo.com appears to have a TTL of 1800 (30 min). But spammers can move millions of messages in 5 minutes. If abuse is possible, you're wide open. Third, this is a very unconventional use of the DNS. I know, SPF, DKIM, and DMARC, but those require O(1) subdomain per Author Domain, not O(users) or even O(forwarders), dynamically named. Fourth, inputting it into DNS either requires a global list (which is probably feasible from an operations standpoint) or a proliferation of artificial domains representing pairs, which isn't going to make the DNS team happy at all (especially since even with a terribly long TTL they'll have a ruinously low cache hit rate). But a global list (ie, one entry per "trusted" forwarder) means that you've opened a much bigger window for abuse. By contrast, changes to the MTA mean much more flexibility for making decisions at message injection time, based on a local lookup in a user profile database. I prefer that (knowing that my preferred MTAs' developers are responsive to user demands for security features). > any additional work is on DMARC receiver which has to upgrade its > DMARC verifier to handle 3rd party alignment, but which it has to > do anyway, as DMARC is still new and changing, I tend to disagree with your logic, again for several reasons. First, the originators who *need* this are relatively few (Yahoo!, AOL, and who else?); Author Domains used only for "transactional email" will never need it, and the rest of us probably have a fair amount of time before we *need* it (granted, several posters here clearly want it badly so they can use "p=reject" too, but like the rest of us they've survived for several years without it, and continue to do so). Better to impose the costs (and risks of experimentation) on those who benefit most. Second, to the extent that receivers need to make adjustments in their MTAs to handle new versions of DMARC, originators will, too. And weighted by mail volume, the relevant originators and recipients are on the same, fairly short, list of major mailbox providers. Third, whether done by DNS or by MTA, the hard work is in determining what policy you want to publish. And with the MTA the policy is surely more flexible than with the DNS. Finally, there's some risk in making changes to any system (and the amount of data you propose adding to DNS, along with the extra queries and the likely effect on cache hit rate, make it a systemic change). Which would you rather have go down on you, your MTA or your DNS? I'll take a working DNS any time! From nobody Fri Jun 20 06:12:17 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998C31B27EA for ; Fri, 20 Jun 2014 06:12:14 -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 McgH0Nrt3Z-t for ; Fri, 20 Jun 2014 06:12: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 B53501B27DE for ; Fri, 20 Jun 2014 06:11:56 -0700 (PDT) Received: (qmail 88361 invoked from network); 20 Jun 2014 13:11:55 -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:cleverness; s=15927.53a4331b.k1406; bh=5wMOl3z/SgEypW9mGH4xfvMUbqDKT+MFw7/7elvk2U8=; b=YA9vpHFOpula26ZcJDOI/6hoqrDPNsmWCM3OMXlRGFoL/dUx9yn5J0Q7182ujAqPKEyarLsaKkcv/2zQpjJfYWnoCNWp4RIEnYYlMJwj66T8uf+ZuKLt+TdbkqtEms9s1/MGK/8j/BuUxDLlyCY2Hnyn7O9gIniqLUKU+SrjR4jAQzDO0AJRamUqRskDAE3kZ2UpeTwFCnb6RMbnCmJT7bx+jeLDF6XpuihtifL1R/ajKlhkpY6PsqsxapVnTa5F 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:cleverness; s=15927.53a4331b.k1406; bh=5wMOl3z/SgEypW9mGH4xfvMUbqDKT+MFw7/7elvk2U8=; b=tH11ZET0ExSy784g59C5msQygEVKWaxS8zkgEIO5MwyDqZ6NsmJa3RLHYqCHKPAqhn56vc44vpNlrYallE1/GOne2fkfuLtEas2Lx+Xe2FkGtkQGlbTxtXTURq3eJd0TJJn4qOJjxuB8ykCtNRhEfzsKPuSCAlmVvXihg95gt839cDYWPE9HVfA68LTUc9Ww0ABTABUUrHQ/OYrMWSoIfy4bvV84M7NwRsmakxkVNotPglUuXUfb+oo302J/7f44 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; 20 Jun 2014 13:11:55 -0000 Date: 20 Jun 2014 09:11:54 -0400 Message-ID: From: "John R Levine" To: "Stephen J. Turnbull" In-Reply-To: <87d2e419bi.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87d2e419bi.fsf@uwakimon.sk.tsukuba.ac.jp> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/QuBz513xrXHkyP7U-VQt-qmGDBI Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] The theory of DKIM versions 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, 20 Jun 2014 13:12:14 -0000 > > d) Versions are cumulative. Every signature that is a valid version N > > signature is still a valid version N+1 signature, give or take the change > > in the b= hash due to the version bump. > > I think this is unnecessarily restrictive. It's unnecessary because a > verifier that wants to handle multiple versions can always incorporate > a routine per version. It's restrictive because a later version might > want to disavow an earlier version. If you want to change the semantics that much, like I said, give it a different name. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Fri Jun 20 06:32:25 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1740A1A0395 for ; Fri, 20 Jun 2014 06:32:23 -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 mGlYkkhCOjIx for ; Fri, 20 Jun 2014 06:32:21 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF56B1A0393 for ; Fri, 20 Jun 2014 06:32:18 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id cc10so818227wib.12 for ; Fri, 20 Jun 2014 06:32: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=ndb1jtRn3r0nsOAy6sodaiDzsMFFM6WVIBNgfB3Ne2Q=; b=fwi0rhfK0EiOTa5+rJfqw1JcoGPxXKlVMNYWT2woYORQHTO7jYF20bIikYFq7cYlii Km/f2Z+6iE+pzObS8MsSJQ0p5SxXl71Ghaq2LRXhCy1KmPVIL0guELSeOdDjOZLX86+T 1pynnkrCJtRyUKSd4ZJuKVC/QqHwzUKamjFnJqvySmnDJL7uDCS5MKq0h7WStGQRKdqz Z0K/kkr6eEuQu7wQRob+PrwGSLFW8py0OISIAAXr1Xq2ybyp1S8ll/1FO9Uw6zEVBBee sOgpCc3JcM5CEgmjhiqR8hK3iazyxSt4LWj8YZg+ARmu5jhrrYfja70s6hYbnmvZmQ55 o63A== MIME-Version: 1.0 X-Received: by 10.194.243.104 with SMTP id wx8mr4471627wjc.32.1403271136860; Fri, 20 Jun 2014 06:32:16 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Fri, 20 Jun 2014 06:32:16 -0700 (PDT) In-Reply-To: <8738f00xur.fsf@uwakimon.sk.tsukuba.ac.jp> References: <1403245132.31456.YahooMailNeo@web164606.mail.gq1.yahoo.com> <8738f00xur.fsf@uwakimon.sk.tsukuba.ac.jp> Date: Fri, 20 Jun 2014 06:32:16 -0700 Message-ID: From: "Murray S. Kucherawy" To: "Stephen J. Turnbull" Content-Type: multipart/alternative; boundary=089e014940f0a2e0bf04fc4485d6 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/mc3fDOd4YK7vGFtS20u2g4Cb9SE Cc: Vlatko Salaj , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] signature sample 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, 20 Jun 2014 13:32:23 -0000 --089e014940f0a2e0bf04fc4485d6 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 20, 2014 at 1:49 AM, Stephen J. Turnbull wrote: > Vlatko Salaj writes: > > > [A DNS-based whitelist] does require u make a whitelist, ofc, but > > other than inputing it into DNS, doesn't require u do anything else > > with it, > > Inputting it into DNS is a *very* big deal, however. First, it's not > at all clear that it scales to precisely the sites I (at least) care > about most: the "> 1 million users" mailbox providers. Several people > have commented here that they expect pushback from their DNS teams on > any DNS-based solution. Also, both populating the list and culling it > of "undesirables" have no good solutions yet (admittedly, nobody has > really tried, there probably *are* "pretty good" solutions, but are > they good enough for Yahoo!?) Most of us control MTAs (or are close > buddies with those who do) -- "let's try it and see, then fix what > ain't so great" will fly for MTA changes. DNS experiments are less > likely, perhaps much less likely, to fly if DNS is in a different > department. > A few further points: You'll need to come up with a way to populate the list, and keep it current. The minute one of your users can't send to a list because your whitelist isn't up to date, you're getting complaints. In a DMARC world, you're even possibly messing with domains outside of your control if that list is stale. The notion of having users register the domains of the lists they want to use is problematic because (a) users don't want to have to do that, and (b) that puts extending your domain's trust to other domains in the hands of your users, not all of whom are necessarily reliable and honest. That leaves the need for some automated way to populate the list so your users don't have to do it. I haven't seen such a proposal yet, and I doubt we could punt and say "that's out of scope" unless there's some kind of feasible concept for doing so. Also, it's a dance to put more policy data into the DNS in any form. The "DNS people", as we appear to like to call them, don't like use of DNS to store policy data even though it's extremely convenient for us to do so. At a minimum, if we try to do that with TXT records again, we can expect a huge amount of friction. We need to be sure that battle is worth having, and I'm not convinced that it is given the caveats above and in Stephen's email. Finally, no DNS-based third party whitelisting scheme has ever gotten any traction. The problems caused by the recent application of DMARC don't appear to have spurred any vendors or operators to try deploying ATPS, TPA, DSAP, or any variant thereof, even as experiments. I even put ATPS into OpenDKIM with zero demand just so it's available for free, today, for anyone that wants to try it as a concept. I saw exactly one use of it after months of data collection. I think this whole topic has turned into something we think those people want or need, but they don't. -MSK --089e014940f0a2e0bf04fc4485d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 20, 2014 at 1:49 AM, Stephen J. Turnbull <st= ephen@xemacs.org> wrote:
Vlatko Salaj writes:

=C2=A0> [A DNS-based whitelist] does require u make a whitelist, ofc, bu= t
=C2=A0> other than inputing it into DNS, doesn't require u do anythi= ng else
=C2=A0> with it,

Inputting it into DNS is a *very* big deal, however. =C2=A0First, it's = not
at all clear that it scales to precisely the sites I (at least) care
about most: the "> 1 million users" mailbox providers. =C2=A0S= everal people
have commented here that they expect pushback from their DNS teams on
any DNS-based solution. =C2=A0Also, both populating the list and culling it=
of "undesirables" have no good solutions yet (admittedly, nobody = has
really tried, there probably *are* "pretty good" solutions, but a= re
they good enough for Yahoo!?) =C2=A0Most of us control MTAs (or are close buddies with those who do) -- "let's try it and see, then fix what=
ain't so great" will fly for MTA changes. =C2=A0DNS experiments ar= e less
likely, perhaps much less likely, to fly if DNS is in a different
department.

A few further points:
You'll need to come up with a way to populate the list, an= d keep it current.=C2=A0 The minute one of your users can't send to a l= ist because your whitelist isn't up to date, you're getting complai= nts.=C2=A0 In a DMARC world, you're even possibly messing with domains = outside of your control if that list is stale.=C2=A0 The notion of having u= sers register the domains of the lists they want to use is problematic beca= use (a) users don't want to have to do that, and (b) that puts extendin= g your domain's trust to other domains in the hands of your users, not = all of whom are necessarily reliable and honest.=C2=A0 That leaves the need= for some automated way to populate the list so your users don't have t= o do it.=C2=A0 I haven't seen such a proposal yet, and I doubt we could= punt and say "that's out of scope" unless there's some k= ind of feasible concept for doing so.

Also, it's a dance to put more policy data into the DNS = in any form.=C2=A0 The "DNS people", as we appear to like to call= them, don't like use of DNS to store policy data even though it's = extremely convenient for us to do so.=C2=A0 At a minimum, if we try to do t= hat with TXT records again, we can expect a huge amount of friction.=C2=A0 = We need to be sure that battle is worth having, and I'm not convinced t= hat it is given the caveats above and in Stephen's email.

Finally, no DNS-based third party whitelisting scheme has ev= er gotten any traction.=C2=A0 The problems caused by the recent application= of DMARC don't appear to have spurred any vendors or operators to try = deploying ATPS, TPA, DSAP, or any variant thereof, even as experiments.=C2= =A0 I even put ATPS into OpenDKIM with zero demand just so it's availab= le for free, today, for anyone that wants to try it as a concept.=C2=A0 I s= aw exactly one use of it after months of data collection.=C2=A0 I think thi= s whole topic has turned into something we think those people want or need,= but they don't.

-MSK
--089e014940f0a2e0bf04fc4485d6-- From nobody Fri Jun 20 07:43:01 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5703B1A03B7 for ; Fri, 20 Jun 2014 07:43: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 qlOg4fh5pkJI for ; Fri, 20 Jun 2014 07:42: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 2D61A1A0394 for ; Fri, 20 Jun 2014 07:42:58 -0700 (PDT) Received: (qmail 11562 invoked from network); 20 Jun 2014 14:42:57 -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:cleverness; s=2d29.53a44871.k1406; bh=/v2G9nNzXf2SpDqi6lXmlh9riCIDkmKrFV3fIJuS+tY=; b=cuDaCQsmMEfwQNODFlSNdlnnbsXIEt0bgTDaFUkLrQroOHs3KbOfJZVUoSQYf/TRG0DAjY8yhopWGuq8XmjBKE6pLQc9RXxTpQHGx2oVO2jU/UKrj/lM2QbC4sLSN6f8/EK8DMMJNzhU/ROEU0m2LZwZXZURxRBKjudGkpbYhj84wSf+QTzw+dorF+mj9H+VFsb0TCU9xlx37a66k07/8Lr+TKO0VG3aHolvjifeIuyBVx0Up1/vRaK6Hq/m6oEm 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:cleverness; s=2d29.53a44871.k1406; bh=/v2G9nNzXf2SpDqi6lXmlh9riCIDkmKrFV3fIJuS+tY=; b=hF3WMLd2UdlCotCJWO5TmdX5lBSmFjY3tgwb4AH1J+RSsyNJU59HXm9mIgCQMmdLIGM667sBKHvMyOwA/FRdjSWgWRtZcgOjNjnP7yPetsIctRVeZ+J4B6eRSxqPp77cz/49SWVZ7J5eNxMIGvQ4+hu0I1hW4OJTYGM4fgRnMoUb74NIgr+dwSrqne/joYD5VhtTi6q8hNBzh3sB9Gq3+hYVwwFakPHchWp/KT3ATCzFHTW1u3dj2PbQrCEIUf95 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; 20 Jun 2014 14:42:57 -0000 Date: 20 Jun 2014 10:42:56 -0400 Message-ID: From: "John R Levine" To: "Stephen J. Turnbull" In-Reply-To: <877g4c15pm.fsf@uwakimon.sk.tsukuba.ac.jp> References: <5f6bf14cdf67430ca0527477c62e0661@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <20140620003815.70612.qmail@joyce.lan> <877g4c15pm.fsf@uwakimon.sk.tsukuba.ac.jp> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/XJ-85F6xasy5Sfv4WC2yaOLodTI Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] versions, was signature sample, was So if you don't want 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, 20 Jun 2014 14:43:00 -0000 >> 4. How does the sending MTA know when to stamp this v=2 DKIM >> header? Presumably, it would need to have a list of known >> forwarders stored somewhere? That seems likely, or else the DMARC group could hire someone to publish a list of known forwarders. Based on Yahoo's statements and Gmail's aggregate reports, they have a pretty good idea of who the forwarders are. > Oops, there's a real question. Should these forwarding signatures be > RECOMMENDED or (REQUIRED) to have "full coverage" of message contents? They're ordinary signatures. I don't think we need to invent new rules for them. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Fri Jun 20 07:50:53 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4A51A03C1 for ; Fri, 20 Jun 2014 07:50: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 ZLdnK5DZBHZK for ; Fri, 20 Jun 2014 07:50: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 031EF1A036A for ; Fri, 20 Jun 2014 07:50:50 -0700 (PDT) Received: (qmail 13858 invoked from network); 20 Jun 2014 14:50:50 -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:cleverness; s=3621.53a44a4a.k1406; bh=xcWHJElZhS60aFGSUjpfXOJUivmZOBzwfYvgQNB8cqQ=; b=MJwr7FAFIyHWOI5ffUgA7qyw5J2H7zen9G9dRpCkOHXSpKyRN/hvhYemK6GO1fnBvs0cgCXh1+YrR9Xwux2N+gRUmuyJcK/PLKAbnKcioDwbRcAqedTZaCTyNhG/D5jSbA21skvVPgL29a5ZWTyXmtEz3DO9QodZlLXdfY2yBjiQ3I5xIHgV1OGu/jR+SieXoK3j8OaMHUdH1yQESu985lUsB8FGyTceQXU4zeF+USqxNkAreGgNfjDNr4pzsdI9 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:cleverness; s=3621.53a44a4a.k1406; bh=xcWHJElZhS60aFGSUjpfXOJUivmZOBzwfYvgQNB8cqQ=; b=U85ruqxH/JyIwe3AuG2FbJ7W3HgVIxCTioaUsKw2m37chfie1Yr6s0dJvhmYQcp//FY4Lj5i5KxwU+6iyFoCMqfAJTpmZIQjpz52nywCHtsTpf2tlrcAJZhxfZb6FGeczWs6WT8cvlnH0qUhZ2c52npRRJaqPn6VMPiYlrzHHeRHOBspG9BCJSHoIPDjjXe3CfkLNMHGezhtOPL21riPfXDBOhXRjUz9CkyUZVAExEDVOokVwdw6oXgrjcGX4jpF 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; 20 Jun 2014 14:50:49 -0000 Date: 20 Jun 2014 10:50:49 -0400 Message-ID: From: "John R Levine" To: "Stephen J. Turnbull" In-Reply-To: <87bnto17um.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20140616201759.84717.qmail@joyce.lan> <01P979UCLT0E0049PU@mauve.mrochek.com> <87bnto17um.fsf@uwakimon.sk.tsukuba.ac.jp> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/HsInlDEwidIjaB9tSzLfm0-6XHE Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] more theory of DKIM extensions, was draft-levine-dkim-conditional-00 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, 20 Jun 2014 14:50:52 -0000 > This particular generality worries me. As I understand it, conditions > become a registry matter, not an RFC matter. I fear the proliferation > of conditions that nobody will implement, or worse similar conditions > with slightly different semantics that somebody prefers to existing > registered conditions. That doesn't strike me as a problem. We have lots of protocols with registries full of little used or unused optional extensions. SMTP is a good example, and it interoperates pretty well. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Fri Jun 20 08:06:12 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481761A0379 for ; Fri, 20 Jun 2014 08:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.762 X-Spam-Level: X-Spam-Status: No, score=0.762 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 cu31nzBPk-tp for ; Fri, 20 Jun 2014 08:06:08 -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 B2FA11A0376 for ; Fri, 20 Jun 2014 08:06:07 -0700 (PDT) Received: (qmail 17071 invoked from network); 20 Jun 2014 15:06:06 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 20 Jun 2014 15:06: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:mime-version:content-type:content-transfer-encoding; s=12d2d.53a44dde.k1406; i=johnl@user.iecc.com; bh=n5fkEPneAOX4q1v52FHXp9zAoFwJrbYsJt3FZzB4NB0=; b=S+VnA9kcd0jg4tdYad0rvcNRA2rrsNOXK+8UMOAccQAtF6pjVRO78XWbDyxOQJHo9LJLrss3QPI+eaPZe/0I6JFr7TC+A3JFwKdY0V04ghtF33hx8aK3xnKPXsTP10+LsSpqvpSWZ9VXCfttmnlWhZckL2iT9xdoQNtC66X2nN84rbF4x5olat/xIfPo5JbQwsUe84pbYw0BKqqjnOD5yMaYcHmOcRjCUd1WNWZkOnAnEsJiukOZ5e8xfGER0+bZ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=12d2d.53a44dde.k1406; olt=johnl@user.iecc.com; bh=n5fkEPneAOX4q1v52FHXp9zAoFwJrbYsJt3FZzB4NB0=; b=V68mzIQSshuCFNhJyrgB6bIHXk+15c3y/H8slJZqgN7YjwbTefbkOSMfRKaipBXXIKxlISTR7lJT9aoD+7u8Zs4OvaoXpXMEgoyz+osFMGmX1CCuEHQdx29cicGs8DpkRXeWDd5hAsrqIXMkf41Vq+rxTzCtePSrOhfQW9Dh7tfI4YmcfXMIBOabVk3FOTQFl/M7TD88CtVJBg5D4gFee9yDjFeAMPIcQyF3iDVu/rHkgwQ9KzvKPjv0FErWmQAX Date: 20 Jun 2014 15:05:44 -0000 Message-ID: <20140620150544.77100.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <8738f00xur.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: http://mailarchive.ietf.org/arch/msg/dmarc/Sj_HYHPW2cvpEOg9FiHALFeiRdU Cc: stephen@xemacs.org Subject: Re: [dmarc-ietf] whitelists, was signature sample 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, 20 Jun 2014 15:06:09 -0000 > > [A DNS-based whitelist] does require u make a whitelist, ofc, but > > other than inputing it into DNS, doesn't require u do anything else > > with it, > >Inputting it into DNS is a *very* big deal, however. First, it's not >at all clear that it scales to precisely the sites I (at least) care >about most: the "> 1 million users" mailbox providers. It's not a problem. Every large mail system* uses DNSBLs; they know how to deal with the scaling issues. The problems are figuring out what to put in the DNSBL and who maintains it. R's, John * - yes, really From nobody Fri Jun 20 08:08:23 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19071A0379 for ; Fri, 20 Jun 2014 08:08:20 -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 4HJzqBfw9WcN for ; Fri, 20 Jun 2014 08:08: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 C90AC1A0369 for ; Fri, 20 Jun 2014 08:08:19 -0700 (PDT) Received: (qmail 17437 invoked from network); 20 Jun 2014 15:08:18 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 20 Jun 2014 15:08:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=12d43.53a44e62.k1406; i=johnl@user.iecc.com; bh=uZCs2qn1eH5r1lMIBKnFeVnJ+kz2u1DrEtBZO0WL9gU=; b=Y2bOYVocnpK8zriAfyDCwzg158lLvLWkSuYgBuXOaKGhD3IvK7IIvKyF+7LHZUc2jC+f2QfqHbuV1dkRMkSO7wjS3vGqOncUJF6/5p6fVTdYCJXhrT/2Ra1JMCZ9IQUynFG4n6EDYEZugmL22q3fj4bLn6Krulbm5ODT5W5psSOxPSLQrzy+51Z/xsAvoYbYTJDDwIDHm9aX2BZas5/VpKVEBM7bCHkmWH8k2/kKnTDj9zo8e1l8CaKCx13MOgKS DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=12d43.53a44e62.k1406; olt=johnl@user.iecc.com; bh=uZCs2qn1eH5r1lMIBKnFeVnJ+kz2u1DrEtBZO0WL9gU=; b=MdCsJ9AileCF/TiLCWAgQ2tdZb/4TEOW7C40wiwEqlPlaQWAz17HnW3LAOrcqqhATUUA/rgEis3prC9gA1xFe9nrYvOsFuiTHDH3UY1DNqhPFeiZolVxGqZk65K4Um7InJjkbB0KlwzGy7FnKhYK77eYfziH5cL7SKjAF/dYKS2SgD/BwD4G+Kp2KxXZNBdzvslRQ+7dLXGEADoqvidsNRXWWHXniT4rd4t99WIfSMbvXFuTwYjGvMNJybLRixmJ Date: 20 Jun 2014 15:07:56 -0000 Message-ID: <20140620150756.77122.qmail@joyce.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: http://mailarchive.ietf.org/arch/msg/dmarc/ZNPAMCCA46OSZxWGVieoqV0zpIs Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] yet more whitelists, was signature sample 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, 20 Jun 2014 15:08:21 -0000 >Also, it's a dance to put more policy data into the DNS in any form. The >"DNS people", as we appear to like to call them, don't like use of DNS to >store policy data even though it's extremely convenient for us to do so. >At a minimum, if we try to do that with TXT records again, we can expect a >huge amount of friction. We need to be sure that battle is worth having, >and I'm not convinced that it is given the caveats above and in Stephen's >email. I don't see that as a problem. We already have RFC 5518 vouch by reference which is very close if not identical to what you'd need here. >Finally, no DNS-based third party whitelisting scheme has ever gotten any >traction. That, on the other hand, is a problem. R's, John From nobody Fri Jun 20 08:14:57 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA741A03C5 for ; Fri, 20 Jun 2014 08:14:51 -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 t9bpS9rxa3c3 for ; Fri, 20 Jun 2014 08:14:46 -0700 (PDT) Received: from dkim.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 95CBB1A03A0 for ; Fri, 20 Jun 2014 08:14:45 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=398; t=1403277278; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=2WvC/Fyw4zSuxZGMg4a5txCKdYk=; b=qTzYQhdyQFjXcJfgqfXj ugYB7j4Hm0kYZ0myLYu4+0vk/VnLS9SbjqtmD16kJsj3uMigVmNWXP5cVQDNGxwJ X6iDGqSR/sQU6o8qun+GZNKMo7QEzFYAMFK144So6abT6dTmvytGoW15dNP122NQ SlLJj398zg3pSn2AcPsRnuQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 20 Jun 2014 11:14:38 -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; Received: from opensite.winserver.com (beta.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2757391460.37430.3372; Fri, 20 Jun 2014 11:14:37 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=398; t=1403277096; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=qI6C2Wb 9Zk+Mpwqu/m7t815ZmJuCQhhjPxCLk2AtgmY=; b=uJIjhhk8zTQSQ7L1Cax+f9x rsBBriS5UHBXmnC3DVKBQcwDQYe+G8vItOQrg4WkIHJXWFQL2xhFoaYNKimKui9U YHE2cBd24WwD2PNU8/PaQCcyFjjj8kIVpziq3rmOv7wJfnX+ZeOP04u/cSjqbfb8 Pugtu1+02ZVyuvBJjS4o= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Fri, 20 Jun 2014 11:11:36 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2773743640.9.5880; Fri, 20 Jun 2014 11:11:35 -0400 Message-ID: <53A44FE2.4000101@isdg.net> Date: Fri, 20 Jun 2014 11:14:42 -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: <20140616010237.77460.qmail@joyce.lan> <1611380D-2178-4116-9583-EC1086942825@tnpi.net> <6.2.5.6.2.20140619093658.0c118da0@resistor.net> <19E404FF-228E-426B-ACDA-97EDC50F23DF@isdg.net> <87egyk1amh.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87egyk1amh.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/0LtTXyBfBjyXFN4xSE-H60V-QtY Subject: Re: [dmarc-ietf] it's a version bump no matter what you call it, was Fwd: New Version 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, 20 Jun 2014 15:14:51 -0000 On 6/20/2014 12:13 AM, Stephen J. Turnbull wrote: > Hector Santos writes: > > > The DNS-based author domain defined policy is the only common > > approach we have now. > > "To a man with a hammer, every problem looks like a nail." Yes, indeed, in this case, it is that simple -- Occam's razor. Quite often, a hammer is all this is needed. -- Hector Santos http://www.santronics.com From nobody Fri Jun 20 10:53:15 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335171B2891 for ; Fri, 20 Jun 2014 10:53:07 -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 irjvHKJSD1Tb for ; Fri, 20 Jun 2014 10:53:04 -0700 (PDT) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E53D1B289B for ; Fri, 20 Jun 2014 10:53:04 -0700 (PDT) Received: by mail-yh0-f51.google.com with SMTP id f10so3112858yha.10 for ; Fri, 20 Jun 2014 10:53: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=uiLelLu2s+rH9OZm9mo1d9WuyOpYCFir0DQoaL6NfPU=; b=pxhH1oICSp7K3A8Owk3qT27MXGPyVLL5IvRJHPr97ET0GGmn9ON3Z35gVxzJhLj4B8 mUje11u7t0Io+D3FdysrZsLr/tgy0UbfqNSFWhUdhPlg+68yA3CgIaKH7Wcf3ZzBMP2H TTHMGgS5N2a/qSRiUrDZ1QoRIDEnlh9eli7WVH9J20nH+e6109vfFDSpPnlUpY1vy7Qi JVfL2f7IxHawIotXSmO7AISiltXuumnqON7PSLRZzdMutldwmq/BSn2Wzgr0BWbWK9cw pxAbPwabZgYC79ntb1D6MJiIESjGQozuKlDV/CI8O1dr3btRNaYCJnmY/csVTm4fuZpC HhSw== X-Received: by 10.236.81.1 with SMTP id l1mr7506982yhe.27.1403286783747; Fri, 20 Jun 2014 10:53:03 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id v4sm13724418yhc.55.2014.06.20.10.53.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Jun 2014 10:53:02 -0700 (PDT) Message-ID: <53A474B8.2060809@gmail.com> Date: Fri, 20 Jun 2014 10:51:52 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dmarc@ietf.org" References: <20140611222207.2338.qmail@joyce.lan> <53993D20.7010901@gmail.com> <8761k6pheq.fsf@uwakimon.sk.tsukuba.ac.jp> <87y4x1oht2.fsf@uwakimon.sk.tsukuba.ac.jp> <87fvj9nxhh.fsf@uwakimon.sk.tsukuba.ac.jp> <9B0EC050-6E8E-443A-B79B-083FA3710DA0@secondlook.com> <87d2ednte9.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87d2ednte9.fsf@uwakimon.sk.tsukuba.ac.jp> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/lIJPH5TYSq7eBXko5WNDym4wY9M Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 20 Jun 2014 17:53:07 -0000 Folks, G'day. I've now caught up on the list activity and am sending my combined comments in a single posting, especially since I think there's really a single organizing issue that's being missed... On 6/13/2014 12:46 AM, Stephen J. Turnbull wrote: > Well, for Author Domains publishing "p=reject", we can certainly > confuse the issue dramatically. Change the protocol to advocate > "silent discard" Question to the group: Does silent discard help? Or rather, do we have any indication that noisy "p=reject" does or can hurt? On 6/15/2014 9:43 AM, Murray S. Kucherawy wrote: > On Sat, Jun 14, 2014 at 11:15 PM, Dave Crocker : > What I was suggesting was merely registering a new canonicalization > algorithm. Legacy DKIM implementations won't understand it. New > ones (presumably also modified to know about DMARC) will. ... > > The reason I don't like this approach -- assuming I am not missing > something from this idea -- is because then we are, directly or not, > tying verification semantics outside of DKIM to a canonicalization. One way or the other, the different approaches are trying to trick legacy receivers into being unable to process the weaker signature. As the cliche goes, we are merely haggling price. However price matters; we should have a good reason for choosing one trick over another. Still I think we shouldn't trick ourselves into believing this game is anything other than producing a hack. On 6/15/2014 10:00 AM, John Levine wrote: >> I do not understand this predilection for trying to change the DKIM >> base engine. It doesn't need it. > > Actually, I claim that a version bump is the approach least likely to > break existing clients. The premise is that a version number change will be noticed by a legacy DKIM engine. While of course it ought to be noticed, do we have evidence that it reliably is? There's some history with version numbers not working for Internet protocols. (I get some perverse enjoyment out of noticing that IPv6 requires a different ethertype value, rather than just relying on the IP version field...) >> I also don't understand the construct of 'special handling', never >> mind not liking the idea of it, especially since it explicitly >> creates the complexity of "depends on the header field". > > I think we agree that the goal here is to have a weak signature that > verifiers disregard unless it's associated with a delegated signature. > Your plan, as I understand it, was that verifiers will ignore a > signature that is too weak. One might argue clients that accept weak > signatures are already broken, but in that case there are an awful lot > of broken clients, starting with spamassassin. (I just checked.) That does not make the issue any less fundamental. The DKIM specification leaves it to the receive-side evaluator to decide whether "enough" of a message was covered and whether the signature was "sufficiently" strong. If engines are currently ignoring this issue, we have a deeper problem, IMO, and should focus on fixing that, rather than treating it as an acceptable given. > Until now there's been no reason other than playing games to use weak > signatures, so in practice it hasn't mattered. Right. Some problems don't surface right away. That does not mean we should ignore these sorts of underlying problems and just work around them. > Murray's trick, add a new canonicalization that's only valid if > there's a paired signature, many not require a version bump, but to be > useful it does require a change to the verifier library interfaces. It's definitely a paradigm change. Arguably the change is 'above' DKIM, in the sense that the core DKIM engine remains unchanged, but rather it is the interpretation of the result for a DKIM evaluation that can be different. Merely validating a signature is /never/ supposed to give a message an automatic pass. Rather, the validation is supposed to be fed into an analysis engine that considers a variety of factors. Adding a requirement that one validation needs to be accompanied by a particular other valid signature is just such an additional factor. In other words, the changes being discussed here are really in DKIM usage policy and not DKIM signing/validating. > With respect to Stephen's concern about libraries knowing when to > construct v1 or v2 signatures, really, that's no big deal. We've been > doing that sort of stuff for version bumps since approximately > forever, and it's a nit compared to the other stuff it'll have to do > to interpret the conditional signatures. Please point to details on the long history of successfully doing version bumps in Internet protocols. I'm not aware of it. I see that http has done it, though I don't know how it is used or how useful it has been. But I haven't noticed the construct being generally useful for other protocols. Certainly not for IP... And note that the rest of the email specs haven't used them. > It also occurs to me that there are all sorts of ways that a > conditionally valid signature would be useful. For example: The signature is not "conditionally valid". The signature validates or it doesn't. Binary choice. That a signature is what we are calling weak does not make it more or less valid. What is conditional is the /use/ of the validation, just as is supposed to already apply for validated DKIM d= values. So the enhancement here concerns a new layer that specifies DKIM usage policies, not changes to the existing signing/validating engine. This does invite the basic and continuing need to worry about how things will be processed by legacy engines that don't know about the enhancements. However we need to be careful in making assumptions about this rather than empirical information. On 6/15/2014 11:58 AM, ned+dmarc@mrochek.com wrote: >> Until now there's been no reason other than playing games to use >> weak signatures, so in practice it hasn't mattered. Now it does, >> so clients have to change their code to check for "too weak", >> probably in inconsistent ways, to check for l= and what headers are >> signed and so forth. > > Agreed. Like it or not, this calls for, let's call it a > "clarification" of existing DKIM semantics. And to do that you either > bump the version or overload some other existing field in the > protocol. I understand the premise here, and agree it's reasonable. What I don't know is whether it is valid. That is, we have a presumption of a problem but I haven't noticed documentation that the problem is real and serious, to justify making a change to the basic DKIM platform. More generally, the IETF has often done BCP-ish documents that clarify usage issues -- such as "watch out for 'weak' signatures" without changing protocol version numbers. >> It also occurs to me that there are all sorts of ways that a >> conditionally valid signature would be useful. For example: > >> * valid if this DNS lookup resolves, for per-signature revocation > >> * valid if the body has this S/MIME signature, to allow for list >> software that reformats the message but keeps the signed body part >> (mailman and mj2, for example) or that resigns with its own S/MIME >> signature (sympa) > >> * valid if the body has this PGP signature (mailman's working on >> it) > >> Some of these can be done with kludges, but most can't. > > Exactly why I think that as long as we're bumping the version, > building in some additional extensibility seems like a really good > idea. The only question is how much and in what form. Which is why I'm classing this as adding a policy engine on top of the (stable and unchanging) DKIM signing and validation engine. For reference, I note that some other postings on the list have been making a similar distinction between validation and policy. However they do not seem to have gotten traction. On 6/20/2014 7:42 AM, John R Levine wrote:>>> 4. How does the sending MTA know when to stamp this v=2 DKIM >>> header? Presumably, it would need to have a list of known >>> forwarders stored somewhere? > > That seems likely, And this underscores just how strange the current discussions are, since a list like that doesn't scale. On 6/19/2014 2:46 PM, Ned Freed wrote: > So, are we going to create a new header field every time we come up > with some new required semantic we want to attach to a DKIM > signature? ... > Why don't we fix the extensibility problem instead? +1 Anyhow and FWIW... As we worry about 'suddenly' having to worry about getting receivers to be careful if they receive a 'weak' signature, let's consider the suddenness in the context of the literally overnight, rapid expansion of DMARC use into generalized mass-market scenarios. By comparison, anything we are talking about doing here is at glacial speeds. That is, it is arguably quite easy to get DKIM receivers to start paying attention to signature strength, without anything other than a public awareness campaign, and certainly not needing anything as extreme as a version number change to an engine that is not actually changing... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jun 20 11:23:08 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732A71B288C for ; Fri, 20 Jun 2014 11:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.762 X-Spam-Level: X-Spam-Status: No, score=0.762 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 NnW0FfGLgG92 for ; Fri, 20 Jun 2014 11:23:00 -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 0ABA11B28A3 for ; Fri, 20 Jun 2014 11:22:22 -0700 (PDT) Received: (qmail 52844 invoked from network); 20 Jun 2014 18:22:21 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 20 Jun 2014 18:22:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=13096.53a47bdd.k1406; i=johnl@user.iecc.com; bh=5W2nuP9kSjrAkm0PPmaodbMQf0W5ZalBKITc8TB7Mqs=; b=bbWrd62elfoufDtT9w3SBu+TZaUp5OX5Kib9r24P3Bf+7YP+0jzPT/kSYp0YcBUnvORi9O5Pxr9ZtBUJf21gApD4jwa2l4toOu6cHsxh8Ylm2zqxEmMbgrfLi4X2zuh0SBUnCqMdryTmLi/NPfy4O4AL+HhJ/A6rkiZGj2z+sT442w96tkAzrisKQc2NWqr44p+lTGOgnpxEQ85RGpxu2SAnpGyj6skT8Fl8R54Ogz28HRgIZqhyEXs+iJCy5APX DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=13096.53a47bdd.k1406; olt=johnl@user.iecc.com; bh=5W2nuP9kSjrAkm0PPmaodbMQf0W5ZalBKITc8TB7Mqs=; b=p2ffsTd0KoCoEy04Uz0IAh1CXroqULw/QMLTGn9tTPloWTGC6n3KksYbh3CB1e1bTRwzNM1jOaRlWopXSp9qjfIA5mIhAMlDkzdsEg3Vnr76UBF25bieS+uN2xgIGx2pOessQY9KSACJu/EX6hZix5fbZ6PQ4FY5Zu59DvlmLvxoDlAJnpFtheM5sY3LUXyXDSjxIKes5maHfM8Cw+SAwTTu/hAoIvNYfZ6I1BAeRM3csWFUmj3wUI+13zMz34Pf Date: 20 Jun 2014 18:21:59 -0000 Message-ID: <20140620182159.77973.qmail@joyce.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: http://mailarchive.ietf.org/arch/msg/dmarc/JFhRu9qlnY6vEdaiP1i7UDpoG6U Cc: superuser@gmail.com Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-01.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, 20 Jun 2014 18:23:01 -0000 >Playing around with ideas here. This one removes the "l=0" signature stuff >and instead makes DKIM-Delegate into a more self-contained thing, which I >believe was suggested (or at least inspired) by Stephen's comments. There >is still the potential for abuse during the ephemeral relationship period >(i.e., prior to expiration), but it it is now an indirect attack on the >author domain rather than a direct one. Perhaps that's more palatable in >this scenario. > >Comments welcome. This looks an awful lot like my draft-levine-cdkim-00 and draft-levine-dkim-conditional-00 except that mine has more bits of DKIM in the cdkim signature so it can sign To and From to limit the range of spoofage. R's, John From nobody Fri Jun 20 11:44:06 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F171B28C3 for ; Fri, 20 Jun 2014 11:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.537 X-Spam-Level: X-Spam-Status: No, score=-0.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_110=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 t9x0n0U5w9po for ; Fri, 20 Jun 2014 11:44: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 39E061B28B5 for ; Fri, 20 Jun 2014 11:44:01 -0700 (PDT) Received: (qmail 57210 invoked from network); 20 Jun 2014 18:43:59 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 20 Jun 2014 18:43:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=130c2.53a480ef.k1406; i=johnl@user.iecc.com; bh=1Qt372LMtdBriMP3PNmq9SM4h4kj/IGvO6PSpVzAFrQ=; b=Pb8JxxcynTs33vETXoxuycgBRjvKwee4fkiG/XzD1/fUZpfYtDqXE637ZAWSVsP0mSUHtT2SCjSDBByaMVHhFbTA3djS5BWNSyiDeRZAOUrErhbN79zEPy5+IRQ073PXYZuzrxX96Q5q9CXNySDfxho6E5NOj0WhRo+pSwHOrMgXHPdp6tJZhVy8jjCWEITgdnqaoXgsZ7LNti9E2Dl6HdCXD80iZrY6iKXyuRPse64M159cFXwpoPh3Fou5VC+j DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=130c2.53a480ef.k1406; olt=johnl@user.iecc.com; bh=1Qt372LMtdBriMP3PNmq9SM4h4kj/IGvO6PSpVzAFrQ=; b=OIAAhFvAL6vOMS7BKYuuBJJfYIJsgqwc096UY0Eqo2SZl1itODcoRQjHU6KiDUwPuK6n7zO7NvSFeIYz092xuPQXI90zR4T2bbtBC7v7a31ZnqcQLRIiPWmYoBM80yyiXywVTH3eilxWOsrs5Ra7zoHNwkUrkwG1grfxThJcaYFxyc9cv/Qi8mPbxljNlfAg8OSO8gQl1C8X2iYM/XdRiDW17SyEMRfAiZuLOdQJahKzB2mAwJ/5LekotbpstQbv Date: 20 Jun 2014 18:43:37 -0000 Message-ID: <20140620184337.78017.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <53A474B8.2060809@gmail.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/BWb2_wckoEV0bRUvHxf0IaX2BgE Cc: dcrocker@gmail.com Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 20 Jun 2014 18:44:02 -0000 >Question to the group: Does silent discard help? Or rather, do we have >any indication that noisy "p=reject" does or can hurt? ADSP had silent discard. It avoided the problem of people bouncing off lists, but made the "where did my mail go" problem even worse. DMARC has p=quarantine. In discussions with people running large mail systems, they said they thought about it and decided it would not be an improvement. >One way or the other, the different approaches are trying to trick >legacy receivers into being unable to process the weaker signature. As >the cliche goes, we are merely haggling price. >The premise is that a version number change will be noticed by a legacy >DKIM engine. > >While of course it ought to be noticed, do we have evidence that it >reliably is? >The DKIM specification leaves it to the receive-side evaluator to decide >whether "enough" of a message was covered and whether the signature was >"sufficiently" strong. If engines are currently ignoring this issue, we >have a deeper problem, IMO, and should focus on fixing that, rather than >treating it as an acceptable given. ... I don't know anyone who's checked whether DKIM validators verify the version number, but if it's an issue, there aren't that many widely used DKIM engines so it wouldn't be hard to check. It seems to me it's a lot easier to verify a specific check for a version number than an ill defined acceptance of "too weak" signatures. It's also not clear to me that there is any reason for a verifier to care about the strength of a signature. If a signer wants to put weak signatures on mail and take the risk that his reputation will be sullied by heavily mutated messages, that's not the verifier's problem. (Note that this is not the same as what I'm proposing, a weak signature that is valid only if there is an additional signature from a second signer that I trust to put on a reasonable signature.) >Adding a requirement that one validation needs to be accompanied by a >particular other valid signature is just such an additional factor. I don't see it that way. In my version, at least, the second signature is part of what makes the signature valid, just like a body hash that matches the body or an expiration date that hasn't passed. It's not a matter of opinion, it's either there or not. >> With respect to Stephen's concern about libraries knowing when to >> construct v1 or v2 signatures, really, that's no big deal. We've been >> doing that sort of stuff for version bumps since approximately >> forever, and it's a nit compared to the other stuff it'll have to do >> to interpret the conditional signatures. > >Please point to details on the long history of successfully doing >version bumps in Internet protocols. I'm not aware of it. ssh seems to work OK with versions 1 and 2 both in use NFS moved from 4.0 (RFC 3530) to 4.1 (RFC 5661) >> It also occurs to me that there are all sorts of ways that a >> conditionally valid signature would be useful. For example: > >The signature is not "conditionally valid". The signature validates or >it doesn't. Binary choice. That a signature is what we are calling >weak does not make it more or less valid. By "conditionally valid" I mean more conditions the verifier uses to make the binary choice. Better wording always welcome. R's, John From nobody Fri Jun 20 12:13:45 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2108D1B28B9 for ; Fri, 20 Jun 2014 12:13:43 -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 snsCqrb8MpRo for ; Fri, 20 Jun 2014 12:13:42 -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 22A971A02AF for ; Fri, 20 Jun 2014 12:13:42 -0700 (PDT) Received: (qmail 63890 invoked from network); 20 Jun 2014 19:13:41 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 20 Jun 2014 19:13:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1314c.53a487e5.k1406; i=johnl@user.iecc.com; bh=FwpX3Qpu7drXa9ctpJr6ojn3lDeVoB1TmpeUtAndOqQ=; b=NVJmPXd0e6eDvhoENqkZ3SsVJ2SROTF4ueWXRwai2p8YBRiWUSe99t0Eo8PidZQv57kmqIJyUF2/qlx9OzZf4rSw9JbtLyztCTOpSmEDIB+HcdjrfsCcINzwAd1EftkQth+b50XP9x8rOR7ZdrrCX2mSWkob0vU1yfGuS3EkwblCSF82XzZY1tJrbXY9ZW/GuWWJqOHxVALM/5+ZxBH9eHI5Au+F2V3dawYO9DBe8+SvQl3o6/sAMuKbdq+ESjHN DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1314c.53a487e5.k1406; olt=johnl@user.iecc.com; bh=FwpX3Qpu7drXa9ctpJr6ojn3lDeVoB1TmpeUtAndOqQ=; b=wEuZxAWI7zA/jE/BbKtyFrcrUp1CZZ3Oxq/AcXV1FBuxWuhwMw6ywFR11tPtQp1KVJ3tqbHihCP4ybLHgp6sr2A+u8IvLtkfHHnhgJ9U+wDNwB8icbVGWodPAWBiXOZNfm6B75Dlzv3thtsQWXA5dLFVrZkQAkGsOhWUxOwVbY8nTvgrp3z/ifpn1Ta3H9a6zOxMV/4ZQ08JDdY9Y7voE/E/mjMe+VkTCjMujy5zTm7OQpZw3VhQCH5lBahGwDSG Date: 20 Jun 2014 19:13:18 -0000 Message-ID: <20140620191318.78155.qmail@joyce.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: http://mailarchive.ietf.org/arch/msg/dmarc/MtajHWYKQZ8xnFAH8C36lA1bEfs Subject: Re: [dmarc-ietf] The theory of DKIM versions 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, 20 Jun 2014 19:13:43 -0000 >The problem may be that we don't agree about what DKIM versions mean. >Here's what I would like them to mean: ... >c) Whenever we add new tags that require that the verifier understand them >to get the right answer, we increment the version number. Ned pointed out that we could add an indicator on a tag that means that interpreting the tag is mandatory, so if the verifier doesn't understand the tag, the verification fails. This would decrease the need for future version bumps. So for example: DKIM-Signature: v=2; a=rsa-sha1; c=relaxed/relaxed; s=s1024; d=sender.example; h=From:To:Date; l=0; !cs=fs; fs=t; bh=... b= The ! in !cs= means that the verifier MUST handle the cs= tag or fail the message. R's, John From nobody Fri Jun 20 13:02:54 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A5A1B28EC for ; Fri, 20 Jun 2014 13:02:52 -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_40=-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 ZaN2zMV5_orm for ; Fri, 20 Jun 2014 13:02:50 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4636A1B28DC for ; Fri, 20 Jun 2014 13:02:50 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id rd3so3456833pab.18 for ; Fri, 20 Jun 2014 13:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=n3LoD0HQebLf5sDAhzlmsWZM8JaVEXH3xHjnBcmFK+c=; b=nVIze21i6NVn3PrbVavrXvX5xDezkVhhABrYLS1W3SqCbrKCndJTKQDDgAkJbuD4Va W4HFzfigpz6eYRyL7pWMYY0UP3MT5c04q41bl9VKwB9FnKCRfsnIpb1og2Os4CPmPIIB kTU5qEfxXVgN6ous3J97JDX4PDpTihCCOWex10iypASWlGTJTwY8n18oqj/IcrQgP7Ux wIQLNveL1x1PtMh8gjQGZBWEFHXNGxXYLEoH8AOueps0rPELYzm1aZoMTw01SWcDn/c1 JhEit7gm4/jYnTHl7nhdrDKcs1g0/ZNsmgKT7zvvDdRqHqfQQRptp1UWfVhxT/Tw7SAe TxqQ== X-Received: by 10.66.235.34 with SMTP id uj2mr7680868pac.28.1403294569888; Fri, 20 Jun 2014 13:02:49 -0700 (PDT) Received: from dhcp150.priv.bungi.com (c-76-21-122-217.hsd1.ca.comcast.net. [76.21.122.217]) by mx.google.com with ESMTPSA id id10sm14825089pbc.35.2014.06.20.13.02.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Jun 2014 13:02:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: <20140620150756.77122.qmail@joyce.lan> Date: Fri, 20 Jun 2014 13:02:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140620150756.77122.qmail@joyce.lan> To: John Levine X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/7MiuOzLZfkXm9ATDOPLiRFGe5IQ Cc: dmarc@ietf.org, superuser@gmail.com Subject: Re: [dmarc-ietf] yet more whitelists, was signature sample 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, 20 Jun 2014 20:02:52 -0000 Dear John, Comments inline: On Jun 20, 2014, at 8:07 AM, John Levine wrote: >> Also, it's a dance to put more policy data into the DNS in any form. = The >> "DNS people", as we appear to like to call them, don't like use of = DNS to >> store policy data even though it's extremely convenient for us to do = so. >> At a minimum, if we try to do that with TXT records again, we can = expect a >> huge amount of friction. We need to be sure that battle is worth = having, >> and I'm not convinced that it is given the caveats above and in = Stephen's >> email. >=20 > I don't see that as a problem. We already have RFC 5518 vouch by > reference which is very close if not identical to what you'd need > here. Strongly disagree. DMARC is an anti-phishing solution deployed by = financial institutions interested in suppressing phishing attacks. = Phish related fraud was not effecting their bottom-line, it was customer = loss resulting from phish related abuse that drove this effort to = protect the =46rom address. DMARC is not about dealing with high volume = spam. Especially since methods for dealing with spam are wholly = ineffective against phish. We offer similar anti-phishing services for corporate customers. = Reputation had proved hopelessly ineffective. The issue is rather = simple. Only the sending domain knows with certainty when their =46rom = address is being spoofed. As such, content of the =46rom address can = not be effectively assessed by third-party reputation services, nor are = normal spam collection techniques comprehensive or effective. DMARC = feedback provides what is needed but contains PII and should not be = generally shared with various third-parties. Although users may have = never sent a message to a mailing-list, DMARC rejection will expose who = subscribed to which mailing list nevertheless.=20 Since third-party allowances are absolutely critical for maintaining = user privacy, TPA-Label expects this information be directly provided by = the DMARC domain. Publication can be easily delegated, but only the = DMARC domain is authoritative about which services are being used or = which of these services are abusing their =46rom headers. =20 >> Finally, no DNS-based third party whitelisting scheme has ever gotten = any >> traction.=20 >=20 > That, on the other hand, is a problem. While meeting with management in Europe, it seems there is some interest = in our company in offering a TPA-Label zone as a service for DMARC = domains. Those interested can contact me privately for appropriate = contacts in their area. Perhaps this will also assuage Stephen's DNS = related issues. Publishing in DNS should never be an issue for = mailing-lists. I will attempt to create a draft outlining how a = subscription process can send a request via DMARC feedback for = authorizations to be granted. It seems wrong to suggest that Yahoo and AOL will be the only domains = able to benefit by enhanced anti-phishing strategies, and that this = issue will soon fade. Unless DMARC is able to ensure adoption of its = recommended handling does not result in service disruption or massive = complaints, a reject recommendation will quickly devolve into a far less = effective quarantine. If this further devolves into discardable, it = will significantly erode email integrity and its usefulness as offering = effective notifications. Regards, Douglas Otis From nobody Fri Jun 20 13:05:41 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D8F1B28E4 for ; Fri, 20 Jun 2014 13:05:40 -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 j4Nu-Sd2P6ea for ; Fri, 20 Jun 2014 13:05:39 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AC071B28DC for ; Fri, 20 Jun 2014 13:05:39 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id x12so4129074wgg.34 for ; Fri, 20 Jun 2014 13:05:37 -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=KhDWRw6RDgWM0xlDbLjXDvXL6eKcp9vywejzN7a6PyY=; b=bEjLvF9zP2WghHJF2ye3ha2AvC09aHzNr9FgQ8YyMMHmjqR86LdKCW5AJGUD2REP/3 mCxU9VSFx9tUPejhQK33dO5/crw6FOy5jM3jDpiniATYQjiXpEn9CIanlSQs7caCmqKL iM21B2/BATe8hJXMCTq1PvVNV5so/lhBfefLftVt1i+z6GkeYHN7MYMzrqzw78gKyE+G 7MVlXZdhKXKNfDJLy3p5MyJCYJDxRNkVGX53OnKdu1vsKF8+PzLBaXNeWmbHzX+9DARn HQxX4G9f405tcsjZUEMunm1hNxeLUkgRp0RNGIArMtZcopUBBuddNfk9kMPrzXgMKkqg r1Yg== MIME-Version: 1.0 X-Received: by 10.180.83.105 with SMTP id p9mr6593322wiy.8.1403294737717; Fri, 20 Jun 2014 13:05:37 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Fri, 20 Jun 2014 13:05:37 -0700 (PDT) In-Reply-To: <20140620150756.77122.qmail@joyce.lan> References: <20140620150756.77122.qmail@joyce.lan> Date: Fri, 20 Jun 2014 13:05:37 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=f46d044282de5b618304fc4a04ca Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/LKv2vWpUh5xNdBA53tk6BmO1vxg Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] yet more whitelists, was signature sample 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, 20 Jun 2014 20:05:40 -0000 --f46d044282de5b618304fc4a04ca Content-Type: text/plain; charset=UTF-8 On Fri, Jun 20, 2014 at 8:07 AM, John Levine wrote: > >Also, it's a dance to put more policy data into the DNS in any form. The > >"DNS people", as we appear to like to call them, don't like use of DNS to > >store policy data even though it's extremely convenient for us to do so. > >At a minimum, if we try to do that with TXT records again, we can expect a > >huge amount of friction. We need to be sure that battle is worth having, > >and I'm not convinced that it is given the caveats above and in Stephen's > >email. > > I don't see that as a problem. We already have RFC 5518 vouch by > reference which is very close if not identical to what you'd need > here. > I'm not talking about recycling existing stuff. I'm talking about new mechanisms that aren't out there already, not new data. -MSK --f46d044282de5b618304fc4a04ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 20, 2014 at 8:07 AM, John Levine <johnl@taugh.c= om> wrote:
>Also, it's a dance to put more policy data into the DNS in any form= . =C2=A0The
>"DNS people", as we appear to like to call them, don't li= ke use of DNS to
>store policy data even though it's extremely convenient for us to d= o so.
>At a minimum, if we try to do that with TXT records again, we can expec= t a
>huge amount of friction. =C2=A0We need to be sure that battle is worth = having,
>and I'm not convinced that it is given the caveats above and in Ste= phen's
>email.

I don't see that as a problem. =C2=A0We already have RFC 5518 vouch by<= br> reference which is very close if not identical to what you'd need
here.

I'm not talking about recycli= ng existing stuff.=C2=A0 I'm talking about new mechanisms that aren'= ;t out there already, not new data.

-MSK
--f46d044282de5b618304fc4a04ca-- From nobody Fri Jun 20 13:07:35 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE821A041B for ; Fri, 20 Jun 2014 13:07:34 -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 X9ZlhyrWNLPq for ; Fri, 20 Jun 2014 13:07:33 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B75F41A0331 for ; Fri, 20 Jun 2014 13:07:32 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id l18so4146617wgh.28 for ; Fri, 20 Jun 2014 13: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=188k7N22R9GjYxTUke59zPLOssT9jQ+fRlGnuPxFOL8=; b=jm0lE+uZrL2m9MK4fwTH5Fh/t1UuFqI/iTX/DO7JFCAGuDsTgXkqYutu931SR7Hcr6 vHyoArwR6HcVP2LtdI++maiD1DuTLFfekuZS5wuNsRMd1dZcF2nzLCEBchfN6UhKs0pQ ZcFQD4LwL772+HZCDVu3edp15v4icQjE8JkZ7eJGLOiIsOmSF7mnpl5DwtbzuO2SWOOL P36HjXynojuuU6gAQROv2tvdnNrVB9csKVlWp0N13LMMerMoS3E2saVYAwO4rNn7RXYG 3oos6MRNUx/Zf02npgeVuKgVHQeD57D/b8bOhRcekgvKAR5qrgymy/IglQwhIHbDSjyg Cwxg== MIME-Version: 1.0 X-Received: by 10.194.7.36 with SMTP id g4mr7063228wja.37.1403294851434; Fri, 20 Jun 2014 13:07:31 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Fri, 20 Jun 2014 13:07:31 -0700 (PDT) In-Reply-To: <20140620182159.77973.qmail@joyce.lan> References: <20140620182159.77973.qmail@joyce.lan> Date: Fri, 20 Jun 2014 13:07:31 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=047d7b450a7c2298fb04fc4a0b57 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/G3iEH7wDKNmEoESzkpIjBtKq2cI Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-01.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, 20 Jun 2014 20:07:34 -0000 --047d7b450a7c2298fb04fc4a0b57 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 20, 2014 at 11:21 AM, John Levine wrote: > This looks an awful lot like my draft-levine-cdkim-00 and > draft-levine-dkim-conditional-00 except that mine has more bits of > DKIM in the cdkim signature so it can sign To and From to limit the > range of spoofage. > The difference is that this proposal doesn't change/extend/spin/fold/mutilate DKIM at all. The semantics are outside entirely. -MSK --047d7b450a7c2298fb04fc4a0b57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 20, 2014 at 11:21 AM, John Levine <johnl@taugh.= com> wrote:
This looks an awful lot like my draft-levine-cdkim-00 and
draft-levine-dkim-conditional-00 except that mine has more bits of
DKIM in the cdkim signature so it can sign To and From to limit the
range of spoofage.

The difference is th= at this proposal doesn't change/extend/spin/fold/mutilate DKIM at all.= =C2=A0 The semantics are outside entirely.

-MSK
--047d7b450a7c2298fb04fc4a0b57-- From nobody Fri Jun 20 13:12:05 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC3B1B28E4 for ; Fri, 20 Jun 2014 13:12:03 -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_110=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 bzuemv5z10Hx for ; Fri, 20 Jun 2014 13:12:00 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 028C11A0331 for ; Fri, 20 Jun 2014 13:11:59 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id i57so3278251yha.13 for ; Fri, 20 Jun 2014 13:11:59 -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=XI1ljxYrk3+p1xj4NkA2rPWMwpNRcgUsPNmWq0Q2Z5Y=; b=s6Fu0oGTBZhSDLxKnWnkFKQhtZpn7TjpX5SCV2bZxVyql3e+UGOzuC+C/Y9C96brPj 4uLr+WK/S7JIgHGn/5al7NOJUY2tV6b/ZvZ1VR2Mc9lvovzVV628UZ87uwL/R+ufHUXz gbKSTiicmnv+kc1jMjl2Zkknv+k7WdHBdmBQMtPSgAbi5uZWJx+4WMrhUrNa2wpK0Zeu trUGSfWKVTEiaHBgW0tYlOTinMGM5L1W0Vh4mxsmuHF5eElz6B3O3VZpBtxO3qjq0dCH ccwI3XlFJvuo7LCTvBO68cRowyQ/IYbDbixvGUaMNBlLsoAnrzE0b6WzVG3r40mVPh9F Ce6A== X-Received: by 10.236.143.229 with SMTP id l65mr8432186yhj.95.1403295119192; Fri, 20 Jun 2014 13:11:59 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id x12sm16035018yhe.53.2014.06.20.13.11.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Jun 2014 13:11:58 -0700 (PDT) Message-ID: <53A49547.2060307@gmail.com> Date: Fri, 20 Jun 2014 13:10:47 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Levine , dmarc@ietf.org References: <20140620184337.78017.qmail@joyce.lan> In-Reply-To: <20140620184337.78017.qmail@joyce.lan> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/2QMPVRY9NXUxye7S4-5i_Z4dOJQ Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 20 Jun 2014 20:12:03 -0000 On 6/20/2014 11:43 AM, John Levine wrote: >> Question to the group: Does silent discard help? Or rather, do we have >> any indication that noisy "p=reject" does or can hurt? > > ADSP had silent discard. Sorry, I meant to indicate an interest in usage that was, well, you know, actually used... > DMARC has p=quarantine. In discussions with people running large mail > systems, they said they thought about it and decided it would not be > an improvement. That could be worth getting some consensus documentation on. >> The DKIM specification leaves it to the receive-side evaluator to decide >> whether "enough" of a message was covered and whether the signature was >> "sufficiently" strong. If engines are currently ignoring this issue, we >> have a deeper problem, IMO, and should focus on fixing that, rather than >> treating it as an acceptable given. ... > > I don't know anyone who's checked whether DKIM validators verify the > version number, but if it's an issue, there aren't that many widely > used DKIM engines so it wouldn't be hard to check. It seems to me > it's a lot easier to verify a specific check for a version number than > an ill defined acceptance of "too weak" signatures. Once you've classed the task as touching existing engines, then we should touch them strategically and not merely with a tactical hack. > It's also not clear to me that there is any reason for a verifier to > care about the strength of a signature. If a signer wants to put weak > signatures on mail and take the risk that his reputation will be > sullied by heavily mutated messages, that's not the verifier's > problem. Actually, it is, since it is the verifier's system that will let the mail get delivered, or not, to an associated mailbox. It is /their/ users who will be most directly affected. Or, at least, I have assumed that is why folks are so concerned about the increased ability to do a replay attack if the signature is 'weak' (mostly meaning, doesn't cover the body.) > (Note that this is not the same as what I'm proposing, a > weak signature that is valid only if there is an additional signature > from a second signer that I trust to put on a reasonable signature.) Right. Adding a Policy layer. >> Adding a requirement that one validation needs to be accompanied by a >> particular other valid signature is just such an additional factor. > > I don't see it that way. Try harder. >> In my version, at least, the second > signature is part of what makes the signature valid, just like a body > hash that matches the body or an expiration date that hasn't passed. One can always define things in a way that conflates issues that should be layered. That doesn't make it the right architectural choice. TCP and IP used to be a single entity. Adding architectural structure and modularity is a discipline. Subroutines aren't "required" but they certainly make code a lot cleaner. The same holds for protocol specification. So on the question of conflating usage of a validated signature with the validation process, I'll offer my usual quote from my favorite engineer: "We can do that, but it would be wrong."[1] > It's not a matter of opinion, it's either there or not. How did you come up with 'opinion' as relevant to the discussion here? >>> With respect to Stephen's concern about libraries knowing when to >>> construct v1 or v2 signatures, really, that's no big deal. We've been >>> doing that sort of stuff for version bumps since approximately >>> forever, and it's a nit compared to the other stuff it'll have to do >>> to interpret the conditional signatures. >> >> Please point to details on the long history of successfully doing >> version bumps in Internet protocols. I'm not aware of it. > > ssh seems to work OK with versions 1 and 2 both in use There is some irony in citing ssh, given things like: Prevent SSH from advertising its version number http://serverfault.com/questions/216801/prevent-ssh-from-advertising-its-version-number But yeah, this sounds like version numbers work /really/ well: RFC 4253: "5.2. New Client, Old Server Since the new client MAY immediately send additional data after its identification string (before receiving the server's identification string), the old protocol may already be corrupt when the client learns that the server is old. When this happens, the client SHOULD close the connection to the server, and reconnect using the old protocol." > NFS moved from 4.0 (RFC 3530) to 4.1 (RFC 5661) Except that the usage model is more like SMTP options, or completely independent dual stack: RFC 5661 "NFS version 4 minor version 1 has no dependencies on NFS version 4 minor version 0, and it is considered a separate protocol. Thus, this document neither updates nor obsoletes RFC 3530." Wow... >>> It also occurs to me that there are all sorts of ways that a >>> conditionally valid signature would be useful. For example: >> >> The signature is not "conditionally valid". The signature validates or >> it doesn't. Binary choice. That a signature is what we are calling >> weak does not make it more or less valid. > > By "conditionally valid" I mean more conditions the verifier uses to > make the binary choice. Better wording always welcome. Having an added layer of policy-related /usage/ of a validated signature is quite different from the question of whether the signature validates. d/ [1] Nixon, R. Watergate tapes. March 21, 1973. http://www.huffingtonpost.com/mitch-rofsky/history-reexamined-waterg_b_838716.html -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jun 20 13:13:12 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A98421B28DC for ; Fri, 20 Jun 2014 13:13:09 -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 K16yc7N7qbQi for ; Fri, 20 Jun 2014 13:13:08 -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 7E13C1A0331 for ; Fri, 20 Jun 2014 13:13:08 -0700 (PDT) Received: (qmail 77003 invoked from network); 20 Jun 2014 20:13:07 -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:cleverness; s=12cc9.53a495d3.k1406; bh=bz4MB5qeknYtbwEmTrmi7cUlj6PDdh/YEP+cmYbwcSw=; b=aZyZL5OHpyX6CE9ozKGq3EWUGg9Szbr+3ik/ks1OkYK+EfA130cyj/OH9u1Kp0pujX976IaWYVd7glMRcj0Yi1FRfIUye3x95oaVAlPJTyiVrJTXESsEgEv645VI9nyUzkIezYkI8qkOLhuT+I/P0HGSLYi/eBCKHsnK/MeIo5tmiGPYxQouMPV8G6y7h6h4kBquu02n4wY4wdPbK00Cz5dGdAN9RSn2yalEo0gdYwItIDMvTWTq32WgsnFhTilw 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:cleverness; s=12cc9.53a495d3.k1406; bh=bz4MB5qeknYtbwEmTrmi7cUlj6PDdh/YEP+cmYbwcSw=; b=EdrTWxK6k76rXSYfSpBf0KS7c9ZbGZ0PqP/+iGjuvgKEqUgt9lo4nYv9A4wJfrQt8qnYtmLrd15oN3Xt1owh0iBMz2ijJCQysJNIfsem0sY1aJr3MrqdDkJLWMPQfnpYjnRnwjrBuxZugtY0nm6rGYvRIGhFSrOgTW1W8fzQnspOtBZKb9URfOBSK004MOv/3Zp8reSXRSCaCqLKybUVNNCnzg6pgkrUcyL3t1YfFFzJVYYeZmFkEEHZVq1hh2Je 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; 20 Jun 2014 20:13:06 -0000 Date: 20 Jun 2014 16:13:06 -0400 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20140620182159.77973.qmail@joyce.lan> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/icWwqcy8QLFXgqwZ_53U8kp80Cs Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-01.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, 20 Jun 2014 20:13:09 -0000 >> This looks an awful lot like my draft-levine-cdkim-00 and >> draft-levine-dkim-conditional-00 except that mine has more bits of >> DKIM in the cdkim signature so it can sign To and From to limit the >> range of spoofage. > > The difference is that this proposal doesn't > change/extend/spin/fold/mutilate DKIM at all. The semantics are outside > entirely. That's draft-levine-cdkim. I changed the name of the header, so it's not a DKIM signature, just a signature that happens to have a lot of aspects that are similar to one. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Fri Jun 20 13:40:05 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF69A1B28ED for ; Fri, 20 Jun 2014 13:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.762 X-Spam-Level: X-Spam-Status: No, score=0.762 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 o2GDv6YICjQi for ; Fri, 20 Jun 2014 13:40:03 -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 D2D4D1B28AD for ; Fri, 20 Jun 2014 13:40:02 -0700 (PDT) Received: (qmail 83877 invoked from network); 20 Jun 2014 20:40:01 -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:cleverness; s=147a4.53a49c21.k1406; bh=NldseC+ZwWhCCdYwNKDCqx4O8QUHGV02xgUAmYIDDz0=; b=mzUU25aQpca7fQUkasN2a62WN12rJqEZvl6qB66W5+vfrR8X6oCb3dMSr+4FBi5FvVAs7h9mPtQPk8hgCJFk9k22VMwnzIongR+Xy55cDGGFRoSzkG+toEhWugotL/r0n8/O/CHMLrYIU7GJMA1ozYc4ko5ehTg2J3cC3zAA5jGPUiM6hQRgQYnyDNUKFeLhAeLOLzZBKCNZDgkus7XUyOqpEkbDzb6DmGfLENh4KuO28boxoZeB0MOAHTog53hf 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:cleverness; s=147a4.53a49c21.k1406; bh=NldseC+ZwWhCCdYwNKDCqx4O8QUHGV02xgUAmYIDDz0=; b=AeVe+UB6J0L2WpMw9eiLeyb97XqAzq+Mem1Koiez/vYP5xXlcMyfyRiEB4AyuaLumy8C/3p3mBFfKBqz1EylkGt3ABRYmv25f6uXMqLjiYeN+Ofz8GpP4rTOIClpYahVZKfDpyz4vHOkbvPp3VIPFWrCCJWe8GWKJDUSxeAcged22SfFqGGznmPsX+Uf1yZ/aN9+6H5/8bF8ICuL2a2pHixhmHw9Oc08pY89HabS8YtBUuDjURPP/egLFg+wlrQQ 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; 20 Jun 2014 20:40:01 -0000 Date: 20 Jun 2014 16:40:00 -0400 Message-ID: From: "John R Levine" To: "Dave Crocker" In-Reply-To: <53A49547.2060307@gmail.com> References: <20140620184337.78017.qmail@joyce.lan> <53A49547.2060307@gmail.com> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ny8unaOLRHH3VEf0TNuRjoVI6ds Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] A detour into signature semantics, was Fwd: New Version 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, 20 Jun 2014 20:40:04 -0000 >> It's also not clear to me that there is any reason for a verifier to >> care about the strength of a signature. If a signer wants to put weak >> signatures on mail and take the risk that his reputation will be >> sullied by heavily mutated messages, that's not the verifier's >> problem. > > Actually, it is, since it is the verifier's system that will let the > mail get delivered, or not, to an associated mailbox. It is /their/ > users who will be most directly affected. > > Or, at least, I have assumed that is why folks are so concerned about > the increased ability to do a replay attack if the signature is 'weak' > (mostly meaning, doesn't cover the body.) Since we have, as far as I can tell, never seen weak signatures, nor am I aware of any actualy attacks that attempt to turn messages into spam while preserving the signature, at this point it's entirely hypothetical. It feels like some people (not you I hope) are assuming that if a message has a valid signature, it's good and you deliver it, which is of course wrong. If the signature is valid *and* the signer has a good reputation, then a delivery agent might do something nice to the message. If it sees a lot of cruddy mail with my signature, I'm going to have a bad reputation, and it doesn't matter whether I'm signing spam, or I'm putting on weak signatures that third parties are turning into spam. Indeed, it's hard to see how a verifier could even tell the difference. R's, John PS: If we're going to tell people what's a sufficiently strong signature, could we start by deciding whether it's sufficient to put one "from" in the h= tag ? From nobody Fri Jun 20 13:46:05 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A80A1A02F8 for ; Fri, 20 Jun 2014 13:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.537 X-Spam-Level: X-Spam-Status: No, score=-0.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_18=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 gWqrpJG4zuSz for ; Fri, 20 Jun 2014 13:46:03 -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 6F0CD1B290E for ; Fri, 20 Jun 2014 13:46:00 -0700 (PDT) Received: (qmail 85029 invoked from network); 20 Jun 2014 20:45:59 -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:cleverness; s=14c24.53a49d87.k1406; bh=o1YnosYxZC/DBt6Sb+KNRThDKGD8ENZM5adaPSsGD8I=; b=VeARD383SVEs2QoaA7w1Ri/4xnxJI1//lnMeT2G4FdscRSGXLKpIQggHAAOJybDSPxR7Uis1OZwiFL6aBIX0rdPn9VCsJyWluDm/EoVCJME1/+ZHKy1vTkkNldFOH7U9Avvw+MrzhyMguwQAvTPWOP1iXPHwSyAsemraAxg6DMAOkRlc7OU2iRkogIWG4dilvpSX4AdwIcmmZAs9yoDmKyGu/J7o1OwZz0yxG/Zm9TAsV5qA4UGOquQvEhLd0517 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:cleverness; s=14c24.53a49d87.k1406; bh=o1YnosYxZC/DBt6Sb+KNRThDKGD8ENZM5adaPSsGD8I=; b=hzpVoWnwmqAsAsj3pJ0YJmU69QUtk8w6DI8+TUqZCJBav+2X4Jo1g/wvTYgoH+5ZGcjwP0ajlmobgU+MUOVXzAUEAnJrFQmTK2Xiwfq2mVSBTaPNS2s9En3U5uXhVid5YzLCnC76MOCzM51UBNFYzfOrqQbm0RGQTrx9nQ1enw8/RioBVc5piGRHL1LdePieCLr74cMeWPaEvFnkb7ectIASpDRa8yz7M4MhbDGlntloBr2dQKt8CjTz6qxkcTY0 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; 20 Jun 2014 20:45:59 -0000 Date: 20 Jun 2014 16:45:58 -0400 Message-ID: From: "John R Levine" To: "Dave Crocker" In-Reply-To: <53A49547.2060307@gmail.com> References: <20140620184337.78017.qmail@joyce.lan> <53A49547.2060307@gmail.com> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/9ir1Cqsl7fJhN2z3mwZgVD7twsI Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] what's a layer, was Fwd: New Version Notification 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, 20 Jun 2014 20:46:04 -0000 >>> Adding a requirement that one validation needs to be accompanied by a >>> particular other valid signature is just such an additional factor. >> >> I don't see it that way. > > Try harder. Still not having much success here, so please help me out. It is presumably permitted to check an external clock to find out what time it is to validate the x= or t= tags. How come that's OK, but checking the message for the presence of a signature with d=whatever isn't? R's, John From nobody Fri Jun 20 13:47:21 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B82B1B2905 for ; Fri, 20 Jun 2014 13:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_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 b5tnCmLL9JYo for ; Fri, 20 Jun 2014 13:47:18 -0700 (PDT) Received: from mail1.altn.com (mail1.altn.com [65.99.242.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 728351A02F8 for ; Fri, 20 Jun 2014 13:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/relaxed; d=altn.com; s=mail1; t=1403297237; x=1403902037; q=dns/txt; h=DomainKey-Signature: Received:VBR-Info:Message-ID:Date:From:Organization:User-Agent: MIME-Version:To:Subject:References:In-Reply-To:Content-Type: Content-Transfer-Encoding; bh=hx+OGXSWW7t6X/cMHQC1151V3qLHBsUhPM COnQSNTfM=; b=Lo78ejS57lcHSVdqrWw30//dsRGjWvV9GMuN/lK3l3+9Pl+o5R tilMR86eIpz9pOkpyvJYTwEFwAO3IyAdITF80uhPH2GZ9p4rN18LnY4cZZBcIGzn oeFxI+q5xPMXdCs/OYxPjPCa/yIt0q/b66o9zORRNyjwHHaFH9OC5sMfo= DomainKey-Signature: a=rsa-sha1; s=mail1; d=altn.com; c=nofws; q=dns; h=message-id:from; b=i9W/hYZHqsAGszwfFB3Wcfh1VMrODyKYATuVvhcARqiVOl0JSh1TqoCEo1l8 CEB3JNz/pjQcJ7AKR+i/xh5ZVZqT7o3ZjOq9Ma9PNMk/FNMHxH5Vp+v3x FlbHM/+XyDdN0hqcFiicY4PrtZR+jlRij0eZ6qQrCyJGcKkTNKslyk=; X-MDAV-Processed: mail1.altn.com, Fri, 20 Jun 2014 15:47:17 -0500 Received: from [10.20.90.146] by altn.com (Cipher TLSv1:AES-SHA:128) (MDaemon PRO v14.0.3a) with ESMTP id md50000073953.msg for ; Fri, 20 Jun 2014 15:47:17 -0500 VBR-Info: md=altn.com; mc=all; mv=dwl.spamhaus.org:vbr.emailcertification.org; X-Spam-Processed: mail1.altn.com, Fri, 20 Jun 2014 15:47:17 -0500 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: Arvel.Hathcock@altn.com X-HashCash: 1:21:140620:md50000073953::Sf44lZdXF3wEgXUm:00002Ewg X-Return-Path: prvs=1248b68808=arvel.hathcock@altn.com X-Envelope-From: arvel.hathcock@altn.com X-MDaemon-Deliver-To: dmarc@ietf.org X-CAV-Result: clean Message-ID: <53A49DEB.6090409@altn.com> Date: Fri, 20 Jun 2014 15:47:39 -0500 From: Arvel Hathcock Organization: Alt-N Technologies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <20140620184337.78017.qmail@joyce.lan> In-Reply-To: <20140620184337.78017.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/RSu4P_m-g7yjqLH5YdQRbcXK3rI Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 20 Jun 2014 20:47:20 -0000 > I don't know anyone who's checked whether DKIM validators verify the > version number, but if it's an issue, there aren't that many widely > used DKIM engines so it wouldn't be hard to check. Just FYI, libdkim which all our products use does check the v= and if it's not "v=1" verification "fails" with an "invalid v=" error which we then document in the authentication-results header. Arvel From nobody Fri Jun 20 13:52:31 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE831B2905 for ; Fri, 20 Jun 2014 13:52:28 -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 y7FdwLZP15aI for ; Fri, 20 Jun 2014 13:52:26 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07F161B28ED for ; Fri, 20 Jun 2014 13:52:25 -0700 (PDT) Received: by mail-yk0-f182.google.com with SMTP id 19so3077938ykq.41 for ; Fri, 20 Jun 2014 13:52:25 -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=uu7VckKNGPjqg35sujM0FLwDX846lnP0laU7kDhpCrw=; b=DjX3HpHg0NygKZ0JzrHBG008UJXnxs1UJRC4Z2yVH6AB6Gaxjpmy2P7jy/IB+VCAJM QSMzjFNsdMZwaQ50DZ1qqMh2FlKkauUi89CAmw5ZkBm19zL4KWj99s5REzKsyiGnGXpr 2lwbmUvOwp5sKU8nPYSjXJf9WWxgR24WKMO2+bupYC2IaWXlma0IqRqlzdCSYixc9Dxl C4YCJxUVjTsjVdA8VcgO2r1Am4dT+h6YoSGLGQoS3kyA2llRgUKUFHqlDL/SLTHC7tqk 3A3xBqz4yXWsuqp07okUWqjtNvLSEn+ZwweNyAdavmdKWM1sIMoO+FjbEt9+ZRT8tnFT lr/A== X-Received: by 10.236.199.45 with SMTP id w33mr8431749yhn.122.1403297545371; Fri, 20 Jun 2014 13:52:25 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id f20sm16237726yhp.36.2014.06.20.13.52.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Jun 2014 13:52:24 -0700 (PDT) Message-ID: <53A49EC2.4010308@gmail.com> Date: Fri, 20 Jun 2014 13:51:14 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John R Levine References: <20140620184337.78017.qmail@joyce.lan> <53A49547.2060307@gmail.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Wn-ZQE56k-60LAwWC3a8WzNvznI Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] A detour into signature semantics, was Fwd: New Version 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, 20 Jun 2014 20:52:28 -0000 On 6/20/2014 1:40 PM, John R Levine wrote: > It feels like some people (not you I hope) are assuming that if a > message has a valid signature, it's good and you deliver it, which is of > course wrong. Since I haven't seen anyone suggest this, during this or frankly any other, discussion, nor have I seen any text that even hinted at that attitude, I've no idea what you are referring to. > If the signature is valid *and* the signer has a good > reputation, then a delivery agent might do something nice to the > message. If it sees a lot of cruddy mail with my signature, The issue is not your 'signature' but your d= domain name. That's where the reputation assessment is supposed to lie. It's one of the problems with language that loosely refers to what DKIM does as 'signing' the message. It's not really doing that. Since your Subject text nicely invokes the question of real DKIM semantics, let's be explicit: DKIM is "affixing" the d= name to the message. The 'signature' is the glue. If we think and talk in those terms, then the question of how strong the glue needs to be needs to be made in the context of real or likely efforts at pulling the name off of a legitimate message and affixing it to an illegitimate one. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jun 20 13:54:23 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D99A1B290C for ; Fri, 20 Jun 2014 13:54:21 -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_18=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 CuwzTrGy0Fnt for ; Fri, 20 Jun 2014 13:54:20 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4251E1B28ED for ; Fri, 20 Jun 2014 13:54:20 -0700 (PDT) Received: by mail-yk0-f178.google.com with SMTP id q9so3106280ykb.9 for ; Fri, 20 Jun 2014 13:54:19 -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=RKbs04x348G+2AvPsxI2ngUqt503Rpx8Tu9cVlrUF2o=; b=rZxhGIliH94LEvzJNMJx6LOpWc3+WQOK+wuLgUSF1LiUhPlsXWL6lqLSGXbyvLABVV Ek8TG7i55sL2grwVa34MVxDi9Uqo3/KC4VcJPwC0zaLYFrDxepyV804Lkl/bKKSi5QFv eMAvxY4+VDFOvISjaEygYbrchMhVze4Dk1owAsr4AqLGfiQmL7s8c5fhpecKno7+TSTT YTvyzG9Y0BmF9iblepNft23EOTNQI5XvU/1cbZ2817h9Fubthy+72y/RKe1MjYR1TZX2 h9z20NLL0BeTle/NAnr+VnRdOquIA5RHCycS81ZQdqkN5GVHPsiJ4oLreL8QuUfs/AU2 58bA== X-Received: by 10.236.35.198 with SMTP id u46mr8994740yha.54.1403297659628; Fri, 20 Jun 2014 13:54:19 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id f2sm16232852yhc.41.2014.06.20.13.54.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Jun 2014 13:54:18 -0700 (PDT) Message-ID: <53A49F34.3040607@gmail.com> Date: Fri, 20 Jun 2014 13:53:08 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John R Levine References: <20140620184337.78017.qmail@joyce.lan> <53A49547.2060307@gmail.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/GD4w91RzqMAuwtMhUwf9RBZiGTI Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] what's a layer, was Fwd: New Version Notification 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, 20 Jun 2014 20:54:21 -0000 On 6/20/2014 1:45 PM, John R Levine wrote: >>>> Adding a requirement that one validation needs to be accompanied by a >>>> particular other valid signature is just such an additional factor. >>> >>> I don't see it that way. >> >> Try harder. > > Still not having much success here, so please help me out. > > It is presumably permitted to check an external clock to find out what > time it is to validate the x= or t= tags. How come that's OK, but > checking the message for the presence of a signature with d=whatever isn't? That has not appeared (to me) to be the nature of what you have been espousing. Rather you appear to be espousing the benefits of mixing policy with mechanism, by placing requirements for combinatorials (one sig in the presence of another) into the middle of a signing/validating spec. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jun 20 14:04:21 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108351B28F3 for ; Fri, 20 Jun 2014 13:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.754 X-Spam-Level: X-Spam-Status: No, score=-0.754 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, 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 tNd_lws34-V9 for ; Fri, 20 Jun 2014 13:39:46 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBEF1B28AD for ; Fri, 20 Jun 2014 13:39:46 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P98L6YP9CG004UYI@mauve.mrochek.com> for dmarc@ietf.org; Fri, 20 Jun 2014 13:34:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1403296493; bh=2gSmVathyjCzUAeQ8EO6bjSGXQzKd7EX7kUnaR44VoQ=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=q7Z2aQpJCr8G+UBfP2wiUkuoXmW8FtTJ6JwO0BNQFbQeQij2EJHcO0Kkza7Vbq5Vi ZUNnkzE0DothXh42LZJRhMvcye6SysZfc+5+sGnyW8R6BJhcO55axBwzxBITSjN4rC jn1WUI+3aWZkw8cXlWcRjHclSPVe9uPho52En3G0= 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 <01P8UD4AOU8W0049PU@mauve.mrochek.com>; Fri, 20 Jun 2014 13:34:33 -0700 (PDT) Message-id: <01P98L6XH1DE0049PU@mauve.mrochek.com> Date: Fri, 20 Jun 2014 13:15:30 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 20 Jun 2014 19:13:18 +0000" <20140620191318.78155.qmail@joyce.lan> References: <20140620191318.78155.qmail@joyce.lan> To: John Levine Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/dNOcI2cliNdeL4c0KknrBCglsBo X-Mailman-Approved-At: Fri, 20 Jun 2014 14:04:19 -0700 Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] The theory of DKIM versions 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, 20 Jun 2014 20:39:48 -0000 > >The problem may be that we don't agree about what DKIM versions mean. > >Here's what I would like them to mean: ... > >c) Whenever we add new tags that require that the verifier understand them > >to get the right answer, we increment the version number. > Ned pointed out that we could add an indicator on a tag that means > that interpreting the tag is mandatory, so if the verifier doesn't > understand the tag, the verification fails. This would decrease the > need for future version bumps. > So for example: > DKIM-Signature: v=2; a=rsa-sha1; c=relaxed/relaxed; s=s1024; d=sender.example; > h=From:To:Date; l=0; !cs=fs; fs=t; > bh=... > b= > The ! in !cs= means that the verifier MUST handle the cs= tag or fail the message. First, credit where credit is due: This is basically the criticality indicator found in X.400, X.500, and various other protocols. The idea dates back to at least the mid-1980s, if not earlier. Second, I didn't originally mention this because I intended to propose adding it, but having thought about it, I find myself liking the idea, especially since it gives you a more general capability-based mechanism for future extensions. In fact I could see this effectively obsoleting the version field in DKIM. Since there's substantial operational experience with this sort of mechanism - not all of it good - it's important to access it in light of that previous experience. The obvious issue is that it makes it possible to create myriad incompatible but nevertheless legitimate variants of DKIM. Since an important aspect of DKIM is use by bilateral agreement, and since nothing prevents you from attaching multiple DKIM-Signature header fields, even if this happens I don't see it as a problem. A second, more subtle, issue, and one that definitely happened in the X.400 space, is that the way this stuff ended up getting deployed created incentives for implementations to simply ignore the criticality bit. This happened because in an effort to create vendor lock-in several implementations decided to decorate all their messages with critical extensions containing who knows what. None of this stuff seemed to matter; messsages could be read and processed in spite of it. So the result was a lot of processors simply ignored the criticality, or at least could be set to do so. I don't see this as likely to happen with DKIM for several reasons. For one thing, the failure to interpret a paritcular DKIM-Signature field isn't supposed to render the message unprocessable - in fact it's required that it not have that effect. And there's so much flexibility along so many other axes - multiple DKIM-Signature fields, fields with different names, etc., that I don't see a serious concern here. From nobody Fri Jun 20 14:04:42 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921F41A03E1 for ; Fri, 20 Jun 2014 09:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 vWqOHFSEldph for ; Fri, 20 Jun 2014 09:51:08 -0700 (PDT) Received: from nm8-vm8.bullet.mail.gq1.yahoo.com (nm8-vm8.bullet.mail.gq1.yahoo.com [98.136.218.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BBDB1A03DF for ; Fri, 20 Jun 2014 09:51:08 -0700 (PDT) Received: from [98.137.12.60] by nm8.bullet.mail.gq1.yahoo.com with NNFMP; 20 Jun 2014 16:51:07 -0000 Received: from [98.137.12.224] by tm5.bullet.mail.gq1.yahoo.com with NNFMP; 20 Jun 2014 16:51:07 -0000 Received: from [127.0.0.1] by omp1032.mail.gq1.yahoo.com with NNFMP; 20 Jun 2014 16:51:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 771645.21250.bm@omp1032.mail.gq1.yahoo.com Received: (qmail 94403 invoked by uid 60001); 20 Jun 2014 16:51:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1403283067; bh=Lb83PIS5YI2Mo41YbxlUx6hnSleEVqfsGOk6vUzlLKw=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=vGUDqwFsLWqp+RaZUChLakUE0YTWVK29bhAZZRjSKOj0dnv/+R2A9IYhlsWVR94+b2p+O4JDWsi7kUxLAeUnXlQLZFx17L8mAEOd9DUmzm4/qGDAUTZ3NSlq8vG9Lxo6cClhWxInoK/2boYbPN6W6NPWV5T50/rW5b3rHh3jz00= X-YMail-OSG: LNNzXFIVM1l2vTWYhEmW9mBZpFPHQIdbp2ndnQY3UdkZ91v Lt4I3YS5L8Uz0tyMQH6NAA1PlSjyerFbrxGE.V_T9NAlplHPmpjms5j6Ig_Q W5v4mbJO2DyH3tnYCQVZhuk_ckG7GMIcFdait4ePsghEth0cDn9GwjcdW2r5 YyIGpPTQkwZenWdxOfPrkzAegXNNYveTcPk8asPkHuBrTaTN.1JO.Jd8SF0m ec7tfmwlOOkWYGcCIOhMckHf5H0pB_aVfwHwTYVsR1kyQQiyRDtwn48uh6hX oMOF8FJB.A6vlXhHt6z4Is7jUyoAjl5.bw7Wn7I4eABnJygyWUk4fjayHvnw evcmF.LPFk1fwBNeSRaFsrNPJQrc0h_ZZJEao4HdLXM121PGCruNL_Zrr7.e J8800IBtrUNC6wRx3ttXAYD.niym9AeAqmdnd2IbW7rMw2JAJzpHlWlIl.R8 ST3J02vdRfAailVcXst8485KpTungeq7Ksi7I_3cIwhIOBtuoP291AMLS_.N 16epwLco6_zy9a_LhWKAeuEj3QCROrHCM4BuGwepH3O0vcr5YTiovThtCmse 8A.Y2laE8x_KAZ0t3kCebdnfNidraHe_70XqSOTU- Received: from [109.121.39.102] by web164606.mail.gq1.yahoo.com via HTTP; Fri, 20 Jun 2014 09:51:07 PDT X-Rocket-MIMEInfo: 002.001, T24gRnJpZGF5LCBKdW5lIDIwLCAyMDE0IDM6MzIgUE0sIE11cnJheSBTLiBLdWNoZXJhd3kgPHN1cGVydXNlckBnbWFpbC5jb20.IHdyb3RlOgoKPiBubyBETlMtYmFzZWQgdGhpcmQgcGFydHkgd2hpdGVsaXN0aW5nIHNjaGVtZSBoYXMgZXZlciBnb3R0ZW4gYW55IHRyYWN0aW9uLgo.IEkgdGhpbmsgdGhpcyB3aG9sZSB0b3BpYyBoYXMgdHVybmVkIGludG8gc29tZXRoaW5nIHdlIHRoaW5rIHRob3NlIHBlb3BsZQo.IHdhbnQgb3IgbmVlZCwgYnV0IHRoZXkgZG9uJ3QuCgppIGJlZyB0byBkaXNhZ3JlZS4gRE0BMAEBAQE- X-RocketYMMF: gwzrd X-Mailer: YahooMailWebService/0.8.191.1 References: <1403245132.31456.YahooMailNeo@web164606.mail.gq1.yahoo.com> <8738f00xur.fsf@uwakimon.sk.tsukuba.ac.jp> Message-ID: <1403283067.23208.YahooMailNeo@web164606.mail.gq1.yahoo.com> Date: Fri, 20 Jun 2014 09:51:07 -0700 From: Vlatko Salaj To: "Murray S. Kucherawy" , "Stephen J. Turnbull" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/5j5HWbsjFfgxFr2_VJlvqV0VbgE X-Mailman-Approved-At: Fri, 20 Jun 2014 14:04:37 -0700 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] signature sample X-BeenThere: dmarc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Vlatko Salaj 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, 20 Jun 2014 16:51:09 -0000 On Friday, June 20, 2014 3:32 PM, Murray S. Kucherawy wrote: > no DNS-based third party whitelisting scheme has ever gotten any traction. > I think this whole topic has turned into something we think those people > want or need, but they don't. i beg to disagree. DMARC is barely known to the world at large, and even less deployed by world at large. even my ISP doesn't know or care about it yet, yet alone all those poor, small, around-every-corner cPanel-based domains that populate internet and make it worthwhile our time. so, any conclusion whether DMARC needs 3rd party alignment support isn't something anyone can base on some concrete data, but merely pure common sense and logic. and i do not subscribe to common sense and logic saying we don't need it. this mailing list wouldn't have three proposals already, and these requests wouldn't go repeating every once in a while if there was zero need for it. and, to be blunt - cause that's just my style - both DKIM-D and CDKIM r, in a way, 3rd party alignment support proposals, even if of a different kind and much lesser support-degree. btw, the same goes for any "DNS ppl" argument. i am a "DNS ppl" for 15 small companies, and i am strongly for DNS TXT 3rd party DMARC alignment policy support. the same goes with the rest of the tl;dr arguments, cause i barely consider something true if its basic truth can't be put in a sentence or two, instead of a novel. -- Vlatko Salaj aka goodone http://goodone.tk From nobody Fri Jun 20 14:05:20 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353E31B28F3 for ; Fri, 20 Jun 2014 14:05:18 -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 YdqM5pZ-Xle0 for ; Fri, 20 Jun 2014 14:05:14 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2DA01A02C5 for ; Fri, 20 Jun 2014 14:05:13 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b13so4165567wgh.11 for ; Fri, 20 Jun 2014 14:05: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=By/ZKj94xNvrnPAgWsx8WrcvcVsmqxzlLbMnWgWEyXY=; b=dGKR4KrrO1W9puEQSvi6uoKQvLGPORFiEUtJkHiJOqSbsmMEqYDBKFVjvEsFbAT5aT d1+HnOtl33lggTO6SIsrfngZu7gUVSHRJsuhWv+pp2Tkpv3G70LH3hxCe5zeDRkOvi1F wK7xrgm1znY+TDRiRCrnN50EzrjAr4UeagtyKKDYLONjoVu1ggjoZ3h+Nvj84Dt04XBU btD6FGk2RN6fDJSjPNw1UlUcNCjZ3JU/JAOe2t+18HzcEBP/dRs6TGqFOJbzJZpP6wYn BvmSiMsiw6mrXxeG1hotdlHNKNBdvGmNHFkFlIYTI0P24gv3LbMDSDBXbJJYoLrWxUFt gByg== MIME-Version: 1.0 X-Received: by 10.180.83.105 with SMTP id p9mr6872999wiy.8.1403298312529; Fri, 20 Jun 2014 14:05:12 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Fri, 20 Jun 2014 14:05:12 -0700 (PDT) In-Reply-To: <53A49DEB.6090409@altn.com> References: <20140620184337.78017.qmail@joyce.lan> <53A49DEB.6090409@altn.com> Date: Fri, 20 Jun 2014 14:05:12 -0700 Message-ID: From: "Murray S. Kucherawy" To: Arvel Hathcock Content-Type: multipart/alternative; boundary=f46d044282de6eb52a04fc4ad92f Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/I8efvxNiLZppSCoYtZNvKsMok5w Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 20 Jun 2014 21:05:18 -0000 --f46d044282de6eb52a04fc4ad92f Content-Type: text/plain; charset=UTF-8 On Fri, Jun 20, 2014 at 1:47 PM, Arvel Hathcock wrote: > I don't know anyone who's checked whether DKIM validators verify the >> version number, but if it's an issue, there aren't that many widely >> used DKIM engines so it wouldn't be hard to check. >> > > Just FYI, libdkim which all our products use does check the v= and if it's > not "v=1" verification "fails" with an "invalid v=" error which we then > document in the authentication-results header. OpenDKIM as well. -MSK --f46d044282de6eb52a04fc4ad92f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 20, 2014 at 1:47 PM, Arvel Hathcock <a= rvel.hathcock@altn.com> wrote:
=
I don't know anyone who's checked whether DKIM validators verify th= e
version number, but if it's an issue, there aren't that many widely=
used DKIM engines so it wouldn't be hard to check.

Just FYI, libdkim which all our products use does check the v=3D and if it&= #39;s not "v=3D1" verification "fails" with an "in= valid v=3D" error which we then document in the authentication-results= header.

OpenDKIM as well.

-MSK
--f46d044282de6eb52a04fc4ad92f-- From nobody Fri Jun 20 14:07:09 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33DCD1B290F for ; Fri, 20 Jun 2014 14:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.762 X-Spam-Level: X-Spam-Status: No, score=0.762 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 g9vYNv6Ah5dZ for ; Fri, 20 Jun 2014 14:07:03 -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 8CBE51A02C5 for ; Fri, 20 Jun 2014 14:07:03 -0700 (PDT) Received: (qmail 89051 invoked from network); 20 Jun 2014 21:07:02 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 20 Jun 2014 21:07:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=132c3.53a4a276.k1406; i=johnl@user.iecc.com; bh=n0m3PKBceGmyZT7FG3xBqygCjuRdmR3btuJExQnfzlI=; b=efWmPrOhPRpJLaFVNAg1aI6ICDVXblCaYldJVTZyLDYIBUC323QgHuXi5ks19cyIwsSjUApkHG5tBx6Jq5wToSy/LBv8ZMBfobVgXRc4wW8gX0MlgaGA6IwWYFNuiXuv1Vbo35K/aVxJjwqLol33tLW8iUXtP1XwaaJAfUE7buEMpt47sTkEznPFcT+wpldkM0+FofOBWR6njmaHWEf7E51D0UyemswbrKRXXn5xrOohcRg6yq9hu8wNTf74c3Q7 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=132c3.53a4a276.k1406; olt=johnl@user.iecc.com; bh=n0m3PKBceGmyZT7FG3xBqygCjuRdmR3btuJExQnfzlI=; b=ht4/XLFKvd2wHPGMedDEgzRhQUYR8YploxHDocvErlo1N6G6KJ4FYwzSwmfx2UCRlZmw2/WfOxRoSTRoesBWS0WXRTMvf3GWUY7fZgocxHoDj66mjW4nhk/OrrLrDA7LOQEaTWpbcq+hB+ZENuZvhlU44Ds3S3Bm1r3vYqMvf3jaROcC67sba4Dc0GcX6Hmd9rfjPOn/leQhrTjGW57qZra6J+osfjPmrzuQLhJnWY2e1B3V4E/6eeUffSyOpPc7 Date: 20 Jun 2014 21:06:40 -0000 Message-ID: <20140620210640.78530.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <53A49EC2.4010308@gmail.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/6fJ6LZVykIT4SqbDNV_B0U9sJS0 Cc: dcrocker@gmail.com Subject: Re: [dmarc-ietf] A detour into signature semantics, was Fwd: New Version 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, 20 Jun 2014 21:07:05 -0000 >> If the signature is valid *and* the signer has a good >> reputation, then a delivery agent might do something nice to the >> message. If it sees a lot of cruddy mail with my signature, > >The issue is not your 'signature' but your d= domain name. That's where >the reputation assessment is supposed to lie. If anyone else found this obvious point confusing, I apologize. >If we think and talk in those terms, then the question of how strong the >glue needs to be needs to be made in the context of real or likely >efforts at pulling the name off of a legitimate message and affixing it >to an illegitimate one. Why would that be the verifier's concern rather than the signer's? If for some (perhaps good, perhaps bad) reason I decide to use weak signatures, why wouldn't the hit to my reputation be an adequate remedy? R's, John From nobody Fri Jun 20 14:10:31 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079DB1A019A for ; Fri, 20 Jun 2014 14:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.362 X-Spam-Level: * X-Spam-Status: No, score=1.362 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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_18=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 T4CZ6IgM3wu4 for ; Fri, 20 Jun 2014 14:10:26 -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 CF40E1A02D2 for ; Fri, 20 Jun 2014 14:10:25 -0700 (PDT) Received: (qmail 89729 invoked from network); 20 Jun 2014 21:10:24 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 20 Jun 2014 21:10:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=132db.53a4a340.k1406; i=johnl@user.iecc.com; bh=Scp9RAeori8r2rkwU8UJ/RUMRRRRL09W1jzivgPSZNg=; b=iRRTST4npciWR7IJr9BkHJrHqH/RJrLYNpPD48LriMV812Yhnh6b3p82Bgj90FrIdSC4igk5HOpPeNgwe0XvpfeqiHFoHISjwEdsvUDXgCOmeBXWCHmtCF1x8BGW8QAqM+Cb/Np8SX1rhyqr4rw1WY7ZCofTJPJfAAO5Vl3b9HCDSEFmAzDVWmtsSRJ31iFvrcLTtfXnyGROPC4DpnMIi9dRgEfttWG++pchfJj4MZzEDdHylS/vz2sxB6S//8B7 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=132db.53a4a340.k1406; olt=johnl@user.iecc.com; bh=Scp9RAeori8r2rkwU8UJ/RUMRRRRL09W1jzivgPSZNg=; b=a+xVUD4Hxw2Hm+JdEkFvVzTOgBXBHqWJU3fEG3vtBOynR0eASzJ7K/beUO/ke0ySadY5td3q6/LzNujfezzBZbzJ9mm3rsTmvsYQC7vIXjRqppgcjRMQRmxWUpsyH8H8FRxQMuXtw8FJ6R3zqQvzCuvMWMvC48JxZPQEQ6l6au4qc5eA1iUm9pId6YsMrg4PSpXv7e81jC/MJRX+OYGIlU0MdEwKVKHTYRElEz0Exn7zmufY/p9t7TdS2z6aMOPP Date: 20 Jun 2014 21:10:02 -0000 Message-ID: <20140620211002.78554.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <53A49F34.3040607@gmail.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/C-lYrs085w4hZlSn_aTDVDDTu8Y Cc: dcrocker@gmail.com Subject: Re: [dmarc-ietf] what's a layer, was Fwd: New Version Notification 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, 20 Jun 2014 21:10:28 -0000 >> It is presumably permitted to check an external clock to find out what >> time it is to validate the x= or t= tags. How come that's OK, but >> checking the message for the presence of a signature with d=whatever isn't? > >That has not appeared (to me) to be the nature of what you have been >espousing. Hmmn. That is exactly what I describe in draft-levine-dkim-conditional-00. If it seems to be saying something else, could you give me some suggestions about where I need to make it clearer? R's, John From nobody Fri Jun 20 14:40:11 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7911A02CA for ; Fri, 20 Jun 2014 14:40:06 -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 EbeWsl_MLTHm for ; Fri, 20 Jun 2014 14:40: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 AA3CA1A0283 for ; Fri, 20 Jun 2014 14:40:05 -0700 (PDT) Received: (qmail 95879 invoked from network); 20 Jun 2014 21:40:03 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 20 Jun 2014 21:40:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=13383.53a4aa33.k1406; i=johnl@user.iecc.com; bh=9dM2p3qawKVuXmGnrHqLwPwl9AQ9qyUlX+F9xqplycc=; b=Ysxzxw9qzHrrFR3qCTmaMCL/pzdVIJIm7rUins6Fr4TI6TyH7sBkOZUW3B5JfmuN78zNtFlL73uzeudh7t0i5bgEQFmLtuaiHNHRXPo5t+WgdEF+x0xFcGG5jTKMUsf96k/NBmkK3i+rCvqJxZJnEvFgriKjryzdDJeVRY04phjq6uOGwB3YxbaHSXxOirbeQx0zqIcu+1Q3GfRHIg5ckKEv/ESGLqVwQMkckBy4lUsdxcPGxWodWm7p8MBWhtvM DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=13383.53a4aa33.k1406; olt=johnl@user.iecc.com; bh=9dM2p3qawKVuXmGnrHqLwPwl9AQ9qyUlX+F9xqplycc=; b=vWRPYtDrNuakIyQu30NvKp/GUcDflQWWJsg8TYa6Z3QYbv8RUTQZ5N0BlBR/7jr4m9KyjklYdoOJYqZJ3WF5wbVG92u+8dzL4FRnWBh8TIkRXs3KE0YgUxTNA//pxPW4uO4q1bqR4TGulPRDViGr04Igk/FCbZ/Qm07IdfjeYE+/uVzfezPwJ8WUsx++K2ZM9F8zrSDuMOFLf/Mhf3HaP4x6CYDIJaUWw8omJ62QalExyMjdEeL7cFIjw3YQ7PqD Date: 20 Jun 2014 21:39:41 -0000 Message-ID: <20140620213941.78722.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <53A49DEB.6090409@altn.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/4Rv3cj_C5ADubr4tR9aneZGzIJM Cc: arvel.hathcock@altn.com Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 20 Jun 2014 21:40:06 -0000 >> I don't know anyone who's checked whether DKIM validators verify the >> version number, but if it's an issue, there aren't that many widely >> used DKIM engines so it wouldn't be hard to check. > >Just FYI, libdkim which all our products use does check the v= and if >it's not "v=1" verification "fails" with an "invalid v=" error which we >then document in the authentication-results header. I looked at the code in Mail::DKIM which is what spamassassin and probably every other perl DKIM application uses. It checks the version number, and for some reason accepts "0.5" as well as "1", but nothing else. The most widely used python module is Scott's dkimpy, which checks that the version is "1". R's, John From nobody Fri Jun 20 15:19:51 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B731A031C for ; Fri, 20 Jun 2014 15:19:49 -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 qJo0WKazkoC8 for ; Fri, 20 Jun 2014 15:19:47 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 972451A00E8 for ; Fri, 20 Jun 2014 15:19:47 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id n12so4201357wgh.31 for ; Fri, 20 Jun 2014 15:19:46 -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=QEjjFojJ7t1YHBb32wMthnQcgrHWL8IYpAa0bdN49X4=; b=UXAVqBgeRcLl5aOcOHrONsCq1XrWBFfzkLJNrzIidqc4L6yeWoX9Tz9xwatfAC6/b4 jAvJkJOa92kiFdBqgKrFvrdYSvZVC1UEWqnFzl8IC8e3Yae+SiG9pCxyVVqM+BUzHFN3 r+wc2UJCGJ/g/4MzvqwTWIrFmnWoymbaRP/JxXkFfW2jgK1P2YVaYXg/9Cg50lEdRDHU Sb6quXo5x+H6FIsriyJDlxfGnsZHf3IY0CX056Bks8e8DxutgFep+moO+DRWEwTDHks3 wva91gBsqoWQFxDaM0QzmKJIBndh+dNIfv2hRx0AUwNtOXgfQWDq56PcnU7hjkSy1P8s 4WbA== MIME-Version: 1.0 X-Received: by 10.194.7.36 with SMTP id g4mr7692820wja.37.1403302785948; Fri, 20 Jun 2014 15:19:45 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Fri, 20 Jun 2014 15:19:45 -0700 (PDT) In-Reply-To: <20140620213941.78722.qmail@joyce.lan> References: <53A49DEB.6090409@altn.com> <20140620213941.78722.qmail@joyce.lan> Date: Fri, 20 Jun 2014 15:19:45 -0700 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=047d7b450a7c11a5ba04fc4be464 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/R4ziUVToIjIiVDWhueHKsjAOQh4 Cc: Arvel Hathcock , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 20 Jun 2014 22:19:49 -0000 --047d7b450a7c11a5ba04fc4be464 Content-Type: text/plain; charset=UTF-8 On Fri, Jun 20, 2014 at 2:39 PM, John Levine wrote: > I looked at the code in Mail::DKIM which is what spamassassin and > probably every other perl DKIM application uses. It checks the > version number, and for some reason accepts "0.5" as well as "1", but > nothing else. > "0.5" was used during early DKIM evolution within the IETF, such as: http://tools.ietf.org/id/draft-ietf-dkim-base-05.txt -MSK --047d7b450a7c11a5ba04fc4be464 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jun 20, 2014 at 2:39 PM, John Levine <johnl@taugh.c= om> wrote:
I looked at the code in Mail::DKIM which is what spamassassin and
probably every other perl DKIM application uses. =C2=A0It checks the
version number, and for some reason accepts "0.5" as well as &quo= t;1", but
nothing else.

"0.5" was used = during early DKIM evolution within the IETF, such as:

http://tools.ietf.org/id= /draft-ietf-dkim-base-05.txt

-MSK
--047d7b450a7c11a5ba04fc4be464-- From nobody Fri Jun 20 20:51:40 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBED1A0151 for ; Fri, 20 Jun 2014 20:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 46drXjrjwdJL for ; Fri, 20 Jun 2014 20:51:37 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 5E70A1A00EA for ; Fri, 20 Jun 2014 20:51:36 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 379F13FA0B18; Sat, 21 Jun 2014 12:51:36 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id E9F311A3D3E; Sat, 21 Jun 2014 12:51:35 +0900 (JST) From: "Stephen J. Turnbull" To: "John R Levine" In-Reply-To: References: <87d2e419bi.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 21 Jun 2014 12:51:35 +0900 Message-ID: <871tui2a48.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/4GjbIvXtXcRPqqIEzeVM65A7IWg Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] The theory of DKIM versions 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, 21 Jun 2014 03:51:39 -0000 John R Levine writes: > > > d) Versions are cumulative. Every signature that is a valid version N > > > signature is still a valid version N+1 signature, give or take the change > > > in the b= hash due to the version bump. > > > > I think this is unnecessarily restrictive. It's unnecessary because a > > verifier that wants to handle multiple versions can always incorporate > > a routine per version. It's restrictive because a later version might > > want to disavow an earlier version. > > If you want to change the semantics that much, like I said, give it a > different name. Like I said, it's unnecessary. Why do you think it's better to proliferate field names? AIUI, what you're proposing here is a major change from the way the RFCs I've seen are constructed. They say, the protocol must be interpreted exactly as in this document and for any different version all bets are off, but of course an agent may choose to support multiple versions. It's a matter of designer judgment whether the incompatibilites are sufficient to warrant a new name. This has worked well enough for the Internet so far AFAICT. Why do you think DMARC is an appropriate place to experiment with a different interpretation of version numbering? I note your file system example, but it seems to me that is fundamentally different in that not only the protocols but the reference (and typically dominant) implementation are controlled by the same entity, and furthermore, layering is much more accurately enforced in OSes than on the Internet. I noted Ned Freed's comment about "MIME-Version: 1.0" being a mistake, but security protocols are a different use case, and I think it's best to control extensions very carefully. From nobody Fri Jun 20 21:08:58 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD9C1A01BB for ; Fri, 20 Jun 2014 21:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 JtqrTibu0JOd for ; Fri, 20 Jun 2014 21:08:55 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 30C861A00EA for ; Fri, 20 Jun 2014 21:08:54 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 623573FA015E; Sat, 21 Jun 2014 13:08:54 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 548881A3D3E; Sat, 21 Jun 2014 13:08:54 +0900 (JST) From: "Stephen J. Turnbull" To: Dave Crocker In-Reply-To: <53A474B8.2060809@gmail.com> References: <20140611222207.2338.qmail@joyce.lan> <53993D20.7010901@gmail.com> <8761k6pheq.fsf@uwakimon.sk.tsukuba.ac.jp> <87y4x1oht2.fsf@uwakimon.sk.tsukuba.ac.jp> <87fvj9nxhh.fsf@uwakimon.sk.tsukuba.ac.jp> <9B0EC050-6E8E-443A-B79B-083FA3710DA0@secondlook.com> <87d2ednte9.fsf@uwakimon.sk.tsukuba.ac.jp> <53A474B8.2060809@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 21 Jun 2014 13:08:54 +0900 Message-ID: <87zjh6zyy1.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/7ffajnkfTFeHeDsO1o0gfSL6sSs Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 21 Jun 2014 04:08:56 -0000 Dave Crocker writes: > On 6/13/2014 12:46 AM, Stephen J. Turnbull wrote: > > Well, for Author Domains publishing "p=reject", we can certainly > > confuse the issue dramatically. Change the protocol to advocate > > "silent discard" > > Question to the group: Does silent discard help? Or rather, do we have > any indication that noisy "p=reject" does or can hurt? We have the latter: mailing list deactivations and unsubscriptions. This effect can be mitigated but not eliminated because the same domains that agree to use "p=reject" refuse to provide informative DSNs, or even consistent status codes. That said, the more I think about this, the less I'm inclined to think it's important. There are multiple mitigations (ie, both heuristic recognition of "p=reject" bounces and mitigations based on avoiding DMARC rejects in the first place). These mitigations will be largely effective in newer versions of Mailman (and I assume other MLMs), and for older versions non-delivery is probably much the bigger problem, now that MLM developers and support understand why the deactivations and unsubscriptions occurred. I withdraw the suggestion of recommending silent discard for the purpose of protecting mailing list subscribers. Steve From nobody Fri Jun 20 21:40:46 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388AA1A050E for ; Fri, 20 Jun 2014 21:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 HQ9VweJEiBcZ for ; Fri, 20 Jun 2014 21:40:42 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 769671A0503 for ; Fri, 20 Jun 2014 21:40:42 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 6C8123FA015E; Sat, 21 Jun 2014 13:40:41 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 5EB9F1A28E3; Sat, 21 Jun 2014 13:40:41 +0900 (JST) From: "Stephen J. Turnbull" To: "John R Levine" In-Reply-To: References: <20140620184337.78017.qmail@joyce.lan> <53A49547.2060307@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 21 Jun 2014 13:40:41 +0900 Message-ID: <87y4wqzxh2.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/mmmlaQHIR4CcMqANJU-xvsEbxVw Cc: Dave Crocker , dmarc@ietf.org Subject: Re: [dmarc-ietf] A detour into signature semantics, was Fwd: New Version 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, 21 Jun 2014 04:40:44 -0000 John R Levine writes: > It feels like some people (not you I hope) are assuming that if a > message has a valid signature, it's good and you deliver it, which > is of course wrong. As far as I can tell this notion was injected by your use of the terms "accept" and "reject" in your discussion of SpamAssassin's DKIM plugin. From nobody Fri Jun 20 22:04:10 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3011A04F6 for ; Fri, 20 Jun 2014 22:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 yGP2t2D0LwaI for ; Fri, 20 Jun 2014 22:04:06 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id B81911A02E2 for ; Fri, 20 Jun 2014 22:04:06 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id D17A23FA0B2C; Sat, 21 Jun 2014 14:04:05 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id C3B141A28E3; Sat, 21 Jun 2014 14:04:05 +0900 (JST) From: "Stephen J. Turnbull" To: "John Levine" In-Reply-To: <20140620182159.77973.qmail@joyce.lan> References: <20140620182159.77973.qmail@joyce.lan> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 21 Jun 2014 14:04:05 +0900 Message-ID: <87wqcazwe2.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/oceMTEG8ft9cE49aRg-1rsNsyEE Cc: dmarc@ietf.org, superuser@gmail.com Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-01.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, 21 Jun 2014 05:04:09 -0000 John Levine writes: > >Playing around with ideas here. This one removes the "l=0" signature stuff > >and instead makes DKIM-Delegate into a more self-contained thing, which I > >believe was suggested (or at least inspired) by Stephen's comments. There > >is still the potential for abuse during the ephemeral relationship period > >(i.e., prior to expiration), but it it is now an indirect attack on the > >author domain rather than a direct one. Perhaps that's more palatable in > >this scenario. > > > >Comments welcome. > > This looks an awful lot like my draft-levine-cdkim-00 and > draft-levine-dkim-conditional-00 except that mine has more bits of > DKIM in the cdkim signature so it can sign To and From to limit the > range of spoofage. I'm not sure about the plusses and minuses of signing To: (and Cc:), but I agree that the new version (which I like a lot) would definitely be more valuable to Author Domains if the signature covered From:. It's not obvious to me that this couldn't be REQUIRED rather than an option (with attendant complication of the protocol), since Mediators that "take ownership" of From: (eg, anonymizers) will then be "first parties". Unless the Mediator chose to use a *different* mailbox in the Author Domain, but I don't see why the Author Domain would want to permit that unless the Mediator is controlled by the Author Domain. From nobody Fri Jun 20 22:08:10 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9698C1B290D for ; Fri, 20 Jun 2014 22:08:06 -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 BQykPtTuqbXe for ; Fri, 20 Jun 2014 22:08:03 -0700 (PDT) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 941ED1A0545 for ; Fri, 20 Jun 2014 22:08:03 -0700 (PDT) Received: from mailout03.controlledmail.com (localhost [127.0.0.1]) by mailout03.controlledmail.com (Postfix) with ESMTP id 9104BD044EC; Sat, 21 Jun 2014 01:08:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2014-01; t=1403327282; bh=lRQtXAZa7mG0uoH6YHK8vu5iAWtkRAlrNLpJ7VCJ/p0=; h=In-Reply-To:References:Subject:From:Date:To:From; b=bFpXC1WZrshTYq8W3gH2wiVWvhneAajT8gGDau8earExiApH0N+f9u/FGZIra1J9/ DbQgJO/fdLMKAbULl8/EpcH82RMv4nGXjBl3Aehmc/0vTDptSJ+lU6D2iqfB3LDDHb zU95Xa8ePZYYo3eZR4yqoi0addovyAA8NVrBV1Ug= Received: from [192.168.111.116] (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 42410D04046; Sat, 21 Jun 2014 01:08:02 -0400 (EDT) User-Agent: K-9 Mail for Android In-Reply-To: <20140620213941.78722.qmail@joyce.lan> References: <20140620213941.78722.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Sat, 21 Jun 2014 01:07:24 -0400 To: dmarc@ietf.org Message-ID: <8e1a90fa-c85a-4c3b-8462-038f7c50317c@email.android.com> X-AV-Checked: ClamAV using ClamSMTP Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/a6XbKVl1Q27tO1rOhhkcYiq0iNU Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-kucherawy-dkim-delegate-00.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, 21 Jun 2014 05:08:07 -0000 On June 20, 2014 5:39:41 PM EDT, John Levine wrote: >>> I don't know anyone who's checked whether DKIM validators verify the >>> version number, but if it's an issue, there aren't that many widely >>> used DKIM engines so it wouldn't be hard to check. >> >>Just FYI, libdkim which all our products use does check the v= and if >>it's not "v=1" verification "fails" with an "invalid v=" error which >we >>then document in the authentication-results header. > >I looked at the code in Mail::DKIM which is what spamassassin and >probably every other perl DKIM application uses. It checks the >version number, and for some reason accepts "0.5" as well as "1", but >nothing else. > >The most widely used python module is Scott's dkimpy, which checks >that the version is "1". It currently raises an error if the version is not 1. That was probably a mistake. It'd have been better just to treat versions !1 as no signature present. I think I'll change that. Scott K From nobody Fri Jun 20 22:42:44 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7742D1B2932 for ; Fri, 20 Jun 2014 22:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 MBesSJW5R-XZ for ; Fri, 20 Jun 2014 22:42:36 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 7FABE1B292E for ; Fri, 20 Jun 2014 22:42:33 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 5E4213FA0B2C; Sat, 21 Jun 2014 14:42:33 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 509B21A28E3; Sat, 21 Jun 2014 14:42:33 +0900 (JST) From: "Stephen J. Turnbull" To: Ned Freed In-Reply-To: <01P98L6XH1DE0049PU@mauve.mrochek.com> References: <20140620191318.78155.qmail@joyce.lan> <01P98L6XH1DE0049PU@mauve.mrochek.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 21 Jun 2014 14:42:33 +0900 Message-ID: <87vbruzuly.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/nN_GyayIi2HVodqmKi9Ru-LVaHs Cc: dmarc@ietf.org, John Levine Subject: Re: [dmarc-ietf] The theory of DKIM versions 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, 21 Jun 2014 05:42:37 -0000 Ned Freed writes: > The obvious issue is that it makes it possible to create myriad > incompatible but nevertheless legitimate variants of DKIM. Since an > important aspect of DKIM is use by bilateral agreement, and since > nothing prevents you from attaching multiple DKIM-Signature header > fields, even if this happens I don't see it as a problem. Multiple signatures with the same basic semantics ("the domain in 'd=' vouches for the mailbox in From:", to paraphrase Dave Crocker) from the same signatory clearly increases complexity, of handling for third parties as well as of interpretation by recipients. The scenario that worries me is not that Yahoo! will choose to apply GMail-style conditions in a separate DKIM-Signature field from their "native" DKIM-Signature field. It's the scenario where they *don't*, and Mediators (and Recipients) have to adjust to new "critical" tags every time a large mailbox provider has a protocol brainstorm or suffers a security breach. > I don't see [ignoring criticality] as likely to happen with DKIM > for several reasons. For one thing, the failure to interpret a > paritcular DKIM-Signature field isn't supposed to render the > message unprocessable - in fact it's required that it not have that > effect. By design, DMARC renders that requirement inoperative, and a "p=reject" policy is intended to render messages unprocessable exactly when a particular DKIM-signature is invalid. DKIM may not need to worry about it, but we do. From nobody Fri Jun 20 23:23:17 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53EF91B2947 for ; Fri, 20 Jun 2014 23:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 bvtqS43tzlMP for ; Fri, 20 Jun 2014 23:23:08 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 182B31B2946 for ; Fri, 20 Jun 2014 23:23:06 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 2AF7C3FA0158; Sat, 21 Jun 2014 15:23:06 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 1D16E1A28E3; Sat, 21 Jun 2014 15:23:06 +0900 (JST) From: "Stephen J. Turnbull" To: Dave Crocker In-Reply-To: <53A48DB1.9080706@gmail.com> References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net> <6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 21 Jun 2014 15:23:06 +0900 Message-ID: <87r42izsqd.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/svaK0vrJx330t_yJ3ZgYCUut_wA Cc: Pete Resnick , "dmarc@ietf.org" , Barry Leiba Subject: [dmarc-ietf] Draft DMARC working group charter 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, 21 Jun 2014 06:23:10 -0000 Dave Crocker writes: > The existing base specification is being submitted as an Independent > Submission to become an Informational RFC. [...] > 2. Intra-Specification -- Audit each part of the DMARC > specification (reporting, policy, auth), making improvements as > appropriate. This last role seems to conflict with "Independent Submission". "Suggesting improvements" would be better? From nobody Sat Jun 21 04:17:19 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB6D1B2A3A for ; Sat, 21 Jun 2014 04:17:18 -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 Q0ph6ZPDLsTy for ; Sat, 21 Jun 2014 04:17:17 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC2031B2A0B for ; Sat, 21 Jun 2014 04:17:16 -0700 (PDT) Received: by mail-yk0-f172.google.com with SMTP id 142so3446930ykq.17 for ; Sat, 21 Jun 2014 04:17:16 -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=J97HAWXHZpM2JbhgMniehjD69cR2kfYbheHv2uyqt4M=; b=Yavg4frpvfeiEXDuhsBw2MDJtvWJkHLBCyURKrsYp0QHTnkKU85frZPrSMc5agf1zw /ekbfGotmUf50nD3qZtUH3DgVBKjteQijsuXeHM2fjpT5Ra/dMzV8UEBjslcBKsLRHTi MVcRkD4dDY9Y1qLX/sWyIwIbJdz5aXnp7Sw7W5grjMZtZ1kGDamZ7kUe/4oy4SwcJZeV Jbx9Sf2Owb6Ac7VB7Rs25wbTaNm4D+3EQJWR4cXeumzXQ9RjvgZdWsMPuF3qOg4fJff+ 9g9Tb/Tb5N1uOk3JF3JRRQ12eiAju7ZW+RinqaP7XbRZF2FputRw/rj4Ge5qu09tNvWo 18Zw== X-Received: by 10.236.104.231 with SMTP id i67mr2457806yhg.133.1403349436242; Sat, 21 Jun 2014 04:17:16 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id f20sm19411384yhp.36.2014.06.21.04.17.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Jun 2014 04:17:15 -0700 (PDT) Message-ID: <53A56974.8020200@gmail.com> Date: Sat, 21 Jun 2014 04:16:04 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Stephen J. Turnbull" References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net> <6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> <87r42izsqd.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87r42izsqd.fsf@uwakimon.sk.tsukuba.ac.jp> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/6d_cC_1PffeqA5ny8E1D2v69ijA Cc: Pete Resnick , "dmarc@ietf.org" , Barry Leiba Subject: Re: [dmarc-ietf] Draft DMARC working group charter 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, 21 Jun 2014 11:17:18 -0000 On 6/20/2014 11:23 PM, Stephen J. Turnbull wrote: > Dave Crocker writes: > > The existing base specification is being submitted as an Independent > > Submission to become an Informational RFC. > > [...] > > 2. Intra-Specification -- Audit each part of the DMARC > > specification (reporting, policy, auth), making improvements as > > appropriate. > > This last role seems to conflict with "Independent Submission". > "Suggesting improvements" would be better? Hmmm. Interesting challenge in writing. What the text means to impart is that it is possible to make changes to the base specification, for publication as a new version of the specification. So, the current version goes as an Independent submissions, and a new one would go as a working group document. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Jun 21 06:45:37 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581561A0381 for ; Sat, 21 Jun 2014 06:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 12d-UZnpx7ov for ; Sat, 21 Jun 2014 06:45:32 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id A051C1A037C for ; Sat, 21 Jun 2014 06:45:31 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 5BA2C3FA0B2C; Sat, 21 Jun 2014 22:45:31 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 4FC311A28E3; Sat, 21 Jun 2014 22:45:31 +0900 (JST) From: "Stephen J. Turnbull" To: Dave Crocker In-Reply-To: <53A56974.8020200@gmail.com> References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net> <6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> <87r42izsqd.fsf@uwakimon.sk.tsukuba.ac.jp> <53A56974.8020200@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 21 Jun 2014 22:45:31 +0900 Message-ID: <87lhsqz890.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/0yQpK61COTnU5A8CyxNjAc5HKoE Cc: Pete Resnick , "dmarc@ietf.org" , Barry Leiba Subject: Re: [dmarc-ietf] Draft DMARC working group charter 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, 21 Jun 2014 13:45:35 -0000 Dave Crocker writes: > What the text means to impart is that it is possible to make changes to > the base specification, for publication as a new version of the > specification. So, the current version goes as an Independent > submissions, and a new one would go as a working group document. How about making that explicit: 2. Intra-Specification -- Audit each part of the DMARC specification (reporting, policy, authentication). Improvements and extensions developed may be considered for incorporation in a future standard. or similar language? From nobody Sat Jun 21 08:59:39 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA241A036B for ; Sat, 21 Jun 2014 08:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.544 X-Spam-Level: X-Spam-Status: No, score=-0.544 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=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 LlteIxmLoHC3 for ; Sat, 21 Jun 2014 08:59:35 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 368E41A028E for ; Sat, 21 Jun 2014 08:59:35 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P99PLG4DKG005R9G@mauve.mrochek.com> for dmarc@ietf.org; Sat, 21 Jun 2014 08:51:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1403365914; bh=dmprQdvG7yxB2iiKg3olv7McklaqHS7n4EpkaGaS7gg=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=BhyW5iF20ySMCXJnwpwOBE75H/atfOqNm9clpT1GmOfkU/vVNn9uX0Wq+nbtkSrzO HHdDhMX1GvR6AH7hzNC9NaC1zkP0rUP2dltmY68pwCyBJmim87ratvT6Y19Eu8SThr kxGqsX3suH3+YJgQ+PYy7d/f/Z7I1eVjrcXivyAU= 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 <01P8UD4AOU8W0049PU@mauve.mrochek.com>; Sat, 21 Jun 2014 08:51:33 -0700 (PDT) Message-id: <01P99PLEHSSO0049PU@mauve.mrochek.com> Date: Sat, 21 Jun 2014 08:46:19 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 21 Jun 2014 14:42:33 +0900" <87vbruzuly.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20140620191318.78155.qmail@joyce.lan> <01P98L6XH1DE0049PU@mauve.mrochek.com> <87vbruzuly.fsf@uwakimon.sk.tsukuba.ac.jp> To: "Stephen J. Turnbull" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/PV6TZnzZfgwQqBQRbtIdQlgl6oA Cc: dmarc@ietf.org, John Levine , Ned Freed Subject: Re: [dmarc-ietf] The theory of DKIM versions 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, 21 Jun 2014 15:59:37 -0000 > Ned Freed writes: > > The obvious issue is that it makes it possible to create myriad > > incompatible but nevertheless legitimate variants of DKIM. Since an > > important aspect of DKIM is use by bilateral agreement, and since > > nothing prevents you from attaching multiple DKIM-Signature header > > fields, even if this happens I don't see it as a problem. > Multiple signatures with the same basic semantics ("the domain in 'd=' > vouches for the mailbox in From:", to paraphrase Dave Crocker) from > the same signatory clearly increases complexity, of handling for third > parties as well as of interpretation by recipients. > The scenario that worries me is not that Yahoo! will choose to apply > GMail-style conditions in a separate DKIM-Signature field from their > "native" DKIM-Signature field. It's the scenario where they *don't*, > and Mediators (and Recipients) have to adjust to new "critical" tags > every time a large mailbox provider has a protocol brainstorm or > suffers a security breach. The scenario you propose makes no sense: If Yahoo! or whoever does what you describe, their messages would in effect have no attached signatures until the receiving systems out there upgrade their software to handle the new critical tags. You can't count on much from large players, but I think you can count on them not intentionally screwing themselves over. > > I don't see [ignoring criticality] as likely to happen with DKIM > > for several reasons. For one thing, the failure to interpret a > > paritcular DKIM-Signature field isn't supposed to render the > > message unprocessable - in fact it's required that it not have that > > effect. > By design, DMARC renders that requirement inoperative, and a > "p=reject" policy is intended to render messages unprocessable exactly > when a particular DKIM-signature is invalid. DKIM may not need to > worry about it, but we do. You're missing the point. We're *changing* the design here so things no longer work this way by associating this with a version bump. And we've already confirmed that a significant number of implementations ignore v=2 signatures. Ned From nobody Sat Jun 21 09:19:41 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D08E31A03D3 for ; Sat, 21 Jun 2014 09:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.762 X-Spam-Level: X-Spam-Status: No, score=0.762 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 muOkXNDBsTSf for ; Sat, 21 Jun 2014 09:19:38 -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 972E31A027D for ; Sat, 21 Jun 2014 09:19:38 -0700 (PDT) Received: (qmail 5782 invoked from network); 21 Jun 2014 16:19:36 -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:cleverness; s=1695.53a5b098.k1406; bh=plKH1cEp2BfFhIdDo2AbkPLX14GiL+hQ1Od31Px1jSQ=; b=wsDNqeiXFbzuvTkmU0rnELfrfQIT5XHWHx7dZD1FBlU0AWVI4liFYgdUYUUd3hVkGq1D+qG11tEZ3ZdJNGbDMWbSPej86HRcWCETejTci9KQ2qrsZPhgEPdoa3iszB/sMFkkvI8lUW1xCAj9JmTBkfAjYxxQAO8BEC4ZOocaxifj1ekl8+oxjKByYBy/WaYh+3P+v0ObIRnALNren+ZBSHErwLomn70lFj93l3os7DOe+Ucc0mJItNg5qB1xCY9q 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:cleverness; s=1695.53a5b098.k1406; bh=plKH1cEp2BfFhIdDo2AbkPLX14GiL+hQ1Od31Px1jSQ=; b=GVU0cRFtqy8M59vet218zF8toDUb1pJ4FpY4eHkZmx4vxKDxtgFNZH9v4NTt6SV0ULMB2jGG1j9YXew4D6QOiZj5SBX+NwiT/RZf7qD9Z76vOKVXLjy1dF8Cqy5ljPBRMSuM/Jr2NbDAH6QOTbpAwLqz9GeMy53zHFng3yYJiJys8xtmOk2U8AGyijykNUH/3K06Vasg7h4bWQ51iJZ6ML+RmvQhQ+0PU/9fMZnirEH0jonzVJSGtDDaEQpPLOuf 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 Jun 2014 16:19:36 -0000 Date: 21 Jun 2014 12:19:36 -0400 Message-ID: From: "John R Levine" To: "Ned Freed" In-Reply-To: <01P99PLEHSSO0049PU@mauve.mrochek.com> References: <20140620191318.78155.qmail@joyce.lan> <01P98L6XH1DE0049PU@mauve.mrochek.com> <87vbruzuly.fsf@uwakimon.sk.tsukuba.ac.jp> <01P99PLEHSSO0049PU@mauve.mrochek.com> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/VcZglRiVqb9eIy50F18JTdKM7DM Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] The theory of DKIM versions 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, 21 Jun 2014 16:19:40 -0000 > You can't count on much from large players, but I think you can count on them > not intentionally screwing themselves over. I'm with Ned. I know a lot of the relevant people at large public mail providers, who are under all sorts of internal political pressure, but they are not stupid. They will not break things for the sake of breaking them. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Sat Jun 21 20:16:51 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD96B1A03FC for ; Sat, 21 Jun 2014 20:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.309 X-Spam-Level: *** X-Spam-Status: No, score=3.309 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 kKmGcSoyP0No for ; Sat, 21 Jun 2014 20:16:48 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id CCB0E1A0341 for ; Sat, 21 Jun 2014 20:16:47 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id CC89F3FA0B2C; Sun, 22 Jun 2014 12:16:46 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id BEFCD1A28E3; Sun, 22 Jun 2014 12:16:46 +0900 (JST) From: "Stephen J. Turnbull" To: "John R Levine" In-Reply-To: References: <20140620191318.78155.qmail@joyce.lan> <01P98L6XH1DE0049PU@mauve.mrochek.com> <87vbruzuly.fsf@uwakimon.sk.tsukuba.ac.jp> <01P99PLEHSSO0049PU@mauve.mrochek.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Sun, 22 Jun 2014 12:16:46 +0900 Message-ID: <87egyhzl9d.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/S8QsB_w7C8mdWxXnMGhd_LA_CAc Cc: dmarc@ietf.org, Ned Freed Subject: Re: [dmarc-ietf] The theory of DKIM versions 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, 22 Jun 2014 03:16:49 -0000 John R Levine writes: > They will not break things for the sake of breaking them. Of course not. They'll break *some* things for the sake of dealing with *other* breakage that's more important to them. I don't see a good reason for thinking that they'll agree on the "other breakage", either. GMail participates in DMARC but mitigates by disrespecting "p=reject", a central protocol of the policy part of DMARC. Yahoo! participates but Yahoo! Groups mitigates by moving the mailbox into the display name, as specifically deprecated by the DMARC FAQ. Remember, I'm here with a specific commission: to advocate the interests of mailing lists, as understood by the Mailman developers. I've said that several times. We are among the folks worst harmed by Yahoo!'s and AOL's actions. I see no reason to expect them to change their definition of "less broken than the alternative" to emphasize us. If the IETF chooses to side with them, and offer its sympathy but no help to us, fine -- not every problem has a solution satisfactory to all parties. But I'm not going to accept an *assumption* that everything is going to work out fine "because nobody *wants* to break things." Explain why goodwill will make things work for us. Please! AIUI, at this point[1] we have *one* protocol we want to provide and *no* validating experience (see Murray's response to your version bump examples) for "cumulative versioning" in Internet protocols. Ned himself declares knowledge of "extensible" protocols with "critical overrides" that ended in fragmentation and failure of interoperability. (Though he declares that he thinks the DKIM/DMARC circumstances are different, as presented so far that's just opinion, even though it is an expert's opinion.) We know that this particular set of protocols is controversial and failure of interoperability causes real harm to *third parties*. I don't see a good reason for experimenting with "extensible protocols" and "protocol versioning", at the same time as we're struggling with a problem that is in itself very hard and high-risk. Regards, Steve Footnotes: [1] Evidently Dave Crocker has a much wider view of the mission of a potential working group, but over the last couple of weeks discussion has focused on delegation and third-party authorization. From nobody Sat Jun 21 21:29:30 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796941B2833 for ; Sat, 21 Jun 2014 17:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.108 X-Spam-Level: *** X-Spam-Status: No, score=3.108 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] 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 LKGjEzkMm4An for ; Sat, 21 Jun 2014 17:54:31 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 4116D1A040C for ; Sat, 21 Jun 2014 17:54:30 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id BA8F33FA0765; Sun, 22 Jun 2014 09:54:29 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id AD8F71A28E3; Sun, 22 Jun 2014 09:54:29 +0900 (JST) From: "Stephen J. Turnbull" To: Ned Freed In-Reply-To: <01P99PLEHSSO0049PU@mauve.mrochek.com> References: <20140620191318.78155.qmail@joyce.lan> <01P98L6XH1DE0049PU@mauve.mrochek.com> <87vbruzuly.fsf@uwakimon.sk.tsukuba.ac.jp> <01P99PLEHSSO0049PU@mauve.mrochek.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Sun, 22 Jun 2014 09:54:29 +0900 Message-ID: <87fvixzrui.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/4BVnMGqpzQ7XFRRfTrNjjblSJoQ X-Mailman-Approved-At: Sat, 21 Jun 2014 21:29:28 -0700 Cc: dmarc@ietf.org, John Levine Subject: Re: [dmarc-ietf] The theory of DKIM versions 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, 22 Jun 2014 00:54:34 -0000 Ned Freed writes: > The scenario you propose makes no sense: True. > If Yahoo! or whoever does what you describe, their messages would > in effect have no attached signatures until the receiving systems > out there upgrade their software to handle the new critical tags. No, they'll have effective signatures. They'll use "v=1" signatures as well during a transition period (they work well enough to be used for a while ), and then do what they're doing now: tell their users to yell at recipients who don't handle vendor-specific "V=2" signatures to get their act together and "be part of the solution". > You can't count on much from large players, but I think you can > count on them not intentionally screwing themselves over. I don't see the strategy above as screwing a large player more than publishing p=reject already does. They did that. > > By design, DMARC renders that requirement inoperative, and a > > "p=reject" policy is intended to render messages unprocessable exactly > > when a particular DKIM-signature is invalid. DKIM may not need to > > worry about it, but we do. > > You're missing the point. We're *changing* the design here so things no > longer work this way by associating this with a version bump. And we've > already confirmed that a significant number of implementations ignore > v=2 signatures. Changing the design of what? I wish we could change the design of DMARC[1], but I don't think that is going to happen. DMARC is a private agreement so far completely out of IETF control, it is known to suck in some ways for third parties, and the big players are doing those sucky things anyway because it accomplishes their goals without hurting them very much. Changing DKIM is not going to change DMARC as far as I can see. DMARC may adopt new features of DKIM, but only as it serves the consortium's purposes, and they will surely continue to apply the "p=reject" override to any "v=2" DKIM signature that fails (generalized) identity alignment or is invalid. No? All the evidence I see says that even if the exact scenario I propose is unlikely to occur, it's possible, maybe even quite probable, that the big players will use the possibility of registering values and imposing criticality to serve their own purposes. You describe the same kind of thing happening in the past -- I understand that "that was then, this is now (and different)", but this "difference" is all hypothetical. The fact is that fragmentation does occur under some circumstances. Footnotes: [1] In some ways. Mostly I think it does what it's supposed to do quite well, and I don't think I'd even change "p=reject" except to add an explicit caveat that publishing "p=reject" means that the Author Domain must assume *full* responsibility for lost or undelivered mail in the current Internet environment. From nobody Sun Jun 22 07:43:06 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE1B1A0383 for ; Sun, 22 Jun 2014 07:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.857 X-Spam-Level: X-Spam-Status: No, score=0.857 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, J_CHICKENPOX_16=0.6, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=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 gx3yBbQsUm0G for ; Sun, 22 Jun 2014 07:43:03 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 220741A0382 for ; Sun, 22 Jun 2014 07:43:03 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P9B1BCZ628003NSK@mauve.mrochek.com> for dmarc@ietf.org; Sun, 22 Jun 2014 07:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1403447872; bh=O3jAnrs+tqcxNxOEMstozDHNNInVJph2PPngFLvTCys=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=r47hxpGPL4JdspTGE77Tm+slvKQJq4xwUGn3ENdZElHFnagTasjQ9wt+zzS5q+9bA +I6ZasTJr+7T46vYktFMZaYE519W7eTjWkzSZ1A6HCkY02EiolFTD5l242pYdkDxMK brW2MQDeqHNt/UawWa8kyptsirQzGL+n4Ea1f2VM= 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 <01P8UD4AOU8W0049PU@mauve.mrochek.com>; Sun, 22 Jun 2014 07:37:48 -0700 (PDT) Message-id: <01P9B1BAYXN40049PU@mauve.mrochek.com> Date: Sun, 22 Jun 2014 07:07:58 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 22 Jun 2014 09:54:29 +0900" <87fvixzrui.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20140620191318.78155.qmail@joyce.lan> <01P98L6XH1DE0049PU@mauve.mrochek.com> <87vbruzuly.fsf@uwakimon.sk.tsukuba.ac.jp> <01P99PLEHSSO0049PU@mauve.mrochek.com> <87fvixzrui.fsf@uwakimon.sk.tsukuba.ac.jp> To: "Stephen J. Turnbull" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/tQANYa5JFJilMorr6cgkkCuMeLQ Cc: dmarc@ietf.org, John Levine , Ned Freed Subject: Re: [dmarc-ietf] The theory of DKIM versions 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, 22 Jun 2014 14:43:05 -0000 > Ned Freed writes: > > The scenario you propose makes no sense: > True. > > If Yahoo! or whoever does what you describe, their messages would > > in effect have no attached signatures until the receiving systems > > out there upgrade their software to handle the new critical tags. > No, they'll have effective signatures. They'll use "v=1" signatures > as well during a transition period (they work well enough to be used > for a while ), and then do what they're doing now: tell their users to > yell at recipients who don't handle vendor-specific "V=2" signatures > to get their act together and "be part of the solution". You've now changed the scenario. Previously you seemed to be talking about switching to the new scheme, not running both in parallel. Since the V2 signatures will be ignored, running them in parallel is effectively the same as just having V1 signatures to old agents. > > You can't count on much from large players, but I think you can > > count on them not intentionally screwing themselves over. > I don't see the strategy above as screwing a large player more than > publishing p=reject already does. They did that. Again, you're talking about a different strategy now. > > > By design, DMARC renders that requirement inoperative, and a > > > "p=reject" policy is intended to render messages unprocessable exactly > > > when a particular DKIM-signature is invalid. DKIM may not need to > > > worry about it, but we do. > > > > You're missing the point. We're *changing* the design here so things no > > longer work this way by associating this with a version bump. And we've > > already confirmed that a significant number of implementations ignore > > v=2 signatures. > Changing the design of what? DKIM and subsequently DMARC. > I wish we could change the design of > DMARC[1], but I don't think that is going to happen. Then this entire effort is pointless and we might as well leave it all to the MLMs to deal with as best they can. > DMARC is a > private agreement so far completely out of IETF control, it is known > to suck in some ways for third parties, and the big players are doing > those sucky things anyway because it accomplishes their goals without > hurting them very much. Changing DKIM is not going to change DMARC as > far as I can see. DMARC may adopt new features of DKIM, but only as > it serves the consortium's purposes, and they will surely continue to > apply the "p=reject" override to any "v=2" DKIM signature that fails > (generalized) identity alignment or is invalid. No? Absolutely not. I would have thought this was obvious, but I guess it isn't, so let me state it plainly: The goal here is to propose changes to DMARC that improve its interoperability with lists while maintaining the security it provides. None of the present proposals make any sense if DMARC agents continue to only see only V1 signatures. > All the evidence I see says that even if the exact scenario I propose > is unlikely to occur, How can there possibly be evidence of anything? We have yet to reach any sort of consensus on a proposal here. So unless you can cite a case where a proposal was made to the folks using DMARC along these lines which was subsequently turned down, I fail to see the point you're trying to make here. > it's possible, maybe even quite probable, that > the big players will use the possibility of registering values and > imposing criticality to serve their own purposes. Why would they bother? If they want to do things along those lines, they can already do them by generating and then requiring a different header field and there's nothing we can do about it. Indeed, we know for a fact that Google already does this sort of thing for their own purposes. For that matter, if someone wants to they can presently require a DKIM-Signature field be present with various optional fields. And once again there's nothing we can do about it. Just because DKIM declares some field to be optional doesn't mean that son-of-DMARC has to. Or that all field values are acceptable. And so on. > You describe the > same kind of thing happening in the past -- I understand that "that > was then, this is now (and different)", but this "difference" is all > hypothetical. The fact is that fragmentation does occur under some > circumstances. No, the differences are very real. I really don't want to get deep into the nitty-gritty of X.400, but suffice it to say that there are various extensbility areas built in to the protocol. The ones defined at the P2 "message" level don't have criticality bits; but one of the ones defined at the P1 "envelope" level does. And the specifications call for a message to be outright rejected if there's a criticality bit set on P1 "envelope" extension that the MTA doesn't understand. This mechanism caused problems because some vendors added critical extensions which would then cause other implementations to bounce those messages. Some cases were probably the result of incompetence, but others seemed more like attempts to achieve vendor lock-in. (No doubt there was some marketing BS somewhere to justify what they were doing, but I never saw it.) There is nothing comparable in Internet mail, and certainly nothing in the present proposal, for the simple reason that the proposal calls for things to be ignored that otherwise would be processed. Ned From nobody Mon Jun 23 05:06:03 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB341B29C0 for ; Mon, 23 Jun 2014 05:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.373 X-Spam-Level: X-Spam-Status: No, score=-0.373 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 gXIfAC-nTGuk for ; Mon, 23 Jun 2014 05:05:56 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF1BF1B2927 for ; Mon, 23 Jun 2014 05:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1403525153; bh=Xjubd9zOSqxbZwapUdDC4TIv49OaRDqOsyC8zOAqzlQ=; l=1428; h=Date:From:To:References:In-Reply-To; b=b4C0RzEDoAYuWDuAYyL4Ybk6j3x4iGlz8KMySpXJr7I/ZoQi/MGqZtqXh0VQFQW6N lwJh0E0EEv7rg/Gz2x2jbitN2V8otEunZb2Xu86OFti7fkfvx8Kvee4fZyXV9TuVlW sHgvkKGNYh7sXe6sMVb8FTVOrhgthLpnY0yN0+YI= Authentication-Results: tana.it; auth=pass (details omitted) Received: from [172.25.197.88] (pcale.tana [172.25.197.88]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Mon, 23 Jun 2014 14:05:53 +0200 id 00000000005DC042.0000000053A81821.0000042B Message-ID: <53A81821.7010908@tana.it> Date: Mon, 23 Jun 2014 14:05:53 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net> <6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> <87r42izsqd.fsf@uwakimon.sk.tsukuba.ac.jp> <53A56974.8020200@gmail.com> In-Reply-To: <53A56974.8020200@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Xu_6uy9klSjY1yggVoQdUpLjyAQ Subject: Re: [dmarc-ietf] Draft DMARC working group charter 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, 23 Jun 2014 12:06:01 -0000 On Sat 21/Jun/2014 13:16:04 +0200 Dave Crocker wrote: > On 6/20/2014 11:23 PM, Stephen J. Turnbull wrote: >> Dave Crocker writes: >>> The existing base specification is being submitted as an Independent >>> Submission to become an Informational RFC. >> >> [...] >>> 2. Intra-Specification -- Audit each part of the DMARC >>> specification (reporting, policy, auth), making improvements as >>> appropriate. >> >> This last role seems to conflict with "Independent Submission". >> "Suggesting improvements" would be better? > > Hmmm. Interesting challenge in writing. > > What the text means to impart is that it is possible to make changes to > the base specification, for publication as a new version of the > specification. So, the current version goes as an Independent > submissions, and a new one would go as a working group document. That reminds the 4870/4871 split. Its usefulness may not be obvious to all, so some explanation might help. For the problem at hand, it is not clear how the WG is going to operate about the "choices", such as: - A form of DKIM signature that is better able to survive transit through intermediaries. Can the WG propose solutions that modify DKIM or is that out of scope? For example, something like the following I-D could be part of a solution. Would the proposed charter allow it? http://datatracker.ietf.org/doc/draft-vesely-smooth-canon/ Ale From nobody Mon Jun 23 08:41:07 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49FD51B2B3C for ; Mon, 23 Jun 2014 08:41:06 -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 VPAraso8ZnlS for ; Mon, 23 Jun 2014 08:41:03 -0700 (PDT) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B53461A03AE for ; Mon, 23 Jun 2014 08:41:03 -0700 (PDT) Received: by mail-yh0-f47.google.com with SMTP id v1so5131270yhn.6 for ; Mon, 23 Jun 2014 08:41: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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Ia1e+i1m2ZgNhB+8esO5oaccz+9a8gRspGgp+QZwtI8=; b=k/GZHjL4pu05cmQtXlN8UjGJamKQ5YH0A1aXn/kN43Brd0FP6ewKtlJ3E+2Ol27YE+ K3U8yeY+MDu3XjznG/Rf+wxG1xXYsuqzLFyfDj9Ha9VP5mgZDRBI9AJ4qfr9jm0NAPPi EAu81F5jDl1clg0U0xJUgq3szQQqXwM0oTFgkZ7zklHVdU7vJAEV1b4aSF/r61hpe+7F 1Z/Y7kHCS1ItJCdDpdAOPgV+v/mE4qF301ppA1fBFfM9TjQsvZ/U+eq9vpTBXQk6wX6+ rnMnOBE2AZb4uLemIlNCJ9prgnwlFttiZuLB3thKUuRqmI+EtVUqz5HZpkPjYotZfEWA +Oiw== X-Received: by 10.236.207.225 with SMTP id n61mr4747664yho.148.1403538063058; Mon, 23 Jun 2014 08:41:03 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id k20sm30384345yhi.20.2014.06.23.08.40.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Jun 2014 08:41:01 -0700 (PDT) Message-ID: <53A84A40.4090008@gmail.com> Date: Mon, 23 Jun 2014 08:39:44 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Stephen J. Turnbull" References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net> <6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> <87r42izsqd.fsf@uwakimon.sk.tsukuba.ac.jp> <53A56974.8020200@gmail.com> <87lhsqz890.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87lhsqz890.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/vg7migNwWmCK7NhwpN8hW5hZ_80 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Draft DMARC working group charter 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, 23 Jun 2014 15:41:06 -0000 On 6/21/2014 6:45 AM, Stephen J. Turnbull wrote: > Dave Crocker writes: > > > What the text means to impart is that it is possible to make changes to > > the base specification, for publication as a new version of the > > specification. So, the current version goes as an Independent > > submissions, and a new one would go as a working group document. > > How about making that explicit: > > 2. Intra-Specification -- Audit each part of the DMARC > specification (reporting, policy, authentication). > Improvements and extensions developed may be considered for > incorporation in a future standard. How about: 2. Intra-Specification -- Audit each part of the DMARC specification (reporting, policy, auth), making improvements to an incremental version as appropriate. Best to leave out statements of intended status and just focus on the work. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jun 23 12:28:58 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A86C1B2979 for ; Mon, 23 Jun 2014 12:28:57 -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 eC4s-BMcvkul for ; Mon, 23 Jun 2014 12:28:55 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22ABE1A03A1 for ; Mon, 23 Jun 2014 12:28:54 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id x48so7355159wes.23 for ; Mon, 23 Jun 2014 12:28:52 -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=1z6XSoRVDrvs/mdj7dm/aMCQPjDKTDe6rdw3k/ctsm0=; b=sII69opVkaG8ZMl84pjF6e/XKsr/jiNoMHetIKZ3/KknsZ6Km3JsnXtGuQOb0Ksp4u UHXldbU6607XMp2ukEIyxrXTnQ/ad11q6SGZXSANaTsi86BKjYPHLNTccRUdJ3xmaO9a 6D5XO4D7JPoDziNE9l6VEoUAIva99/W73oz2CQ90Qbq36HEH1zWw+WND9etRQ8bgGpdi 8hJpPmc8mf2EvqRZlRwxyj0TbzkB3HFZ0pHWwxkZqDXDWdt8fYK3G6jyCobexOLks+F0 7FtcW77uKByqVuQQ7G5UHNBNWtC7n13Pants6PEo5JHj+eUVpWRoNIFQmBiaFopXP7bs nyWw== MIME-Version: 1.0 X-Received: by 10.180.83.105 with SMTP id p9mr28359451wiy.8.1403551731880; Mon, 23 Jun 2014 12:28:51 -0700 (PDT) Received: by 10.180.19.73 with HTTP; Mon, 23 Jun 2014 12:28:51 -0700 (PDT) In-Reply-To: References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net> <6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> Date: Mon, 23 Jun 2014 12:28:51 -0700 Message-ID: From: "Murray S. Kucherawy" To: "dmarc@ietf.org" Content-Type: multipart/alternative; boundary=f46d044282de671dc104fc85daac Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/hhzCQfjzObr8dRC08BQLQlBqmcM Subject: Re: [dmarc-ietf] ***SPAM*** 11.422 (5) Re: Draft DMARC working group charter 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, 23 Jun 2014 19:28:57 -0000 --f46d044282de671dc104fc85daac Content-Type: text/plain; charset=UTF-8 On Sun, Jun 22, 2014 at 10:44 PM, Barry Leiba wrote: > Please have at it. (And please remove me from the CC list when you > reply to this; I subscribe to the list from another email address, and > don't want a separate copy.) > I think this looks like a reasonable charter. I'm hoping this: > The working group will seek to preserve interoperability with the > installed base of DMARC systems, and will provide careful justification > for any non-interoperability. The working group will seek to maintain > the viability of stable domain-level identifiers in mail, and will > document existing mail streams that do not conform to the DMARC model. > ...is a reasonable compromise with respect to the thing that derailed us last time. -MSK --f46d044282de671dc104fc85daac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Jun 22, 2014 at 10:44 PM, Barry Leiba <barr= yleiba@computer.org> wrote:
Please have at it. =C2=A0(And please remove = me from the CC list when you
reply to this; I subscribe to the list from another email address, and
don't want a separate copy.)

I thin= k this looks like a reasonable charter.=C2=A0 I'm hoping this:
=C2= =A0
The working group will seek to preserve interoperability with the
installed base of DMARC systems, and will provide careful justification
for any non-interoperability. The working group will seek to maintain
the viability of stable domain-level identifiers in mail, and will
document existing mail streams that do not conform to the DMARC model.
<= /blockquote>

...is a reasonable compromise with respect = to the thing that derailed us last time.

-MSK

--f46d044282de671dc104fc85daac-- From nobody Wed Jun 25 11:04:24 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54141B2D8D for ; Wed, 25 Jun 2014 11:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.309 X-Spam-Level: *** X-Spam-Status: No, score=3.309 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 s2jwSWZ1Shqe for ; Wed, 25 Jun 2014 11:04:21 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id CCAD01B2D90 for ; Wed, 25 Jun 2014 11:04:19 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 815D43FA0B31; Thu, 26 Jun 2014 03:04:18 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 6C47F11F082; Thu, 26 Jun 2014 03:04:18 +0900 (JST) From: "Stephen J. Turnbull" To: Ned Freed In-Reply-To: <01P9B1BAYXN40049PU@mauve.mrochek.com> References: <20140620191318.78155.qmail@joyce.lan> <01P98L6XH1DE0049PU@mauve.mrochek.com> <87vbruzuly.fsf@uwakimon.sk.tsukuba.ac.jp> <01P99PLEHSSO0049PU@mauve.mrochek.com> <87fvixzrui.fsf@uwakimon.sk.tsukuba.ac.jp> <01P9B1BAYXN40049PU@mauve.mrochek.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 26 Jun 2014 03:04:18 +0900 Message-ID: <87ha38yifx.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/fFrsF0JDuT9BGKnsoXK3Nb8y0OQ Cc: dmarc@ietf.org, John Levine Subject: Re: [dmarc-ietf] The theory of DKIM versions 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, 25 Jun 2014 18:04:23 -0000 Ned Freed writes: > Again, you're talking about a different strategy now. Well, one way to look at this is that if the strategy you *thought* I was talking about involves self-inflicted injury to some participant, maybe neither that participant nor I are that stupid, and I was talking about something else. Not specifying the full scenario was my bad. We can stop there, at "my bad", if you like, but it would be more productive if we could meet halfway, on some bridge between "your good" and "my bad". > > > You're missing the point. We're *changing* the design here so > > > things no longer work this way by associating this with a > > > version bump. And we've already confirmed that a significant > > > number of implementations ignore v=2 signatures. > > > Changing the design of what? > > DKIM and subsequently DMARC. That's not *the* design, that's *two* designs you're changing. DKIM is "owned" by the IETF, and "we" can change it. DMARC is not; DMARC is a successful private protocol, and "we" can't change it. We can make suggestions that provide sufficient benefits to the current DMARC participants so that they prefer our proposal to the one that works for them already. That's a tall order though. "Don't fix what ain't broke." > Then this entire effort is pointless I'm afraid it's going to be unsuccessful, indeed. That doesn't make it pointless. OTOH I'd rather not waste your effort and mine if it is pointlees. > and we might as well leave it all to the MLMs to deal with as best > they can. Well, we MLM devs will deal. But it's not just us. There are a bunch of third parties for whom the workarounds so far are suboptimal. > None of the present proposals make any sense if DMARC agents continue > to only see only V1 signatures. True. But some of the non-V1 signatures proposed are in new fields. Why is it a good idea to do an extensible protocol that we don't have any proposed extensions for? I grant that if we're going to do that, a version bump to DKIM-Signature (rather than a new field) is very plausible. > > it's possible, maybe even quite probable, that the big players > > will use the possibility of registering values and imposing > > criticality to serve their own purposes. > > Why would they bother? If they want to do things along those lines, > they can already do them by generating and then requiring a > different header field and there's nothing we can do about > it. Because if the IETF publishes it, it's a "standard", and the onus is on them to conform. If they can conform without conforming, they can blame everyone else (as Yahoo! and AOL are already doing, albeit implicitly). And they can do it explicitly, because they "conform." > This [X.400] mechanism caused problems because some vendors added > critical extensions which would then cause other implementations to > bounce those messages. Sounds like "p=reject" to me. More precisely, in the "p=reject" environment, ignoring things is no longer "fail-safe", it's "fail-mail-lost". A critical extension must be handled properly, or the signature doesn't validate ... and the message bounces. Steve From nobody Wed Jun 25 11:14:07 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1ABC1B2D4E for ; Wed, 25 Jun 2014 11:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.508 X-Spam-Level: ** X-Spam-Status: No, score=2.508 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 09nqUSX2b3vt for ; Wed, 25 Jun 2014 11:14:04 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 010EA1B2DA0 for ; Wed, 25 Jun 2014 11:14:03 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 31ADB3FA0B27; Thu, 26 Jun 2014 03:14:03 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 21A9311F082; Thu, 26 Jun 2014 03:14:03 +0900 (JST) From: "Stephen J. Turnbull" To: Dave Crocker In-Reply-To: <53A84A40.4090008@gmail.com> References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net> <6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> <87r42izsqd.fsf@uwakimon.sk.tsukuba.ac.jp> <53A56974.8020200@gmail.com> <87lhsqz890.fsf@uwakimon.sk.tsukuba.ac.jp> <53A84A40.4090008@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 26 Jun 2014 03:14:02 +0900 Message-ID: <87egycyhzp.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/14AH_MXyzTcU97d28oz-UPukpPI Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Draft DMARC working group charter 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, 25 Jun 2014 18:14:04 -0000 Dave Crocker writes: > How about: > > 2. Intra-Specification -- Audit each part of the DMARC > specification (reporting, policy, auth), making improvements to > an incremental version as appropriate. > > Best to leave out statements of intended status and just focus on the work. OK. Kinda picky, but how about "revised specification" instead of "incremental version"? From nobody Wed Jun 25 12:09:04 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4701B2E45 for ; Wed, 25 Jun 2014 12:08: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 yZGGb9v2o7rI for ; Wed, 25 Jun 2014 12:08:48 -0700 (PDT) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80FEA1B2E33 for ; Wed, 25 Jun 2014 12:08:14 -0700 (PDT) Received: by mail-yh0-f50.google.com with SMTP id t59so1473784yho.9 for ; Wed, 25 Jun 2014 12:08: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:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6jHHyzmd51r3F7L5TnQHNorkFnNi3P+blJJxmYAtLb4=; b=i5RhzOjoY+gCqX+JrdZTAS59LSA0HZPEwfbeZoGMHP8cK4YBAV5HtkkOhQni9WN54N hpTJuQpR80i6qeW3pnjSbeBO2lG2TC2+P7GqN/v4jSqw4mUX6b3TgS9TEcfyElKgMT0y VlYl1e4rmZgQ59Pb5QZjcZLqLgmim5+1HnSjdw4Dk3EdLA6B/1FjYuPVDPtjQCVkdAjJ RBkn621IBKAPMl4fVkk31fgNDg9hv4N73m6oAEfJwyox4SOZC57Ai3KGoLKpK492bJzd Eoj11IgMJTWyth7QXcu6U8NKH6DmGxXns0R8NhtdKSyXRIWdb4PK/Sf23HrEm2tPBzyY SF+Q== X-Received: by 10.236.227.230 with SMTP id d96mr14650971yhq.100.1403723293741; Wed, 25 Jun 2014 12:08:13 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id i24sm3400493yha.12.2014.06.25.12.08.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Jun 2014 12:08:12 -0700 (PDT) Message-ID: <53AB1DD0.30901@gmail.com> Date: Wed, 25 Jun 2014 12:06:56 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Stephen J. Turnbull" References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net> <6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> <87r42izsqd.fsf@uwakimon.sk.tsukuba.ac.jp> <53A56974.8020200@gmail.com> <87lhsqz890.fsf@uwakimon.sk.tsukuba.ac.jp> <53A84A40.4090008@gmail.com> <87egycyhzp.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <87egycyhzp.fsf@uwakimon.sk.tsukuba.ac.jp> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/9_pN3TUcVzz3hCUmtsTzzy_jJVc Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Draft DMARC working group charter 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, 25 Jun 2014 19:08:53 -0000 On 6/25/2014 11:14 AM, Stephen J. Turnbull wrote: > Dave Crocker writes: > > How about: > > > > 2. Intra-Specification -- Audit each part of the DMARC > > specification (reporting, policy, auth), making improvements to > > an incremental version as appropriate. > > > > Best to leave out statements of intended status and just focus on the work. > > OK. Kinda picky, but how about "revised specification" instead of > "incremental version"? Well, the language I offered was also produced from pickiness. In reaction to a possible misunderstanding of the earlier draft charter text. The problem is that 'revised specification' might be taken to mean a 'replacement' for the existing version, as in not publishing the current version but instead publishing the revision. By contrast, incremental is meant to imply that both current and new get published... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Jun 25 13:17:38 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F461A01BA for ; Wed, 25 Jun 2014 13:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.257 X-Spam-Level: X-Spam-Status: No, score=0.257 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=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 sT4kQGvlSbZL for ; Wed, 25 Jun 2014 13:17:32 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 25A581A00D3 for ; Wed, 25 Jun 2014 13:17:32 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P9FJV3PCI8006JWF@mauve.mrochek.com> for dmarc@ietf.org; Wed, 25 Jun 2014 13:12:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1403727140; bh=AbeB0tk5FW8aexdtyrSLeD66UV+nkdIk4Bh/oR+4Kd8=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=TwhgodJN8YbxkbWSLQVnY1otWa8z/hodEndgh4Pivtmm90lV4STe7p6pdFXCAz29R ChmaOl4L/FHLXGIbgyMtSbEAwJKm5zgKoYK+ed+gAvdpD0rYlppq6X9cPTt+mCvK0P mLDIbHFH1DBks9m0cuIlAN8e1XxJcKd6B5AJq2Ao= 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 <01P8UD4AOU8W0049PU@mauve.mrochek.com>; Wed, 25 Jun 2014 13:12:17 -0700 (PDT) Message-id: <01P9FJV1KIBY0049PU@mauve.mrochek.com> Date: Wed, 25 Jun 2014 11:41:34 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 26 Jun 2014 03:04:18 +0900" <87ha38yifx.fsf@uwakimon.sk.tsukuba.ac.jp> References: <20140620191318.78155.qmail@joyce.lan> <01P98L6XH1DE0049PU@mauve.mrochek.com> <87vbruzuly.fsf@uwakimon.sk.tsukuba.ac.jp> <01P99PLEHSSO0049PU@mauve.mrochek.com> <87fvixzrui.fsf@uwakimon.sk.tsukuba.ac.jp> <01P9B1BAYXN40049PU@mauve.mrochek.com> <87ha38yifx.fsf@uwakimon.sk.tsukuba.ac.jp> To: "Stephen J. Turnbull" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Dc5NgvwoETdS0papqGVDqPnROxg Cc: dmarc@ietf.org, John Levine , Ned Freed Subject: Re: [dmarc-ietf] The theory of DKIM versions 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, 25 Jun 2014 20:17:35 -0000 > Not specifying the full scenario was my bad. We can stop there, at > "my bad", if you like, but it would be more productive if we could > meet halfway, on some bridge between "your good" and "my bad". > > > > You're missing the point. We're *changing* the design here so > > > > things no longer work this way by associating this with a > > > > version bump. And we've already confirmed that a significant > > > > number of implementations ignore v=2 signatures. > > > > > Changing the design of what? > > > > DKIM and subsequently DMARC. > That's not *the* design, that's *two* designs you're changing. DKIM > is "owned" by the IETF, and "we" can change it. > DMARC is not; DMARC is a successful private protocol, and "we" can't > change it. We can make suggestions that provide sufficient benefits > to the current DMARC participants so that they prefer our proposal to > the one that works for them already. In other words, if may be difficult but we can change it. > That's a tall order though. "Don't fix what ain't broke." > > Then this entire effort is pointless > I'm afraid it's going to be unsuccessful, indeed. That doesn't make > it pointless. OTOH I'd rather not waste your effort and mine if it is > pointlees. > > and we might as well leave it all to the MLMs to deal with as best > > they can. > Well, we MLM devs will deal. But it's not just us. There are a bunch > of third parties for whom the workarounds so far are suboptimal. > > None of the present proposals make any sense if DMARC agents continue > > to only see only V1 signatures. > True. But some of the non-V1 signatures proposed are in new fields. > Why is it a good idea to do an extensible protocol that we don't have > any proposed extensions for? First, the protocol is already extensible, just not in the right way for this case. Second, what do you think the "non-V1 signatures in new fields" are if they aren't extensions? > I grant that if we're going to do that, > a version bump to DKIM-Signature (rather than a new field) is very > plausible. > > > it's possible, maybe even quite probable, that the big players > > > will use the possibility of registering values and imposing > > > criticality to serve their own purposes. > > > > Why would they bother? If they want to do things along those lines, > > they can already do them by generating and then requiring a > > different header field and there's nothing we can do about > > it. > Because if the IETF publishes it, it's a "standard", and the onus is > on them to conform. If they can conform without conforming, they can > blame everyone else (as Yahoo! and AOL are already doing, albeit > implicitly). And they can do it explicitly, because they "conform." You're confusing the definition of an extensibility mechanism with its use. We specify extensibility mechanisms all the time without there being any implication that someone using them is creating any sort of standard. Indeed, we could, as part of this mechanism, include additional tagging to make it clear whether or not a given set of tags are standardized or not. This is all old and well-tread ground in many protocols, and there's large amounts of "running code" saying that the issues you imagine this will create don't actually occur in practice. (I have described the issues that have occurred, as well as why that won't happen here.) > > This [X.400] mechanism caused problems because some vendors added > > critical extensions which would then cause other implementations to > > bounce those messages. > Sounds like "p=reject" to me. More precisely, in the "p=reject" > environment, ignoring things is no longer "fail-safe", it's > "fail-mail-lost". A critical extension must be handled properly, or > the signature doesn't validate ... and the message bounces. I have previously explained why the contexts aren't remotely comparable, but let's suppose for a moment that they are. "p=reject" was in no way dependent on any kind of extension to DKIM. Indeed, the main motivation behind extending DKIM is that DKIM gives us no way to specify what a signature is for, which makes it impossible to sign something twice with different grades of signature while making sure the weaker one isn't used for the wrong purpose. Although I don't agree with it and think it's gone one layer of abstraction too far, I accept the design decision that having a means to specify the intended purpose of a given signature in the signature itself is the wrong approach. Which means the only alternative is to extend the signature semantics one way or the other. Given that that this need has arisen, it seems to me that solving the general problem in a clean way makes a lot more sense than a one time hack, especially since the implementation costs are, AFAICT, nearly identical. Ned From nobody Wed Jun 25 20:18:08 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40AD91B2A40 for ; Wed, 25 Jun 2014 20:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.009 X-Spam-Level: ** X-Spam-Status: No, score=2.009 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 q6tgkd8ZQe5b for ; Wed, 25 Jun 2014 20:18:05 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id CC7CA1B2A3A for ; Wed, 25 Jun 2014 20:18:04 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id D3C0E3FA0B31; Thu, 26 Jun 2014 12:18:03 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id C7CCC11F082; Thu, 26 Jun 2014 12:18:03 +0900 (JST) From: "Stephen J. Turnbull" To: Dave Crocker In-Reply-To: <53AB1DD0.30901@gmail.com> References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net> <6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> <87r42izsqd.fsf@uwakimon.sk.tsukuba.ac.jp> <53A56974.8020200@gmail.com> <87lhsqz890.fsf@uwakimon.sk.tsukuba.ac.jp> <53A84A40.4090008@gmail.com> <87egycyhzp.fsf@uwakimon.sk.tsukuba.ac.jp> <53AB1DD0.30901@gmail.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 26 Jun 2014 12:18:03 +0900 Message-ID: <877g44xst0.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/WOuuHi3PxYwVSDS5yLJdbMHBxj4 Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] Draft DMARC working group charter 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, 26 Jun 2014 03:18:06 -0000 Dave Crocker writes: > Well, the language I offered was also produced from pickiness. In > reaction to a possible misunderstanding of the earlier draft > charter text. "Incremental version" is not a "term of art", then? (That occurred to me after hitting send.) Surely this terminological problem (foreseeing updates to another WG's -- or external body's -- in-progress specification, but not stepping on their toes) has been encountered by working groups before? (If nobody has examples off hand, I'll go research other charters for similar language, no reply necessary.) From nobody Wed Jun 25 22:20:53 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF111B2AC1 for ; Wed, 25 Jun 2014 22:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.508 X-Spam-Level: ** X-Spam-Status: No, score=2.508 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 b5DzQciOOnxD for ; Wed, 25 Jun 2014 22:20:49 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 080DC1B2AB9 for ; Wed, 25 Jun 2014 22:20:48 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id 5C2623FA0B31; Thu, 26 Jun 2014 14:20:47 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 4DFE311F082; Thu, 26 Jun 2014 14:20:47 +0900 (JST) From: "Stephen J. Turnbull" To: Ned Freed In-Reply-To: <01P9FJV1KIBY0049PU@mauve.mrochek.com> References: <20140620191318.78155.qmail@joyce.lan> <01P98L6XH1DE0049PU@mauve.mrochek.com> <87vbruzuly.fsf@uwakimon.sk.tsukuba.ac.jp> <01P99PLEHSSO0049PU@mauve.mrochek.com> <87fvixzrui.fsf@uwakimon.sk.tsukuba.ac.jp> <01P9B1BAYXN40049PU@mauve.mrochek.com> <87ha38yifx.fsf@uwakimon.sk.tsukuba.ac.jp> <01P9FJV1KIBY0049PU@mauve.mrochek.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Thu, 26 Jun 2014 14:20:47 +0900 Message-ID: <8738esxn4g.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/kPvAgSp6pFQqaEYAtCVBNZ0OGBk Cc: dmarc@ietf.org, John Levine Subject: Re: [dmarc-ietf] The theory of DKIM versions 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, 26 Jun 2014 05:20:51 -0000 Ned Freed writes: > > Why is it a good idea to do an extensible protocol that we don't have > > any proposed extensions for? > > First, the protocol is already extensible, just not in the right way for this > case. By which you mean? It doesn't have a "criticality" indicator for tags? > Second, what do you think the "non-V1 signatures in new fields" are if > they aren't extensions? Of course they're extensions, but not of an existing field. The process required to get them standardized is different. > This is all old and well-tread ground in many protocols, and > there's large amounts of "running code" saying that the issues you > imagine this will create don't actually occur in practice. I hope you're right. What worries me that I suspect that there really aren't all that many protocols whose purpose is to DoS illegitimate use, whose design is to DoS unauthenticated use, and where the set of legitimate uses is so much larger than the authenticatible set, as in the case of domain-based authentication. > (I have described the issues that have occurred, as well as why > that won't happen here.) Actually, no, you haven't. I accept your expertise, but I've seen insufficient evidence to lead me to the same conclusion in your absence. > Given that that this need has arisen, it seems to me that solving > the general problem in a clean way makes a lot more sense than a > one time hack, especially since the implementation costs are, > AFAICT, nearly identical. Why do you think the general problem can be solved "cleanly"? I agree that a clean syntax can be constructed, and that it could be reused for a lot of different individual problems that seem to be amenable to DKIM-signature-based solutions. But the domain of the "general problem" seems to be unknown, and the specific example we have (third party authorization via in-band protocol) is fraught with external semantic issues (criteria for authorization, how to populate those lists, etc). I see no reason to suppose that other problems won't have critical external semantics as well, and those leading to conflicting requirements. As soon as you have multiple signatures for various purposes, you have potential for unwanted interactions where one signature may validate even though it's the wrong purpose, as we've seen with "token signatures" in this discussion. I don't really see good reason to expect a semantically clean solution. While semantic confusion is no excuse for ugly syntax, I remain worried that use of one syntax for multiple semantics will lead to more confusion than cleanliness. I'd be a lot happier if we had another example of the "general problem" to help justify claims that these tags really are a "polymorphic" solution for a class of similar problems rather than C++ style arbitrary "overloading" of syntax. From nobody Thu Jun 26 01:15:41 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F7D1B2AF1 for ; Thu, 26 Jun 2014 01:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, 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 KXz026BV4rPu for ; Thu, 26 Jun 2014 01:15:03 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id 245631B2AF4 for ; Thu, 26 Jun 2014 01:15:03 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P9G8XPWNEO005HVE@mauve.mrochek.com> for dmarc@ietf.org; Thu, 26 Jun 2014 01:09:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1403770193; bh=UhCHYxMn1r3wEte91t7tTqTYyxD/Fhl3jwXIDFOEHSQ=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=BWcQguuwedU3//6Oc81ujO313jh1uKntYkDrbp1/2+OAJexYhbmuchZg6uJ1LW1Vn aYSR7tq1kcEilUrck2qWpxx71Zd/V7Z/RVlhG1ZfPCWRU5wdCpPjipi6nESOFAme4e ktr7mnmyUwti8z7mjVyebbc+VMHC2sTkaYakD6qU= 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 <01P9G7YH40XS000054@mauve.mrochek.com>; Thu, 26 Jun 2014 01:09:50 -0700 (PDT) Message-id: <01P9G8XNSP92000054@mauve.mrochek.com> Date: Thu, 26 Jun 2014 00:46:32 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 26 Jun 2014 14:20:47 +0900" <8738esxn4g.fsf@uwakimon.sk.tsukuba.ac.jp> Sender: Ned Freed References: <20140620191318.78155.qmail@joyce.lan> <01P98L6XH1DE0049PU@mauve.mrochek.com> <87vbruzuly.fsf@uwakimon.sk.tsukuba.ac.jp> <01P99PLEHSSO0049PU@mauve.mrochek.com> <87fvixzrui.fsf@uwakimon.sk.tsukuba.ac.jp> <01P9B1BAYXN40049PU@mauve.mrochek.com> <87ha38yifx.fsf@uwakimon.sk.tsukuba.ac.jp> <01P9FJV1KIBY0049PU@mauve.mrochek.com> <8738esxn4g.fsf@uwakimon.sk.tsukuba.ac.jp> To: "Stephen J. Turnbull" Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/4z29Y8ZhWf2izISS-7zSi_o3oUY Cc: dmarc@ietf.org, John Levine , Ned Freed Subject: Re: [dmarc-ietf] The theory of DKIM versions 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, 26 Jun 2014 08:15:06 -0000 > Ned Freed writes: > > > Why is it a good idea to do an extensible protocol that we don't have > > > any proposed extensions for? > > > > First, the protocol is already extensible, just not in the right way for this > > case. > By which you mean? I mean that any implementor can add whatever previously undefined tags they want to a signature and still be fully compliant. The meaning of those tags could then be taken to be whatever anyone eants by bilateral agreement. Semantics and requirements can also be attached to signatures through external means like publishing DNS records, as DMARC did. In other words, the issues you seem to be worried about criticality indicators introducing already exist. > It doesn't have a "criticality" indicator for tags? All criticality indicators would do, essentially is tell people when a signature has to be *ignored*. > > Second, what do you think the "non-V1 signatures in new fields" are if > > they aren't extensions? > Of course they're extensions, but not of an existing field. The > process required to get them standardized is different. Really? How does it differ? In either case you have to write a specification and get it through the IETF process. > > This is all old and well-tread ground in many protocols, and > > there's large amounts of "running code" saying that the issues you > > imagine this will create don't actually occur in practice. > I hope you're right. What worries me that I suspect that there really > aren't all that many protocols whose purpose is to DoS illegitimate > use, whose design is to DoS unauthenticated use, and where the set of > legitimate uses is so much larger than the authenticatible set, as in > the case of domain-based authentication. OK, let's say for the sake of argument that this is true - the question then is why would that mean that adding criticality indicators is a bad idea? > > (I have described the issues that have occurred, as well as why > > that won't happen here.) > Actually, no, you haven't. I accept your expertise, but I've seen > insufficient evidence to lead me to the same conclusion in your > absence. Then you need to reread my original message on this topic, where I covered the one previous adverse/perverse outcome I'm aware of in this space. And if you don't understand the difference between semantics requiring something be ignored and semantics requiring something be rejected, there's really nothing more I can say. And anything beyond examination of previous failures amounts to trying to prove a negative. > > Given that that this need has arisen, it seems to me that solving > > the general problem in a clean way makes a lot more sense than a > > one time hack, especially since the implementation costs are, > > AFAICT, nearly identical. > Why do you think the general problem can be solved "cleanly"? I agree > that a clean syntax can be constructed, and that it could be reused > for a lot of different individual problems that seem to be amenable to > DKIM-signature-based solutions. That's the general problem I'm talking about. So it seems we agree it can be solved cleanly. > But the domain of the "general problem" seems to be unknown, and the > specific example we have (third party authorization via in-band > protocol) is fraught with external semantic issues (criteria for > authorization, how to populate those lists, etc). I see no reason to > suppose that other problems won't have critical external semantics as > well, and those leading to conflicting requirements. In which case you define new critical tags to specify those semantics. > As soon as you > have multiple signatures for various purposes, you have potential for > unwanted interactions where one signature may validate even though > it's the wrong purpose, as we've seen with "token signatures" in this > discussion. I don't really see good reason to expect a semantically > clean solution. Of course it's necessary to properly design and specify future extensions. Any concievable mechanism carries with it the potential for misuse. > While semantic confusion is no excuse for ugly syntax, I remain > worried that use of one syntax for multiple semantics will lead to > more confusion than cleanliness. I'd be a lot happier if we had > another example of the "general problem" to help justify claims that > these tags really are a "polymorphic" solution for a class of similar > problems rather than C++ style arbitrary "overloading" of syntax. Yes, it's always nice to have more data to base decisions on. Are you prepared to wait for more data to show up before acting? Based on the current rate, that would mean waiting several years at least. Finally, since this conversation is essentially out of order at the present time - we're supposed to be discussing the DMARC charter - this will be my final message on this topic. Ned From nobody Thu Jun 26 13:38:14 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1723E1B2E7D for ; Thu, 26 Jun 2014 13:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.762 X-Spam-Level: X-Spam-Status: No, score=0.762 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 sXaioPd05BNX for ; Thu, 26 Jun 2014 13:38:12 -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 A91861B2E58 for ; Thu, 26 Jun 2014 13:38:11 -0700 (PDT) Received: (qmail 17432 invoked from network); 26 Jun 2014 20:38:09 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 26 Jun 2014 20:38:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=b035.53ac84b1.k1406; i=johnl@user.iecc.com; bh=dUdoHP29tajOBKJ29W3BwuTag/jVPx8mTJSSOKGC/Ac=; b=RZxmgAsq6Hc6A53OEz5dqCcW5KG4GfjJiXAkjf5lS5LkthiKn0+2R2Rc3F12WBP5+TpXeQrYMQFQq0S8ujrfrAy+vPYh2OqEnIDCM8bMfwSWO2UzF3rL/4N8BpylX46CVgcIQDMbu86Rwimu8mIwlKsYcKeCa1g7nG58CPgnyn1D0N/exIyA/os6KbrG/0rpT0gROoZusaoLz4rXQ5Azk48rPh5Y9XbwSgCsz+T7NDlZfNTWX3mc3y1FyvTS3nbu DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=b035.53ac84b1.k1406; olt=johnl@user.iecc.com; bh=dUdoHP29tajOBKJ29W3BwuTag/jVPx8mTJSSOKGC/Ac=; b=MZ+5ALQpM1xdN6vWVWptELSWGiTvwNpGT4EzGpU3mSmsEQEGKx9uty27Grs1mK7omN4gxuu8jiosRlwiF6TANhi2Zt/2pR0uhXg7JmLJwoltppbcGiscmqJFKtpEwXW9i/IGRS1OsTS4qUy0fyRvIW3/4/Hvm9WEioIGQNINcXZNYbnYFPVeaH9xXML2pcjKuLwa271EpQhz2lCUxKrQbPRI9NXhUWH+g9mXIpSzxaZwOxiOFTlR73+qdbSAk+sD Date: 26 Jun 2014 20:37:47 -0000 Message-ID: <20140626203747.45108.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <53AC57AC.2050705@bluepopcorn.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/CnX1EQUZDs0BWJ4rzx67DPCTNmY Cc: fenton@bluepopcorn.net Subject: Re: [dmarc-ietf] Draft DMARC working group charter 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, 26 Jun 2014 20:38:13 -0000 >I don't see how this can be considered out of scope without a viable >alternative. The identification of the Administrative Domain is a >normative requirement in DMARC, and if this problem is not solved, the >specification will be stuck. Having tried and failed to solve this >problem several years ago, I am convinced that this is a very difficult >problem. There's a proto-wg called dbound thinking about this topic. Marc Blanchet and I are trying to write up a problem statement before the Toronto cutoff, so we can at least try and see if there is any agreement on what problem we're trying to solve. In practice, until something better shows up everyone downloads and uses Mozilla's PSL. It's a crock, but it's what people use. R's, John From nobody Thu Jun 26 17:51:49 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BED921B3052 for ; Thu, 26 Jun 2014 17:51:47 -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 S9qc5P5GQCXp for ; Thu, 26 Jun 2014 17:51:45 -0700 (PDT) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 484E71B3064 for ; Thu, 26 Jun 2014 17:51:45 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id i8so3848015qcq.6 for ; Thu, 26 Jun 2014 17:51:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=ou8E9UeRJIhTu0rXhB3pmZkIwOuopGEyVw4EpzK7yAg=; b=zMu1ATgKRjHHLgdHyD/847QYof0F5/WCSWBbTcB67PuRMbuMMP02F9QxzGtKn1Itvf ruU1hdzOqCcOhGt5L9tT5jDSmSahXIhP4A7RHojvLGUV0RuIoorEz85XBcTHo+wfN4us E3Uj4Ku8uR8CQJFVK+qN5uBa9hWlfrUF6Z6QteAVj8QZH5L++Un93Xl+VOLUlwHe8NpR i1ZbfoKMgTl/7nwbUIsJxH5puElBtW6nNCGdj3w2Fv4G+SaEKR4QaFiwN2frRxSBi91z YhOgYWh8XxGIrgyARdYybeD3/We6gtJvrNe7XwihsAGMjjLt4z/tUUWaI0ScfqHxs+3t /fkA== X-Received: by 10.224.128.193 with SMTP id l1mr27529686qas.91.1403830304300; Thu, 26 Jun 2014 17:51:44 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id 72sm5258323qgt.1.2014.06.26.17.51.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Jun 2014 17:51:44 -0700 (PDT) From: Douglas Otis Content-Type: multipart/alternative; boundary="Apple-Mail=_5E0D003C-230D-4A96-AEAE-B9F58AFB2198" Message-Id: <47E1721F-14A6-4FFB-B207-9E65EB99A857@gmail.com> Date: Thu, 26 Jun 2014 17:51:42 -0700 To: DMARC Discussion Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/Vn7wm6DHBRNa9psmTobnnvg7ops Subject: [dmarc-ietf] DMARC Charter 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, 27 Jun 2014 00:51:47 -0000 --Apple-Mail=_5E0D003C-230D-4A96-AEAE-B9F58AFB2198 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear DMARC discussion, It seems the proposed charter omitted considerations of a federation = concept much like that of XMPP or single-sign-on but with one authority = regarding abuse. A federation concept can offer an effective mitigation = strategy for dealing with alignment issues. Methods to deal with spam = are ineffective in this space so new tools must be considered.=20 There can be only one authority regarding abuse of the =46rom header = field, the DMARC domain. Concisely expressing this authority will inevitably be the price paid = for continued acceptance of domain specific alignment policy assertions. = As such, these assertions must avoid the disruption of legitimate (not = as currently defined by DMARC) messages, but as eventually determined = upon review by the DMARC domain. =20 DMARC needs to accommodate a broad spectrum of use while avoiding easily = gamed methods. Immediate elements likely needed might be to include a form sent the = DMARC feedback requesting that a domain be informally federated. This = might include details regarding the list of elements supported by the = domain. Any one interested in being a co-author? Other issues might include: DMARC based acceptance based on an extended definition. Federation request forms detailing adoption of the various = authentication strategies. (not just DKIM or SPF) Tracking federated domains to retain trust with follow on conditions = imposed when abuse is detected. The following is a draft outlining this missing concept. http://tools.ietf.org/html/draft-otis-tpa-label-04 We hope to find a large ISP willing to work with us at establishing a = large scale working prototype. Regards, Douglas Otis =20 =20 --Apple-Mail=_5E0D003C-230D-4A96-AEAE-B9F58AFB2198 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Dear DMARC discussion,

It = seems the proposed charter omitted considerations of a federation = concept much like that of XMPP or single-sign-on but with one authority = regarding abuse.  A federation concept can offer an effective = mitigation strategy for dealing with alignment issues.  Methods to = deal with spam are ineffective in this space so new tools must be = considered. 

There can be only one authority = regarding abuse of the =46rom header field, the DMARC = domain.

Concisely expressing this authority will = inevitably be the price paid for continued acceptance of domain specific = alignment policy assertions.  As such, these assertions must avoid = the disruption of legitimate (not as currently defined by DMARC) = messages, but as eventually determined upon review by the DMARC domain. =  

DMARC needs to accommodate a broad = spectrum of use while avoiding easily gamed = methods.

Immediate elements likely needed might = be to include a form sent the DMARC feedback requesting that a domain be = informally federated.  This might include details regarding the = list of elements supported by the domain.  Any one interested in = being a co-author?

Other issues might = include:

DMARC based acceptance based on an = extended definition.

Federation request forms = detailing adoption of the various authentication strategies. (not just = DKIM or SPF)

Tracking federated domains to = retain trust with follow on conditions imposed when abuse is = detected.

The following is a draft outlining = this missing concept.
We hope to find a large ISP willing to work with us at = establishing a large scale working = prototype.

Regards,
Douglas = Otis



  

 


= --Apple-Mail=_5E0D003C-230D-4A96-AEAE-B9F58AFB2198-- From nobody Thu Jun 26 18:13:29 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 660761B30AF for ; Thu, 26 Jun 2014 18:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 clRWasfQ8nBE for ; Thu, 26 Jun 2014 18:13:27 -0700 (PDT) Received: from st11p02mm-asmtp001.mac.com (st11p02mm-asmtp001.mac.com [17.172.220.236]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 119FF1B30A5 for ; Thu, 26 Jun 2014 18:13:25 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [192.168.1.2] (246.sub-70-208-67.myvzw.com [70.208.67.246]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0N7S005OIZE73V50@st11p02mm-asmtp001.mac.com> for dmarc@ietf.org; Fri, 27 Jun 2014 01:13:21 +0000 (GMT) From: Chris Meidinger Message-id: <8E79C75F-3021-42E2-B975-443DBE2F5883@me.com> Date: Thu, 26 Jun 2014 21:13:17 -0400 To: dmarc@ietf.org X-Mailer: Apple Mail (2.1878.2) X-MANTSH: 1TEIXWV4bG1oaGkdHB0lGUkdDRl5PWBoaHxEKTEMXGx0EGx0YBBIZBBscEBseGh8 aEQpYTRdLEQptfhcaEQpMWRcbGhsbEQpZSRcRClleF2hueREKQ04XSxsbGmJCHx1SHhN9GXhzB x94GhsbGWYYEQpFQxcWEm8dE2kdH2wHGRoYGwceGG8YB2gTHR8HHh4ZbmhvGGwfEhIZakdPBEl FRxQRClhcFxkEGgQbHgdNThwTGhodEwUbHQQbHRgEEhkEGxwQGx4aHxsRCl5ZF2EeR0RnEQpDW hcdGgQYGhIEHB0EGB4cEQpCRRdsektpYmQZc0xjExEKQk4XbHBgeUAdYlJpGmIRCkJMF25FXGh aTW0fa2V+EQpCbBdjeQFJX2xBGVBzaBEKQkAXYAVMWF0dQ0EcTkARCkJYF2cTeWFgQltze29oE QpwaBdof0NFGnlYWxhdUhEKcGgXaU54f1tIQW5uWkERCnBoF2FEZ29ETBlSGlthEQpwaBdgU0V kYEJ7YXx8GhEKcGgXbH8fZ2tofXp6QEYRCnBsF21JAWV4Q3tbTkUSEQ== X-CLX-Spam: false X-CLX-Score: 1011 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.14,0.0.0000 definitions=2014-06-26_07:2014-06-26,2014-06-26,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406270012 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/g9fygNCL5pB7DzVthWlTzBPmWYk Subject: [dmarc-ietf] DMARC & Lists - Minimal Change Set 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, 27 Jun 2014 01:13:28 -0000 Folks, I've been thinking about this for a while, as I know many of you have. Obviously things have to change to some degree in order for domain owners and large operators to protect their email channels with DMARC and also allow list operators to remail their messages. There are a couple of thoughts I want to share with you and get some feedback on in terms of the minimum viable change set. DMARC and traditional mailing lists don't play nice for two reasons: the subject is modified to add a prefix, which invalidates the DKIM signature, and the body is modified to add a footer, which again invalidates the DKIM signature. I find the former relatively critical - I get value from the modified subjects on all of my listmail. I do not personally find the latter particularly valuable, the footer is not useful to me personally. Regardless of whether a footer is desirable, it is easily configurable and list operators that want to avoid breaking DKIM/failing DMARC could omit it - particularly if that were all they had to do. As far as the subject, I have been wondering whether not signing the Subject: header would be an option for large ISP's and large DMARC senders. It would increase the threat space by allowing replay of legitimate messages with weaponized subjects, but a) that's what everyone was able to do in the pre-DMARC days anyway and b) I'm not certain how real the threat is of someone clicking a link in the subject, where HTML etc are not viable to disguise a URL and the body is not modifiable to induce a click on the link in the subject header. So two questions to the group: 1: Regardless of whether it has simply always been that way, could list operators forego modifying message bodies by adding footers? 2: How real is the threat space of a modified subject? Would it be acceptable to allow bizarre subjects attached to otherwise intact and signed messages to pass DKIM and DMARC in the name of interoperability? Looking forward to your thoughts, Chris From nobody Thu Jun 26 18:25:06 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE2D1B30BC for ; Thu, 26 Jun 2014 18:25:04 -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 0PuPX_yau3-8 for ; Thu, 26 Jun 2014 18:25:03 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02DEA1B30BB for ; Thu, 26 Jun 2014 18:25:02 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id et14so3919887pad.27 for ; Thu, 26 Jun 2014 18:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=g4yTqFrIxFNVQSKnYUV+NN/YXixGYCehSOZohCpSLEU=; b=aRUclz9NgQODODKWl5Cmzz34B/nVp9LP+ghJNqqz/HC4ip02EhRO8PP11MVUgHiQWe gTxwXA4kuIby9gt3EY8NgfFkFGM9QKYMkXtMlBZIGoK4vC4ub2nGzW3uA598ZDpa04jH 4ISGU5OY3Pu3LQjPkPhjQiAIWg9I0/O8H/9j4+hNBKqEJ2lCe46lxsrago0NclPxdrpr mo42SzwI1a5Ls7XcgQy8tQCoy54mLgW4hLTYfRkGB5Ebf3t60y8nJcrRt4J5hi7PKL9d MTJRE+SkY482cRRkFPGQMo3J4ts77GGkvDBfdIpLPXtdj7CZ5CceCUo8wmQkAX+0KHfl 1PZQ== X-Received: by 10.68.211.233 with SMTP id nf9mr26293568pbc.29.1403832302612; Thu, 26 Jun 2014 18:25:02 -0700 (PDT) Received: from ?IPv6:2601:9:7680:203:ddba:86d2:c806:c633? ([2601:9:7680:203:ddba:86d2:c806:c633]) by mx.google.com with ESMTPSA id gi1sm11978800pbd.15.2014.06.26.18.25.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Jun 2014 18:25:02 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: <8E79C75F-3021-42E2-B975-443DBE2F5883@me.com> Date: Thu, 26 Jun 2014 18:24:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <328C9612-D029-4F3D-9534-474456760C63@gmail.com> References: <8E79C75F-3021-42E2-B975-443DBE2F5883@me.com> To: Chris Meidinger X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/opm6HB2yJ8NR3JfvVDtE6kw7xzY Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC & Lists - Minimal Change Set 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, 27 Jun 2014 01:25:04 -0000 On Jun 26, 2014, at 6:13 PM, Chris Meidinger = wrote: > Folks, >=20 > I've been thinking about this for a while, as I know many of you have. = Obviously things have to change to some degree in order for domain = owners and large operators to protect their email channels with DMARC = and also allow list operators to remail their messages. There are a = couple of thoughts I want to share with you and get some feedback on in = terms of the minimum viable change set. >=20 > DMARC and traditional mailing lists don't play nice for two reasons: = the subject is modified to add a prefix, which invalidates the DKIM = signature, and the body is modified to add a footer, which again = invalidates the DKIM signature. I find the former relatively critical - = I get value from the modified subjects on all of my listmail. I do not = personally find the latter particularly valuable, the footer is not = useful to me personally. Regardless of whether a footer is desirable, it = is easily configurable and list operators that want to avoid breaking = DKIM/failing DMARC could omit it - particularly if that were all they = had to do. >=20 > As far as the subject, I have been wondering whether not signing the = Subject: header would be an option for large ISP's and large DMARC = senders. It would increase the threat space by allowing replay of = legitimate messages with weaponized subjects, but a) that's what = everyone was able to do in the pre-DMARC days anyway and b) I'm not = certain how real the threat is of someone clicking a link in the = subject, where HTML etc are not viable to disguise a URL and the body is = not modifiable to induce a click on the link in the subject header.=20 >=20 > So two questions to the group: >=20 > 1: Regardless of whether it has simply always been that way, could = list operators forego modifying message bodies by adding footers? >=20 > 2: How real is the threat space of a modified subject? Would it be = acceptable to allow bizarre subjects attached to otherwise intact and = signed messages to pass DKIM and DMARC in the name of interoperability? >=20 > Looking forward to your thoughts, Dear Chris, We have been ask to focus on Charter related issues.=20 The subject can include URLs that get translated into potentially = malicious links. There is still the Intuit issue where a Sender signs the message. All of these issues and more eventually relate to exceptions that a = DMARC domain should be able to accommodate... Regards, Douglas Otis= From nobody Thu Jun 26 18:54:21 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F751B30D9 for ; Thu, 26 Jun 2014 18:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.762 X-Spam-Level: X-Spam-Status: No, score=0.762 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 KwqhKvV25zyA for ; Thu, 26 Jun 2014 18:54:18 -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 B45691B30D6 for ; Thu, 26 Jun 2014 18:54:17 -0700 (PDT) Received: (qmail 70246 invoked from network); 27 Jun 2014 01:54:16 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 27 Jun 2014 01:54:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=b407.53accec8.k1406; i=johnl@user.iecc.com; bh=XQ5xhNcats0lx+gAr1XLUW8h0bnADEK/A7Emc0jOCiU=; b=N6yEO+cjQGPubIbUBQpYA+p34GWumC2cDmU65JpMuddiT7Gc9taHsG9N8llnBOywMoV1sTSS7bvMYoiRv9CGVJx78/B4Mnwzo7797Noh2wSmWx1HdPMI288VE9OhPk0oq034l4AGvtyXwPOSelkvyxlvOVlYM7yIKC1b6TBcyaBDQjKQsWyDW0ABhre06M2cpSx8KvqiaU3LfHooT8aH912JDTrqp3FNjkugKLx07qPoM1aJjJ4xXh/XrT6Azay9 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=b407.53accec8.k1406; olt=johnl@user.iecc.com; bh=XQ5xhNcats0lx+gAr1XLUW8h0bnADEK/A7Emc0jOCiU=; b=SqZxHapFoKWquw35UX2g3nN9pgkAqT2/7ZFB29rnp1PAWZRBvj4Uq42QxLa2V2KklkYG2e9MbOv2FX7p97SUTjUXKYlucFgFfE5PliuG0r74tepaoRvJ85/pKLhp/5yi5R8m6/aKFae4JrM7M752YV/HI1dTjoQt22awE4ua69W+SCQIxW5SBEfXGQE0l3VHE6xgxmOXsYv2sVXk5BCwUPYLaVgxNOa1jMHbiVOQrYFEvdZZT+v4bL+DFhuTfLr1 Date: 27 Jun 2014 01:53:54 -0000 Message-ID: <20140627015354.46086.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <8E79C75F-3021-42E2-B975-443DBE2F5883@me.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/-p4xDuZRsdaUil4Nymn0DBo8PDg Cc: chrismeidinger@me.com Subject: Re: [dmarc-ietf] DMARC & Lists - Minimal Change Set 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, 27 Jun 2014 01:54:19 -0000 >DMARC and traditional mailing lists don't play nice for two reasons: the subject is modified to add a prefix, >which invalidates the DKIM signature, and the body is modified to add a footer, which again invalidates the DKIM >signature. It's more than that. Lists do all sorts of other stuff, from adding body headers to reordering, stripping, or flattening attachments. When we were doing DKIM we spent a lot of time trying to figure out whether there was a way to make signatures that would survive mailing list modifications with little success. The l= option was intended to allow lists to add footers, but I don't know of anyone who uses it. To answer your specific question, I don't think modified subjects are a huge threat, but the subject line isn't the problem. R's, John From nobody Thu Jun 26 19:00:17 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CE61B2EB3 for ; Thu, 26 Jun 2014 19:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 C9rhWaMzjTS8 for ; Thu, 26 Jun 2014 19:00:12 -0700 (PDT) Received: from st11p02mm-asmtp002.mac.com (st11p02mm-asmtp002.mac.com [17.172.220.237]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8095B1B30DE for ; Thu, 26 Jun 2014 19:00:11 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [192.168.1.2] (175.sub-70-208-64.myvzw.com [70.208.64.175]) by st11p02mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0N7T009F61K5NK80@st11p02mm-asmtp002.mac.com> for dmarc@ietf.org; Fri, 27 Jun 2014 02:00:08 +0000 (GMT) From: Chris Meidinger In-reply-to: <20140627015354.46086.qmail@joyce.lan> Date: Thu, 26 Jun 2014 22:00:03 -0400 Message-id: <59E906EA-51F9-41CF-B23E-CEEE804C7960@me.com> References: <20140627015354.46086.qmail@joyce.lan> To: John Levine X-Mailer: Apple Mail (2.1878.2) X-MANTSH: 1TEIXWV4bG1oaGkdHB0lGUkdDRl5PWBoaGBEKTEMXGx0EGx0YBBIZBBscEBseGh8 aEQpYTRdLEQptfhcaEQpMWRcbGhsbEQpZSRcRClleF2huZhEKQ04XSxsbGmJCH2luGlxlGXhzB x94GhgaGhIZEQpFQxcWHxNvExocb2sHHxtsEwceG2lsB2gYGW8HaW9vbxIaHmkdExwaakdPBEl FRxQRClhcFxkEGgQbHgdNThwTGhodEwUbHQQbHRgEEhkEGxwQGx4aHxsRCl5ZF2EeRH5uEQpMR hdsa2sRCkNaFx0aBBgaEgQcHgQbHR8RCkRYFxgRCkRJFxsRCkJGF2V9e2ZtEx8TQBJvEQpCRRd sektpYmQZc0xjExEKQk4XbHBgeUAdYlJpGmIRCkJMF25FXGhaTW0fa2V+EQpCbBdjeQFJX2xBG VBzaBEKQkAXYlN7f01+YEh+eGIRCnBoF2VrG0dNQh1uS0N+EQpwaBduUHtzXhh8Z2wBZBEKcGg XbW9DeR9lQHBTZm0RCnBsF21JAWV4Q3tbTkUSEQpwTBdlcl9nXl9JSUxcSxE= X-CLX-Spam: false X-CLX-Score: 1011 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.14,0.0.0000 definitions=2014-06-27_01:2014-06-26,2014-06-27,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406270021 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/77-XSLlBRm8fDyxjpoQK1f3_IK8 Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] DMARC & Lists - Minimal Change Set 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, 27 Jun 2014 02:00:15 -0000 On Jun 26, 2014, at 21:53, John Levine wrote: > To answer your specific question, I don't think modified subjects are > a huge threat, but the subject line isn't the problem. Good input. Thanks for your thoughts on subjects - I obviously agree, but am very interested in outside input. That said, would moving the goalposts to lists passing the body exactly intact as it was received (yes, it would take effort, but I'm talking about the goal line) and /not/ making any other changes get us closer to DMARC and lists happily co-existing? That appears to me to be a hell of a lot easier than many of the other things in discussion. Chris From nobody Fri Jun 27 01:09:40 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264A31ACAD6 for ; Fri, 27 Jun 2014 01:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 WTswxLPBR745 for ; Fri, 27 Jun 2014 01:09:34 -0700 (PDT) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CED2B1A02E3 for ; Fri, 27 Jun 2014 01:09:33 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id hy4so4764298vcb.34 for ; Fri, 27 Jun 2014 01:09:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4asCVrJJ7yZTCrNSLmvmMNyyApO+c/vdi0zJv+f7/+4=; b=xE2ZEQsaf2IW/VeKa/QxVAoXLl+NlrTG20xCNiTjG8uWczBcDFHCBCApoFxHQkE40b VnFei1O8s+MS/WTGf+1xhKJau5dUZMNiVK3g7G2W2XpPSDB0mQVFDF2b8lANQbQesk3T 7QUpkZj2XtONgqueLi0wKrxZgkyPsba/26hv8BHMCbJlZ3eU+xGa7iso3OPElwpUy7Fn rQOe292cvdsNP1V7/KsJM1P/5o0wjeKfikpYEno72GYsQew+IVHTNfxnr8LW5VlfXXtc gxjVJxC3U01s3oZV75KyQn0OMgcQ7m/dJghTGg7MqJRXPMgtaWT4OekZ6smuFRdrZUYS ruow== MIME-Version: 1.0 X-Received: by 10.52.135.7 with SMTP id po7mr1676863vdb.50.1403856572998; Fri, 27 Jun 2014 01:09:32 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.106.73 with HTTP; Fri, 27 Jun 2014 01:09:32 -0700 (PDT) In-Reply-To: <53AC57AC.2050705@bluepopcorn.net> References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net> <6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> <53AC57AC.2050705@bluepopcorn.net> Date: Fri, 27 Jun 2014 04:09:32 -0400 X-Google-Sender-Auth: NMYyDbQb08W95HdfiwpbJxhiQ68 Message-ID: From: Barry Leiba To: Jim Fenton Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/mZ1mncp-p0gAVQNxZlJ0092OAmc Cc: "dmarc@ietf.org" Subject: Re: [dmarc-ietf] ***SPAM*** 7.348 (5) Re: Re: Draft DMARC working group charter 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, 27 Jun 2014 08:09:36 -0000 > [removed the SPAM tag from subject] Which the mailing list put right back on. It seems that something in the charter text is causing that, and I've asked the Secretariat IT support to look into it. The worst part of this is that none of the charter discussion is in the archive. I have put the proposed charter in the appsawg wiki: http://trac.tools.ietf.org/wg/appsawg/trac/wiki/DMARC > I'm not sure if this belongs in the charter, but in any case I wonder if > it creates market confusion to pursue both an Informational Independent > Submission and a Standards-track working group RFC. Are there other > examples of where that has been done? As a counter-example, note that > the publication of DomainKeys (RFC 4870) was delayed until DKIM > published to avoid confusion, and there the names were somewhat different. HTTP 1.0 (RFC 1945) and OAUTH 1.0 (RFC 5849), to name two. Barry From nobody Fri Jun 27 10:35:44 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5313A1A03B4 for ; Fri, 27 Jun 2014 10:35: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 Y6SLIWN8hYeD for ; Fri, 27 Jun 2014 10:35:41 -0700 (PDT) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A40A41A037F for ; Fri, 27 Jun 2014 10:35:41 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id uo5so4817886pbc.12 for ; Fri, 27 Jun 2014 10:35:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=epPL8R13yy03G4Zilxa/FOYjuI4b/fZy/YSr5zEtRqY=; b=iESGy8jVmdnFkQiUSQtjPhdzqceJ9dvoco2OGuwCkAK55709NIIE3F+/MSbhZ6u2Qk My8C+VvPC1GVR5XaQET5EZQYjcxP8v7R5ZJJkN1lxrXplzJfDourIrULWQisR5lt5IPh loz0li/eM4rLacoBgimNlOcpDB6CZCCXQe/b1fcHOrUGUleHy+P2gz4oBZhoswP6/l3S JMqVU31EJxJ4CtdY5suuBMIrThfnjFnzdZszux0ZRqlOfvcsKlE89smJh3VDEkhEYpGI Ejs5qHHQQdWheA6N6ZfMO/4IkFioDTdkhZbWb4N4rxv2b9zOspYuYjIRjJ6CXjk087xr QAzw== X-Received: by 10.66.192.104 with SMTP id hf8mr33056255pac.13.1403890541301; Fri, 27 Jun 2014 10:35:41 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id be7sm54497644pad.9.2014.06.27.10.35.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Jun 2014 10:35:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: Date: Fri, 27 Jun 2014 10:35:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net> <6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> <53AC57AC.2050705@bluepopcorn.net> To: Barry Leiba X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/liEK-mnIm3iPPufXcw8T6Ir6eFE Cc: Jim Fenton , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] ***SPAM*** 7.348 (5) Re: Re: Draft DMARC working group charter 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, 27 Jun 2014 17:35:43 -0000 On Jun 27, 2014, at 1:09 AM, Barry Leiba = wrote: >> [removed the SPAM tag from subject] >=20 > Which the mailing list put right back on. It seems that something in > the charter text is causing that, and I've asked the Secretariat IT > support to look into it. The worst part of this is that none of the > charter discussion is in the archive. >=20 > I have put the proposed charter in the appsawg wiki: > http://trac.tools.ietf.org/wg/appsawg/trac/wiki/DMARC >=20 >> I'm not sure if this belongs in the charter, but in any case I wonder = if >> it creates market confusion to pursue both an Informational = Independent >> Submission and a Standards-track working group RFC. Are there other >> examples of where that has been done? As a counter-example, note that >> the publication of DomainKeys (RFC 4870) was delayed until DKIM >> published to avoid confusion, and there the names were somewhat = different. >=20 > HTTP 1.0 (RFC 1945) and OAUTH 1.0 (RFC 5849), to name two. Dear Barry, This type of problem is emblematic of anti-spam and also why anti-spam = has not flatten the attack surface enough to be a meaningful deterrent = for the problem DMARC addresses. DMARC constrains "trust" to validated = elements from known sources as a tremendous benefit to recipients. Placing an expiry on trusted elements that can be replayed with = indeterminate content from unvalidated sources takes this into the = statistical area best described as anti-spam. In effect, this says = we'll make this hard by asking spammers to jump this high beyond the = bayesian mean. After deploying such schemes, this then becomes the well = practiced height and we are back to where we started. =20 Regards, Douglas Otis From nobody Fri Jun 27 12:26:32 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B461A002B for ; Fri, 27 Jun 2014 12:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, 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 E0-ctK5_dTBm for ; Fri, 27 Jun 2014 12:26:29 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B33581A0024 for ; Fri, 27 Jun 2014 12:26:29 -0700 (PDT) Received: from splunge.local (c-50-136-244-117.hsd1.ca.comcast.net [50.136.244.117]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id s5RJQREr018587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 27 Jun 2014 12:26:29 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1403897189; bh=9SmNDfH0RFEg18MoLLJ5NrZWcEpxuWwljtWWdZFNbU4=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=NJX1dlLrSa/zsQZJbI/h7r5/qX8HF8lPBz53JDifFGpDR+GuBIRdE2pfGFkSv72bH wmSMg6JU1pMGWrJS2sJaMWLJxJgQqGCDx2kIH9dBMFVLOTUqS6Wgq+1OEtY1xEwHjT S8xK8XXrb1LP8gSjnYJIppG7lExPPFry7mDyESKI= Message-ID: <53ADC563.10101@bluepopcorn.net> Date: Fri, 27 Jun 2014 12:26:27 -0700 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Levine , dmarc@ietf.org References: <20140626203747.45108.qmail@joyce.lan> In-Reply-To: <20140626203747.45108.qmail@joyce.lan> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/O1KNN7E5W6fI6teffC4lDBZT2GM Subject: Re: [dmarc-ietf] Draft DMARC working group charter 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, 27 Jun 2014 19:26:31 -0000 On 6/26/14 1:37 PM, John Levine wrote: >> I don't see how this can be considered out of scope without a viable >> alternative. The identification of the Administrative Domain is a >> normative requirement in DMARC, and if this problem is not solved, the >> specification will be stuck. Having tried and failed to solve this >> problem several years ago, I am convinced that this is a very difficult >> problem. > There's a proto-wg called dbound thinking about this topic. Marc > Blanchet and I are trying to write up a problem statement before the > Toronto cutoff, so we can at least try and see if there is any > agreement on what problem we're trying to solve. That's good acknowledgment of the problem, and I agree with Dave Crocker's comment that this problem is bigger than this WG. > > In practice, until something better shows up everyone downloads and > uses Mozilla's PSL. It's a crock, but it's what people use. But I can't see IETF publishing a standards-track specification that uses the PSL, or anything like that. So given that the dbound effort is behind this one, I'm concerned that this WG would face a very long normative reference dependency wait before it could publish anything standards-track. -Jim From nobody Fri Jun 27 12:59:51 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0768C1A00A5 for ; Fri, 27 Jun 2014 12:59:45 -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 vNbQyS88LQDB for ; Fri, 27 Jun 2014 12:59:44 -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 D94021A009C for ; Fri, 27 Jun 2014 12:59:43 -0700 (PDT) Received: (qmail 39440 invoked from network); 27 Jun 2014 19:59: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:cleverness; s=9a0f.53adcd2c.k1406; bh=e+hKwUN6qoKzqlsJOIYl5828NNsnVOqEoK1QHN4Ti8w=; b=AtpOCVmpUuBqXtJubNjnZjuR3WHa+zl3IF4tSndhuDumy8E/08DtrO/N9X/gteFeVS8eAxTB9cXZKd0v3yCLCJ67Zgcy4Q1B3z+WtcZhQOrYlBNwh3N8q9+tjJUwVXspspzZeYQgzcODcgVvZ+n0HgQ0AnCvw7hcA2F9K+anqFzTH/wV4AJ9c38GSwIHGHirNXyuOvNYT6piFmL6xtnXhTQk84HD0HZsY4Och2L+T71WfRKwqGAuBvCou915vWTO 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:cleverness; s=9a0f.53adcd2c.k1406; bh=e+hKwUN6qoKzqlsJOIYl5828NNsnVOqEoK1QHN4Ti8w=; b=wW4hIS2FrcJl9nBQUX1vnGgivNsdewIcgnOU9rUe2FEYKO7sIC6HX3v5ad3QvOnK7ec/Ps5p3ryVRHN8tGTodU283qpS24wwWvkUuKyJ9Z7Vuw+dmvnJm73i9FkNptyItjnJGZqrL/9oq+mjfNYcBdtRyVibrk7Z50D/ngaHFgZtuOlwXz4KK01mRH/4lgGLIIK8LdCC7sCwG3W5lb9dBldoAc+d9cSjoYt8FfLTHuTuC6RsQI/9HmyaSGzSvlWd 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; 27 Jun 2014 19:59:40 -0000 Date: 27 Jun 2014 15:59:38 -0400 Message-ID: From: "John R Levine" To: "Jim Fenton" In-Reply-To: <53ADC563.10101@bluepopcorn.net> References: <20140626203747.45108.qmail@joyce.lan> <53ADC563.10101@bluepopcorn.net> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/0BSP4rEM2u24950UCtJuVmOAW1k Cc: dmarc@ietf.org Subject: Re: [dmarc-ietf] Draft DMARC working group charter 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, 27 Jun 2014 19:59:45 -0000 >> In practice, until something better shows up everyone downloads and >> uses Mozilla's PSL. It's a crock, but it's what people use. > > But I can't see IETF publishing a standards-track specification that > uses the PSL, or anything like that. The current DMARC spec just waves its hands and says use something like the PSL without specifically pointing at the PSL. We've done worse. Having said that, it is not my impression that producing a standards track DMARC-bis is a goal of this group. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Fri Jun 27 14:38:08 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 283321A01C7 for ; Fri, 27 Jun 2014 14:38:07 -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 cxzGpLwOhd0g for ; Fri, 27 Jun 2014 14:38:05 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4102D1A01C6 for ; Fri, 27 Jun 2014 14:38:05 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id g10so4944438pdj.0 for ; Fri, 27 Jun 2014 14:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=R4qbGNVQkZVEY4VjoUKL8HuwOGFqt3ryJoMfajkZGl4=; b=lsVAYGBmVjFbAcyr7CjwnvK6+pudLaMuGVmB4yN8B/KMVq0ewdiLbnVZ29063jaRvH VChKDibkXX57Poym4nA1D6LGthoTeoxwr+gWR3lLmZTc9qI9ARvn0N3WQ7NUydIC91NF B2xCQp/8T6i/BhfoTlxWsvbaawMiG7z/eEE1OwxHXRh7rvzbuuc/wW5dlPVIFXwIoM4G kTlg9cfilU43U6kmGLocryrwEiVU6l8LNlLuA2o+I+vq8mDd+RLS0dJAInVfY3eUuMax 9eKvnKmEsdSA5r3CyLjvLm4bjo8DpS2Bbbiu26Sa0TZVMpsCMGjl5exY3u6UML+IYLbj szKw== X-Received: by 10.66.65.169 with SMTP id y9mr33318534pas.145.1403905084935; Fri, 27 Jun 2014 14:38:04 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id xc1sm56907406pab.39.2014.06.27.14.38.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Jun 2014 14:38:04 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: Date: Fri, 27 Jun 2014 14:38:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1201473C-DCC9-4037-858A-8BE6A18D295C@gmail.com> References: <20140626203747.45108.qmail@joyce.lan> <53ADC563.10101@bluepopcorn.net> To: John R Levine X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/cQ66jyAc0P6datlzFFYkmGVZeZ0 Cc: Jim Fenton , dmarc@ietf.org Subject: Re: [dmarc-ietf] Draft DMARC working group charter 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, 27 Jun 2014 21:38:07 -0000 On Jun 27, 2014, at 12:59 PM, John R Levine wrote: >>> In practice, until something better shows up everyone downloads and >>> uses Mozilla's PSL. It's a crock, but it's what people use. >>=20 >> But I can't see IETF publishing a standards-track specification that >> uses the PSL, or anything like that. >=20 > The current DMARC spec just waves its hands and says use something = like the PSL without specifically pointing at the PSL. We've done = worse. >=20 > Having said that, it is not my impression that producing a standards = track DMARC-bis is a goal of this group. Dear John, It seems one solution for the PSL would be to cull out domains not = directly assigned by a registrar recognized by the global Internet. It = may mean some domain holders will then be unable to control their = domain. They never did. Such a change may motivate those holders to = seek a safer name basis. Regards, Douglas Otis =20= From nobody Fri Jun 27 15:55:51 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4D31A0217 for ; Fri, 27 Jun 2014 15:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=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 3A60BenLX5eh for ; Fri, 27 Jun 2014 15:55:48 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC38F1A0213 for ; Fri, 27 Jun 2014 15:55:48 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id il7so5688040vcb.41 for ; Fri, 27 Jun 2014 15:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=EIi+7ofJihtV+jS+ZQVAUWTATOqFnCOnWDkuMNv0CYc=; b=YgNmKEeXW1QhX+J5atKF4GB6fULEMpBC9mjiBXyrG+hZckl7/VQGFh/Vn3rMIfFtiU FI8corfyY56VK5Pvuwm+wMcz4uYfBAhmHKVK2NLtfK9G6V3sqiUTWoeqXK3NBmJ0EfRp xSR9c4OhwPLWOG2awSEmfhPB1KYlUixKCv218+1FyY+Pi6v7VT2D/2lFwxCQSq19T3+T sB/tDLfBa0C8OLHCE/BS7Yco7QfZAVVMAN+KJuqLlorVnWM58nlfuKJtKJeBLHQjJqi8 UhUQ5jaCoKpCPhIk9ccgg3oTJU0dhnBt/8XMk4Hg1X0xTtQyDlpKsnEk6ur3EJN/JOp6 VR+A== MIME-Version: 1.0 X-Received: by 10.58.150.100 with SMTP id uh4mr22879232veb.30.1403909747672; Fri, 27 Jun 2014 15:55:47 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.106.73 with HTTP; Fri, 27 Jun 2014 15:55:47 -0700 (PDT) Date: Fri, 27 Jun 2014 18:55:47 -0400 X-Google-Sender-Auth: u1q8EgwjXBV7-LN22VOPwj2DYOw Message-ID: From: Barry Leiba To: "dmarc@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/eZEB1LrAbJwpOfiK0kkpbE1jHa8 Subject: [dmarc-ietf] Charter discussion being marked as spam 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, 27 Jun 2014 22:55:50 -0000 >> [removed the SPAM tag from subject] > > Which the mailing list put right back on. It seems that something in > the charter text is causing that, and I've asked the Secretariat IT > support to look into it. The worst part of this is that none of the > charter discussion is in the archive. > > I have put the proposed charter in the appsawg wiki: > http://trac.tools.ietf.org/wg/appsawg/trac/wiki/DMARC The Secretariat gave their usual quick response (I just wasn't able to respond here as quickly): it seems that there's a .co.uk domain name used as an example in the charter text, that domain name is on a spam block list, and that caused a high spam score. That particular domain name has had its spamminess score reduced, so the problem should stop (though I'm not trusting it here, obviously). I've suggested that this represents a faulty spam rule: a blacklisted domain name in an address field should cause a high spam score, but it shouldn't do so when we're talking about the domain in the body of the message. I've also asked whether it's possible to get the missing messages put back into the archive. Meanwhile, discussions that include that part of the charter text shouldn't cause a problem any more. And just in case, it might not be a bad idea just to redact the domain name in question when you include the charter text. More when I know more. From nobody Fri Jun 27 16:17:36 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8371A01D4 for ; Fri, 27 Jun 2014 16:17:33 -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 DDjqTdJTAWx4 for ; Fri, 27 Jun 2014 16:17:32 -0700 (PDT) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2E271A01CD for ; Fri, 27 Jun 2014 16:17:31 -0700 (PDT) Received: by mail-yh0-f46.google.com with SMTP id c41so3514415yho.5 for ; Fri, 27 Jun 2014 16:17:31 -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=5IwhyD4i1UMcXySYgZzC141xeWyM2GX/PwikEXmJTJQ=; b=S/yOg7I80ieGtrUm42UxQbIaucwHto3Ek0Tpicqmu51QEn/Ifr9aHF8flday3TfWcc qFQH0xkfygoC6sqjU9WJUsv2sf3gOjWHpvzLC9ey7Ma+w0azFRN9yrZ/Iecv9jymmuHz HepVkIlLOyG10prLC5OLEPeUaCBfNNe3rQEgNz0+WTVDfv4CwzxPro21Rw1UsdkEoPzV 5wOoSyF8wBI0/VXFzG3Zp9pKqBBwE8TSVXPqQpZxjfOhoPZt3o/bR1umDHC9Mp6lfday GPLAWIjxclci3JjZJ8gjwVBwf0pmjrJjUQ6exOB4lvE5mb7LB2HAi9r2J7jPRNeLsVLL DeMQ== X-Received: by 10.236.10.6 with SMTP id 6mr36624302yhu.23.1403911051313; Fri, 27 Jun 2014 16:17:31 -0700 (PDT) Received: from [192.168.2.129] (adsl-108-93-152-147.dsl.pltn13.sbcglobal.net. [108.93.152.147]) by mx.google.com with ESMTPSA id h94sm6198843yhq.35.2014.06.27.16.17.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Jun 2014 16:17:30 -0700 (PDT) Message-ID: <53ADFB3A.2020105@gmail.com> Date: Fri, 27 Jun 2014 16:16:10 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Barry Leiba , "dmarc@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/B-vQKBu15JlxM8kexGYBBHxY7eI Subject: Re: [dmarc-ietf] Charter discussion being marked as spam 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, 27 Jun 2014 23:17:33 -0000 On 6/27/2014 3:55 PM, Barry Leiba wrote: > it seems that there's a .co.uk domain name > used as an example in the charter text, that domain name is on a spam > block list, and that caused a high spam score. What is especially frustrating is that it's a formally-legal/appropriate example name. > I've suggested that this represents a faulty spam rule: a blacklisted > domain name in an address field should cause a high spam score, but it > shouldn't do so when we're talking about the domain in the body of the > message. Lots of spam can be detected by virtue of specific URLs that occur in the body. So it's entirely reasonable that it was looking there. That said, yes, the ruleset for IETF mailing lists probably needs tweaking, given the unusual nature of our content, with respect to spam/anti-spam work. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Jun 27 17:06:12 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D30F1A024D for ; Fri, 27 Jun 2014 17:06:10 -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_40=-0.001, FREEMAIL_FROM=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 325DEoVnpt8z for ; Fri, 27 Jun 2014 17:06:09 -0700 (PDT) Received: from BLU004-OMC3S3.hotmail.com (blu004-omc3s3.hotmail.com [65.55.116.78]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B84191A0247 for ; Fri, 27 Jun 2014 17:06:08 -0700 (PDT) Received: from BLU436-SMTP240 ([65.55.116.72]) by BLU004-OMC3S3.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712); Fri, 27 Jun 2014 17:06:07 -0700 X-TMN: [Itr2aSJCQx5dOkam+6sIRI9lRWaXynfX] X-Originating-Email: [jtrentadams@live.com] Message-ID: Received: from jtrentadams-isoc.local ([67.166.0.110]) by BLU436-SMTP240.smtp.hotmail.com over TLS secured channel with Microsoft SMTPSVC(8.0.9200.16384); Fri, 27 Jun 2014 17:06:07 -0700 Date: Fri, 27 Jun 2014 18:06:06 -0600 From: "J. Trent Adams" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dmarc@ietf.org References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net> <6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> <87r42izsqd.fsf@uwakimon.sk.tsukuba.ac.jp> <53A56974.8020200@gmail.com> <87lhsqz890.fsf@uwakimon.sk.tsukuba.ac.jp> <53A84A40.4090008@gmail.com> <87egycyhzp.fsf@uwakimon.sk.tsukuba.ac.jp> <53AB1DD0.30901@gmail.com> <877g44xst0.fsf@uwakimon.sk.tsukuba.ac.jp> In-Reply-To: <877g44xst0.fsf@uwakimon.sk.tsukuba.ac.jp> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jun 2014 00:06:07.0551 (UTC) FILETIME=[C28E14F0:01CF9264] Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/IHMx5vdvnZTr2119vk1S8BOs498 Subject: Re: [dmarc-ietf] Draft DMARC working group charter 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, 28 Jun 2014 00:06:10 -0000 IMO, either term will do fine in this context. If one or the other results in a prolonged discussion within the WG that hinges on this that the Chair can't resolve, we've got bigger issues. Let's not let this issue wrap around the axle and slow things down. My $0.02, Trent On 6/25/14 9:18 PM, Stephen J. Turnbull wrote: > Dave Crocker writes: > > > Well, the language I offered was also produced from pickiness. In > > reaction to a possible misunderstanding of the earlier draft > > charter text. > > "Incremental version" is not a "term of art", then? (That occurred to > me after hitting send.) > > Surely this terminological problem (foreseeing updates to another WG's > -- or external body's -- in-progress specification, but not stepping > on their toes) has been encountered by working groups before? > > (If nobody has examples off hand, I'll go research other charters for > similar language, no reply necessary.) > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc From nobody Fri Jun 27 17:07:46 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A57731A024B for ; Fri, 27 Jun 2014 17:07:33 -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 7BlTdRCqpD-m for ; Fri, 27 Jun 2014 17:07:31 -0700 (PDT) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A7BD1A0247 for ; Fri, 27 Jun 2014 17:07:31 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id fp1so5012795pdb.25 for ; Fri, 27 Jun 2014 17:07:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6o4EEvecsYUOVCn1mg+5/5x59gaJ4rhgdreEv+XW5DM=; b=qa7kLJPvuGJ/X4MJbs/YxBGLyLGmuA+ZDNtPCGZOpky8BYA9u11IqOBIuPgkbQDB2q CWs9PxljxvUdt6/CwJc9AuQA5Vxjnh8N2ss4yhv/hUKmbPIo+5AkBlvGCWg11XjMDZyy Qo/U6iubjjlOs7XW3c3ypfZR/BZZoWeUTeL/9AeAJ8qzmKEtRhWAgABgXHnqlDd6YueE rQKYH87JL81ra1YGh1WQ54RgeLnz48/lGQ8shdPnIa72CidE26AS6q8PvRMIg5NSHNPB t8TWD127OXBiTlt+YsrFX7dwk2VjPDEvbDZYZos3oKIHCm0CzL/qfHvzbx4PUZVZ84cF c4Lw== X-Received: by 10.66.227.4 with SMTP id rw4mr34991254pac.18.1403914049755; Fri, 27 Jun 2014 17:07:29 -0700 (PDT) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id vy8sm2999203pbc.84.2014.06.27.17.07.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Jun 2014 17:07:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Douglas Otis In-Reply-To: <53ADFB3A.2020105@gmail.com> Date: Fri, 27 Jun 2014 17:07:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7504030D-601E-4809-8E8E-927FEE495FCD@gmail.com> References: <53ADFB3A.2020105@gmail.com> To: Dave Crocker X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/5C44okt3OMxN5ap-xE6JHdMF4Hw Cc: "dmarc@ietf.org" , Barry Leiba Subject: Re: [dmarc-ietf] Charter discussion being marked as spam 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, 28 Jun 2014 00:07:34 -0000 On Jun 27, 2014, at 4:16 PM, Dave Crocker wrote: > On 6/27/2014 3:55 PM, Barry Leiba wrote: >> it seems that there's a .co.uk domain name >> used as an example in the charter text, that domain name is on a spam >> block list, and that caused a high spam score. >=20 > What is especially frustrating is that it's a = formally-legal/appropriate > example name. >=20 >=20 >> I've suggested that this represents a faulty spam rule: a blacklisted >> domain name in an address field should cause a high spam score, but = it >> shouldn't do so when we're talking about the domain in the body of = the >> message. >=20 > Lots of spam can be detected by virtue of specific URLs that occur in > the body. So it's entirely reasonable that it was looking there. >=20 > That said, yes, the ruleset for IETF mailing lists probably needs > tweaking, given the unusual nature of our content, with respect to > spam/anti-spam work. Dear Dave, Adjusting the spam filter is fine, but not the characterization of work = at hand. Our company has had a fair amount of experience dealing with = phishing, which DMARC helps to mitigate. In essence, this is not an = anti-spam effort. Anti-spam is ineffective at dealing with the phishing = problem which is why there is DMARC in the first place.=20 It takes little effort for a malefactor to compose a phish not detected = as spam. Anti-spam generally looks for advertising or reaching out with = a contact with related statistics identifying various campaigns. There = needs to be a mindset change about the problem, since it can't be = measured or viewed as yet another spam issue. Much greater weight must = be given to source validation. Phishing differs from the way spam is = detected, which is why DMARC offers feedback. Only the DMARC domain is = ever authoritative. They need to offer specific advice and NOT some = spam reputation service. As I said, anti-spam does not work. We have = tried and it completely failed.=20 The payoff from a successful phish can be fairly high allowing much = smaller numbers to be sent. Often the malefactors increase their = success rates by knowing more about their victim which is often not done = with most spam. If such weighing were done in this case, there should = not have been a problem indicated with the proposed charter. Perhaps = one day we will be able to eat our own dog food while using a = mailing-list. Consider what can be done with the development of an informal federation = where the =46rom starts a chain of trust. The overhead is much smaller = than most seem to imagine. As I said, we were doing this for each = message received by several very large ISPs using only modest resources. = Far less than that needed to sustain that of SPF, DKIM, or any reverse = lookup. Only those very few messages failing DMARC alignment checks = will require additional federation related info. In comparison. a piece = of cake. Regards Douglas Otis From nobody Sat Jun 28 06:41:46 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55AD01A0348 for ; Sat, 28 Jun 2014 06:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 CHAa7jDMKdJ2 for ; Sat, 28 Jun 2014 06:41:37 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30FFD1A027E for ; Sat, 28 Jun 2014 06:41:37 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id l6so5523963qcy.32 for ; Sat, 28 Jun 2014 06:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=iM1xasI3C6wp3/bvQ6u3/1CDrh+OgYNadzh2NwFhm+I=; b=kTSzvNlev/w24PDhLo0/jpgsYXTlSkXa5fURu65x9iOQZgbD6kA2fv/c4VmyRXmyhp YgnvZFum0+g/wrvG2y50man8Sw4RM5EYlQC3IjuxVmhhHL31HDKQATrRqW/GsrjfgcpU D7cVhKtNNvaIZlwf0dLZigGHfZRLJd10LM152bSGzLxF81qbiXb0Z01Ip9/0DT5jCpsv tjq4l+t7HpQqwI9HqOZL/Bi+T1BACf9r+Ilb1udgZj+vMgYly7T2jhOVBJbaNyikYBvC a8xJDDnVcs7VFWKdnKawhO8aR+dbZnuLARIEY4eAonFnQfVE8kS8gAD7VcvS+UF+EcHo GuRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=iM1xasI3C6wp3/bvQ6u3/1CDrh+OgYNadzh2NwFhm+I=; b=HcI0orPKXK35KoGWvBaPTHq5tdYfZ9QgQNmPGWJ0iHXf9o/pSf8HBoIo6YcW0+m9ju vYaRx1d+oed+Cqc9CYv/zBE3QRadG2EN8dxZ3hveOc9DGgs5qInJLvKcZg24zl5nhskx ykBwo3LjOJR74moNQSY8+7W4d7tkXyf7u7raLoNAvbzMUQEGq1b4NRb51ivqDA9JRUU3 aU7W/cIU9FlcgwzPzCSBgzGlekEd2eOvHoP+PQlqg59XHUKipK5F8mNLLbSidXobwpks S5xOYrwvJq3pJljq101q8YDtVQsB/QQo7s8g2eJbsUO9QCwM8vQNICju/k/EjA1oHPk1 +H/g== X-Gm-Message-State: ALoCoQlc2E165EXY1FikwKfhcLVQBxJFpQIpE0x0sl6GkmIqEmWTTyVqzwjT2p0SMjREIK1RL3vg X-Received: by 10.224.2.196 with SMTP id 4mr33924942qak.60.1403962896239; Sat, 28 Jun 2014 06:41:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.58.1 with HTTP; Sat, 28 Jun 2014 06:41:14 -0700 (PDT) From: Wei Chuang Date: Sat, 28 Jun 2014 06:41:14 -0700 Message-ID: To: dmarc@ietf.org, apps-discuss Content-Type: multipart/alternative; boundary=001a11c3bfdeb57cf404fce595cc Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/_soxy-2IPCbXuV5aET9z4RFnG4o Subject: [dmarc-ietf] DKIM Forwarding History (Provenance) Proposal 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, 28 Jun 2014 13:41:41 -0000 --001a11c3bfdeb57cf404fce595cc Content-Type: text/plain; charset=ISO-8859-1 We propose the following enhancement to DKIM for tracking message changes relevant to authentication as a message is forwarded and modified by mail providers, typically mailing lists. At each SMTP delivery step, starting with the original sender and through all intermediate forwarders, the message must be DKIM signed. Each intermediate forwarder then adds a diff so that the recipient can recover the message as received by that forwarder and any earlier version. This change enables the recipient to verify the authenticity of the message and allows a more accurate decision for preventing abuse. In addition, it answers the problem of handling DMARC domains relayed through mailing lists. The advantage of this is that the recipient can recover the DKIM signed and verified message as received by the intermediate mail provider by reverse patching the diff, and can repeatedly apply this as necessary to recover the message sent by the original sender. Observing all versions of messages is most useful for Spam and Phishing detection in evaluating the reputation of the message. In particular one can observe the original sender's intent, and this is useful for example to verify that the original sender meant to send along a particular mail forwarding path or mailing-list. This proposal would introduce a new MIME CONTENT-TYPE: multipart/dkim-forwarding-history that would contain the diffs. Diffs between successive versions of the message are added sequentially as subparts to dkim-forwarding-history part. Diff parts are treated as attachments so that the user doesn't get confused by the contents. This particular proposal only works with 7-bit encoding, and a future proposal will deal with 8bit and binary. This process is illustrated in the example later. Note this isn't a full proposal as we would like the concept to be considered first. If this discussion is successful, we would like to also discuss a related improvement to SPF and DMARC, as well as the binary encoding change. At the conclusion we can have a longer discussion about the details of CONTENT-TYPE: multipart/dkim-forwarding-history or write a draft that tightly specifies how this works. ===== DKIM Forwarding History illustrative example Message is generated at Mymail and sent to mailing-list Yourgroup. Yourgroup modifies the subject line to indicate to the user which mailinglist the message went through. Then it is delivered to a Forwardmail which forwards without visible modifications to its ultimate destination at recipient@dest.org. Despite the lack of visible changes, the message at Forwardmail is likely modified with at least a Received header appended. At each intermediate domain, the SMTP server takes a diff of the message as it is to be sent including any modifications, and the received version excluding the diff contents and excluding the new DKIM signature since that's computed after the diff. The diff content is appended to the any previous diff content as an attachment. All diff content resides in a multipart/dkim-forwarding-history MIME part. After that, DKIM signing is done includes the header, original body, and diffs. If there is a previous DKIM header, it is removed, so that it is clear what the ownership is. The new DKIM header is added to the message header. Here's the message content that would be seen by the user. Original message: From: sender@mymail.com To: big-mailinglist@yourgroup.com Subject: I'm testing how DKIM forwarding history versioning works. This example illustrates how using diff and patch can obtain the message versions. -Sender Yourgroup message: From: sender@mymail.com To: big-mailinglist@yourgroup.com Subject: [big-mailinglist] I'm testing how DKIM forwarding history versioning works. This example illustrates how using diff and patch can obtain the message versions. -Sender Forwardmail message: From: sender@mymail.com To: big-mailinglist@yourgroup.com Subject: [big-mailinglist] I'm testing how DKIM forwarding history versioning works. This example illustrates how using diff and patch can obtain the message versions. -Sender Here's the more detailed description with the abbreviated RFC5322 message. Original message generated at mymail.com and sent to yourgroup.com. ====== DKIM-Signature: d=mymail.com ... From: sender@mymail.com To: big-mailinglist@yourgroup.com Subject: I'm testing how DKIM forwarding history versioning works. Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit This example illustrates how using diff and patch can obtain the message versions. -Sender Yourgroup mailing list takes ownership of message and composes the following which is sent to Forwardmail. ===== DKIM-Signature: d=yourgroup.com ... From: sender@mymail.com To: big-mailinglist@yourgroup.com Subject: [big-mailinglist] I'm testing how DKIM forwarding history versioning works. Content-Type: multipart/mixed; boundary="ABC123" --ABC123 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit This example illustrates how using diff and patch can obtain the message versions. -Sender --ABC123 Content-Type: multipart/dkim-forwarding-history; boundary="DFH456" --DFH456 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="message-25june2014_1301.patch" *** original-message-25june2014_1301.txt 2014-06-26 07:21:11.472671000 -0700 --- yourgroup-message-25june2014_1301.txt 2014-06-26 07:23:18.110909000 -0700 *************** *** 1 **** - DKIM-Signature: d=mymail.com ... --- 0 ---- *************** *** 4 **** ! Subject: I'm testing how DKIM forwarding history versioning works. --- 3,7 ---- ! Subject: [big-mailinglist] I'm testing how DKIM forwarding history versioning works. ! Content-Type: multipart/mixed; ! boundary="ABC123" ! ! --ABC123 *************** *** 9 **** --- 13,14 ---- + --ABC123 + --ABC123-- --DFH456-- --ABC123-- Forwarder Forwardmail takes ownership of message, composes the following and sends to recipient@dest.org. ===== DKIM-Signature: d=forwardmail.com ... From: sender@mymail.com To: big-mailinglist@yourgroup.com Subject: [big-mailinglist] I'm testing how DKIM forwarding history versioning works. Content-Type: multipart/mixed; boundary="ABC123" --ABC123 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit This example illustrates how using diff and patch can obtain the message versions. -Sender --ABC123 Content-Type: multipart/dkim-forwarding-history; boundary="DFH456" --DFH456 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="message-25june2014_1301.patch" *** original-message-25june2014_1301.txt 2014-06-26 07:21:11.472671000 -0700 --- yourgroup-message-25june2014_1301.txt 2014-06-26 07:23:18.110909000 -0700 *************** *** 1 **** - DKIM-Signature: d=mymail.com ... --- 0 ---- *************** *** 4 **** ! Subject: I'm testing how DKIM forwarding history versioning works. --- 3,7 ---- ! Subject: [big-mailinglist] I'm testing how DKIM forwarding history versioning works. ! Content-Type: multipart/mixed; ! boundary="ABC123" ! ! --ABC123 *************** *** 9 **** --- 13,14 ---- + --ABC123 + --ABC123-- --DFH456 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="message-25june2014_1302.patch" *** yourgroup-message-25june2014_1302.txt 2014-06-26 07:43:31.055270000 -0700 *** forwardmail-message-25june2014_1302.txt 2014-06-26 07:43:13.518164000 -0700 *** 1 **** - DKIM-Signature: d=yourgroup.com ... --- 0 ---- --DFH456-- --ABC123-- --001a11c3bfdeb57cf404fce595cc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

We propose the following enhancement to DKIM for tracking = message changes relevant to authentication as a message is forwarded and mo= dified by mail providers, typically mailing lists. At each SMTP delivery st= ep, starting with the original sender and through all intermediate forwarde= rs, the message must be DKIM signed. =A0Each intermediate forwarder then ad= ds a diff so that the recipient can recover the message as received by that= forwarder and any earlier version. =A0This change enables the recipient to= verify the authenticity of the message and allows a more accurate decision= for preventing abuse. In addition, it answers the problem of handling DMAR= C domains relayed through mailing lists. =A0The advantage of this is that t= he recipient can recover the DKIM signed and verified message as received b= y the intermediate mail provider by reverse patching the diff, and can repe= atedly apply this as necessary to recover the message sent by the original = sender. =A0Observing all versions of messages is most useful for Spam and P= hishing detection in evaluating the reputation of the message. =A0In partic= ular one can observe the original sender's intent, and this is useful f= or example to verify that the original sender meant to send along a particu= lar mail forwarding path or mailing-list.

This proposal would introduce a ne= w MIME CONTENT-TYPE: multipart/dkim-forwarding-history that would contain t= he diffs. =A0Diffs between successive versions of the message are added seq= uentially as subparts to dkim-forwarding-history part. =A0Diff parts are tr= eated as attachments so that the user doesn't get confused by the conte= nts. =A0This particular proposal only works with 7-bit encoding, and a futu= re proposal will deal with 8bit and binary. =A0This process is illustrated = in the example later.


Note this isn't a full proposal as we would like the concept = to be considered first. =A0If this discussion is successful, we would like = to also discuss a related improvement to SPF and DMARC, as well as the bina= ry encoding change. =A0At the conclusion we can have a longer discussion ab= out the details of CONTENT-TYPE: multipart/dkim-forwarding-history or write= a draft that tightly specifies how this works.


=3D=3D=3D=3D=3D

= DKIM Forwarding History illustrative example


Message is generated at Mymail and sent to mailing-list Yourgroup= . =A0Yourgroup modifies the subject line to indicate to the user which mail= inglist the message went through. =A0Then it is delivered to a Forwardmail = which forwards without visible modifications to its ultimate destination at= recipient@dest.org. =A0Despite t= he lack of visible changes, the message at Forwardmail is likely modified w= ith at least a Received header appended.


At each intermediate domain, the SMTP server takes a diff of the = message as it is to be sent including any modifications, and the received v= ersion excluding the diff contents and excluding the new DKIM signature sin= ce that's computed after the diff. =A0The diff content is appended to t= he any previous diff content as an attachment. =A0All diff content resides = in a multipart/dkim-forwarding-history MIME part. =A0After that, DKIM signi= ng is done includes the header, original body, and diffs. =A0If there is a = previous DKIM header, it is removed, so that it is clear what the ownership= is. The new DKIM header is added to the message header.


Here's the message content that would be seen by the user.

=
Original message:
 =A0From: sender@mymail.c= om
 =A0To: big-m= ailinglist@yourgroup.com
 =A0Subject: I'm testing how DKIM forwarding history versi= oning works.

 =A0This example illustrates how u= sing diff and patch can obtain the message versions.
 =A0-Sender

Yourgroup message: =A0From: sender@mymail.c= om
 =A0To: big-m= ailinglist@yourgroup.com
 =A0Subject: [big-mailinglist] I'm testing how DKIM forwar= ding history versioning works.
 =A0
 =A0This example illustrates how using diff and patch can obta= in the message versions.
 =A0-Sender

Forwardmail message:<= br class=3D""> =A0From: sender@mymail.c= om
 =A0To: big-m= ailinglist@yourgroup.com
 =A0Subject: [big-mailinglist] I'm testing how DKIM forwar= ding history versioning works.
 =A0
 =A0This example illustrates how using diff and patch can obta= in the message versions.
 =A0-Sender

Here's the more detailed descr= iption with the abbreviated RFC5322 message.

Original message generated at mymail.com and sent to yourgroup.com.
=3D=3D=3D=3D=3D=3D
 =A0DKIM-Signature: d=3Dmymail.c= om ...
 =A0From: sender@mymail.c= om
 =A0To: big-m= ailinglist@yourgroup.com
 =A0Subject: I'm testing how DKIM forwarding history versi= oning works.
 =A0Content-Type: text/plain; charset=3DUS-ASCII<= br class=3D""> =A0Content-Transfer-Encoding: 7bit
 =A0
 =A0This example illustrates how using diff and patch can obta= in the message versions.
 =A0-Sender

Yourgroup mailing list takes owner= ship of message and composes the following which is sent to Forwardmail.
=3D=3D=3D=3D=3D
 =A0DKIM-Signature: d=3Dyourg= roup.com ...
 =A0From: sender@mymail.c= om
 =A0To: big-m= ailinglist@yourgroup.com
 =A0Subject: [big-mailinglist] I'm testing how DKIM forwar= ding history versioning works.
 =A0Content-Type: multipart/mixed;
 =A0 <= /span>boundary=3D"ABC123"
 =A0
 =A0--ABC123
 =A0Content-Type: text/plain; charset=3DUS-ASCII<= br class=3D""> =A0Content-Transfer-Encoding: 7bit
 =A0
 =A0This example illustrates how using diff and patch can obta= in the message versions.
 =A0-Sender
 =A0--ABC123
 =A0Content-Type: multipart/dkim-forwarding-history;
 =A0 <= /span>boundary=3D"DFH456"

 =A0--DFH456
 =A0Content-Type: text/plain; charset=3DUS-ASCII<= br class=3D""> =A0Content-Transfer-Encoding: 7bit
 =A0Content-Disposition: attachment;
 =A0 <= /span>filename=3D"message-25june2014_1301.patch"

 =A0*** original-message-25june201= 4_1301.txt <= /span>2014-06-26 07:21:11.472671000 -0700
 =A0--- yourgroup-message-25june2014_1301.txt 2014-06-26 07:2= 3:18.110909000 -0700
 =A0***************
 =A0*** 1 ****
 =A0- DKIM-Signature: d=3Dmymail= .com ...
 =A0--- 0 ----
 =A0***************
 =A0*** 4 ****
 =A0! Subject: I'm testing how DKIM forwarding history ver= sioning works.
 =A0--- 3,7 ----
 =A0! Subject: [big-mailinglist] I'm testing how DKIM forw= arding history versioning works.
 =A0! Content-Type: multipart/mixed;
 =A0! =A0=A0=A0=A0=A0=A0boundary=3D"ABC123"
 =A0!
=A0! --ABC123
 =A0***************
 =A0*** 9 ****
 =A0--- 13,14 ----
 =A0+ --ABC123
 =A0+ --ABC123--
 =A0--DFH456--
 =A0--ABC123--


Forwarder Forwardmail takes ownership of message, composes the= following and sends to recipient@des= t.org.
=3D=3D=3D=3D=3D
 =A0DKIM-Signature: d=3Dfor= wardmail.com ...
 =A0From: sender@mymail.c= om
 =A0To: big-m= ailinglist@yourgroup.com
 =A0Subject: [big-mailinglist] I'm testing how DKIM forwar= ding history versioning works.
 =A0Content-Type: multipart/mixed;
 =A0 <= /span>boundary=3D"ABC123"
 =A0
 =A0--ABC123
 =A0Content-Type: text/plain; charset=3DUS-ASCII<= br class=3D""> =A0Content-Transfer-Encoding: 7bit
 =A0
 =A0This example illustrates how using diff and patch can obta= in the message versions.
 =A0-Sender
 =A0--ABC123
 =A0Content-Type: multipart/dkim-forwarding-history;
 =A0 <= /span>boundary=3D"DFH456"

 =A0--DFH456
 =A0Content-Type: text/plain; charset=3DUS-ASCII<= br class=3D""> =A0Content-Transfer-Encoding: 7bit
 =A0Content-Disposition: attachment;
 =A0 <= /span>filename=3D"message-25june2014_1301.patch"

 =A0*** original-message-25june201= 4_1301.txt <= /span>2014-06-26 07:21:11.472671000 -0700
 =A0--- yourgroup-message-25june2014_1301.txt 2014-06-26 07:2= 3:18.110909000 -0700
 =A0***************
 =A0*** 1 ****
 =A0- DKIM-Signature: d=3Dmymail= .com ...
 =A0--- 0 ----
 =A0***************
 =A0*** 4 ****
 =A0! Subject: I'm testing how DKIM forwarding history ver= sioning works.
 =A0--- 3,7 ----
 =A0! Subject: [big-mailinglist] I'm testing how DKIM forw= arding history versioning works.
 =A0! Content-Type: multipart/mixed;
 =A0! =A0=A0=A0=A0=A0=A0boundary=3D"ABC123"
 =A0!
=A0! --ABC123
 =A0***************
 =A0*** 9 ****
 =A0--- 13,14 ----
 =A0+ --ABC123
 =A0+ --ABC123--
 =A0--DFH456
 =A0Content-Type: text/plain; charset=3DUS-ASCII<= br class=3D""> =A0Content-Transfer-Encoding: 7bit
 =A0Content-Disposition: attachment;
 =A0 <= /span>filename=3D"message-25june2014_1302.patch"

 =A0*** yourgroup-message-25june20= 14_1302.txt = 2014-06-26 07:43:31.055270000 -0700
 =A0*** forwardmail-message-25june2014_1302.txt =A0=A0=A0=A0= =A0=A02014-06-26 07:43:13.518164000 -0700
 =A0*** 1 ****
 =A0- DKIM-Signature: d=3Dyou= rgroup.com ...
 =A0--- 0 ----
 =A0--DFH456--
 =A0--ABC123--


--001a11c3bfdeb57cf404fce595cc-- From nobody Sat Jun 28 08:22:44 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68541A0353 for ; Sat, 28 Jun 2014 08:22:41 -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=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 eH4glBW3wfEU for ; Sat, 28 Jun 2014 08:22:38 -0700 (PDT) Received: from secure.winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 713541A034F for ; Sat, 28 Jun 2014 08:22:38 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2002; t=1403968949; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=1G2rellS6jhUnbKZ9Gw8WyPUfEo=; b=oclONNDX5jlUfPLGdvBX 8tMQSzqhnW8MkKwhpWQHTD3ulSiDgXJzN2mKuYtZLDqGLk0ViFxZBTp0vyTOeN8/ XZJmqSpdaJGDrEddVDfA1qAjLgWCSMDIwd2dEZntaIncHtDP9hx+hHeO4mfZXd59 WuhsusSxX4IKWOwJbqS7m8c= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 28 Jun 2014 11:22: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; Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3449054231.7425.1524; Sat, 28 Jun 2014 11:22:28 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2002; t=1403968748; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=DbvSZNN aG16ckngxizjOCPCDPyVzUCJTPjjuzwUjvPg=; b=BhJKADkoGevGgn9i1/rSYBA QmOQP51JYlC/8CGUgS0ccDK/VbZuzPfOLIRIAqzFkO8PvbvDcoWog4zlgZ6MeJQw 2NAwBXXjSwJcWy0rY9fliYZahKVBcbg4Gi8+SS8FMREeCBtMj8Elqn5/pHRrjz72 9QnOkTbn4sN8GYpdL0t0= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 28 Jun 2014 11:19:08 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3465394406.9.1380; Sat, 28 Jun 2014 11:19:06 -0400 Message-ID: <53AEDDB5.8080702@isdg.net> Date: Sat, 28 Jun 2014 11:22: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: Wei Chuang , dmarc@ietf.org, apps-discuss References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/G0fS95cjZym1YN9PCY1sJlf5QIA Subject: Re: [dmarc-ietf] DKIM Forwarding History (Provenance) Proposal 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, 28 Jun 2014 15:22:41 -0000 On 6/28/2014 9:41 AM, Wei Chuang wrote: > Note this isn't a full proposal as we would like the concept to be > considered first. If this discussion is successful, we would like to also > discuss a related improvement to SPF and DMARC, as well as the binary > encoding change. At the conclusion we can have a longer discussion about > the details of CONTENT-TYPE: multipart/dkim-forwarding-history or write a > draft that tightly specifies how this works. Wei, Any "chain of trust" idea will work with a honored client/server negotiated protocol steps and ideals. The problem has always been in dealing with the deviation from the ideal protocol steps and compliancy expectations. So if you have a protocol ABC, what are the benefits of this ABC processing? What is the payoff for the compliant mail receiver? What is the payoff for the originating/author domain? What happens when there is deviation, something broke in the chain of MIME diffs? What do you want receivers to do? You must think of the massive volume of wasteful mail processing. Not everyone is going to do this just for nothing. It has to have a meaningful payoff, and today that payoff comes in the form of mail filtering policies with rejection/quarantine/discard author domain policy concepts. So if your proposal says: "If you follow these steps, the author domain is OK with you (because you asked him) honoring rejection, if you see a problem, then there is something wrong with it and its better (trust the author policy) if you just reject it." then we you got something to consider. But I think in this case, your proposal is a higher processing complexity factor when all you need to do is ask the author if the final/last signature in the chain is an trusted and/or authorized signer domain. If you are not asking the author (directly or indirectly) if any of this forwarding stuff is ok, then I think you have a security conflict (loophole) to consider. -- HLS From nobody Sat Jun 28 10:39:27 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 615761A0386 for ; Sat, 28 Jun 2014 10:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.438 X-Spam-Level: X-Spam-Status: No, score=-98.438 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_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 CraxeJAejdza for ; Sat, 28 Jun 2014 10:39:21 -0700 (PDT) Received: from mail.santronics.com (catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 659351A0384 for ; Sat, 28 Jun 2014 10:39:21 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5532; t=1403977155; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Z7XOdhDYsHQ26e1s3/t87qDVKW4=; b=pnK4KiiH+lCIvKJuB/SR +SNhnY+TarTYwSHf9QoxMjeJsxMUgU5zLKB4qySPXqYjz8N8qxAKZXffou4+1fE9 YcHrdLsH8yz/nTNPSDSAe12YJTYVrz3Pm4uVhXl2fghViT9XyVOr/xts3Rk74jfi tlVNQTpNVZArRnpGADUh5gQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 28 Jun 2014 13:39: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; Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3457259619.1.6060; Sat, 28 Jun 2014 13:39:13 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5532; t=1403976956; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=5843b54 2oi2LNjprnn9KWCSAVOV/dL80qj+ppQIW8k4=; b=L1fHtVV2uVnhUyjQ1bj3pzB tFmRIp4Brji5BCcGcESmaZXSq8y2cf3WmS8aUwSOMSrjcg4AcPkN8H2pCWuhUlaD WJoapSV/hR1h2tRfKqSwi/YzVzDs9KkjAsTc1wjH1VfEmez8mApdSyGPrhzu1Cf0 cEA90mAVf//w+XZ9I1JM= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 28 Jun 2014 13:35: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 3473603328.9.5708; Sat, 28 Jun 2014 13:35:55 -0400 Message-ID: <53AEFDC6.7040107@isdg.net> Date: Sat, 28 Jun 2014 13:39:18 -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: Jim Fenton , dmarc@ietf.org References: <20140626203747.45108.qmail@joyce.lan> <53ADC563.10101@bluepopcorn.net> In-Reply-To: <53ADC563.10101@bluepopcorn.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/WtacgtBrP8O2plekuwjTV_TLQbE Subject: Re: [dmarc-ietf] Draft DMARC working group charter 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, 28 Jun 2014 17:39:25 -0000 On 6/27/2014 3:26 PM, Jim Fenton wrote: >> There's a proto-wg called dbound thinking about this topic. Marc >> Blanchet and I are trying to write up a problem statement before the >> Toronto cutoff, so we can at least try and see if there is any >> agreement on what problem we're trying to solve. > > That's good acknowledgment of the problem, and I agree with Dave > Crocker's comment that this problem is bigger than this WG. My suggestions on the draft charter are below. But I have a few summary comments of my thoughts on this matter. We did have the wider disciplines of industry vendors and participants involved. But I would suggest more than half them were "pushed out" in the name of TRUST signer algorithms. Remember, very powerful and conceptually popular author domain policies were pushed out of the framework. It was "outlawed" and it had to be "outlawed" in order to allow the resigner/list market to blindly exist unchanged. IMO, mail integrity list problems was the least of our concerns because we did have a major consensus of a secured concept and idea of using a "trusted" additional/last signature resigner for these cases. The possible different types were: 1 - Mail integrity not changed, no resigner 2 - Mail integrity changed, no resigner 3 - Mail integrity not changed, resigner 4 - Mail integrity changed, resigner The only real case we did not have control over was #2 when the integrity was changed and there was no resigning. The only way to deal with that was to wait for a wider market of list outbound resigned mail. We just didn't agree on how to get the "trusted resigner" part. DKIM STD did come up with a model as a function of the Signer Domain Identity (SDID) and the Agent/User Identity (AUID) but it intentionally excluded the Author Domain Identity (ADID). This STD model did not get industry wide implementation support. It was a "batteries required" concept -- DKIM did not have a payoff without the "Trust Batteries" that you would most likely have to buy from some future trust service "DKIM CA" vendor. VBR was the closest thing. No traction. DAC was started by Levine. Abandoned. Levine started other lookup GOOD REPUTATION zones too. I have no idea where that went. But now this PSL? So rhetorically, where is this "repository" of centralized trust located? Who will own it? How do you get in? What will cost a domain? Will it be fair? Will the DMA members "buy" their way into it? etc, and so on with all these "monopolistic" long term concerns with this trust concept. You did not fail with your and Eric's SSP efforts. I was among those disappointed that it was replaced with a weaker "poison pill" ADSP that was non-supported, non-championed by it author. So in my opinion, the lack of getting it fixed didn't apply because we didn't have the right "technical sales" team on it. If they are not interested in fixing it because there were other product plans related to trust repositories, well, of course, its going to fail. But DMARC today, proves you did not fail. The whole concept of DKIM + POLICY did not fail. Three expected migration goals were finally reached: 1) More Publishers of Author Domain Mail Policies 2) More Receivers performing the DNS lookup, 3) More Receivers honoring the strict policies, not just recording and/or reporting results. We all expected this to be a short term migration path. Until wider publishing took place, we would see a high waste in NXDOMAINS and also relaxed records. But eventually, we expected domains to turn on the "reject" handling switches and that finally happen with DMARC. So you did not fail. It just took awhile and we are back to square one: How to authorize and scale resigners. Personally, I would like the DMARC WG to concentrate on: 1) Split DMARC into REPORTING and POLICY. 2) Refine DMARC to make sure flexible EXTENSIONS and possible. 3) Add 3rd party semantics starting allow any resigner option. 4) Pick and chose a flexible 3rd party authorization extension, modified version of ATPS, TPA, etc, for a PS track item or allow them both to be experimental. 6) Develop an in-band optimizer for the exclusive policies. 5) Draft some BCP for scaling and management. Foremost, the IETF must endorse the 3rd party authorization effort. Nothing will work if its not championed with the level of integrated product development required. That was lacking before. It it continues, I don't have the confident there will be success. We are beyond the R&D. The Yahoo"s did the first step to doing the lookup and honoring strong policies. Now, if it desires, it needs to figure out how to scale the authorization of resigners. For most domains, this isn't going to be a problem and the IETF should support a framework that satisfies all scales, even if the larger ones are going to have a larger management problem with it. The IETF already has small vs large scale dilemma in other protocol areas. I personally do not believe it will be that big of a problem once the larger domains get rolling with it. We can handle "Big Data" problems, can we? Thats a separate problem and it should not stop progress with the basic 3rd party authorization model that is fundamentally needed. To argue that its no good because it doesn't scale is not a good idea. Many ideas didn't scale when they were introduced, but we learned how to optimize and scale them over time. -- HLS From nobody Sat Jun 28 11:35:42 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 710461A038E for ; Sat, 28 Jun 2014 10:55:31 -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 ZMkmf3GsfjfA for ; Sat, 28 Jun 2014 10:55:30 -0700 (PDT) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA17B1A038B for ; Sat, 28 Jun 2014 10:55:29 -0700 (PDT) Received: from gsp.org (localhost [127.0.0.1]) by taos.firemountain.net (8.14.9/8.14.9) with SMTP id s5SHtRIr002738 for ; Sat, 28 Jun 2014 13:55:28 -0400 (EDT) Date: Sat, 28 Jun 2014 13:55:27 -0400 From: Rich Kulawiec To: dmarc@ietf.org Message-ID: <20140628175527.GA9821@gsp.org> References: <53ADFB3A.2020105@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53ADFB3A.2020105@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/tgjhJosnnvYDrfokkqxykBxOXtU X-Mailman-Approved-At: Sat, 28 Jun 2014 11:35:39 -0700 Subject: Re: [dmarc-ietf] Charter discussion being marked as spam 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, 28 Jun 2014 17:55:31 -0000 On Fri, Jun 27, 2014 at 04:16:10PM -0700, Dave Crocker wrote: > That said, yes, the ruleset for IETF mailing lists probably needs > tweaking, given the unusual nature of our content, with respect to > spam/anti-spam work. There's no need to run SpamAssassin on the IETF lists: simply configure Mailman to reject all traffic from non-members and let the list-owner add other needed addresses on an ad-hoc basis. (Mailman will by default hold traffic sent from addresses it doesn't recognize. The interface then allows the list-owner to either discard, accept or reject those messages. Simultaneously, it allows the list-owner to decide what to do about the originating address, and one common choice is to add the address to the list which are permitted to send traffic. This avoids involving the list-owner again when more traffic is received from the same non-subscribed address. I've used this mechanism for many years and it works efficiently and beautifully, particularly with people who use multiple addresses to end traffic to mailing lists.) ---rsk From nobody Sat Jun 28 12:11:57 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC6A1A03C4 for ; Sat, 28 Jun 2014 12:11:55 -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 yK-xN9CLKSoO for ; Sat, 28 Jun 2014 12:11:52 -0700 (PDT) Received: from secure.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 674FA1A03B4 for ; Sat, 28 Jun 2014 12:11:52 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=8909; t=1403982700; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=2IyN6pG/uTKb3KorKKoAh//SuJM=; b=W9P2AXA1kZu1P1u2goZS fas+xomwXZo4ke5tw9PmBSmEH3k+u1K2aoW4dkZNC7JZIOI3PE+HTPoSywgytWha alvchVYaAeUPJ7WQJRhXIqlUvWdD9yLZejMYmTkfQ4cu6XRtPrxVp+c6d4mcjUb2 MGcJtGmNoBV2ElQB5O4qwNc= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 28 Jun 2014 15:11: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; Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3462804986.1.5128; Sat, 28 Jun 2014 15:11:39 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=8909; t=1403982502; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=hacEk3n gv7bmpTwKC21nnfRN4OcucM1orBT1t+0/Wqs=; b=SEyZjEpMvwnBERPNFC9sVUh ijHW7w9IKEfq6TuHMusVcliPAPEbx+0NPoAwyRWzBfMjBoNuUnr90XOknBJgkE+A Pl5u/C7s0/aAP9JFnFhpFiPf4NEoxH3HDnI0w6MV3zFq+IrjnM01dF+A1fJmWGor 5KPEeEm1mJu2cskZV7jA= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sat, 28 Jun 2014 15:08: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 3479148890.9.2536; Sat, 28 Jun 2014 15:08:21 -0400 Message-ID: <53AF1370.2030409@isdg.net> Date: Sat, 28 Jun 2014 15:11:44 -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: Chris Meidinger , dmarc@ietf.org References: <8E79C75F-3021-42E2-B975-443DBE2F5883@me.com> In-Reply-To: <8E79C75F-3021-42E2-B975-443DBE2F5883@me.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/_IAeRylNh1S7MjKNhBxgSyKOSxM Subject: Re: [dmarc-ietf] DMARC & Lists - Minimal Change Set 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, 28 Jun 2014 19:11:56 -0000 On 6/26/2014 9:13 PM, Chris Meidinger wrote: > > So two questions to the group: > > 1: Regardless of whether it has simply always been that way, could list operators forego modifying message bodies by adding footers? But will operators forgo adding footers for this as a standard practice? You can't enforce this and you will find some that believe it isn't necessary to forego it. In additional, in some jurisdictions, a footer is now legally required. Double check with CAN-SPAM. CAN-SPAM basically says if a spammer follows certain rules, like adding an opt-out footer, then it is legally allowed to have a capitalistic right to exist. > 2: How real is the threat space of a modified subject? Would it be acceptable to allow bizarre subjects attached to otherwise intact and signed messages to pass DKIM and DMARC in the name of interoperability? I don't think the subject is a big thing. But anything is possible. For my implementation design standpoint, the best one can do currently is to anticipate that a outbound message is going to target a particular site where you would have different "signing" rules for it. For example, we have a configuration out of the box installation signing rules that applies to outbound expanded messages that have a "List-ID" added by our list server and for specific recipient addresses. This is our wcDKIM INI configuration file. Read/Examine all the design considerations as the work was being done with the eventual default state conditions: ###################################################################### # Wildcat! DKIM (wcDKIM) # (c) copyright 2011 Santronics Software, Inc. # version: 3.10 # # There are four main sections plus optional overriding Signing Rules # sections: # # [General] defines global options # [Signer.Defaults] defines the default Signing options # [Verifier] defines the default Verifying options # [Authentication-Results] defines the default Reporting options # # See Signing Rules for examples of overriding the Signer.Defaults # options. # # Technical Notes: # # MACROS: # # Several macros are available which will be expanded and set # at run time: # # {PRIMARY.DOMAIN} Wildcat! Mail Setup Primary Domain # {VERIFIER.DOMAIN} WCSMTP host domain when verifying # {AUTHOR} author address # {AUTHOR.DOMAIN} author domain # {SIGNER} signing domain # ###################################################################### #--------------------------------------------------------------------- # General Options #--------------------------------------------------------------------- [General] Enable.Signer = 1 # set 0 to globally disable signing mail Enable.Verifier = 1 # set 0 to globally disable verification FirstTimeSetup = 1 #--------------------------------------------------------------------- # Signing Mail Setup. The default settings for [Signer.Defaults] are: #--------------------------------------------------------------------- [Signer.Defaults] Enable = 1 # Default ON/OFF switch per signer Signer = {PRIMARY.DOMAIN} # signer domain for all outbound Selector = global # selector sub-domain for public key Canon = simple/relaxed # header/body canonicalization method Hash = sha1 # hashing method, sha1 or sha256 Identity = # optional, if set adds i= tag, see below AddBodyLength = 0 # optional, 1 - adds l= tag body size AddTimeStamp = 1 # optional, 1 - adds t= tag timestamp AddQueryMethod = 0 # optional, 1 - adds q= tag AddCopiedHeaders = 0 # optional, 1 - adds z= tag AddExpireTime = 0 # optional, days, adds x= tag UseRequiredHeadersOnly = 1 # optional, 1 - used RequireHeaders RequiredHeaders = From:To:Date:Message-Id:Organization:Subject:Received*:List-ID SkipHeaders = X-*:Authentication-Results:DKIM-Signature:DomainKey-Signature:Return-Path StripHeaders = # optional, headers stripped by resigners UserTags = # Notes: # # CANONICALIZATION (C14N): # # Possible values for canon= are either simple or relaxed or a combination # listed below. They apply to both the the header and body in the format: # # canon = HEADER/BODY # # The default is simple for both HEADER and BODY. simple keeps the data as # is removing all final EOLs (carriage return, line feeds), while relaxed # replaces tabs with spaces, removes of multiple spaces and EOLs. # # canon = simple simple applies to HEADER and BODY # canon = relaxed relaxed for HEADER, simple for BODY # canon = simple/simple # canon = simple/relaxed # canon = relaxed/simple # canon = relaxed/relaxed # # HASHING: # # Possible values for hash= # # hash = sha1 # hash = sha256 # hash = both # # SIGNING HEADERS: # # When UseRequiredHeaderOnly = 0, all headers are signed except those in the # SkipHeaders list. When UseRequiredHeaderOnly = 1, only the headers in the # RequiredHeaders list are signed except those in the SkipHeaders list. # # Each header is the RequiredHeaders or SkipHeaders list are colon separated # If you wish to sign or skip multiple headers, use an asterish '*' for the # header, i.e. Received* for signing all Received: headers or or X-* for skipping # all X- headers. # # 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. # # 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} #--------------------------------------------------------------------- # Verifier #--------------------------------------------------------------------- [Verifier] IgnoreBodyLengthTag = 0 # 0 = honor l= length, 1 = ignore length CheckPractices = 1 # 0 = don't check signing practice, 1 = check signing practices CheckVBR = 1 # 0 = don't check VBR, 1 = check for VBR SubjectRequired = 0 # 0 = not required, 1 = subject is required to be signed SaveCanonicalizedData = 0 # 0 = canonicalized data is not saved, 1 = canonicalized data is saved AllowUnsignedFromHeaders = 0 # 0 = From headers not included in the signature are not allowed, 1 = allowed IgnoreGranularity = 0 # 0 = check sig tag i= granularity with policy g= tag, 1 = don't check IgnoreExpire = 0 # 0 = check expire, 1 to ignore x= expiration FixSubjectHeader = 0 # 0 = don't fix, 1 to capitalized Subject: header #--------------------------------------------------------------------- # Authentication Results #--------------------------------------------------------------------- [Authentication-Results] Enable = 1 AuthenticationHost = {VERIFIER.HOST} #--------------------------------------------------------------------- # Signing Rules #--------------------------------------------------------------------- # # Before a signing can take place it must be enabled, a signer and # selector must be set and the private key exist. At a minimum, the # Signer.Defaults section can be used to prepare the signing of all # outgoing messages using the default settings defined, but you may # override any of the default signing options by creating signing # rules sections. # # A Signing Rule section allow you to change the Signer.Defaults # options. The rules are checked from top down and the end result is # a composite of the final signing options. Only the fields you wish # to check need to set per rule. No need to duplicate them all. # # A Signing Rule has a format of: # # [HEADER:VALUE] # # There are 3 main header fields checked: FROM, LIST-ID, and RCPT. # Each rule value can have a wildcard spec: # # [FROM:*] check options for all messages # [FROM:*@domain.com] check options for author's matching domain.com # [LIST-ID:*] check options for all list messages # [LIST-ID:list-id] check options for specific list-id # [RCPT:address] check options for specific destination address # # You can check other message HEADER fields by defining them as well: # # [HEADER:*] check options for existing HEADER with any value # [HEADER:value] check options for existing HEADER value # #--------------------------------------------------------------------- [from:*@example.com] Enable = 1 Signer = example.com Selector = beta1 AddExpireTime = 60 [from:*] Enable=1 [list-id:*] Enable=1 AddBodyLength=0 StripHeaders=DKIM-Signature # add body length tag for ietf.org list address [rcpt:*@ietf.org] AddBodyLength=1 [X-NoSigning:*] Enable=0 #--------------------------------------------------------------------- -- HLS From nobody Sat Jun 28 17:02:22 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337361A01E2 for ; Sat, 28 Jun 2014 17:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 ii0QerZ8my1w for ; Sat, 28 Jun 2014 17:02:11 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72A531A01BE for ; Sat, 28 Jun 2014 17:02:11 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id q107so766567qgd.19 for ; Sat, 28 Jun 2014 17:02:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PulpK46ZuP3ix/aYEGqHt2m4FxJD5zN0uYFRunQBab0=; b=EZt0t0AnTkWOTLJNCLAxArt74SwcwKOmu9IzQVcOHtMuPOqFEWSeF7uMFQc326xYXG EMvXA1xFSPP/LkRq++Qv0X9eBgwUZIGinQUcC7/2Ad/yWBvl0rZWkvrpyGm4/+6MXu/G ZNeg/BJF+/I8B4XmEALmfbZzPQoqtQSGaxGK5yPruGtxZ2/I6AFaC9EdNkkxmnoenxZ7 Q41q97uYmggDchA/yKyBA6FVZIDyhGc8i7fxg+PIi3aU2Zw5CYt/9bhkcnB5Se8mQycr oEWkrG9BH4ZORLJGWxoB+7Y3t2lTQlGjSk5a426Eiv375HTxRseuKLEX5LwyDtSUHTaD T2YA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=PulpK46ZuP3ix/aYEGqHt2m4FxJD5zN0uYFRunQBab0=; b=XHLBa7n0Slh/79lDGTntgfKs4ycVLOxI76vgQ9LH1HdTOPpQRHeulRJww7eUakfgNf 746F0EEbpIQ2w3lR7w5GEnUCE0V4nXqggKoxO9AYYPyblVX3ERDXlYdYmhwW9AooedZg OXn6QQnLI7/ScL8Ol5KiIjEkDThH1jLib5sppkBX3fBwjNXeyX6U8E7BzsdyC+bNEelQ okPrhIbyPjGE78p7ILKREqGd5+M57qU4afYMBHRL3yYFhx6+RT5Rs1xq++WRkdM2k1v1 5s7aoAyiEPBsT5rO74BfkvifxiSSLG+2X5PgfTPKFEI8KsS4KIo0NRyqbMj/H4/PBCVj aW0g== X-Gm-Message-State: ALoCoQnCuWqrNCn+Vm9dwSxSozgSDMScICU5LOvdmT/ehySLqeeWO4OyaGjfWm8A1XRXFkH5emjp X-Received: by 10.140.107.132 with SMTP id h4mr19100685qgf.83.1404000130522; Sat, 28 Jun 2014 17:02:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.58.1 with HTTP; Sat, 28 Jun 2014 17:01:49 -0700 (PDT) In-Reply-To: <53AEDDB5.8080702@isdg.net> References: <53AEDDB5.8080702@isdg.net> From: Wei Chuang Date: Sat, 28 Jun 2014 17:01:49 -0700 Message-ID: To: Hector Santos Content-Type: multipart/alternative; boundary=001a113a79960b813204fcee4142 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/w0_9U7gBKJj7j7Jk6hksGDI8iFI Cc: dmarc@ietf.org, apps-discuss Subject: Re: [dmarc-ietf] DKIM Forwarding History (Provenance) Proposal 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, 29 Jun 2014 00:02:15 -0000 --001a113a79960b813204fcee4142 Content-Type: text/plain; charset=ISO-8859-1 Hi Hector On Sat, Jun 28, 2014 at 8:22 AM, Hector Santos wrote: > On 6/28/2014 9:41 AM, Wei Chuang wrote: > >> Note this isn't a full proposal as we would like the concept to be >> considered first. If this discussion is successful, we would like to also >> discuss a related improvement to SPF and DMARC, as well as the binary >> encoding change. At the conclusion we can have a longer discussion about >> the details of CONTENT-TYPE: multipart/dkim-forwarding-history or write a >> draft that tightly specifies how this works. >> > > Wei, > > Any "chain of trust" idea will work with a honored client/server > negotiated protocol steps and ideals. > > The problem has always been in dealing with the deviation from the ideal > protocol steps and compliancy expectations. > > So if you have a protocol ABC, what are the benefits of this ABC > processing? What is the payoff for the compliant mail receiver? What is > the payoff for the originating/author domain? The benefit is that the recipient can authenticate the originating sender and in particular a particular action such as sending to a mailing list, yet allow intermediate domains to modify messages. It may be that a user has a filter to see all messages from the original sender. This is jumping ahead a bit, but the current DMARC paradigm is for the mailing list to own the message and rewrite the RFC5322.FROM which make this difficult. In addition SPAM filters likely can benefit from being able to process the original message and know message was authenticated by the original sending domain. > What happens when there is deviation, something broke in the chain of MIME > diffs? What do you want receivers to do? > In this proposal, it would be the same as failing DKIM RFC 6376 verification. It ought to be treated as information the recipient domain can use for additional Spam processing etc but not necessarily indicate reject or other action. This proposal is meant to build infrastructure that can be used to enhance DMARC in a subsequent proposal. By itself this proposal primarily provides extra information (well a strong guarantee on the authenticity and modifications) for Spam processing. > > You must think of the massive volume of wasteful mail processing. Not > everyone is going to do this just for nothing. It has to have a meaningful > payoff, and today that payoff comes in the form of mail filtering policies > with rejection/quarantine/discard author domain policy concepts. > > So if your proposal says: > > "If you follow these steps, the author domain > is OK with you (because you asked him) honoring > rejection, if you see a problem, then there is > something wrong with it and its better (trust the > author policy) if you just reject it." > > then we you got something to consider. > > But I think in this case, your proposal is a higher processing complexity > factor when all you need to do is ask the author if the final/last > signature in the chain is an trusted and/or authorized signer domain. If > you are not asking the author (directly or indirectly) if any of this > forwarding stuff is ok, then I think you have a security conflict > (loophole) to consider. > > I'm probably misunderstanding your intent. Here's a stab at a response: Passing the DKIM Provenance verification is meant to provide a stronger verification from a purported original sender. If intermediates want to claim that a mail came from some original sender, then they have to provide evidence. If they don't due maliciousness or otherwise, they don't have to include such evidence but they won't get any benefit of claiming the reputation of the original sender. -Wei PS It was mentioned offline that the discussion on dmarc@ietf is currently restricted to building the WG charter. First apologies I missed that. Second I can restrict subsequent discussion to apps-discuss if that's preferred by the WG. --001a113a79960b813204fcee4142 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Hector

On Sat, Jun 28, 2014 at 8:22 AM, Hector Santos <hsa= ntos@isdg.net> wrote:
On 6/28/2014 9:41 AM, Wei Chuang wrote:
Note this isn't a full proposal as we would like the concept to be
considered first. =A0If this discussion is successful, we would like to als= o
discuss a related improvement to SPF and DMARC, as well as the binary
encoding change. =A0At the conclusion we can have a longer discussion about=
the details of CONTENT-TYPE: multipart/dkim-forwarding-history or wr= ite a
draft that tightly specifies how this works.

Wei,

Any "chain of trust" idea will work with a honored client/server = negotiated protocol steps and ideals.

The problem has always been in dealing with the deviation from the ideal pr= otocol steps and compliancy expectations.

So if you have a protocol ABC, what are the benefits of this ABC processing= ? =A0What is the payoff for the compliant mail receiver? =A0What is the pay= off for the originating/author domain? =A0

The benefit is that the recipient can authenticate the originating sender a= nd in particular a particular action such as sending to a mailing list, yet= allow intermediate domains to modify messages. =A0It may be that a user ha= s a filter to see all messages from the original sender. =A0This is jumping= ahead a bit, but the current DMARC paradigm is for the mailing list to own= the message and rewrite the RFC5322.FROM which make this difficult. =A0In = addition SPAM filters likely can benefit from being able to process the ori= ginal message and know message was authenticated by the original sending do= main.
=A0
What happens when there is deviation, someth= ing broke in the chain of MIME diffs? =A0What do you want receivers to do?<= br>

In this proposal, it would be the same as = failing DKIM RFC=A06376=A0verification. =A0It ought to be treated as information the recipient d= omain can use for additional Spam processing etc but not necessarily indica= te reject or other action. =A0This proposal is meant to build infrastructur= e that can be used to enhance DMARC in a subsequent proposal. =A0By itself = this proposal primarily provides extra information (well a strong guarantee= on the authenticity and modifications) for Spam processing.
=A0

You must think of the massive volume of wasteful mail processing. Not every= one is going to do this just for nothing. It has to have a meaningful payof= f, and today that payoff comes in the form of mail filtering policies with = rejection/quarantine/discard author domain policy concepts.

So if your proposal says:

=A0 =A0"If you follow these steps, the author domain
=A0 =A0 is OK with you (because you asked him) honoring
=A0 =A0 rejection, if you see a problem, then there is
=A0 =A0 something wrong with it and its better (trust the
=A0 =A0 author policy) if you just reject it."

then we you got something to consider.

But I think in this case, your proposal is a higher processing complexity f= actor when all you need to do is ask the author if the final/last signature= in the chain is an trusted and/or authorized signer domain. =A0 If you are= not asking the author (directly or indirectly) if any of this forwarding s= tuff is ok, then I think you have a security conflict (loophole) to conside= r.


I'm probably misunde= rstanding your intent. =A0Here's a stab at a response: Passing the DKIM= Provenance verification is meant to provide a stronger verification from a= purported original sender. =A0If intermediates want to claim that a mail c= ame from some original sender, then they have to provide evidence. =A0If th= ey don't due maliciousness or otherwise, they don't have to include= such evidence but they won't get any benefit of claiming the reputatio= n of the original sender.

-Wei

PS It was mentioned = offline that the discussion on dmarc@ietf is currently restricted to buildi= ng the WG charter. =A0First apologies I missed that. =A0Second I can restri= ct subsequent discussion to apps-discuss if that's preferred by the WG.=

--001a113a79960b813204fcee4142-- From nobody Sun Jun 29 07:58:49 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4D61A0021 for ; Sun, 29 Jun 2014 07:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.735 X-Spam-Level: X-Spam-Status: No, score=-99.735 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, HTML_MESSAGE=0.001, 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 ahNwA1oxWdlU for ; Sun, 29 Jun 2014 07:58:39 -0700 (PDT) Received: from secure.winserver.com (mail.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id F30721A0010 for ; Sun, 29 Jun 2014 07:58:38 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=15856; t=1404053911; h=Received:Received: Message-Id:From:Subject:Date:To:Organization:List-ID; bh=DWqEA9G BR66fhXDk5Apxhccl4gU=; b=fItOymMlzZBq7WJP9jVfvb2VOrcX3ccUUXEuiva TaVE+kF0mZ2zQi5S/6S3eoxoiyQk27+Zobuh7BnE3gufYgtA6dQYdnPym+x9QMRr 1eMCrMSuT+OrCIlMC1j+AF/FPmmeArQGMU81IEoLbav1RI4e/dN982VgWYk649rI 40+U= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for dmarc@ietf.org; Sun, 29 Jun 2014 10:58:31 -0400 Received: from [192.168.1.67] (99-121-4-27.lightspeed.miamfl.sbcglobal.net [99.121.4.27]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3534015433.687.1100; Sun, 29 Jun 2014 10:58:30 -0400 References: <53AEDDB5.8080702@isdg.net> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-86302092-99B1-4050-A843-122F42CA0F0C Content-Transfer-Encoding: 7bit Message-Id: <4A3194BC-A940-4365-B848-BD930650B33F@isdg.net> X-Mailer: iPad Mail (11B651) From: Hector Santos Date: Sun, 29 Jun 2014 10:58:27 -0400 To: Wei Chuang Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/SrSWVoTa-M0cP605ElqML5Kd58Q Cc: "dmarc@ietf.org" , apps-discuss Subject: Re: [dmarc-ietf] DKIM Forwarding History (Provenance) Proposal 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, 29 Jun 2014 14:58:43 -0000 --Apple-Mail-86302092-99B1-4050-A843-122F42CA0F0C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Wei, =20 IMO, your proposal is on par with the engineering considerations needed to d= evelop and mold the charter. Your proposal intent is to preserve the integr= ity and indirectly, the authorization for forwarding, resigning mail. The d= raft charter has its own even higher complex ideas for the same intent. My i= ntent is to keep it simple with 3rd party authorization framework and I don'= t see any other better method than a DNS-based lookup method for resigning a= uthorization or allowance. I believe in strong rejection author domain poli= cies. You can't standardize random, subjective heuristic methods, but you ca= n standardize deterministic protocol methods. This is the wider, network per= sistent and consistent solution that everyone can use.=20 If your offline moderation control messenger intent was to steer the work to= wards a specific more. complex, DKIM changing direction, and any negative di= scussion about it or censoring other better alternatives, and specifically a= uthorization methods, are out of scope, then I don't wish to spend any more t= ime, money and resources in what I strongly believe is going to be a big was= te of time, doesn't resolve the problem, nor does it eliminate the need to d= o DNS lookups. =20 The ADs need to consider more engineering solutions views that are outside t= he same typical folks who have long had control of this project. We are her= e today because the DKIM project leaders were incorrect in their presumption= s about the market needs, directions and they seem to be repeating it again.= I don't want to go thru this costly error again. The draft charter as wri= tten is too complex and IMO, it will not solve the main problem we always ha= d which is how to authorize and scale resigners. =20 Your idea is really not that different than what Murray and Dave want to pur= sue in the draft with a higher level DKIM processing complexity, long term p= rospects which I believe are not necessary and probably unrealistic to belie= ve people are going to blindly accept with even more expense in long term ex= perimentation. DKIM was just made into an STD document last year and already= there is consideration in changing. Thanks -- Hector Santos http://www.santronics.com > On Jun 28, 2014, at 8:01 PM, Wei Chuang wrote: >=20 > Hi Hector >=20 >> On Sat, Jun 28, 2014 at 8:22 AM, Hector Santos wrote: >>> On 6/28/2014 9:41 AM, Wei Chuang wrote: >>> Note this isn't a full proposal as we would like the concept to be >>> considered first. If this discussion is successful, we would like to al= so >>> discuss a related improvement to SPF and DMARC, as well as the binary >>> encoding change. At the conclusion we can have a longer discussion abou= t >>> the details of CONTENT-TYPE: multipart/dkim-forwarding-history or write a= >>> draft that tightly specifies how this works. >>=20 >> Wei, >>=20 >> Any "chain of trust" idea will work with a honored client/server negotiat= ed protocol steps and ideals. >>=20 >> The problem has always been in dealing with the deviation from the ideal p= rotocol steps and compliancy expectations. >>=20 >> So if you have a protocol ABC, what are the benefits of this ABC processi= ng? What is the payoff for the compliant mail receiver? What is the payoff= for the originating/author domain? =20 >=20 > The benefit is that the recipient can authenticate the originating sender a= nd in particular a particular action such as sending to a mailing list, yet a= llow intermediate domains to modify messages. It may be that a user has a f= ilter to see all messages from the original sender. This is jumping ahead a= bit, but the current DMARC paradigm is for the mailing list to own the mess= age and rewrite the RFC5322.FROM which make this difficult. In addition SPA= M filters likely can benefit from being able to process the original message= and know message was authenticated by the original sending domain. > =20 >> What happens when there is deviation, something broke in the chain of MIM= E diffs? What do you want receivers to do? >=20 > In this proposal, it would be the same as failing DKIM RFC 6376 verificati= on. It ought to be treated as information the recipient domain can use for a= dditional Spam processing etc but not necessarily indicate reject or other a= ction. This proposal is meant to build infrastructure that can be used to e= nhance DMARC in a subsequent proposal. By itself this proposal primarily pr= ovides extra information (well a strong guarantee on the authenticity and mo= difications) for Spam processing. > =20 >>=20 >> You must think of the massive volume of wasteful mail processing. Not eve= ryone is going to do this just for nothing. It has to have a meaningful payo= ff, and today that payoff comes in the form of mail filtering policies with r= ejection/quarantine/discard author domain policy concepts. >>=20 >> So if your proposal says: >>=20 >> "If you follow these steps, the author domain >> is OK with you (because you asked him) honoring >> rejection, if you see a problem, then there is >> something wrong with it and its better (trust the >> author policy) if you just reject it." >>=20 >> then we you got something to consider. >>=20 >> But I think in this case, your proposal is a higher processing complexity= factor when all you need to do is ask the author if the final/last signatur= e in the chain is an trusted and/or authorized signer domain. If you are n= ot asking the author (directly or indirectly) if any of this forwarding stuf= f is ok, then I think you have a security conflict (loophole) to consider. >=20 > I'm probably misunderstanding your intent. Here's a stab at a response: P= assing the DKIM Provenance verification is meant to provide a stronger verif= ication from a purported original sender. If intermediates want to claim th= at a mail came from some original sender, then they have to provide evidence= . If they don't due maliciousness or otherwise, they don't have to include s= uch evidence but they won't get any benefit of claiming the reputation of th= e original sender. >=20 > -Wei >=20 > PS It was mentioned offline that the discussion on dmarc@ietf is currently= restricted to building the WG charter. First apologies I missed that. Sec= ond I can restrict subsequent discussion to apps-discuss if that's preferred= by the WG. >=20 > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc --Apple-Mail-86302092-99B1-4050-A843-122F42CA0F0C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Wei,  

IMO, your proposal is on par with the engineering considerations needed to= develop and mold the charter.  Your proposal intent is to preserve the= integrity and indirectly, the authorization for forwarding, resigning mail.=   The draft charter has its own even higher complex ideas for the same= intent.  My intent is to keep it simple with 3rd party authorization f= ramework and I don't see any other better method than a DNS-based lookup met= hod for resigning authorization or allowance.  I believe in strong reje= ction author domain policies. You can't standardize random, subjective heuri= stic methods, but you can standardize deterministic protocol methods. This i= s the wider, network persistent and consistent solution that everyone can us= e. 

If your offline moderation control messeng= er intent was to steer the work towards a specific more. complex, DKIM chang= ing direction, and any negative discussion about it or censoring other bette= r alternatives, and specifically authorization methods, are out of scope, th= en I don't wish to spend any more time, money and resources in what I strong= ly believe is going to be a big waste of time, doesn't resolve the problem, n= or does it eliminate the need to do DNS lookups.  

=
The ADs need to consider more engineering solutions views that are outs= ide the same typical folks who have long had control of this project.  = We are here today because the DKIM project leaders were incorrect in their p= resumptions about the market needs, directions and they seem to be repeating= it again.  I don't want to go thru this costly error again.  The d= raft charter as written is too complex and IMO, it will not solve the main p= roblem we always had which is how to authorize and scale resigners.  &n= bsp;

Your idea is really not that different than wh= at Murray and Dave want to pursue in the draft with a higher level DKIM proc= essing complexity, long term prospects which I believe are not necessary and= probably unrealistic to believe people are going to blindly accept with eve= n more expense in long term experimentation. DKIM was just made into an STD d= ocument last year and already there is consideration in changing.
=
Thanks

<= /div>

On Jun 28, 2014, at 8:01 PM, Wei Chuang <weihaw@google.com> wrote:

Hi Hector

On Sat, Jun 28, 2014 at 8:22 AM, He= ctor Santos <hsantos@isdg.net> wrote:
On 6/28/2014 9:41 AM, Wei Chuang wrote:
Note this isn't a full proposal as we would like the concept to be
considered first.  If this discussion is successful, we would like to a= lso
discuss a related improvement to SPF and DMARC, as well as the binary
encoding change.  At the conclusion we can have a longer discussion abo= ut
the details of CONTENT-TYPE: multipart/dkim-forwarding-history or wri= te a
draft that tightly specifies how this works.

Wei,

Any "chain of trust" idea will work with a honored client/server negotiated p= rotocol steps and ideals.

The problem has always been in dealing with the deviation from the ideal pro= tocol steps and compliancy expectations.

So if you have a protocol ABC, what are the benefits of this ABC processing?=  What is the payoff for the compliant mail receiver?  What is the= payoff for the originating/author domain?  

The benefit is that the recipient can authenticate the originating sender an= d in particular a particular action such as sending to a mailing list, yet a= llow intermediate domains to modify messages.  It may be that a user ha= s a filter to see all messages from the original sender.  This is jumpi= ng ahead a bit, but the current DMARC paradigm is for the mailing list to ow= n the message and rewrite the RFC5322.FROM which make this difficult.  = In addition SPAM filters likely can benefit from being able to process the o= riginal message and know message was authenticated by the original sending d= omain.
 
What happens when there is deviation, someth= ing broke in the chain of MIME diffs?  What do you want receivers to do= ?

In this proposal, it would be the same as f= ailing DKIM RFC 6376&nbs= p;verification.  It ought to be treated as information the recip= ient domain can use for additional Spam processing etc but not necessarily i= ndicate reject or other action.  This proposal is meant to build infras= tructure that can be used to enhance DMARC in a subsequent proposal.  B= y itself this proposal primarily provides extra information (well a strong g= uarantee on the authenticity and modifications) for Spam processing.
 

You must think of the massive volume of wasteful mail processing. Not everyo= ne is going to do this just for nothing. It has to have a meaningful payoff,= and today that payoff comes in the form of mail filtering policies with rej= ection/quarantine/discard author domain policy concepts.

So if your proposal says:

   "If you follow these steps, the author domain
    is OK with you (because you asked him) honoring
    rejection, if you see a problem, then there is
    something wrong with it and its better (trust the
    author policy) if you just reject it."

then we you got something to consider.

But I think in this case, your proposal is a higher processing complexity fa= ctor when all you need to do is ask the author if the final/last signature i= n the chain is an trusted and/or authorized signer domain.   If you are= not asking the author (directly or indirectly) if any of this forwarding st= uff is ok, then I think you have a security conflict (loophole) to consider.=


I'm probably misunderstan= ding your intent.  Here's a stab at a response: Passing the DKIM Proven= ance verification is meant to provide a stronger verification from a purport= ed original sender.  If intermediates want to claim that a mail came fr= om some original sender, then they have to provide evidence.  If they d= on't due maliciousness or otherwise, they don't have to include such evidenc= e but they won't get any benefit of claiming the reputation of the original s= ender.

-Wei

PS It was mentioned o= ffline that the discussion on dmarc@ietf is currently restricted to building= the WG charter.  First apologies I missed that.  Second I can res= trict subsequent discussion to apps-discuss if that's preferred by the WG.

____________________= ___________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mai= lman/listinfo/dmarc
= --Apple-Mail-86302092-99B1-4050-A843-122F42CA0F0C-- From nobody Sun Jun 29 16:54:05 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA6531A0058 for ; Sun, 29 Jun 2014 16:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.671 X-Spam-Level: X-Spam-Status: No, score=0.671 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, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 o1YZLKUcvUop for ; Sun, 29 Jun 2014 16:54:01 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1841A1A004A for ; Sun, 29 Jun 2014 16:54:00 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id i50so1344645qgf.40 for ; Sun, 29 Jun 2014 16:54:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Hlo/fnzvpV1ETv8neLn0VGINrZbT57UDU50VQUmh3Wo=; b=memClb5QLKy5PLl/cvb5y5iC0C1MKjf8hjqK4rkRg2S6bV/MP+Fu/d/kfr1rIorQ2a poXP2phcUgYtwbAgHNrGScuPe4m+PYOqXGn+eStadppadFwJkpqWhLlowoesEl2w2IeY 6N6eS+BYROs7MduMafi3pm/0ym7S9hD4KkQ/YM1sl6/i6x2Q1WnpUmnpym3X5uLWGLdb p480GtnR/4An7TW9bJjhFohEfr+01Z0BBeeif8nPsSRszoqxw8UUL/2NnqrpXxJeoA0M zFYu+VdOyGfH6Q8eMPpolfo/g42TJR9s7vQGdDTeSAoc5lRTg726c0L8YFVx/XL62VwX e+gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Hlo/fnzvpV1ETv8neLn0VGINrZbT57UDU50VQUmh3Wo=; b=Z5qNk7Fxmc72jDTv11JvN4cs54elKUE+x6DVjdMxW5Vk4GCRYsqeLVdLqlqduF9KAE 4XnYZKxHusf6eDyjak2uIK0QADlqzPEVLdB+vVVLypRVm96iBn0hQbzL9jkyqPsLn/Vn CElsHML9LaknY2nSj0Qa4iKYBTMMOt5gFhWj44hFO9ceqjovT8FFsatuXL4MQb5Tjybb MVrU40CKf4vGof6IR2Knro068PnaUhrQZkhWE8T3ZowIB6Jhkiizw/tRqoxyfhDbZpOd dZJTQgvn+sx4m6W/Wbr71dtGrJzY7FlR4Cm8SN4lrlryu7boSZS1AK1xpgveEM8WlgwN 5a+A== X-Gm-Message-State: ALoCoQk6SVSjrAnPkc2za3FPrYDwADqqIlEXVBz9hXbzK0ypNPH61saZtHX5c8daxg7nr6W/MUQG X-Received: by 10.224.104.10 with SMTP id m10mr55731957qao.27.1404086040124; Sun, 29 Jun 2014 16:54:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.58.1 with HTTP; Sun, 29 Jun 2014 16:53:39 -0700 (PDT) In-Reply-To: <4A3194BC-A940-4365-B848-BD930650B33F@isdg.net> References: <53AEDDB5.8080702@isdg.net> <4A3194BC-A940-4365-B848-BD930650B33F@isdg.net> From: Wei Chuang Date: Sun, 29 Jun 2014 16:53:39 -0700 Message-ID: To: Hector Santos Content-Type: multipart/alternative; boundary=001a11c1ca16a80aa504fd024106 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/7IrZRHUh_VhAoefNuHuLE7wiQCI Cc: "dmarc@ietf.org" , apps-discuss Subject: Re: [dmarc-ietf] DKIM Forwarding History (Provenance) Proposal 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, 29 Jun 2014 23:54:04 -0000 --001a11c1ca16a80aa504fd024106 Content-Type: text/plain; charset=ISO-8859-1 Hi Hector, On Sun, Jun 29, 2014 at 7:58 AM, Hector Santos wrote: > Hi Wei, > > IMO, your proposal is on par with the engineering considerations needed to > develop and mold the charter. Your proposal intent is to preserve the > integrity and indirectly, the authorization for forwarding, resigning mail. > The draft charter has its own even higher complex ideas for the same > intent. My intent is to keep it simple with 3rd party authorization > framework and I don't see any other better method than a DNS-based lookup > method for resigning authorization or allowance. I believe in strong > rejection author domain policies. You can't standardize random, subjective > heuristic methods, but you can standardize deterministic protocol methods. > This is the wider, network persistent and consistent solution that everyone > can use. > > If your offline moderation control messenger intent was to steer the work > towards a specific more. complex, DKIM changing direction, and any negative > discussion about it or censoring other better alternatives, and > specifically authorization methods, are out of scope, then I don't wish to > spend any more time, money and resources in what I strongly believe is > going to be a big waste of time, doesn't resolve the problem, nor does it > eliminate the need to do DNS lookups. > > The person sending me mail offline was just mentioning the WG status as justifying why he brought his conversation offline. I had seen comments regarding the charter status in some recent emails, but when I looked for the ground rules for the mailing list, couldn't find it. I was updated that a spam filter removed the earlier ground rules email. > The ADs need to consider more engineering solutions views that are outside > the same typical folks who have long had control of this project. We are > here today because the DKIM project leaders were incorrect in their > presumptions about the market needs, directions and they seem to be > repeating it again. I don't want to go thru this costly error again. The > draft charter as written is too complex and IMO, it will not solve the main > problem we always had which is how to authorize and scale resigners. > > Your idea is really not that different than what Murray and Dave want to > pursue in the draft with a higher level DKIM processing complexity, long > term prospects which I believe are not necessary and probably unrealistic > to believe people are going to blindly accept with even more expense in > long term experimentation. DKIM was just made into an STD document last > year and already there is consideration in changing. > This proposal means to use DKIM as a building block and doesn't call for changing the DKIM spec. I think there's an opportunity with DMARC IETF standardization process to revisit some of the features that restrict its deployment. The ultimate direction of these proposals will be advance some ideas to address them. I agree that changing the goal posts is a difficult thing, but then preventing Spam and Phishing on our users is also a pretty powerful motivator. I would say that DKIM, SPF, and DMARC are attractive tools to prevent Spam and Phishing and making changes to facilitating their deployment is justified. -Wei > > Thanks > > -- > Hector Santos > http://www.santronics.com > > On Jun 28, 2014, at 8:01 PM, Wei Chuang wrote: > > Hi Hector > > On Sat, Jun 28, 2014 at 8:22 AM, Hector Santos wrote: > >> On 6/28/2014 9:41 AM, Wei Chuang wrote: >> >>> Note this isn't a full proposal as we would like the concept to be >>> considered first. If this discussion is successful, we would like to >>> also >>> discuss a related improvement to SPF and DMARC, as well as the binary >>> encoding change. At the conclusion we can have a longer discussion about >>> the details of CONTENT-TYPE: multipart/dkim-forwarding-history or write >>> a >>> draft that tightly specifies how this works. >>> >> >> Wei, >> >> Any "chain of trust" idea will work with a honored client/server >> negotiated protocol steps and ideals. >> >> The problem has always been in dealing with the deviation from the ideal >> protocol steps and compliancy expectations. >> >> So if you have a protocol ABC, what are the benefits of this ABC >> processing? What is the payoff for the compliant mail receiver? What is >> the payoff for the originating/author domain? > > > The benefit is that the recipient can authenticate the originating sender > and in particular a particular action such as sending to a mailing list, > yet allow intermediate domains to modify messages. It may be that a user > has a filter to see all messages from the original sender. This is jumping > ahead a bit, but the current DMARC paradigm is for the mailing list to own > the message and rewrite the RFC5322.FROM which make this difficult. In > addition SPAM filters likely can benefit from being able to process the > original message and know message was authenticated by the original sending > domain. > > >> What happens when there is deviation, something broke in the chain of >> MIME diffs? What do you want receivers to do? >> > > In this proposal, it would be the same as failing DKIM RFC 6376 verification. > It ought to be treated as information the recipient domain can use for > additional Spam processing etc but not necessarily indicate reject or other > action. This proposal is meant to build infrastructure that can be used to > enhance DMARC in a subsequent proposal. By itself this proposal primarily > provides extra information (well a strong guarantee on the authenticity and > modifications) for Spam processing. > > >> >> You must think of the massive volume of wasteful mail processing. Not >> everyone is going to do this just for nothing. It has to have a meaningful >> payoff, and today that payoff comes in the form of mail filtering policies >> with rejection/quarantine/discard author domain policy concepts. >> >> So if your proposal says: >> >> "If you follow these steps, the author domain >> is OK with you (because you asked him) honoring >> rejection, if you see a problem, then there is >> something wrong with it and its better (trust the >> author policy) if you just reject it." >> >> then we you got something to consider. >> >> But I think in this case, your proposal is a higher processing complexity >> factor when all you need to do is ask the author if the final/last >> signature in the chain is an trusted and/or authorized signer domain. If >> you are not asking the author (directly or indirectly) if any of this >> forwarding stuff is ok, then I think you have a security conflict >> (loophole) to consider. >> >> > I'm probably misunderstanding your intent. Here's a stab at a response: > Passing the DKIM Provenance verification is meant to provide a stronger > verification from a purported original sender. If intermediates want to > claim that a mail came from some original sender, then they have to provide > evidence. If they don't due maliciousness or otherwise, they don't have to > include such evidence but they won't get any benefit of claiming the > reputation of the original sender. > > -Wei > > PS It was mentioned offline that the discussion on dmarc@ietf is > currently restricted to building the WG charter. First apologies I missed > that. Second I can restrict subsequent discussion to apps-discuss if > that's preferred by the WG. > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > > --001a11c1ca16a80aa504fd024106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Hector,

On Sun, Jun 29, 2014 at 7:58 AM, Hector Santos <hsantos@= isdg.net> wrote:
Hi Wei, =A0

IMO, your proposal is on par with the engineering considera= tions needed to develop and mold the charter. =A0Your proposal intent is to= preserve the integrity and indirectly, the authorization for forwarding, r= esigning mail. =A0 The draft charter has its own even higher complex ideas = for the same intent. =A0My intent is to keep it simple with 3rd party autho= rization framework and I don't see any other better method than a DNS-b= ased lookup method for resigning authorization or allowance. =A0I believe i= n strong rejection author domain policies. You can't standardize random= , subjective heuristic methods, but you can standardize deterministic proto= col methods. This is the wider, network persistent and consistent solution = that everyone can use.=A0

If your offline moderation control messenger intent was= to steer the work towards a specific more. complex, DKIM changing directio= n, and any negative discussion about it or censoring other better alternati= ves, and specifically authorization methods, are out of scope, then I don&#= 39;t wish to spend any more time, money and resources in what I strongly be= lieve is going to be a big waste of time, doesn't resolve the problem, = nor does it eliminate the need to do DNS lookups. =A0


The person sending me= mail offline was just mentioning the WG status as justifying why he brough= t his conversation offline. =A0I had seen comments regarding the charter st= atus in some recent emails, but when I looked for the ground rules for the = mailing list, couldn't find it. =A0I was updated that a spam filter rem= oved the earlier ground rules email.
=A0
<= div>The ADs need to consider more engineering solutions views that are outs= ide the same typical folks who have long had control of this project. =A0We= are here today because the DKIM project leaders were incorrect in their pr= esumptions about the market needs, directions and they seem to be repeating= it again. =A0I don't want to go thru this costly error again. =A0The d= raft charter as written is too complex and IMO, it will not solve the main = problem we always had which is how to authorize and scale resigners. =A0=A0=

Your idea is really not that different than what Murray= and Dave want to pursue in the draft with a higher level DKIM processing c= omplexity, long term prospects which I believe are not necessary and probab= ly unrealistic to believe people are going to blindly accept with even more= expense in long term experimentation. DKIM was just made into an STD docum= ent last year and already there is consideration in changing.

This proposal means to use DKIM as a= building block and doesn't call for changing the DKIM spec. =A0I think= there's an opportunity with DMARC IETF standardization process to revi= sit some of the features that restrict its deployment. =A0The ultimate dire= ction of these proposals will be advance some ideas to address them. =A0I a= gree that changing the goal posts is a difficult thing, but then preventing= Spam and Phishing on our users is also a pretty powerful motivator. =A0I w= ould say that DKIM, SPF, and DMARC are attractive tools to prevent Spam and= Phishing and making changes to facilitating their deployment is justified.=

-Wei
=A0
=

Thanks

--Hector Santos

On Jun 28, 2014,= at 8:01 PM, Wei Chuang <weihaw@google.com> wrote:

Hi Hector

On Sat, Ju= n 28, 2014 at 8:22 AM, Hector Santos <hsantos@isdg.net> wrote= :
On 6/28/2014 9:41 AM, Wei Chuang wrote:
Note this isn't a full proposal as we would like the concept to be
considered first. =A0If this discussion is successful, we would like to als= o
discuss a related improvement to SPF and DMARC, as well as the binary
encoding change. =A0At the conclusion we can have a longer discussion about=
the details of CONTENT-TYPE: multipart/dkim-forwarding-history or wr= ite a
draft that tightly specifies how this works.

Wei,

Any "chain of trust" idea will work with a honored client/server = negotiated protocol steps and ideals.

The problem has always been in dealing with the deviation from the ideal pr= otocol steps and compliancy expectations.

So if you have a protocol ABC, what are the benefits of this ABC processing= ? =A0What is the payoff for the compliant mail receiver? =A0What is the pay= off for the originating/author domain? =A0

The benefit is that the recipient can authenticate the originating sender a= nd in particular a particular action such as sending to a mailing list, yet= allow intermediate domains to modify messages. =A0It may be that a user ha= s a filter to see all messages from the original sender. =A0This is jumping= ahead a bit, but the current DMARC paradigm is for the mailing list to own= the message and rewrite the RFC5322.FROM which make this difficult. =A0In = addition SPAM filters likely can benefit from being able to process the ori= ginal message and know message was authenticated by the original sending do= main.
=A0
What happens when there is deviation, someth= ing broke in the chain of MIME diffs? =A0What do you want receivers to do?<= br>

In this proposal, it would be the same as = failing DKIM RFC=A06376=A0verification. =A0It ought to be treated as information the recipient d= omain can use for additional Spam processing etc but not necessarily indica= te reject or other action. =A0This proposal is meant to build infrastructur= e that can be used to enhance DMARC in a subsequent proposal. =A0By itself = this proposal primarily provides extra information (well a strong guarantee= on the authenticity and modifications) for Spam processing.
=A0

You must think of the massive volume of wasteful mail processing. Not every= one is going to do this just for nothing. It has to have a meaningful payof= f, and today that payoff comes in the form of mail filtering policies with = rejection/quarantine/discard author domain policy concepts.

So if your proposal says:

=A0 =A0"If you follow these steps, the author domain
=A0 =A0 is OK with you (because you asked him) honoring
=A0 =A0 rejection, if you see a problem, then there is
=A0 =A0 something wrong with it and its better (trust the
=A0 =A0 author policy) if you just reject it."

then we you got something to consider.

But I think in this case, your proposal is a higher processing complexity f= actor when all you need to do is ask the author if the final/last signature= in the chain is an trusted and/or authorized signer domain. =A0 If you are= not asking the author (directly or indirectly) if any of this forwarding s= tuff is ok, then I think you have a security conflict (loophole) to conside= r.


I'm probably misunde= rstanding your intent. =A0Here's a stab at a response: Passing the DKIM= Provenance verification is meant to provide a stronger verification from a= purported original sender. =A0If intermediates want to claim that a mail c= ame from some original sender, then they have to provide evidence. =A0If th= ey don't due maliciousness or otherwise, they don't have to include= such evidence but they won't get any benefit of claiming the reputatio= n of the original sender.

-Wei

PS It was mentioned = offline that the discussion on dmarc@ietf is currently restricted to buildi= ng the WG charter. =A0First apologies I missed that. =A0Second I can restri= ct subsequent discussion to apps-discuss if that's preferred by the WG.=

_______= ________________________________________
dmarc mailing list=
dmarc@= ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

--001a11c1ca16a80aa504fd024106-- From nobody Sun Jun 29 18:15:37 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1EB41A0086 for ; Sun, 29 Jun 2014 18:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.508 X-Spam-Level: ** X-Spam-Status: No, score=2.508 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 cfk6eFwGdps4 for ; Sun, 29 Jun 2014 18:15:13 -0700 (PDT) Received: from mgmt1.sk.tsukuba.ac.jp (mgmt1.sk.tsukuba.ac.jp [130.158.97.223]) by ietfa.amsl.com (Postfix) with ESMTP id 362101A0080 for ; Sun, 29 Jun 2014 18:15:12 -0700 (PDT) Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id BFEA33FA0B20; Mon, 30 Jun 2014 10:15:11 +0900 (JST) Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id B27941A322F; Mon, 30 Jun 2014 10:15:11 +0900 (JST) From: "Stephen J. Turnbull" To: Hector Santos In-Reply-To: <4A3194BC-A940-4365-B848-BD930650B33F@isdg.net> References: <53AEDDB5.8080702@isdg.net> <4A3194BC-A940-4365-B848-BD930650B33F@isdg.net> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 XEmacs Lucid (x86_64-unknown-linux) Date: Mon, 30 Jun 2014 10:15:11 +0900 Message-ID: <874mz3w63k.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/ZaXj1UEQJe0HKdtvjFkgut-Caqg Cc: Wei Chuang , "dmarc@ietf.org" Subject: Re: [dmarc-ietf] DKIM Forwarding History (Provenance) Proposal 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, 30 Jun 2014 01:15:14 -0000 apps-discuss isn't interested in demarc procedural issues, I suppose. Hector Santos writes: > IMO, your proposal is on par with the engineering considerations > needed to develop and mold the charter. Maybe, that's for Barry to decide, I believe. My opinion is that this part of the discussion has gone far past the development of the charter. I think a suggestion to add proposals "to maintain a history of body changes" in the message to the list in the proposed charter would be in order, of course. I suppose that's your intent, expressed verbosely? > If your offline moderation control messenger intent *My* intent (perhaps he received other advice about topicality) was to provide information about mailing list needs, not to discourage him from anything. I think he will tell you that my message was actually on the whole mildly encouraging. That was my intent, anyway. From nobody Mon Jun 30 06:29:08 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1571A030D for ; Mon, 30 Jun 2014 06:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.654 X-Spam-Level: X-Spam-Status: No, score=-0.654 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.651, 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 b8F-29BubMZU for ; Mon, 30 Jun 2014 06:29:03 -0700 (PDT) Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF9B1A031B for ; Mon, 30 Jun 2014 06:29:03 -0700 (PDT) Received: from [10.0.1.114] (97-82-223-101.dhcp.hckr.nc.charter.com [97.82.223.101]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id D689DCB46 for ; Mon, 30 Jun 2014 09:29:15 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Tim Draegen In-Reply-To: Date: Mon, 30 Jun 2014 09:29:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <08F4BF06-8DDF-4396-B2B7-DFA7D9D6F740@eudaemon.net> References: <539AE0FB.1090909@bbiw.net> <53A098DB.4090801@bbiw.net> <1EFCC6B6-83CD-4D14-9E8E-B72769764E2B@eudev.net> <6DA6615A-B1B4-495D-BE7A-C5BA0770A6C8@eudev.net> <53A48DB1.9080706@gmail.com> To: "dmarc@ietf.org" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/6uo_yQyc2omGUF-TrE7SPLSStJo Subject: [dmarc-ietf] Draft DMARC working group charter 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, 30 Jun 2014 13:29:06 -0000 On Jun 23, 2014, at 1:44 AM, Barry Leiba = wrote: > Let's please stop all the other discussions for now, and say that the > purpose of the mailing list is, for now, to discuss > the charter proposal and converge on a charter for a working group. >=20 > http://trac.tools.ietf.org/wg/appsawg/trac/wiki/DMARC IMO, the proposed Charter does a good job of recognizing the complexity = of the topic, which is why it seems to be long. Two points stick out to me. One of emphasis and one of clarity. 1. I like the break out of different tracks. The divide and conquer = approach would give time and attention to all facets of the work (I = don't see any missing tracks at a high level). As a bonus, maybe specific areas of work can be announced in = advance so that everyone involved knows what to expect. This would help = keep list conversations relevant to the focus of the WG, and would also = allow people time to solicit feedback/participation on specific topics = from interested communities. 2. "The working group will seek to maintain the viability of stable = domain-level identifiers in mail.." This is a powerful statement. I = take this to mean that the WG won't have to focus on the "Why" of stable = domain-level identifiers in mail? If this is the case, I'm suddenly = seeing the WG as being able to focus on the technical work. =3D- Tim From nobody Mon Jun 30 08:44:45 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897CA1A0390 for ; Mon, 30 Jun 2014 08:44:39 -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 VUeTqcPGvUjG for ; Mon, 30 Jun 2014 08:44:38 -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 6C2891A0056 for ; Mon, 30 Jun 2014 08:44:38 -0700 (PDT) Received: (qmail 44176 invoked from network); 30 Jun 2014 15:44:37 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 30 Jun 2014 15:44:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=30d1.53b185e5.k1406; i=johnl@user.iecc.com; bh=6ojKV6+aCZbt5z1HYP0uCXmokZ76G+Bhdomgw6Idq/I=; b=Q8jM2ITPXQACM3k5PvK/zx35UlUDR+dw5p6X4vh7v9nhd4SlqHWoaWtR/7+JBs/1ybJYQAuRiSO+TxNHrlhVDbF8Kzb0aj7dR2QtmQ8gf/R9jQfMY4vYmING1OjCuKsIHawQmZvDfszkNXYyjjb2E5S86moJbOf6ZsCYcjskMTqHmgL+3ift0leLN8eR85LJ8Fqjb5ksAPqGGU1efFB8tOKpwcNBhL5XJwjTEUQiUqLD8wnrdOxdkDiaf6h7Kb6a DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=30d1.53b185e5.k1406; olt=johnl@user.iecc.com; bh=6ojKV6+aCZbt5z1HYP0uCXmokZ76G+Bhdomgw6Idq/I=; b=b7XYQ6PdV2L2MVND6vfaBI/ZP0Mcl/zCpgH594BckOj42SpilHPXP2Fd8MXWBT77UqlpXy7uxaor+lWqSciXisTUBLDVDMTj2j9COOKstwXp9tjSmtwlbs8kRVKRPIkYigQvqPd7Yb6WUqRCd0hnfdGVAX7Is4QPQL9MAtTMYttK5PJPPpTcmvIFQRQRXO6Fg8pA37Ae2D6fmwket9n8yIi0xSYYjmUCynwKj6ZxJqPq/sBt0pOS2pCHJdy3AMVc Date: 30 Jun 2014 15:44:14 -0000 Message-ID: <20140630154414.12496.qmail@joyce.lan> From: "John Levine" To: dmarc@ietf.org In-Reply-To: <08F4BF06-8DDF-4396-B2B7-DFA7D9D6F740@eudaemon.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/EHHxBuWdN5M8xKKrt5z15UQLjFc Cc: tim@eudaemon.net Subject: Re: [dmarc-ietf] Draft DMARC working group charter 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, 30 Jun 2014 15:44:39 -0000 >2. "The working group will seek to maintain the viability of stable domain-level >identifiers in mail.." This is a powerful statement. I take this to mean that the WG >won't have to focus on the "Why" of stable domain-level identifiers in mail? If this >is the case, I'm suddenly seeing the WG as being able to focus on the technical work. I hope we can assume that people who don't see the utility of stable identifiers will consider this project a waste of time and won't bother us. R's, John From nobody Mon Jun 30 08:53:26 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4D61A035C for ; Mon, 30 Jun 2014 08:53: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 bJPHelg5MGS1 for ; Mon, 30 Jun 2014 08:53:20 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97C751A0391 for ; Mon, 30 Jun 2014 08:53:20 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id i57so5082622yha.27 for ; Mon, 30 Jun 2014 08:53:19 -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=KGNolylaC58ELa075jVWoo8cFRRh0mDp/av7wLd2rUQ=; b=czBLMCRu/qd+QB3clnOg90mMK14f9FLjRwHdx1XyNvSyXV8BZuxCOBxs7OiQVq1ynY 70VzaerNcxxHGqFCqO6n7IG0JPN7dmKQ63A43A3OnRnlAAM5jU1+HbOzwCzLouV+Ne4f uyNCppbrKelrPMIz/5Ddg9E0UsySos6mjNi9wK42lnC2Us6ISrXKhSh+c0C15t+E+W6Y y+v89bYcghkDjwNQwmTojrT5UpjYILg/Trdwy7/LvdJt+QawTdOnpm61yyitOE9DIv5Y eAHQRFXLiZW/s8lnDtClrMwSn610BXxFsA4kxXM4dHx5UTQmxNxdxQcwpeWTXMhfcLGe irmw== X-Received: by 10.236.40.81 with SMTP id e57mr60738848yhb.26.1404143599791; Mon, 30 Jun 2014 08:53:19 -0700 (PDT) Received: from [192.168.1.66] (76-218-8-156.lightspeed.sntcca.sbcglobal.net. [76.218.8.156]) by mx.google.com with ESMTPSA id p55sm19411224yhh.34.2014.06.30.08.53.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Jun 2014 08:53:18 -0700 (PDT) Message-ID: <53B1879B.1060808@gmail.com> Date: Mon, 30 Jun 2014 08:51:55 -0700 From: Dave Crocker User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: John Levine , dmarc@ietf.org References: <20140630154414.12496.qmail@joyce.lan> In-Reply-To: <20140630154414.12496.qmail@joyce.lan> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/wtokWZ2ZeyHH0JdWSmLSCORdIu0 Cc: tim@eudaemon.net Subject: Re: [dmarc-ietf] Draft DMARC working group charter 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, 30 Jun 2014 15:53:23 -0000 On 6/30/2014 8:44 AM, John Levine wrote: >> 2. "The working group will seek to maintain the viability of stable domain-level >> >identifiers in mail.." This is a powerful statement. I take this to mean that the WG >> >won't have to focus on the "Why" of stable domain-level identifiers in mail? If this >> >is the case, I'm suddenly seeing the WG as being able to focus on the technical work. > I hope we can assume that people who don't see the utility of stable > identifiers will consider this project a waste of time and won't > bother us. I'm not in love with this phrasing in the current charter draft, but I do believe it useful to state core principles, given the confusion common in this arena of discussion. -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Mon Jun 30 11:31:53 2014 Return-Path: X-Original-To: dmarc@ietfa.amsl.com Delivered-To: dmarc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB421A04AE for ; Mon, 30 Jun 2014 11:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 4dNO-3JgBuZ9 for ; Mon, 30 Jun 2014 11:31:43 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B53401A04A3 for ; Mon, 30 Jun 2014 11:31:43 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id z60so2377861qgd.10 for ; Mon, 30 Jun 2014 11:31:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=O9bY3K37uslDKlxV37vjSXbwnLGep923UCZDmMZB+/g=; b=jlaR8m3ot1di+5pVMh+38ws4hdBww/O/5umM8pxTNeFDTsDUeisbyRmB9CHc5I57/l dymOUjVuBa6QrfoWTOtgmPV5NMd5a/GvtVjM+5ERYgBa1Lel/plPB5/+pP691D5Mb9Jg LOwpOeDzww2ItHQyHGlbIYzC5LV0bi7YRAQExfjB5PDzM6k67/9H0AhdH7fQFd8AW69i HQIcR1m5ND/4S40JSkhOVzSznlaEVljBlba5Dtq3G9jbYrxdvf0OZgKI/l90eyshO3zv yn+ibpOJNAw1xCFD5f4J2Q8swPulWMv717yMGctGn9EStRGtif6nwkPIOgpw3RxyWpVF xw8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=O9bY3K37uslDKlxV37vjSXbwnLGep923UCZDmMZB+/g=; b=JSR5yzsaOObIfUIkH4/Jnqb2nHgjRnIrVyxOPDSBBndqsRgHr0xKHOXkgLgQ4Iiz5y pR/5ZSw1J1T3X6bPNP3G+ZCr4wt5o2KHD1T1MHkSwYpTfCBUZwhn5V+B4jEy5Rx9cFCT f13f1y7kxwdHutudwE1Z570QdrFRPXZLV4UJqZWXjO6btzfEIKeGHbTmfJWuClnuFLyt gxN2G0Ku0gWRkQYrMpah/nlB26QwT8HvQzW/1wuzJp0KbRuXhrAIdLPRnMwSzdYBeenw g67nQVJudYlcPkdJ3pKhfcBL5lsPGluY+q1LtXThzIY8KpoaZ0oiEOsOd/jWlhtLehGf +AfQ== X-Gm-Message-State: ALoCoQmuXqOyRjcT5Fwvx38VBSnI380pyxAFemffcw03C8f+agheJRdpBntlTmevFv/7nsWydvvH X-Received: by 10.229.178.202 with SMTP id bn10mr61783042qcb.6.1404153102933; Mon, 30 Jun 2014 11:31:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.58.1 with HTTP; Mon, 30 Jun 2014 11:31:21 -0700 (PDT) In-Reply-To: References: <53AEDDB5.8080702@isdg.net> From: Wei Chuang Date: Mon, 30 Jun 2014 11:31:21 -0700 Message-ID: To: Hector Santos Content-Type: multipart/alternative; boundary=001a11c2be92e93dc004fd11de26 Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/lrsSBfqCMgxB2Ih6S6kDDUY7Wwk Cc: "dmarc@ietf.org" , apps-discuss Subject: Re: [dmarc-ietf] DKIM Forwarding History (Provenance) Proposal 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, 30 Jun 2014 18:31:45 -0000 --001a11c2be92e93dc004fd11de26 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Jun 28, 2014 at 5:01 PM, Wei Chuang wrote: > > > PS It was mentioned offline that the discussion on dmarc@ietf is > currently restricted to building the WG charter. First apologies I missed > that. Second I can restrict subsequent discussion to apps-discuss if > that's preferred by the WG. > > I got in touch with the moderators. The list discussion is still charter oriented, so I'm moving any discussion of this proposal to apps-discuss@ietf.org. Hopefully the charter discussion wraps up soon. Thanks, -Wei --001a11c2be92e93dc004fd11de26 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sat, Jun 28, 2014 at 5:01 PM, Wei Chuang <<= a href=3D"mailto:weihaw@google.com" target=3D"_blank">weihaw@google.com= > wrote:


PS It was mentioned offline that the discussion on= dmarc@ietf is currently restricted to building the WG charter. =A0First ap= ologies I missed that. =A0Second I can restrict subsequent discussion to ap= ps-discuss if that's preferred by the WG.


I got in= touch with the moderators. =A0The list discussion is still charter oriente= d, so I'm moving any discussion of this proposal to apps-discuss@ietf.org. =A0Hopefully the charter d= iscussion wraps up soon. =A0

Thanks,
-Wei=A0

--001a11c2be92e93dc004fd11de26--