ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)

2011-04-06 21:57:02
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

<Prev in Thread] Current Thread [Next in Thread>