Including the whole mail since it was only replied to me.
Kenneth Lyons wrote:
I strongly disagree by the way you are dealing with internal mail.
It's MORE than just internal email. I used it as an example so everyone
could
follow the design/comcept. We ARE a hosting provider so we have lots of
companies email, and lots of public users. Both have the same problem.
We will get the biggest benifit with companys' email and a little less from
public email users, unless most of their email friends are also hosted
by us.
If I was the sysadmin at your place I would start teaching ppl how to
share files (if you have sharable directories in your users homedir or
if you have share section folders somewhere, solutions are many)
rather then to duplicate them.
I used that *company* example as it is easy for people to understand. We
also have about 20,000 public email accounts as an ISP. So when
BoBo sends a 10MB email of pictures to their entire family, and half
their family is under our ISP we have the same issue.
I don't know of anyway to *teach* regular users how to use
FTP when email is just natural for them.
(most home users don't know what FTP is)
We've used MIMEDEFANG in the past to rip off and archive attachments,
which did the same as the symlinks (once copy, many emails)...but we
noticed it confused users and had to disable this feature. People couldn't
get the concept of 'click here to download attachment.' when they
didn't see
a paperclip icon.
If you still wish to continue I would suggest setting up a shared
emailaddress and put a maildrop wrapper that in some way other then
just droping the mail to the user puts a link of some kind to a read
only copy.
For normal companies, this wouldn't be that hard. But 20,000 everyday
private emails it would be.
We are setting up the SYMLINKS as it will save a heck of a lot of HDD.
For now Binc will just run like a normal IMAP. Mass mailings will be
limited
as they can't use any tags because of binc's lack of a filter (even
sendmail has milter).
Pop3 users will be fine, since it was an easy matter to include a filter
in the perl sources.
I still don't see why you want to put this type of "space compressing"
in the IMAP layer rather then to put it in the maildrop layer where it
would do the most good.
Having the MDA sorting out if the recent 100 droped mails could be the
same and then moving it to a shared location and linking it into the
users Maildir seems to me to be the effect you want. Having the space
compressed right away insteed of the MDA duplicating the mails and
waiting for binc to HOOKS it right and _then_ compressing.
That would mean that the 10MB mail gets duplicated 100 times until the
users checks its INBOX. Again, this should be done directly by the MDA.
Now, I havn't checked exacly if binc is picky if the file in new/ or
cur/ is really a symlink but it that is the case I belive its very
simple to fix/patch and/or put a --configure options up on how binc
handles symlinks.
Prob at a later date we will just make a donation to some binc dev and
have them
incorp a filter in the program, till them... we're sol on our e-list
compatiblity.
--
Jerry Lundström, System Developer
Section for IT and Media, Stockholms University, Sweden
+46 (0)8 16 19 99 / http://www.it.su.se
