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

Charles Lindsey wrote:

>> Hector Santos writes:
>>
>> In my view, the conflictive issues are:
>> 
>> 1) Servers which employ automatic purging of old messages
>>    MAY let this field influence the purging process.
>>
>> or
>> 
>> 2) Servers which employ automatic purging of old messages
>>    MUST NOT let this field influence the purging process.
>> 
>> or
>> 
>> 3) Servers which employ automatic purging of old messages
>>    SHOULD NOT let this field influence the purging process
>>    without USER PERMISSION.
> 
> But what do you mean be "servers" here? Surely you don't mean MTAs,
> because they are not in the business of storing messages (beyond maybe for
> 7 days or so trying to deliver a message, after which then bounce it back
> up the Return-Path as "undeliverable")?

Right. Not MTAs.

For one example, our framework is client/server RPC based.  Backend 
mail database servers.  Our SMTP, POP3, IMAP, WEB MAIL, GUI AGENT/JAVA 
  Servers are RPC clients to the RPC Mail Database server.   The 
server has a built-in mail purging/packing events from floating 
between 1am to 5am.  1am today, 2pm tomorrow, and so on.

Other systems have different designs and methods, but fundamentally, 
they all have the similar ideas in place.

> Or do you mean IMAP and POP servers? AFAICS, those are the _only_ places
> where some semantic action connected with the Expires header MIGHT be
> specified, and even there it would have to be a user-configurable option.

No, it can happen other places as described above.

I guess POP3 might be a consideration because POP3 has to gather its 
new (mail indexes for the POP3 client.   I guess I can see it where it 
might use a Expires criteria here to skip over those messages.

But if this standard became reality today, lets see, off the top of my 
head:

For the backend:

   - No doubt, it will be considered as part of the
     backend purging/packing system.  Thats a no brainer
     and most appropriate place *for us.*  Possible add options like:

     [X] Support RFC XXXX Expires Header
         [X] To Accelerate Expiration declared by Sender
         [_] Allow Extension of expiration declared by Sender

   - Consider added it to our automated nntp client.

For developers/operators:

   - Add functionality to support a "Date Comparison" so that
     operators/developers can add rules into their server-side
     scripts:

     [RULE #XXXX]
     if Headers["Expires"] GTE Today then reject|move|keep

I doubt we would provide the rule, but document it as new feature, and 
then you might find people liking this that they will add the rule. 
This is also where they might be add a user permission.

I can also see some extended new ideas as part of warning system where 
  mail is highlighted when it approaches 7, 4, 2, 1 days from 
expiration, etc.

The sky the limit with this one, or, nothing happens at all :-)

-- 
HLS