[ietf-dkim] Issue: Section 3.9 - Add AUID and ODID
hsantos at isdg.net
Thu May 5 09:52:52 PDT 2011
Rolf E. Sonneveld wrote:
>> 3.x Originating Domain Identity (ODID)
>> The ODID is the domain part of the From: address. This identity
>> MAY be considered as an output communicated to an advanced
>> Identity Assessor module.
>> INFORMATIVE IMPLEMENTATION NOTE:
>> The ODID and SDID are inputs for the optional
>> Checking Signing Practices component as described
>> in the DKIM Service Architecture [RFC5585]
>> 3.9. Output Requirements
>> For each signature that verifies successfully or produces a TEMPFAIL
>> result, the output of a DKIM verifier module MUST include the set
>> o The domain name, taken from the "d=" signature tag; and
>> o The result of the verification attempt for that signature.
>> | Optional output are:
>> | o The Agent or User Identity (AUID) taken from "i=", if any.
>> | o The Originating Domain Identity (ODID). Verifier output
>> | MAY consider ODID when no signatures or invalid signatures
>> | are found.
>> The output MAY include other signature properties or result meta-
>> data, including PERMFAILed or otherwise ignored signatures, for use
>> by modules that consume those results.
>> See Section 6.1 for discussion of signature validation result codes.
> are you aware of the fact that 5322.From can consist of a mailbox-list
> as per section 3.6.2 of RFC5322? What is the ODID in case the 5322.From
> contains multiple 'mailboxes' (terminology of RFC5322)?.
While technically possible, it is rare (more on this below).
It was worked out over the years to be either the first address or
each one is to be considered.
SSP described it as a potential DNS overhead its and this is where the
first one was considered technically correct and for its rarity
factor. Also limits can be placed. I believe the consensus (as
reflected in ADSP) was to leave it technically open leaving it up to
ADSP [RFC5617] has the following:
3. Operation Overview
...... If a message has
multiple Author Addresses, the ADSP lookups SHOULD be performed
independently on each address. This document does not address the
process a host might use to combine the lookup results.
But keep in mind of the importance of End to End technical "vetting"
process beginning predominately at the Originating point. I have
design, nor seen an MUA in my 29 years of mail system commercial
product development, which allows for multi-address From INPUT. That
is for good reason - mail hosting 99.99% of the time force only one
From tied to the user account And the exception is normally a system
that allow for manual From change such as in an anonymous mail system
- but its still only one. One that allows for uncontrolled
multi-address From Input is already a BAD SYSTEM.
So the ODID payoff is just to consider the first address. I'm open
though to pass the RFC5322.From value and the only reason I didn't
suggest that is because it passes additional technical "subjective"
semantics such as user part considerations and all we wanted here as a
Hector Santos, CTO
More information about the ietf-dkim