On Jun 4, 2007, at 8:12 AM, Damon wrote:
What I am suggesting is a bit different. As this label must have
a prefix, why not allow the prefix to associate with another
domain via a hash? Check the existence of an MX record when no
policy record is found. When policy record lookup fails and the
MX record exists (we are at two transactions), a third lookup
could be for _dkim-all.<email-address-domain> to determine whether
a lack of an association is acceptable.
This approach represents the same number of transactions as
suggested by Phillip, but also provides a means to curtail a
replay-abuse and broken-signature bounce problem. Doing this now
ensures at most one additional transaction occurs. This seems
well worth it.
Doug,
Interesting idea. Can you provide an example of how this would work
IRL?
I am confused about the "hash".
Several domains within components of an email may reference an
originating administration. This includes the EHLO, SMTP MAILFROM,
the PRA, From, Sender, etc. While the DKIM signature provides a
means to authenticate who provided content, often this alone will not
be enough to prevent a replay problem. There is also a problem of
bounces spoofing a DKIM signed message. BATV allows spoofed bounces
to be discarded. But to use BATV, those using the email-address must
always send through a system that adds the BATV signature. In
addition, BATV can not prevent the bounce traffic from being
initially accepted either.
A better solution can handle the replay problem, and spoofed bounces,
and any unsigned message that should be signed.
Senders would do the following:
a) Provide an MX record that does not use a wildcard.
b) Provide a default policy record.
c) Provide associated domain policy records.
Recipients can then do the following:
i) Check for the existence of MX record when no domain specific
policy record exists.
ii) Check for the existence of a default policy record when an MX
record exists.
When an MX record is not found for an email-domain, refuse the
message. (See note below.)
When no policy record is found at the location of the MX record,
there is no policy.
When a message is from a domain having replay abuse problems:
(Perhaps as indicated in originator's default policy.)
- Check for a domain specific policy record for the EHLO hostname.
(Checking for a domain specific policy record would precede a check
for a default policy when domain specific policies become common.)
When a message might be bounced by subsequent handling then: (This
is only known by the recipient.)
- Check for a domain specific policy record for the SMTP MAILFROM.
Hostname policies are located by:
a) Excluding the leftmost label of hostname, and converting the
remaining domain into a base32 encoded SHA1 hash.
b) Adding a rightmost prefix to the hash indicating that the policy
requested is for a hostname, such as:
_SMTP_H
_SMTP-ALL (default excludes leftmost hash)
b) Placing the base32 encoded SHA1 hash of the domain and prefix
below the originating email-domain in question.
When DKIM and email address domains differ, email-address domain
policies are located by:
a) Converting the DKIM domain into a base32 encoded SHA1 hash.
b) Adding a prefix to the hash indicate the policy requested is for
a specific field or parameter such as:
_DKIM-MF
_DKIM-PRA
_DKIM-F
_DKIM-S
_DKIM-ALL (default excludes leftmost hash)
b) Placing the base32 encoded SHA1 hash of the domain and prefix
below the email-address domain in question.
When the default hostname policy indicates a message MUST be from an
associated SMTP client, but the associated hostname policy does not
exist, refuse the message.
When the default email-address domain policy indicates the email-
address must be signed by an associated domain, but the associated
DKIM domain policy does not exist, refuse the message.
Note:
When refusing messages that fail to have an MX record is decided to
be too problematic, then all A and AAAA records must also include a
default policy at the same level. Such records will not collide with
any existing records due to the prefix. At least there is no
searching for a record. Hopefully, over time the use of A or AAAA
records in place of MX records can be obsoleted to eliminate this
need to publish policies at every A or AAAA record location.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html