[Top] [All Lists]

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

2008-07-29 14:00:47

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.


2) Servers which employ automatic purging of old messages
   MUST NOT let this field influence the purging process.


3) Servers which employ automatic purging of old messages
   SHOULD NOT let this field influence the purging process

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

    [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 :-)


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