Re: [bug-mailutils] Re: POP3d enhancements(EXPIRE)

[Alain Magloire]

> 
> Some thoughts/questions that I have after testing EXPIRE stuff:
> 
> I guess that the actual removal of messages must be done by
> pop3d itself, not by an external script as we supposed at the
> beginning. There are several reasons for that:
> 
> 1) This is the only way to implement EXPIRE 0.
> 
> 2) Setup consistency. Sysadmin will not be required to remember
> to fix up his cron scripts each time he updates the --expire option
> to pop3d. Otherwise, I am sure that the most frequent error will be:
> 'start pop3d --expire N and forget to set up the cron job'.
> 
> 3) Running a cron job that will remove expired messages from
> *all users mailboxes* on a server with ~10000 users 
> means a considerable strain for that server. Removing messages
> asynchronously, before closing pop3 session is more preferable
> in this context.
> 
> Second thought: currently X-Expire-Timestamp is set on each retrieved
> message. This means that a user can effectively disable the imposed
> expiration policy by simply retrieving messages each time he
> opens a pop3 session. I'd propose to set X-Expire-Timestamp 
> only on the very first RETR, i.e.:
> 
> void
> pop3d_mark_retr (attribute_t attr)
> {
>   if (!pop3d_is_retr (attr)
>     attribute_set_userflag (attr, POP3_ATTRIBUTE_RETR);
> }
> 
> Third thought: shouldn't a message be marked upon executing TOP as well?
> 
> Comments, opinions?
> 

Like Canadian politics, the solution is probably in the center.

Why not have the two options:

--expire=DAYS
--expire-enforce

When --expire-enforce, pop3d will also delete any expire emails.

Sys admins wanting more control on the policy an do things
like copy the expire emails in a spool backup(to be restore) etc ..
can still run an external program(without the --expire-enforce).