----- 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.
2) I suggest all removing mail alteration to help the project.
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.
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.
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.
Anyway, I think the positives outweigh the negatives.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
ietf-dkim mailing list
http://dkim.org