----- Original Message ----- From: "Jim Fenton" <[EMAIL PROTECTED]> To: "Hector Santos" <[EMAIL PROTECTED]>
> 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
