Franck Martin wrote:
Yes, so far I have been trying to assert:
1) How hard is it to add a new dkim header like st=
considering the current software implementation of DKIM
Of the current popular open source APIs I am aware of and I use of one
them, this will require a software change.
The better idea is to propose that implementators add the ability for
operators to add extra tags to the DKIM-Signature. That will probably
get better traction with DKIM API developers.
2) Can we use i= for a purpose of reputation as a) it's meaning is loosely
defined, b) it is there already (cf (1) ) c) it has been used by some to
differentiate different emails in the same domain.
This sound more like a POLICY need.
3) Should we better get DKIM to sign a 5322 header because a) any DKIM
implementation can do it b) for senders it is easy to add a header when the
email is created and then sign it on the way out, than to figure what type of
email it is on the way out during signing. c) for receivers a signed header
is easy to process likewise.
DKIM technical design requirements calls for flexibility to allow
additional headers to be hash bound to the signature. So it is safer
to have an expectation that DKIM implementations for signing mail
offer a way for DKIM administrators to pick and set what headers will
be signed. How they offer it is a different matter.
4) Would senders and more important receivers likely to
adopt such mechanism to mimic IP reputation with dkim,
rather than using subdomains.
When you say IP Reputation, do your bad IP filtering as done with DNS
RBL methods or IP white-listing? Are you talking about SPF?
If your reason is the concern IPv6 will kill IPv4. Just consider SMTP.
Its needs to support IP4 to keep the public mail infrastructure
running. To presume IPv6 will kill IPv4 is to presume that all SMTP
software will STOP allowing IP4 connections. I don't think that would
be desirable. I wouldn't worry about this happening anytime soon, nor
would it be a reason for what you want.
So for your idea, because it is already possible to create
multi-signer streams, the only incentive I can see is a signer
incentive to reduce multi-signer stream management and cost related
issues.
It sounds your question about handling results a certain way.
--
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