Re: WSJ/gmail/ML, was a permission to...

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: [email protected], [email protected]
>
> 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 <[email protected]>
    List-Id: <ietf-822.ietf.org>
    List-Post:  <mailto:[email protected]>

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 <[email protected]>
    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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-822