Hi Stephen,
The 2006 DSAP "DKIM Signature Authorization Protocol" draft
concentrated on the process boundary conditions (possible values for
1st and 3rd party conditions). Section 4.2 summaries the boundary
conditions:
http://tools.ietf.org/html/draft-santos-dkim-dsap-00#section-4.2
4.2. DSAP Tags: op=<signing-policy>; 3p=<signing-policy>;
From the viewpoint of the verifier, when a message is received, there
are two basic pieces of signature information to be of interest when
analyzing the transaction:
o Original Party Signatures (OP)
* never expected
* always expected
* optional
o 3rd Party Signatures (3P)
* never expected
* always expected
* optional
When the two signature types are combines, the possible policies are
listed in this following table:
+=================================================================+
| op= | 3p= | Domain Policy Semantics |
|=================================================================|
| empty | empty | No mail expected |
|-----------------------------------------------------------------|
| never | never | No signing expected |
| never | always | Only 3P signing expected |
| never | optional | Only 3P signing optional |
|-----------------------------------------------------------------|
| always | never | OP signature expected |
| always | always | Both parties expected |
| always | optional | OP expected, 3P may sign |
|-----------------------------------------------------------------|
| optional | never | Only OP signing expected |
| optional | always | OP expected, 3P expected |
| optional | optional | Both parties may sign. |
+-----------------------------------------------------------------+
Figure 4: DSAP Message Signing Policies
Section 3.3 basically provided some simple guidelines for a MLS:
http://tools.ietf.org/html/draft-santos-dkim-dsap-00#section-3.3
The term DMARC can be swapped in the section since its really about a
general DKIM+POLICY and it doesn't matter if it was SSP, ADSP, DSAP or
DMARC:
3.3. Mailing List Servers
Mailing List Servers (MLS) applications who are compliant with DKIM
and DMARC operations, SHOULD adhere to the following guidelines:
Subscription Controls
MLS subscription processes should perform a DMARC check to
determine if a subscribing email domain DMARC 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 DMARC 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.
However, the same issues of integrity changes was apparent then as it
is now. The only way to minimize the impact is to first support it and
only deal with the optional policies. In other words, allow the
YAHOO's to change their policies to FIT a proper end to end protocol
(that means DMARC MUST offer 3rd party policies) that does include and
allow the MLS to fit in -- PROPERLY without all this hacking and
"ignore DMARC" and 5322.From destruction mentality going on that is
only going to work with selected groups or systems, if that, leaving a
security hole for the rest of the world to deal with.
Keep in mind that as much as DKIM wishes to separate the AUTHOR from
the SIGNER domain, it can not. It is BURNED into the spec as the
single most important binding requirement -- That means it can't
change and thats the purpose of this *security* concept. Breaking it
and assuming the original domains will allow this to occur
unchallenged is not a good idea, playing with fire.
Have a good day Stephen
--
Hector Santos
http://www.santronics.com
On 10/6/2014 10:29 PM, Stephen J. Turnbull wrote:
Hector Santos writes:
> The 2006 DSAP draft section 3.3 Mailing List Servers suggest some
> simple basic concepts that I believe is near universal.
URL, please. I never heard of this concept before. To this MLM
developer, your heavily abbreviated description doesn't make the
utility of the concept clear, but I suppose the original document
explains in more detail.
> But by 2009, the actual suggested implementation changes were done
> outside the MLS component. See my point?
Nope. Need context.
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
