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