----- Original Message -----
From: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>
So what is the important, incremental benefit of this parameter?
Although I personally don't see any compelling need, other than maybe
assisting verifiers to further minimize unwanted/undesireable mail at the
transport level, I see a few things, incrementally (future) wise at the
"service" level.
1) Contributing to the AU mail maintenance, archiving policy.
For example, we can probably add a new option to our mail
maintenance/archiving policy offerings that says:
[_] Delete/Archive if DKIM signature expired
AND message as been received.
We already have an similar mail packing options such as:
Days to keep READ Private Mail: ____
Days to keep UNREAD Private Mail: ____
So I can see a valid consideration to adding more options based on the value
of the message itself, including and especially one that says:
Days to keep INVALID DKIM messages: _____
2) Server provided Users Options
Online Servers may offer the user mail reading control options:
[X] Do not accept invalid DKIM-based mail
[X] Move to folder: ____Junk folder_____
[X] Do not accept/show expired DKIM-based mail
[X] Only after reading it once.
[X] Move to folder: ____Expired folder_____
3) Commercialization/Venture Aspects
ESP/ISP sells domain space with an optional DKIM signing subscription based
add-on service. Although, the biggest control would be to remove/stop DKIM
signing (and remove keys from domains DNS record) for the domain when the
service expires (fixed annual certificates?), this might hurt downlinks
suddenly seeing was good valid mail suddenly becoming invalid. With the
expiration descriptor, much like a Browser does day, the Mail Reader can
show an Valid by Expired "certified" message.
If anything, I think #1 and #2 probably is more realistic that an future
implementation may wish to offer if only to distinguish itself from the next
guy. I probably said more than I wanted too already, but overall, if you
have an x= tag or any other extra piece of information the domain wish to
expose, someone will use it one way or another. The question is, I think,
is this a candidate for consistent usage i.e. mandating all verifiers to
honor it for whatever purpose. If you don't think you can accomplish that,
then maybe it doesn't have any value.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html