[Top] [All Lists]

Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15

2008-07-24 04:18:58


I don't understand your point. I wholeaheartedly agree that
online MUAs should also be supported - so what? I don't see
how this affects the rules that Keith Moore beautifully
laid out in this email:

In our University's webmail system, I can define folders
and set some filters; by default, the system should only
highlight expired emails somehow (which it could), and
it might allow me to automatically have them deleted,
or moved somewhere...

I just don't see a difference with regards to usage
of the expiry date.


On Wed, 2008-07-23 at 19:56 -0400, Hector Santos wrote:

I think it should be made clear what we are talking about when it
comes to the type of MUA.

There is typical a propensity to think of offline MUA, like Outlook,
ThunderBird, Eudora, Unix based offline mail readers etc.

But you also have online based MUAs as well.

The difference?

Offline Storage vs Online Storage

Both present a different set of technical and very important legal
engineering design requirements.  

Obviously, the options for Online MUAs (i.e. WebMail)  are defined by
what the backend provides the user.    Offline MUA options are defined
by what the vendors of offline mail writer/reader programs provides.
The consistency in the options between the two should not be presumed
to exist.

So I think it is short on design to think that a proposed IETF 2822
header of this caliber is only useful for offline MUA systems.  The
design considerations must also be consistent for Online MUAs,
including Offline MUAs in regards to the stored mail kept on the
server which generally is the same used for online MUA connectivity as

So in my view,  being that we offer a mail process entity for each
stage of the total mail system, including multiple MUA softwares
(offline, Online, and Mixed,  text, html and GUI),  I think the
question is which one processes in the end to end flow process can use
this and how.   If the proposal mandates the Expire Header is for MUAs
only, then for the online based MUA, this implies the backend has to
support and work with it too.

My Point?

It isn't as simple as it might appear when we only consider the
offline mail write/reader software MUA.  It would be a half baked,
incomplete and only partial consideration within the many variant and
complete mail systems as we know it today.

How about mobile?  

One the key issues here is redundant, wasteful mail  downloads because
of the "Keep On Mail Server" idea which forces backends to not mark
mail as received allowing user to get their mail on mobile and back in
the office/home desktop.

If the Expire Header can be one small additional part of the complete
process to eliminate "irrelevant" mail,  then it will have a "some"
payoff for mobile users as well of offline users.

Michael Welzl wrote: 
So, would you still be happy to have your MUA silently delete
expired  messages?

Believe it or don't: yes.
Granted, when I said "silently delete", I meant "silently move it to my
trashcan folder, which is what my MUA does when I delete emails. This way, 
if I
lose something and start to wonder what's wrong, I can still look things up
in the trash. If I don't start to wonder what's wrong, I believe I have the
right to assume it's the sender's fault that their message never reached 
me. This
is what they risk when falsely setting the expiry date.

Other people could use it to automatically move emails to a suitable
folder, which makes email reading more efficient and still doesn't
let them miss the stuff that you mention above. But they can regard
it as low priority and go through it if and when they consider it

AFAICS, the only safe way to use 'expire' would either be for it not to
move/delete messages at all (in which case, what's the point) or to have
different rules handling expire differently from different senders (when
you know how THAT sender uses it), but this would only be useful if you
repeatedly got expired messages from particular people (which is doubtful)

I disagree, on the basis of what I said above.

(I do wonder, how important is this anyway? How often do you receive
messages after they would have expired? The only time I can think it
would be even slightly useful is if you've just come back from a
vacation and haven't checked your mail whilst you've been away, but then
a few CFP or talk announcements is going to be irrelevant amongst all
the other thousands of semi-junk messages you'll have received!)

I agree that this would be especially useful (but not "the only time
when this would be even slightly useful") after a holiday. The few
announcements are not going to be irrelevant among the other
semi-junk things.

Something more time consuming, to give you one more example:

"Michael, please do this until ... messages" - where you have to
carefully read the whole thing, only to find out that the sender
has absolutely no use for what he demanded by the time you
read this message. That happens to me on a regular basis and
is really annoying.

Putting all of this together, for me and I'm sure that a lot of other
people, an expired field would be well worth having. You shoudln't
make your own personal preferences and daily life with email the

Probably we (as we discuss on this list) are not even good examples.
There are newspaper articles and even books discussing how to
deal with emails, for higher level managers - I'm sure that, for these
people, any small contribution to reducing the number of daily emails
is extremely valuable.

I don't have a massive problem with an 'expires' header, I just see it
as, at best, pointless, and at worst, dangerous in the hands of an
unthinking user (of which there are many using the Internet).

Pointless: this is based on your personal preference which you
outlined above.

Dangerous: no, because of its strictly advisory nature. You would have
to be unthinking enough to set your mail client to always delete expired
emails on purpose, then wonder what's wrong. This is equivalent to
formatting a hard disk on purpose, then wondering what's wrong - that
a user could do that is the inevitable risk that comes with every
you give him (for once, I think it's actually better to use the male form,
the sake of political correctness!  :-)   ), but this should not be at the
of the rest of us.



<Prev in Thread] Current Thread [Next in Thread>