Summary:
I would like to reintroduce the DSAP (DKIM Sender Authorization Protocol) as a
DMARC extended tag extension -dsap. The original DSAP draft covered nine 1st vs
3rd party signature policies from a verifier viewpoint, which addressed
boundary conditions for DKIM signatures. The reintroduction aims to address
concerns regarding 3rd party resigners.
Key changes proposed for DMARC integration:
o Introduce -dsap tag for DSAP support, covering a complete range of possible
policies.
o Use -asl tag for inline list of authorized signer support.
o Implement -atps tag for ATPS support.
o Formalize the From rewrite logic with a -rewrite tag.
o Introduce -target tag to assist mail forwarders with authorized redirection
of exclusive policies.
The proposal seeks to offer better integration with today's wide range of mail
applications, building on the existing DMARC protocol and improving 3rd party
authorization and reporting.
Background:
In 2006, I submitted an I-D DSAP “DKIM Sender Authorization Protocol” that
covers the boundary conditions for 1st vs 3rd party signature expectations.
There are nine 1st vs 3rd party signature policies in DSAP from a verifier
viewpoint:
Original 1st Party Signature (OPS)
Not expected (-)
Expected (+)
Optional (~)
Third Party Signature (3PS)
Not expected (-)
Expected (+)
Optional (~)
Using these expectations, DSAP can cover most if not all possible Boundary
Conditions for DKIM signatures.
I would like to re-propose DSAP but this time as a DMARC extended tag extension
`-dsap` as I believe it can address our concerns regarding 3rd party resigners.
Here is the 2006 DSAP proposal I plan on updating to support DMARC and ATPS:
https://datatracker.ietf.org/doc/html/draft-santos-dkim-dsap-00
History:
The DKIM Policy Model began with SSP “Sender Signature Practices/Policy.” This
image illustrates the overall process:
Many today do not realize the original DKIM included Signature Policy protocol
called SSP. It was spit into DKIM-BASE and DKIM-SSP to help speed up the
process. DKIM was well defined but SSP was not. SSP covered various signing
scenarios, however, there were 3 policies missing which DSAP covered:
The DMARC protocol offers an exclusive only policy with p=reject|quarantine.
This would be a -dsa=OP+,3P- policy With DMARC p=none, no other policy possible
in terms of expectation other than an unhandled failed exclusive policy. So
DMARC is very limited making it a very to integrate with today’s wide range of
mail applications.
DMARC also introduced two more takes that I would like use replaced with DMARC
and ATPS.
For Reporting, DSAP provides tags for failure reports. This is now well-defined
with DMARC. [DSAP only considered failure reports].
For 3rd party authorization, DSAP provided the -asl tag. The asl tag was an
inline small domain list tag. But it can also signify a check using ATPS for
higher scale applications.
Everything would be the same with DMARC and DMARCbis. The change would be:
-dsap tag for DSAP support for the complete range of possible policies.
-asl for inline list of authorize signer support
-atps for ATPS support
I would also like to formalize the From rewrite logic with a tag:
-rewrite
Which tells a resigner it may rewrite the From under certain conditions.
-target is a new tag to help mail forwarders.
DMARC has considerations for SPF results with a strong alignment requirement.
One scenario where a -dsap=op+,3p- is with SPF hard failure during mail
forwarding. The -target will allow a forwarder to resign as a 3rd party
without -asl or -atps requirements.
—
Hector Santos, CEO/CTO
Santronics Software, Inc,_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
