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

Hector Santos wrote:
> 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.

more to the point, they're not widely used enough to get traction for 
new email features.

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

...or by showing them in a different color, or optionally hiding them in 
summaries.  if the only options most MUAs provided were effectively 
deleting them, that would IMHO be a bad result.

> 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

yet another configuration knob to twiddle for an interface (MUA to 
message store) that's already notoriously hard for users to get right.

heck, we still have WAY too many people using POP or IMAP with cleartext 
passwords, mostly because that's the configuration that "works" with all 
clients and servers, and partially because there's no uniform language 
to describe the other configurations.  (does "use secure authentication" 
mean APOP, or POP+SSL over a reserved port, or POP with the STARTTLS 
command?)

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

I already have way too much mail being either deleted or misfiled by 
spam filters.  The last thing I want is even more justification for MSPs 
to delete messages without my explicit consent.

Keith