On 29. jan. 2007, at 18.35, Michael Cashwell wrote:
On Jan 29, 2007, at 8:46 AM, tsuraan wrote:
... [no client programs] have very good control over when emails
are removed from the IMAP server. Our requirements (imposed by
corporate legal...) are that the archiving machine not delete
messages from the email server until _after_ they have been
archived to tape, and that emails stay on the archiving machine's
hard drives for a certain amount of time for quick retrieval. The
volume of email is large enough that scheduled batch fetching is
not feasible; fetching must be continuous, but tape archiving
can't be. So, we need to be able to signal to the email client
that it needs to delete a specific set of emails that it has
fetched once the archiving is done.
[ snip ]
Even then, I'm left wondering how involving the email client adds
value. Wouldn't the cleanest implementation of such an archiving
system be at the SMTP boundary?
Consider an email server where all accepted inbound email
(undelivered messages like unknown recipients and spam need not be
archived) and all outbound email were additionally copied to a
regularly archived mail spool. Wouldn't that provide a complete
record of all email traffic?
Since such archiving would be completely independent of email
retrieval I don't see why IMAP or POP need be involved at all. The
email would be archived long before it is even available via IMAP.
Comments?
I would agree that feeding the archive from the mx and outgoing SMTP
servers would be the most practical sollution.
Add one way gpg encryption to the chain (keep the secret key on a CD
in a safe), and you have protection against disloyal employees or
hackers gaining instant access to all your correnspondence should
they have / gain access to the server the archive lives on.
--
Frode Nordahl
_______________________________________________
Imap-uw mailing list
Imap-uw@u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
