| Santronics Online |
 |
DKIM Policy Zone Record Generator and Test Simulator v2.6
This wizard helps prepare the ZONE records for DKIM ADSP authorized third party policies.
It also allows you test it against various signer domains. Read Description Below
Legend:
| AUTHOR-DOMAIN | The domain part of the email message From: header field |
| SIGNER-DOMAIN | The domain in the DKIM-Signature d= tag is the responsible signer of the message. |
| 1st Party Signature | This is when the AUTHOR-DOMAIN and SIGNER-DOMAIN are the same. |
| 3rd Party Signature | This is when the AUTHOR-DOMAIN and SIGNER-DOMAIN are NOT the same. |
ADSP is a policy layer for DKIM. It is an optional protocol to help
protect domain signers against unauthorized signing (spoofing and
phishing).
The IETF documents provide the details:
DomainKeys Identified Mail (DKIM) Signatures
Analysis of Threats Motivating DKIM
Requirements for a DKIM Signing Practices Protocol
DKIM Author Domain Signing Practices (ADSP)
DKIM Authorized Third-Party Signers (ATPS)
DKIM Allowed Signer List (ASL)
New extensions to ADSP offers a way to authorized third party
signatures.
The ATPS proposal adds an optional tag to the ADSP record called
"atps=y". If set, then additional TXT records per signer can be checked
for authorization.
The ASL proposal combines a simple lite weight method to define a list
of allowed signers in a ADSP record tag called "asl=".
Example ADSP records:
#1 _adsp._domainkey.example.com = dkim=all;
#2 _adsp._domainkey.example.com = dkim=all; asl=gmail.com
#3 _adsp._domainkey.example.com = dkim=all; atps=y; asl=gmail.com
In example #1, there is no third party authorization preparation. Only
example.com can sign its own mail. However, ambiguities in the ADSP
specifications can allow for others to sign for example.com.
In example #2, example.com is declaring only itself and gmail.com can sign
mail on its behalf.
In example #3, example.com is declaring only itself and gmail.com can sign
mail on its behalf. However, with atps=y set, other third party signers
may be authorized using atps DNS txt records using a special hashing
method to prepare the sub-domain record:
base32(sha1(SIGNER-DOMAIN))._atps.example.com
The SIGNER-DOMAIN is obtain from the DKIM-Signature d= tag value.
This wizard helps prepare the ZONE record for all the ASL/ATPS options.
It also allows you test it against various signer domains. The two
proposed changes to ATPS:
[_] Add ATPS record value with domain name
[_] Support ATPS Sub Domains Lookups
The first one is designed to help with manual editing of zone files to
help associate the signer domain ATPS hashes.
The second option allows you to create a single ATPS record for the
originating domain sub-domains using a wildcard hashing of the
author-domain, i.e. *.example.com.
The ASL draft is still under construction. The following are the steps
the ADSP ASL/ATPS verifier will perform:
1) Obtain the AUTHOR-DOMAIN and perform TXT query the ADSP
record to obtain the value.:
_adsp._domainkey.AUTHOR-DOMAIN
2) If no ADSP record is found (NXDOMAIN), return ADSP=NONE
3) Obtain the SIGNER-DOMAIN and compare with the AUTHOR-DOMAIN
If the two domains are the same, return ADSP=PASS, otherwise
continue with third party authorization checking.
4) If an asl= tag is present, check the SIGNER-DOMAIN within
the asl= list of domains. See section X.XX for asl= parsing rule.
If SIGNER-DOMAIN is found in the asl= list, return ADSP=PASS
5) If an atps=y tag is present, perform the steps as outlined in
[ATPS]
6) return ADSP=FAIL