The Milk Carton Analogy was good, but there is a slight difference when it
comes to (DKIM) mail.
The problem with the milk analogy is that the expiration date is a shelf
life concept. To the store, it is the date it must remove the cartons from
the store shelves. To the consumer, who brought it days or weeks before, it
is probably not a good idea to keep and use the milk on or after this date.
However, when the MILK was used, opened by the user it is the same as the
message being read and already verified as good (milk) at the moment he
first opened it to read (drink) it.
That is what is most important. Is the milk good when you first open it?
So if MAIL was read or received by the user, the concept of expiration
really should not apply anymore. This was like Dave Crocker's excellent "Car
in Intersection, Light Changing to red" analogy. Are you support to stop
driving because the light change red when you are already crossing it?
A signer might want you to avoid the meaning of the message, but it was
already received, verified and validated.
In other words, the mail presentation software can show this:
Today Date: April 22, 2006
This message was received and validated on April 16, 2006.
However, it is now considered stale.
I have a hard time seeing a verifier at the MUA level going to continually
try to validate the signature, over and over again every time you want to
reread the message.
So it was a good analogy, but doesn't 100% apply to mail once the mail is
received and validated before it expired. The mail is still readable. It
was safe the first time you read it. Unless the message is a nuclear bomb
that will hurt you if you continue to read it, I just don't see how it
applies at the USER level.
That said, I already mentioned how I see it apply at the backend or system
level. I can easily see how we might want to add a system option to use
expired DKIM messages as part our mail maintenance, archiving system
allowing the operator to use this additional piece of information to help
the backend software to purge the message from the system.
But while it is still alive and available, once you read it, at best, the
presentation software could or might be fancy enough to tell you that it has
already verified but now expired message.
Anyway, that's my view.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Sandy Wills" <sandy(_at_)weijax(_dot_)com>
To: "Eliot Lear" <lear(_at_)cisco(_dot_)com>
Cc: "DKIM Mailing List" <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Saturday, April 22, 2006 8:31 AM
Subject: Re: [ietf-dkim] Notes from DKIM jabber meeting on 20 April 2006
(Thanks to you, John, Hector, and the others for helping. I think I
understand a little better where you are going, now. I'll let you know
when I know everything and have solved all the world's problems.)
Eliot Lear wrote:
Sandy Wills wrote:
I love analogies, so let's extend this one a bit. If her daughter
received thousands upon thousands of pieces of junk mail, some of which
used fake postmarks to gain attention, others of which use her
grandmothers' name, how would her daughter even know that the letter was
real or worth her time? If someone thought she would open it, then
they'd mimic that behavior as best they could so that their junk could
get read.
Well, yeah, that's the reason that the WG was formed - to build one of
the links in a chain of verifiability. 65 years ago, a letter cost too
much for undirected mass mailings. I'm willing to pay a penny a post
for email, (maybe it could pay for IETF meetings?), if it means that
spam is no longer economically viable. Again, what you guys are trying
to do is a necessary step in _that_ direction, too. Something to think
about, if you have religious problems with making all people pay for
email.
On the other hand, I think only experience is going to dictate good
practice here. I doubt I would want to yank my keys for a message only
seven days after transit. I suspect I'd want people to be able to
verify my messages for several months, if possible.
That makes sense. If you post a message today, it should be
verifiable for several months, at least. Years would be nice, if key
storage isn't a problem (Don't think so, as data storage costs seem
determined to keep going down. If that trend is linear, the HD
companies will be paying me to take their drives, in a couple of years).
At the same time, the key should also expire such that _new_ mail
should not use it after [some as-yet-undetermined time]. The "Best if
used by" milk carton analogy (credit to whoever that was, sorry!) seems
to fit very well, to me, although it's more like "We put a time-release
poison in this stuff. REALLY don't drink it after this date." Which
way it goes depends upon how painful key generation and propagation are,
I guess.
--
Unable to locate coffee.
Operator halted.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html