I guess I'm with Bill on this. My main issue with an 'expires' header is
that it will mean many things to many people. That means that it will
only be really useful if YOU set the expires header on messages you
receive (which obviously is not going to be very common). Since most
people seem to want it to be defined in a woolly way, it could mean
absolutely anything, which means that there's only a limited amount you
could actually do with it since you don't know what the sender actually
meant it for. This woolliness is also going to mean that no one with any
sense will set it, because they don't know what the recipient is going
to do with it - some may mark it the message as more urgent if it has
just expired, others might delete it - so the safest thing to do is not
to set it at all...
But even if there was justification for additional work on calendaring that
isn't already being done somewhere else, it's a completely separate problem
from message expiration. Message expiration is just about saying when, in the
opinion of the sender, the content of a given message - whatever it happens to
be - is no longer going to be useful. The semantics don't extend to inferring
that a message with an expiration date necessarily describes some sort of event
and that the expiration time is somehow related to the time of the event.
When you get down to it this is really about being able to manage
ever-increasing amounts of email a litte more easily. If we try and take it
further than that we'll lose focus and likely derail the entire proposal.
Having a stricter definition would help IMHO, as the sender would have a
chance to know how the recipient will interpret it, and the recipient
will have a chance to know what the sender meant by it.
VPOP3 - POP3/SMTP/IMAP4/Webmail Email server for Windows