When we look at DKIM and the DMARC protocol by exposing the boundary
conditions of the protocol, it helps with laying the groundwork for a
protocol-complete model.
DKIM has three possible signature states:
- NONE (no valid signature)
- 1PS (1st party valid signature, Author.domain == Signer.domain)
- 3PS (3rd party valid signature, Author.domain != Signer.domain)
DMARC has three polices:
- none
- quarantine
- reject
With these 3x3=9 states, the following table with the boundary
conditions of the protocol is established with the expected and
potential actionable result:
DMARC POLICY
+===================================================+
|////// | p=NONE | p=QUARANTINE | p=REJECT |
|===================================================|
D | NONE | fail-pass | fail-filter | fail-reject |
K |-------+------------+------------------------------|
I | 1PS | pass | pass | pass |
M |-------+------------+------------------------------|
| 3PS | fail-pass | fail-filter | fail-reject |
+===================================================+
Note: I intentionally left out SPF conditions for NONE, NEUTRAL,
SOFTFAIL and HARDFAIL. SPF adds an additional 9x4 or 36 total states.
For this exercise, we are assuming DMARC/SPF alignment is in play
and failure can be for any DMARC known reason including the 3PS failed
states.
The states for DKIM none and 1PS are expected protocol conditions.
DMARC describes these conditions. But the DKIM 3PS conditions are not
described and are subject to questionable actions because of the
possible false positives results.
The 3PS failures occur because of the dearth for an Authorized Third
party Signature protocol. DMARC does not offer 3rd party signature
solutions nor semantics, nor did the ADSP RFC5716 [1] proposal. But
they did not restrict an ADD-ON extension to the protocol.
ATPS RFC6541 [2] was one such add-on proposed extension to ADSP and
when DMARC replaced ADSP, it equally applies to DMARC as well as an
extension. We do not need to get into the specific ATPS protocol
details on how to authorize a 3rd party signer. Any "ATPS-like"
protocol will only need to answer one question:
Is the 3rd party (re)signer authorized? Yes or NO
With this consideration, the table has one additional 3PS-AUTH row
meaning Yes, the 3rd party (re)signer domain was authorized by the
author domain.
DMARC POLICY W/ ATPS
+======================================================+
|////// | p=NONE | p=QUARANTINE | p=REJECT |
|======================================================|
D | NONE | fail-pass | fail-filter | fail-reject |
K |----------+------------+------------------------------|
I | 1PS | pass | pass | pass |
M |----------+------------+------------------------------|
| 3PS | fail-pass | fail-filter | fail-reject |
|----------+------------+------------------------------|
| 3PS-AUTH | pass | pass | pass |
+======================================================+
Overall, as it was originally conceived, the DKIM Policy model can not
ignore ATPS conditions because as you can see above, it would not be
protocol-complete -- it is missing the 3PS-AUTH conditions.
While ADSP is a specific RFC proposed protocol, I am using it as an
acronym for any authorizing third party signature concept:
Result = DKIM_ATPS(author.domain, signer.domain)
Lets finish that part of the DKIM model.
Thanks
[1] https://tools.ietf.orgy/html/rfc5617
[2] https://tools.ietf.org/html/rfc6541
--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
