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