Dave CROCKER wrote:
>
>
> On 4/28/2011 12:49 PM, Hector Santos wrote:
>> To illustrate this in RFC5585 by labeling the inputs required:
>>
>>
>> |
>> |- RFC5322 Message
>> V
>> +--------------------------------+
>> | Message Signed? |
>> +-----+--------------------+-----+
>> |yes |no
>> | |
>> |SDID/AUID |AUID
>> | |
>> V |
>> +-------------+ SDID/AUID |
>> | Verify +---------+ |
>> | Signature | | |
>> +------+------+ | |
>> pass| fail| |
>> |SDID | |
>> V | |
>> +-------------+ | |
>> | Assessments | | |
>> | | V V
>> +--------+----+ +-------+
>> | | / Check \
>> | +--SDID-->/ Signing \
>> | / Practices \
>> | +-------+-------+
>> | |
>> V V
>>
>>
>> As you can see, per RFC5585, both SDID and AUID are mandatory DKIM
>> outputs.
>
>
> You are confusing DKIM requirements with ADSP requirements.
Please respect there is no intent to do this.
Rather I am highlighting the limited DKIM output requirements is
outdated and insufficient to support today's (extended) DKIM mail
integration and security needs outlined by WG consensus-built RFC
documents:
DKIM Security Assessment (RFC4686)
DKIM Service Architecture (RFC5585)
DKIM Deployment Guideline (RFC5863)
DKIM Signing Practices (RFC5617)
DKIM Reporting using A-R (RFC5451)
Here is a way to view the old vs new design dilemma:
SMTP vs ESMTP (Extended SMTP)
We have decades of engineering foresight to not repeat completing a
protocol design with an outdated limited output scope especially when
extensions are already available.
While I am in no way suggesting RFC4871Bis should be updated as an
EDKIM (Extended DKIM) standard, we should recognized that DKIM-BASE
has limited usefulness with its limit outputs requirements. As we
know today, AUID should not be excluded from the output summary.
--
Hector Santos, CTO
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
