ietf-mta-filters
[Top] [All Lists]

Re: Expiring/deleting old mail

2004-03-17 08:38:08

Maybe these can offer some insight. These are our mail server mail policy
attributes (per conference AKA folder).  Our mail server automatically
maintains the mail once per day between 1am and 5am (adjustable).

o Maximum Messages:
o Message Number to Trigger Renumber:
o Days to Keep Read Private Mail:
o Days to Keep Unread Private or Public Mail:
o Days to keep external user mail : (outgoing mail created by your users).
o Delete external user mail once delivered by SMTP:

Other folder/user profile group based options  that can have an effect on
the mail tracking/maintance.

o Allow Mail Previewing (Non-POP3 devices)
o Mark downloaded (POP3) Mail as Received:  Yes/No

In general, users have no say in our product mail policy design.  POP3/WEB
mail access has changed that over the years with users now having some
"leave on server" options in their MUA to help them with roaming.   However,
tracking, mail maintenance, mail receipt request, etc (Subscribers can't
claim they didn't get an expiration notice) is still important so our design
compromise was to have two Receive bits. One that is always recorded for
internal purposes and one that is used for the user.  This allows them to
Preview mail on lets say the Web without marking it read, and then via MUA
download the mail with direct mail
pointers retrieving the "unread user mail."    Same idea with the MUA
(POP3), option to not mark receive allows them to roam to around to other
machines.   However, the internal received bit still prevails for the normal
mail packing/maintenance options (Days to Key UnRead/Read Private Mail
options).   Users have no say on how long mail stays in storage, unless of
course, it is shorter than the server limits, in which case,  the MUA can
delete the message.

I guess my point with the note, that whole concept present a very difficult
PR/system policy issue where MUA clients were demanding new behaviors
conflict with some of the product's traditional strong mail security,
tracking and maintenance policies.  The #1 being subscription notices could
not be bypass with user's previews or non-marking downloads, and the 2nd was
the increase mail storage requirements in large systems because the triggers
were being bypassed.

Hope this provide some engineering insights.

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com







----- Original Message ----- 
From: "Michael Haardt" <michael(_at_)freenet-ag(_dot_)de>
To: <ietf-mta-filters(_at_)mail(_dot_)imc(_dot_)org>
Sent: Tuesday, March 16, 2004 8:22 AM
Subject: Expiring/deleting old mail



Hello,

let me summarise the recent discussion.  I hope this reflects most
views expressed on the topic:

Some mail systems allow the concept of "rolling/automatically expiring"
mailboxes/folders which automatically remove old mail, which is useful
for mailing lists and junk mail folders.  It is important that this
function is not performed by the client, because clients usually don't
clean up during vacation.

For that reason, I suggest a Sieve extension, which allows the mail
system to remove mail.  There are several ways to address the problem:

Folder Attributes

Sieve focuses on message delivery, so using sieve to control folder
attributes would be using it for a purpose it was not intended for.

Message Attributes

This fits well into Sieve, it allows the richest set of features, but
message expiration attributes are also the most complicated approach.
Further, users might expect expiration dates to be met exactly and
not be pleased about lazy expiration, adding further complexity for
the implementation.  IMAP ANNOTATE may be the way to go for message
attributes.

Message removal at delivery

This approach is easy to understand for users and easy to implement: It
keeps removing mail, starting from the oldest, until the given criteria
are matched.  It could be realised by adding an option to "fileinto"
and probably "keep":

  fileinto :max-days 7 "inbox.mailinglist";
  fileinto :max-messages 100 "inbox.mailinglist";
  fileinto :max-storage 1M "inbox.mailinglist";

It is still open how the last action should behave when delivering
a 2M message.  Perhaps there is a better name instead of "max-".
This mechanism should not be called expiration, because people expect
a different behaviour by that name.

Michael





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