Barry Leiba wrote:
> We've had a bit of discussion in this thread (and elsewhere) about
> this, but I need to get a clear view of consensus. Doug agrees with
> Hector's note, below, and Dave and Murray do not. I'd like to hear
> from others within the next few days, about whether you think we
> should make the change Hector requests or not. I need to get a sense
> of whether there's significant support for it. Again, please keep
> arguments to a minimum, so it's clearer to me what the consensus is --
> we've had the arguments going for a while now.
>
> Barry, as chair
BTW Barry, the proposal I made was this:
http://mipassoc.org/pipermail/ietf-dkim/2011q2/016282.html
Repeated here for those without editor URL launching support or disabled.
----------------------
>> Murray wrote:
>> You want AUID and RFC5322.From added to the Output Requirements
>> section explicitly.
BTW, while RFC5322.From will satisfy requirements, I am proposing a
new ODID identity (RFC5322.From.domain) since that is whats already
extracted by APIs in order to do the current ADSP support.
I proposes the following:
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.
You might be able to figure out better text.
-----------------
--
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
