Mark Delany wrote:
DKIM-Signature Header tags
x: Signature expiration
l: Body length count
Removal of these would be a show stopper for me. In fact, overall,
anything that is SECURITY related should be protected from removal
Do you mean anything that is security related or do you mean any thing
that improves security? You're not being very precise.
Mark you know what I mean.
Overall, I would be -1 for removing any current feature designed to
improve security, control aspects of the message that are related to
the validity of it.
As I understand it l: reduces security because it introduces wiggle-
True. Maybe I was thinking l is the original pre-cl4n byte count of
the message, not the signed count, so anything over the original
should be considered invalid.
and x: seems only to offer theoretical benefits that are far more
concretely established via key revocation in the DNS.
Thats one thought. But if you are not going to be revocation keys, you
still might want to have a time limit. You are making the assumption
that people will be revoking keys for the purpose to expire messages.
Its a good policy, but IMO after a while that is going to get
tiresome for many when all they wanted to do is put an x= on the
message. Its like passwords, it would be nice if users change their
password regularly, but their don't so many systems force it with
password expirations. Consider also it is does the verifier a favor
too. Whether or not x= matches the key expiration period, the verifier
can save lookup overhead for those messages that expired.
Overall, I don't see these as candidates for complexity. These are
simple low overhead checks, especially x= because if the message
expired there is no need hashing overhead - immediate reject.
Anyway, thanks for your feedback.
NOTE WELL: This list operates according to