DMARC Extension for 3rd party Signers

On 4/20/2014 12:17 AM, Scott Kitterman wrote:

>> Where is the alignment requirement description for when only p=reject
>> is used?
>
> See section 3.1.4 of the current DMARC draft.
>

Got it. I see the problem.  DMARC by definition requires alignment for 
matching domains. An adkim=s (strict) is an exact match and adkim=r 
(relaxed) means sub-domains are allowed.

 From what I see, there is no 3rd party allowance and the only things 
that saves you is p=none or p=quarantine.

This will need an extension if the DMARC draft is locked down. 
Section 3.1.4.3 talks about authentication extensions:

    3.1.4.3.  Alignment and Extension Technologies

    If DMARC is extended to include the use of other authentication
    mechanisms, the extensions will need to allow for domain identifier
    extraction so that alignment with the RFC5322.From domain can be
    verified.

This would be a simple first step consideration -- A new ATPS tag

   atps=0  default, extension disabled allowed backward compatibility.
   atps=1  Valid alignment allows a valid 3rd party signature.
   atps=2  Valid alignment allows a valid 3rd party signature with ATPS
           (Authorized 3rd Party Signer) checking, RFC6541.

atps=1 basically declares a relaxed MUST SIGN policy.  atps=2 means 
the 3rd party signer must be authorized using RFC6541.

Lets go further using Pete's idea:

   atps=3  Valid alignment allows a valid 3rd party signature using
           the May-Resign header/token.


-- 
HLS


_______________________________________________
ietf-822 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-822