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