[Top] [All Lists]

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

2008-07-23 17:29:06

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 well.

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. 
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>