ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: Single Organization TXT Lookup with Multiple TXT Records Result

2007-06-04 10:57:42

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

<Prev in Thread] Current Thread [Next in Thread>