----- Original Message -----
From: "Sandy Wills" <sandy(_at_)WEIJax(_dot_)com>
To: "DKIM Mailing List" <ietf-dkim(_at_)mipassoc(_dot_)org>
Let's say that your grandmother, somewhere in the US, sent her
daughter (your mother) a letter at her newlywed house sometime in late
1941. Something bad happened out in the Pacific, causing a hiccup in
the mail-delivery system, and a lot of stuff was delayed, some of it so
much that it was forgotten.
A couple of years ago, you moved back into that old house you grew
up in to take care of your parents, and your mother is still there at
the same address. These days, you have to do pretty much everything for
her, including going thru her mail, throwing out all the ads for things
that she no longer needs. Your grandmother, unfortunately, is no longer
with us.
Yesterday, the USPS was closing down an old post office, and found a
box of old letters that never got delivered. Your grandmother's letter
is in there.
There is an exactly a movie plot based on the similar premise :-) In this
case, a WW II soldier lost love letter and married proposal (with a ring in
letter) to his sweetheart going unanswered because it fell behind a shelf at
the post office. Although living in the same town, the two bitter people
went their separate married lives for the next 30 years. His son and her
daugther fell love but the bitter parent history kept them apart. During
remodeling of the old town post office, the lost letter/marriage proposal
(with ring) was found and delivers it resparking an old love. In this case,
the love between them never did expire but both recognized it was too late.
However, their kids were blessed to marry now. :-)
If I understand the expiration time question right, some people
think that it's okay for a USPS drone to throw that letter out, because
the 3 cent postage doesn't match current rates. I think that it would
be better if his supervisor said "No, that postage was valid when that
letter entered the system -look at the postmark date, meathead- and we
have to deliver it."
Walking down the mail delivery system, each handler should say the
same, including the postman who hands it to you, and you should give it
to your mother. Make sure she's up to date on her heart medicine,
first. I guess that's okay.
Well, IMV, the main issue or analogy would be if the user aware that it even
existed?
Maybe it was delivered. Maybe it wasn't lost. Maybe it was just a matter
of not checking your mail box frequently. The love story could be an
American soldier in Iraq and his sweentheart using hotmail.com as a central
place to send love emails. But for some reason, she doesn't go to
hotmail.com offer enough to login and read her new mail. Hotmail.com I
think has 30 day inactive limit. This is not unique. For our own
software, one of our top support questions is how to purge old or inactive
user accounts. So it is real possibility.
In fact, we have in our options:
Days to keep received mail: ____ (default infinite)
Days to keep unreceived mail: ____ (default infinite)
We will have to rethink about what DKIM expiration means here now. Could it
be used to accelerate the maintenance? Certainly, DKIM is not going to
trump the 25+ years time engineered, existing operations. DKIM or no DKIM,
mail can go unreceived and lost.
Also keep in my that USERS have no control of server policies. This concepts
and issues are well documented in RFC 2449 and RFC 1939. In fact, in
Outlook, if you hit F1 on the "[X] Leave mail on server" option it will
clearly tell the user that this feature may not be honored by the backend
mail server.
Which bring up this point, Roaming users support is a feature, not a Right.
Imagine the user on vacation picking up his mail on one machine, but no
longer is able to pick it up from his mail work/home machine. A real
possibility.
Am I out to lunch here, or am I making sense?
In my view, in the end, when it is all said and done, people creativity will
take hold and will inevitably begin to see the expiration tag for various
applications, including possibly helping the aging process and/or Message
Expiration processes.
But overall, these are all implemention considerations. I don't think the
specs should mandate it, but only to define it and suggest that an
expiration is onsidered invalid by the domain.
Getting back to DKIM, I thought that the discussion about which
country had the longest vacation time was irrelevant, in the context of
key expiration. Am I making DKIM too unwieldy, here, asking for a key
to be verified as good, not today, but when it was used? There doesn't
seem to be any added storage cost or processing cycles, since either
way, you have to have the key to test it, just the question of which
date to compare to.
Right. Defining the timestamp is important. I believe it should be
generically described as the transaction reception time - the time it
arrived at the host system, not the time it was actually verified or
received by the user.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html