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