ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] list config, was Admilistrivia question

2005-10-19 15:22:56
Hector Santos wrote:

----- Original Message -----
From: "Jim Fenton" <fenton(_at_)cisco(_dot_)com>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>


But what about the addition of [ietf-dkim] to the subject lines if it
isn't already there?  That will break signatures as well (since just
about everyone signs Subject) but not adding [ietf-dkim] will likely
break mail filtering for some folks.

Good points Jim.

Three comments:

0) Don't know about others but I filter/move by email address since that is
more guarantee than the subject line.

1) The signer can use the z= tags to save the header signing data.
Remember that z= is optional.

2) I suggest all removing mail alteration to help the project.
I agree that it would be a great idea to have a mailing list that re-signs messages in order to get some experience with that. I don't think this is the list to experiment on, though.

I think its offers much greater project benefits to help developers get on
board and begin R&D.  In all honesty, my start into this was seeing DKIM and
DOMAINKEY signatures in MASS, storing them on disk and saying "Ok, lets
checks this all out."   Many of these messages where from you, Thomas,
Delany and Hathcock.
It worked!  :-)

That's lost now for the any new curious developers as DKIM gets more stable
and promoted, and I don't think I am completely off saying the canonical and
hashing worked out was not a piece of cake.  :-)  Developers like it when
they can work with ideal baseline examples these your DKIM signed messages
provided, get that worked out first, then deal with the possible expected or
unexpected baseline deviations.
Our testing folks have started a website, http://testing.dkim.org/ which has a number of test resources, including a corpus of properly (and improperly) signed messages, pointers to test reflectors that we know about, and the like. Let us know if you have any more ideas that will help developers.

As a related side note, we can't use the 3rd party source code DKIM API or
KITS for legal reasons. We have to develop everything in-house.  That's just
the way it is.  So I don't think it is safe to assume everyone will be
working off some common open source API public source/gnu license or
otherwise.
We expect that will be the case for some people. Hope the above resources help.

-Jim
_______________________________________________
ietf-dkim mailing list
http://dkim.org