Re: browser new mail count
People have said many things in response to Derek's question, many of
which I agree with, so won't repeat them here. I waffle enough as it is
and this is verging on off-topic; I do think that understanding how
people use email is important for the people writing to mail tools
though, so I've decided to post after all.
One point: 50 recipients on a list and people complaining about the
"small" 8MB limit on emails (so 6MB on binary attachments); saying "disk
is cheap" doesn't match that sort of fan-out once that attachment has
been passed back and forth a few times a day, either just attached to a
reply (aargh!) or with minor changes; by someone who just doesn't
understand "use the Z: drive, your department's folder, it's shared
across the network and anyone in your dept can see it". Just imagine
two weeks of that at some crunch point .. that's what staff _want_ and
they don't want the techs explaining why it's bad. If we can say "post
to this address, it's this folder in your client here, and if we need to
reclaim storage space later we can grab your team-leader and go through
deleting the duplicates which are already on backups, don't worry about
it" then we're ahead.
We're not there yet.
On 2006-03-03 at 15:12 -0600, David Champion wrote:
> My last effort to resolve this split was to connect an IMAP server
> to Mailman archives,
Our shared folders fall into two groups:
* a very few folders which are shared IMAP only; mostly exploders for
external lists to prevent broken clients sending auto-replies and
quota complaints to the poster to some external list
* clones of mailman-managed lists; IMAP users currently get to choose
how to receive email.
Mailman has hung around longer than expected, because of staff time
constraints, but I'd expected to move to Sympa: better designed for a
consistent set of subscribers choosing from a pool of lists with common
management of things like passwords. Mailman's good for "this is one
list, subscribers from all over the Internet, not much correlation" but
not so good for "many lists, internal community".
The central internal mail-server clones a silent copy of posts to
mailman lists if a flag-file has been touched inside the mailman list
dir and sends the copy to the IMAP server. Complexity of set-up is one
extra Exim rule and a little extra code (Perl) in a reporting tool which
lets people see what's configured. Per-list setup complexity is
touch(1).
Some tech staff use the mailman lists for the most part, but for
high-volume stuff they rarely touch they subscribed to the IMAP folder
and unsubscribed from mailman; if they need to see a message, they can
dig it out. Rather than configure their mail client (almost all mutt
here), they're as likely to just use the webmail interface to IMAP.
IMAP especially rocks for full content searches, if your server supports
server-side searches and maintains full-body indexes. Cyrus is good, my
only niggle there is that I need to get around to making the index
updates incremental instead of full rebuilds. To see this in action,
mutt's new =<op> matchers, instead of ~<op>, come into play. =b ...
It's faster now than mutt with local mbox.
-Phil