Hi Mark, At 19:14 25-03-2009, Mark Martinec wrote: >Appliance/sw GUI that does so is misguiding the administrator. >Requiring a header field not to ever be present should be an expert setting. >A checkbox like 'sign this header field' should have a semantics 'sign it >if present' (at least by default).
It's a bit more complicated than that. Some header fields should be signed even when they are absent or else you leave the door open to abuse. There are the "visible" header fields and some header fields which can be used to "repurpose" the message. If you don't sign them, you leave the door open for abuse. >It would also help if it were easier to report signer mistakes to the >guilty part. With large ISPs or commerces I find it particularly difficult >or futile. There is an I-D about DKIM reporting. >The invention of an 'h' tag made a tremendous improvement in survivability >of a DKIM signature over the initial DomainKeys drafts. Agreed. >Not in cases I observed. There was no Message-ID at the time of signing. >It's easy to prove - just deleting the late-added Message-ID makes a >signature valid again. Section 5.5 of RFC 4871 recommends signing the Message-ID if it is present in the message being signed. Instead of trying to make a signature valid again, it is better to fix the problem at the (signer) source. >I don't think that MS/Unix/Mac differences in line endings will present >a share of failures worth mentioning. So far I have yet to find a single >case of such breakage. The DKIM rfc is clear on it, and as long as >implementers do it by the book, this is a non-issue. I've come across such cases. I agree with you that this is a non-issue as there should always be CRLF at the end of the lines. >True. But a signer sw had no right to require that the header field >must not be added later, at least not in a default setting, without >explicitly asked to do so. I prefer to see such issues addressed through guidelines instead of forcing people "to do the right thing" as we might not agree on what the correct behavior should be. Default settings are a matter of tradeoffs. The user-base might not find what we believe is right suitable for their environment. >The approach of anticipating a munge only helps when the feature >is used in a signer in conjunction with the MTA which is expected to >do the modification. It does not help if a message is signed by some >other mailer and just happens to pass through a header-modifying MTA >on its was out (e.g. an outbound mail submission mailer for a SOHO >at an ISP), or on it way in (like a backup MX relay). Yes, that would be a problem. I don't have a solution for that. :-) >The To and Cc header fields are purely informational, they do not >affect mail delivery, and many (but not all) recipients have already >learned not to be confused by them - be it due to the use of Bcc, >or mailing lists, or just by a daily exposure to spam. There is still room for social engineering. >Right, the default is 300 seconds. A MTA and a signing host should >be running NTP. Setting time manually and letting it free-run >is at least unrespectful and confusing to recipients or senders, >or can cause mail misclassification/blocking at worst. The verifying host should also be running NTP. Regards, -sm _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
