From: Murray S. K. <ms...@se...> - 2009-02-22 08:56:38
|
This is probably of particular interest to those of you who are familiar with the internals of DKIM, i.e. the standard document and thus the protocol itself, but everyone is invited to participate. Are there any portions of DKIM you feel are not useful to you? That is, are there things in DKIM which, if they weren't there to begin with, wouldn't make a difference to you? Or, on the flipside, are there some things outside of the obviously mandatory features which without which you would consider DKIM not useful? Or possibly, are there some features you're not using now but you plan to use in the future? Some specific topics, if you need a starting place: In signatures: x= (signature expiration) t= (signature timestamps) l= (body lengths) i= (signing identity) q= (query method) z= (original signed header set) In keys: g= (key granularity; restricting keys to specific users) n= (free-form comment) Our implementation provides at least indirect access to or support of nearly all of these. I, for example, have found "z=" to be useful when debugging interoperability issues, so it would get a "keep" vote from me. Please give it some thought and let me know if you have any opinions about these. -MSK |
From: SM <sm...@re...> - 2009-02-24 00:33:02
|
At 00:56 22-02-2009, Murray S. Kucherawy wrote: >Are there any portions of DKIM you feel are not useful to you? That is, >are there things in DKIM which, if they weren't there to begin with, >wouldn't make a difference to you? Or, on the flipside, are there some I commented about this some time ago in response to a comment about DKIM complexity. >Some specific topics, if you need a starting place: > >In signatures: > x= (signature expiration) > t= (signature timestamps) The two tags are to prevent or at least mitigate replay attacks. > l= (body lengths) That tag was included because of mailing lists. > i= (signing identity) There's still some work to be done then. :-) > q= (query method) All the queries I have seen up to now use DNS. > z= (original signed header set) This is for debugging. >In keys: > g= (key granularity; restricting keys to specific users) I've seen it being used to restrict the address used by third parties. >Our implementation provides at least indirect access to or support of >nearly all of these. I, for example, have found "z=" to be useful when >debugging interoperability issues, so it would get a "keep" vote from me. DKIM is still in its infancy. Users are still learning about how to make use of it. Some people may sign their messages because provider X does it. In terms of dkim-milter, there's still the question of how to make better use of verification. I make use of the authentication results it provides for filtering. It's too early to say which feature is indeed useful and which one can be removed. For what it's worth, most of the messages coming through mailing list will fail DKIM verification. Maybe people could comment on which of the features they use. Regards, -sm |
From: Dave C. <dh...@dc...> - 2009-03-02 19:02:14
|
Folks, I believe there was only one response to Murray's query. His request was not from idle curiosity. There is a serious discussion underway, looking for DKIM features that are clearly essential and those that might not be. This requires feedback from the folks using DKIM. Like yourselves. Dkim-milter is a significant, free resource. It really is not asking all that much of those benefiting from this free software that they (yoou) provide some feedback about the system is enables. Please reply to Murray's survey, indicating the features you rely on now. Feel free also to indicate the ones you do not expect to ever use. d/ Murray S. Kucherawy wrote: > This is probably of particular interest to those of you who are familiar > with the internals of DKIM, i.e. the standard document and thus the > protocol itself, but everyone is invited to participate. > > Are there any portions of DKIM you feel are not useful to you? That is, > are there things in DKIM which, if they weren't there to begin with, > wouldn't make a difference to you? Or, on the flipside, are there some > things outside of the obviously mandatory features which without which you > would consider DKIM not useful? Or possibly, are there some features > you're not using now but you plan to use in the future? > > Some specific topics, if you need a starting place: > > In signatures: > x= (signature expiration) > t= (signature timestamps) > l= (body lengths) > i= (signing identity) > q= (query method) > z= (original signed header set) > > In keys: > g= (key granularity; restricting keys to specific users) > n= (free-form comment) > > Our implementation provides at least indirect access to or support of > nearly all of these. I, for example, have found "z=" to be useful when > debugging interoperability issues, so it would get a "keep" vote from me. > > Please give it some thought and let me know if you have any opinions about > these. > > -MSK > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > dkim-milter-discuss mailing list > dki...@li... > https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss > -- Dave Crocker Brandenburg InternetWorking bbiw.net |
From: Rob M. <rob...@gm...> - 2009-03-02 21:46:02
|
On Mon, Mar 2, 2009 at 19:01, Dave CROCKER <dh...@dc...> wrote: > Folks, > > I believe there was only one response to Murray's query. His request was not > from idle curiosity. > > There is a serious discussion underway, looking for DKIM features that are > clearly essential and those that might not be. This requires feedback from the > folks using DKIM. Like yourselves. > > Dkim-milter is a significant, free resource. It really is not asking all that > much of those benefiting from this free software that they (yoou) provide some > feedback about the system is enables. > > Please reply to Murray's survey, indicating the features you rely on now. Feel > free also to indicate the ones you do not expect to ever use. Ok: > Some specific topics, if you need a starting place: > > In signatures: > x= (signature expiration) Don't care - I don't (personally) see any need. If I signed the email to say I sent it, then I signed the email to say I sent it. > t= (signature timestamps) Obviously useful ;) > l= (body lengths) Potentially useful for mailing lists, but allows people to modify your email later. I'm all for dropping it. > i= (signing identity) Don't understand what this is for > q= (query method) Given that the only option is dns/txt there doesn't seem to be any point to it. Part of the problem of lack of reponse may be that the DKIM site doesn't lend itself to easily finding information. I don't really want to wade through hundreds of lines of RFC to understand what the header options are ;) -- Please keep list traffic on the list. Rob MacGregor Whoever fights monsters should see to it that in the process he doesn't become a monster. Friedrich Nietzsche |
From: Dave C. <dh...@dc...> - 2009-03-03 04:41:19
|
Thanks for the response. As for you squib at the end of your note, hope this helps, if belatedly: Rob MacGregor wrote: > On Mon, Mar 2, 2009 at 19:01, Dave CROCKER <dh...@dc...> wrote: >> Please reply to Murray's survey, indicating the features you rely on now. Feel >> free also to indicate the ones you do not expect to ever use. ... > Part of the problem of lack of reponse may be that the DKIM site > doesn't lend itself to easily finding information. I don't really > want to wade through hundreds of lines of RFC to understand what the > header options are ;) From the RFC 4871 table of contents: 3.5 The DKIM-Signature Header Field <http://dkim.org/specs/rfc4871-dkimbase.html#dkim-sig-hdr> These are the tags inside the DKIM-Signature: header field 3.6 Key Management and Representation <http://dkim.org/specs/rfc4871-dkimbase.html#keys> These are the parameters in the DNS TXT record for a DKIM key d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net |
From: Mike M. <mi...@ma...> - 2009-03-03 00:58:30
|
On Mon, Mar 02, 2009 at 11:01:58AM -0800, Dave CROCKER <dh...@dc...> wrote: > Folks, > > I believe there was only one response to Murray's query. His request was not > from idle curiosity. > > There is a serious discussion underway, looking for DKIM features that are > clearly essential and those that might not be. This requires feedback from the > folks using DKIM. Like yourselves. > > Dkim-milter is a significant, free resource. It really is not asking all that > much of those benefiting from this free software that they (yoou) provide some > feedback about the system is enables. > > Please reply to Murray's survey, indicating the features you rely on now. Feel > free also to indicate the ones you do not expect to ever use. Frankly, I don't see myself NEVER using any of these features. With that said, if we're framing it as essential vs. non, I'd say i= is essential, and g= is possibly so (although I don't know if it's gained much deployment). q= becomes essential the moment a key query mechanism that isn't DNS becomes available. Whether one will is harder to say. If DNSSEC finally gets moving, the impetus to do so may not be there, but the potential use cases are myriad. In my estimation, x= and t= are non-essential but useful. z= is essential for debugging. I don't see a use for n=, but others might. l= is potentially useful, albeit controversial, and far from perfect-- it's really only reliable for its intended purpose when dealing with messages with a single plain-text body part. Except for corner cases, I'll never deploy it at my day job where people use HTML email almost exclusively. > > In signatures: > > x= (signature expiration) > > t= (signature timestamps) > > l= (body lengths) > > i= (signing identity) > > q= (query method) > > z= (original signed header set) > > > > In keys: > > g= (key granularity; restricting keys to specific users) > > n= (free-form comment) -- Mike Markley <mi...@ma...> I know not with what weapons World War III will be fought, but World War IV will be fought with sticks and stones. - Albert Einstein. |
From: System S. <su...@mi...> - 2009-03-02 22:18:40
|
On 2 Mar 2009 at 11:01, Dave CROCKER wrote: > Folks, > > I believe there was only one response to Murray's query. His request > was not from idle curiosity. > > Murray S. Kucherawy wrote: > > This is probably of particular interest to those of you who are > > familiar with the internals of DKIM, i.e. the standard document and > > thus the protocol itself, but everyone is invited to participate. > > > > Are there any portions of DKIM you feel are not useful to you? That > > is, are there things in DKIM which, if they weren't there to begin > > with, wouldn't make a difference to you? Or, on the flipside, are > > there some things outside of the obviously mandatory features which > > without which you would consider DKIM not useful? Or possibly, are > > there some features you're not using now but you plan to use in the > > future? Following is a combined list of the features that I use on a Postfix installation supporting several mail domains. I had some issues when trying to implement DKIM on a single process processing all mail, but after splitting it into three processes handling outgoing preprocessing, outgoing signing, and incomming, things have been running quite smothly. ADSPDiscard Yes ADSPDiscard No ADSPNoSuchDomain Yes ADSPNoSuchDomain No AlwaysAddARHeader No AlwaysAddARHeader Yes Background Yes Canonicalization simple/simple DontSignMailTo ExternalIgnoreList InternalHosts KeyList Mode s Mode v OmitHeaders X-Spam On-BadSignature On-DNSError On-Default On-InternalError On-NoSignature On-Security On-SignatureMissing RemoveOldSignatures No RemoveOldSignatures Yes SendReports Yes SignatureAlgorithm rsa-sha256 SubDomains Yes Syslog Yes SyslogFacility local1 SyslogSuccess Yes UMask 017 X-Header Yes On the single system there were issues with determining which outgoing mail to sign, and which incomming mail to check. I did get it working with a lot of help from Murray, but it was a bit fragile. Other than the debuging bits, I currently don't plan to use any of the other features. The area that needed the most help, was installation on a non-sendmail system. Quite a bit of frustration trying to get all of the necessary bits to get a clean complile. ...don dhughes (at) microtechniques.com White Plains, NY |