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
of:
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 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
the implementation
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
ADSP functionality.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html