> The protocol consistency must be consistent for the entire x822.From domain > list. At best, we can recommend that the signer use the "primary" domain > it is signing for, as the first address in the list. This might require > reordering of the list when the message is first submitted for signing. > > Example of reordering (optional optimization) > > From: A, C, B, D > > A new message was created by a user B and he wishes to add co-authors A, C > and D to the From: header. For some odd-ball, but still technically legal > reason, the user B address is not the first: > > Nonetheless, User B submits it to his/her MSA and the MSA signing for > domain B can reorder this prior to signing: > > From: B, A, C, D > Dkim-Signature: d=B >
+1 > > +-[ NOTE ]+-------------------------------------------+ > | | > | The MSA may also want to check the SSP for domains | > | A, C and D to make sure they are not DKIM=STRICT. | > | See Note1 below on this. | > | | > +-----------------------------------------------------+ I am not so sure about this, please see my reasoning below > > As the logic is currently defined, a 3PS (3rd Party Signature) is when the > DKIM d= domain is not matching the x822.From domain part. > I believe that 3rd party signing and this issue are separate. > So in this case, the signature d=B helps by checking the primary domain B > regardless of the From: list order. Only if d=B and there has been a reorder. Without the reorder, the responsible party (at least in the readers eyes) is A. > > The Sender:, if provided, can possible add "weigh" if it was also pointing > to domain B. > > Sender: B > From: A, C, B, D > Dkim-Signature: d=B > > and under this "all" matching case, there would be no need to reorder the > From: list. > > o Missing Signature > > Of course, the situation is when we don't have a signature and we want to > find what policies apply to the unsigned message. > > I don't think we can trust relying on Sender: especially if the domain is > not among the From: list. So at best, an verifier can possible choose to > use Sender: only if it matches and it helps define the order of the > preferred lookup. I believe that we should say that in the absence of a d= the first from address will be the default author. > > In all cases, we can not violate the basic principle in SSP From: domain > requirement - the single From: domain logic must be consistent with a > multiple From: domains logic. > > Note #1: > > What rule is necessary for multiple SSP policies? > None. Regardless of the policies of the other From: addresses, if a d= exists and there has been a reorder, the author is, at this point, defaulted to the first address. Anything else and we are going to break VERP implementations. > This question pertains to how mixed SSP policies are interpreted. > > In order to be protocol consistent, IMO, any domain exposing a DKIM=STRICT > or DKIM=ALL policy can not be violated by other mixed restrictive policies. > > I think we need to look at the mixed possibilities in order to get a handle > on this multiple From: domains SSP logic. Here are few examples: > > Example 1: > > From: A, B, C > DKIM-signature: d=A > > A --> DKIM=STRICT > B --> NO SSP (DKIM=UNKNOWN) > C --> NO SSP (DKIM=UNKNOWN) > > Issues: > > I see no Issue. Perfect SSP/DKIM protection. If the message > was not signed, then it would be viewed as suspicious. Agree > > Example 2: > > From: A, B, C > DKIM-signature: d=B > > A --> DKIM=STRICT > B --> NO SSP (DKIM=UNKNOWN) > C --> NO SSP (DKIM=UNKNOWN) > > Issues: > > Domain A is unprotected. This message should be suspicious. Disagree- There should be a reorder in this case where after processing: From: B,A,C DKIM-signature: d=B A is no longer the author. > > Example 3: > > From: A, B, C > DKIM-signature: d=A > > A --> DKIM=STRICT > B --> DKIM=ALL > C --> DKIM=STRICT > > Issues: > > Can't have two DKIM=STRICT? > > One consideration might be, maybe as long as a valid > signature was found any of the STRICT domains, in this case > D=A matches one of the STRICT domains, this this may be an > exemption. > This is ok. The author is correctly identified and checked. > However, this would be a LOOPHOLE if we allow this. > > Example 4: > > From: A, B, C > DKIM-signature: d=B > > A --> DKIM=STRICT > B --> DKIM=ALL > C --> DKIM=STRICT > > Issues: > > Even though domain B allows anyone to sign, can it sign > on its own behalf and still use strict co-domains? > > If we allow this, then we have a loophole. > Disagree- If we allow reordering, it would then be allowed. > > -- > Sincerely > > Hector Santos, CTO > http://www.santronics.com > > Regards, Damon Sauer _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
