Re: [ietf-822] WSJ/gmail/ML, was a permission to...
2014-05-03 16:14:13
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(_at_)pscs(_dot_)co(_dot_)uk, ietf-822(_at_)ietf(_dot_)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(_at_)pscs(_dot_)co(_dot_)uk>
List-Id: <ietf-822.ietf.org>
List-Post: <mailto:ietf-822(_at_)ietf(_dot_)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(_at_)pscs(_dot_)co(_dot_)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 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [ietf-822] WSJ/gmail/ML, was a permission to..., (continued)
- Re: [ietf-822] WSJ/gmail/ML, was a permission to..., Hector Santos
- Re: [ietf-822] WSJ/gmail/ML, was a permission to..., Arnt Gulbrandsen
- Re: [ietf-822] WSJ/gmail/ML, was a permission to..., Dave Crocker
- Re: [ietf-822] WSJ/gmail/ML, was a permission to..., Arnt Gulbrandsen
- 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..., Alessandro Vesely
Re: [ietf-822] WSJ/gmail/ML, was a permission to..., Paul Smith
- Re: [ietf-822] WSJ/gmail/ML, was a permission to...,
Hector Santos <=
Re: [ietf-822] WSJ/gmail/ML, was a permission to..., Paul Smith
Re: [ietf-822] WSJ/gmail/ML, was a permission to..., Miles Fidelman
Re: [ietf-822] WSJ/gmail/ML, was a permission to... (off-topic), S Moonesamy
Re: [ietf-822] WSJ/gmail/ML, was a permission to... (off-topic), Miles Fidelman
Re: [ietf-822] WSJ/gmail/ML, was a permission to... (off-topic), Ned Freed
Re: [ietf-822] WSJ/gmail/ML, was a permission to... (off-topic), S Moonesamy
|
|
|