Re: [ietf-822] WSJ/gmail/ML, was a permission to...
Hector Santos <hsantos@isdg.net> Sat, 03 May 2014 21:14 UTC
Return-Path: <hsantos@isdg.net>
X-Original-To: ietf-822@ietfa.amsl.com
Delivered-To: ietf-822@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459DB1A0134 for <ietf-822@ietfa.amsl.com>; Sat, 3 May 2014 14:14:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.801
X-Spam-Level:
X-Spam-Status: No, score=-100.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, J_CHICKENPOX_41=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 YiCNHXfWWufp for <ietf-822@ietfa.amsl.com>; Sat, 3 May 2014 14:14:01 -0700 (PDT)
Received: from pop3.winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 630D61A0133 for <ietf-822@ietf.org>; Sat, 3 May 2014 14:14:01 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4893; t=1399151630; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=FlBKR8qziqmcyjt+/TI+NWR7x6E=; b=uW0/AMkhvt/6i5hN1Njv D0qpvpv9HV059oaqp1/c/POK3G+1CyR79eFpbIyuKRbQUBmsvVJvSgo47YHQDbL6 f5PrKjQWaeJaZBRcMI3LFYDYd6MwVRsoR5+d0KDoFzYF3ALE/ywUYrYVs1/UIvHl 4/4HZbyZdCAUkxZ+phtu7cU=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf-822@ietf.org; Sat, 03 May 2014 17:13:50 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com;
Received: from beta.winserver.com (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2260188942.3325.3096; Sat, 03 May 2014 17:13:49 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4893; t=1399151532; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=EPkoU98 NvIWnxACqk1i8vjG19bBDx/I/0KZ28lr20/I=; b=GOm0YmctB+OKnNsP+DQQqPf SP3VoWU/pRHXh0HWoCw7m/HOmV8d95cVKrlgv11/mRc1eSJTnflD7qer4MHi+H8a z5S6apAuvS2Fh2I7ON54KSdlLGf/9yMxl2s8gJG9ygMAc1uSd7d87ZFd784blgQI Ae8QgCGqF3s3un2H8sKM=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for ietf-822@ietf.org; Sat, 03 May 2014 17:12:12 -0400
Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2279708343.9.14140; Sat, 03 May 2014 17:12:11 -0400
Message-ID: <53655C13.9070201@isdg.net>
Date: Sat, 03 May 2014 17:13:55 -0400
From: Hector Santos <hsantos@isdg.net>
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Paul Smith <paul@pscs.co.uk>, ietf-822@ietf.org
References: <20140418123721.3610.qmail@joyce.lan> <5365357D.2020101@tana.it> <53653C7A.3090304@pscs.co.uk>
In-Reply-To: <53653C7A.3090304@pscs.co.uk>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-822/Y4M4qjEj7SaqauaJ7Wb4zgX55Ug
Subject: Re: [ietf-822] WSJ/gmail/ML, was a permission to...
X-BeenThere: ietf-822@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion of issues related to Internet Message Format \[RFC 822, RFC 2822, RFC 5322\]" <ietf-822.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-822>, <mailto:ietf-822-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-822/>
List-Post: <mailto:ietf-822@ietf.org>
List-Help: <mailto:ietf-822-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-822>, <mailto:ietf-822-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 May 2014 21:14:05 -0000
On 5/3/2014 2:59 PM, Paul Smith wrote: > Who is the 'author' of the message? The message you received is NOT > the one I sent. So, I'm not the author, so why am I in the 'From' > field? So, arguably, the From field should be changed. Possibly it > should be changed to: > > From: paul@pscs.co.uk, ietf-822@ietf.org > > because we both, "collaboratively", wrote the message. However, this > would probably break some mail clients/filters/etc because using > multiple From addresses is not "normal". Paul, You need to translate this technical philosophy into client/server protocol rule which means that the authoring domain has authorized resigning with a DMARC policy. Otherwise, its will be detected as an unauthorized signer, spoofed mail. It is far easier to fix DMARC which is still in draft form than to get into complex, borderline ethical, long time taboos of tampering with the 5322.From. To do a visual display "Posted on behalf of" does not require a header change. That could be an online MUA backend server rendering or offline MUA mail reader that takes the mail headers: From: Paul Smith <paul@pscs.co.uk> List-Id: <ietf-822.ietf.org> List-Post: <mailto:ietf-822@ietf.org> and displays it in some way in the MUA: From: Paul Smith (Posted by ietf-822.ietf.org) But thats not the problem. The problem is when we dealing with the BAD mail. Lets suppose you began to sign all your mail with pscs.co.uk at your server so that all your outbound mail has: From: Paul Smith <paul@pscs.co.uk> Dkim-Signature: d=pscs.co.uk This is considered a 1st party signature. An central issue is how strong do you wish to make this signing practice. You need to tell the world what to expect about your signed mail: Do you always sign your mail or is it optional? Do you always sign your mail with psca.co.uk? Do you allow others to sign on your behalf? If so, who? To do this, suppose you published a DMARC record: v=dmarc1 p=reject ...... which basically means only psca.co.uk always the mail. No one else. Now, when you send mail to non-list receivers, direct to people, you will want the protection that DMARC offers at these receiver sites. However, when you send mail to the IETF-822 list receivers, hopefully you want the list to also protect your domain by honoring your policy and only allow a valid 1st party signature submissions from you, reject it if not valid. But now you also want to give the list server permission to resign. So basically what you want is to give the ietf.org domain permission to resign. How is that done? There are currently one way to do this using ADSP ATPS, ASL or TPA extensions. ADSP was used as to piggy back to extend 3rd party policy information. Since ADSP is now historic, lets switch this to DMARC instead with the extensions. Using ASL, your DMARC record changes to: v=dmarc1 p=reject asl=ietf.org ...... This simple small scale change fixes the problem by allowing all parties to see that your domain is allowing ietf.org to resign the mail. It is "small scale" because you would be limited in the record size in how many domains you can fit in a TXT DMARC string record. For larger scale, using Murray's ATPS (RFC6541 ) extension, the DMARC record is: v=dmarc1 p=reject atps=y ...... The atps=y tag say to check for "_atps." zone record for the signing domain, ietf.org, authorization. You can create and see this record at the wizard http://www.winserver.com/public/wcadsp ; ; ATPS (v01) Zone Records for author-domain: psca.co.uk ; Generated by wcMakeADSP v3.11(c) copyright 2010 Santronics Software,Inc. ; _adsp._domainkey TXT ("dkim=all; atps=y; asl=ietf.org;") PQ6XADOZSI47RLUIQ5YOHG2HY3MVJYOO._atps TXT ("v=atps01; d=ietf.org;") I think this is is very simple and elegant solution. Doug has TPA with similar zone records tags and labels to lookup. Its all basically the same ideas. Either way, we somewhat resolved the technical problem but we are left with the practical problem of getting the list operators/servers to even bother to do any POLICY lookup of any kind. If the IETF had supported ADSP/ATPS back in DKIM-WG, this would of been a done deal long ago. Yahoo's DMARC record would of been: v=dmarc1 p=reject atps=y and there would be 30,000 ATPS records for all the purported list that yahoo says their users are members of. 30,000 DNS records for _atps authorizations? Is that too much? I'm sure it is, but i don't see realistic for most domains to see close to that much, not even 100 or even 50. How many list domains do you believe too? What would be the average number of list domains the average user belongs too? The IETF SHOULD endorse 3rd party Authorization ideas so we can begin to finally solve this problem. I'm done. -- HLS
- [ietf-822] A permission to re-sign header John Levine
- Re: [ietf-822] A permission to re-sign header Alessandro Vesely
- Re: [ietf-822] A permission to re-sign header John Levine
- Re: [ietf-822] A permission to re-sign header Hector Santos
- Re: [ietf-822] A permission to re-sign header Murray S. Kucherawy
- Re: [ietf-822] A permission to re-sign header John R Levine
- Re: [ietf-822] A permission to re-sign header Murray S. Kucherawy
- Re: [ietf-822] A permission to re-sign header John R Levine
- Re: [ietf-822] A permission to re-sign header Pete Resnick
- Re: [ietf-822] A permission to re-sign header Pete Resnick
- Re: [ietf-822] A permission to re-sign header John R Levine
- Re: [ietf-822] A permission to re-sign header Pete Resnick
- Re: [ietf-822] A permission to re-sign header John R Levine
- Re: [ietf-822] A permission to re-sign header Alessandro Vesely
- Re: [ietf-822] A permission to re-sign header Michael Richardson
- Re: [ietf-822] A permission to re-sign header Michael Richardson
- Re: [ietf-822] A permission to re-sign header Theodore Ts'o
- Re: [ietf-822] A permission to re-sign header Pete Resnick
- Re: [ietf-822] A permission to re-sign header Miles Fidelman
- Re: [ietf-822] A permission to re-sign header John Levine
- Re: [ietf-822] one can re-sign without a permissi… Ned Freed
- Re: [ietf-822] one can re-sign without a permissi… Alessandro Vesely
- Re: [ietf-822] A permission to re-sign header Ned Freed
- Re: [ietf-822] A permission to re-sign header Alessandro Vesely
- Re: [ietf-822] A permission to re-sign header Paul Smith
- Re: [ietf-822] don't need a permission to re-sign… John Levine
- Re: [ietf-822] don't need a permission to re-sign… Ned Freed
- Re: [ietf-822] don't need a permission to re-sign… John R Levine
- Re: [ietf-822] don't need a permission to re-sign… Ned Freed
- Re: [ietf-822] one can re-sign without a permissi… Alessandro Vesely
- Re: [ietf-822] one can re-sign without a permissi… Ned Freed
- Re: [ietf-822] one can re-sign without a permissi… Pete Resnick
- Re: [ietf-822] one can re-sign without a permissi… Douglas Otis
- [ietf-822] We need a DKIM Policy Working Group Hector Santos
- Re: [ietf-822] We need a DKIM Policy Working Group S Moonesamy
- Re: [ietf-822] one can re-sign without a permissi… John Levine
- Re: [ietf-822] one can re-sign without a permissi… John Levine
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Miles Fidelman
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Alessandro Vesely
- Re: [ietf-822] one can re-sign without a permissi… Douglas Otis
- Re: [ietf-822] one can re-sign without a permissi… Pete Resnick
- Re: [ietf-822] one can re-sign without a permissi… Alessandro Vesely
- Re: [ietf-822] one can re-sign without a permissi… Paul Smith
- Re: [ietf-822] one can re-sign without a permissi… John R Levine
- Re: [ietf-822] one can re-sign without a permissi… Hector Santos
- Re: [ietf-822] one can re-sign without a permissi… Douglas Otis
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Alessandro Vesely
- Re: [ietf-822] one can re-sign without a permissi… Hector Santos
- [ietf-822] WSJ/gmail/ML, was a permission to... Alessandro Vesely
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… John R Levine
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Paul Smith
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Rolf E. Sonneveld
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Hector Santos
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Michael Richardson
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Paul Smith
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Alessandro Vesely
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Miles Fidelman
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… John R Levine
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… John Levine
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Arnt Gulbrandsen
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… John Levine
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Ned Freed
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Dave Crocker
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Ned Freed
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… John R Levine
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… John R Levine
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Arnt Gulbrandsen
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Bart Schaefer
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Hector Santos
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… John Levine
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Michael Richardson
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Michael Richardson
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… John Levine
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Ned Freed
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Michael Richardson
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Michael Richardson
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Russ Allbery
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Brandon Long
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Brandon Long
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Arnt Gulbrandsen
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Alessandro Vesely
- Re: [ietf-822] one can re-sign without a permissi… Paul Smith
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Hector Santos
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… John R Levine
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Ned Freed
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… S Moonesamy
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Russ Allbery
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Hector Santos
- Re: [ietf-822] one can re-sign without a permissi… Brandon Long
- Re: [ietf-822] one can re-sign without a permissi… Murray S. Kucherawy
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Miles Fidelman
- Re: [ietf-822] one can re-sign without a permissi… John R Levine
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Ned Freed
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… S Moonesamy
- Re: [ietf-822] one can re-sign without a permissi… John Levine
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Miles Fidelman
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Scott Kitterman
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Russ Allbery
- Re: [ietf-822] one can re-sign without a permissi… Murray S. Kucherawy
- Re: [ietf-822] one can re-sign without a permissi… John R Levine
- Re: [ietf-822] one can re-sign without a permissi… Hector Santos
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… S Moonesamy
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Paul Smith
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Alessandro Vesely
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Miles Fidelman
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… John Levine
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… John Levine
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Brandon Long
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Brandon Long
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Russ Allbery
- [ietf-822] Aptness of DKIM for MLs Alessandro Vesely
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Alessandro Vesely
- Re: [ietf-822] Aptness of DKIM for MLs S Moonesamy
- Re: [ietf-822] Aptness of DKIM for MLs Alessandro Vesely
- Re: [ietf-822] Aptness of DKIM for MLs S Moonesamy
- Re: [ietf-822] Aptness of DKIM for MLs Hector Santos
- Re: [ietf-822] Aptness of DKIM for MLs Douglas Otis
- Re: [ietf-822] Aptness of DKIM for MLs Alessandro Vesely
- Re: [ietf-822] Aptness of DKIM for MLs Douglas Otis
- Re: [ietf-822] WSJ/gmail/ML, was a permission to.… Douglas Otis
- Re: [ietf-822] Aptness of DKIM for MLs Alessandro Vesely
- Re: [ietf-822] one can re-sign without a permissi… Douglas Otis