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

Keith Moore wrote:
>
> Michael Welzl wrote:
>> That's what we have filters for! You could let your client
>> move the email to some subfolder, mark it somehow (light
>> grey in the list, whatever - up to your client), or just
>> delete it (like I would).
>
> I'd love to believe that mail clients will be that flexible.  

MUA like Firefox offer plug-in support that pretty much allow you do do 
whatever you like.   Of course, plug-ins are not standard.

> But I also have to consider that most mail clients today are still 
> fairly primitive as to what they can do with existing headers.   My 
> guess is that if expiry-date / expires is implemented at all, it will 
> generally be implemented in the simplest possible way - e.g. by 
> deleting the message silently.
+1.    

This proposal can serve well to standardize the header itself,  thats 
the easy part.  But how it will apply is a different ball of wax.   The 
MUA side can deal with it by moving it into folders or deleting it.    
But how it applies with the server,  would be under the common 
MUA/Server Interface options generally offered for the mail server 
account.   So a new Expiration Headers option can be added:

    [X] Keep Mail on Server for Days: ____         <--- common MUA 
feature to control server storage
    [X] Support Expiration Headers                     <--- new RFC 
related feature

Both of which is at best a request to delete (DEL command) and no way 
dictates or overrides what the server policy is in the area of mail 
destruction.

A more useful MUA (OFFLINE or ONLINE) option would be to add a 3rd option:

    [X] Server MAY use Expire Headers to delete (or mail received) mail 
before mail pickup.

As you pointed out, this can help lower the mail pickup payload 
overhead, which can be fairly high these days with laissez-faire  usage 
of html and attachments and over bloated wasted bandwidth of headers./
/

-- 
HLS