James H. McCullars wrote:
Haven't heard a peep today. One of my co-workers says that before today
it would take his webmail application three or four minutes to display
his inbox (if it displayed it at all) and now it takes about 10 seconds.
Maybe some user education is in place? No one
James H. McCullars wrote:
user to do this on behalf of a user? Doing this: su user mailutil
create #driver.mbx/INBOX is problematic in that most users do not have
a login shell (we set it to /bin/false to keep them from logging in).
Any ideas, like a way to use su without giving a login
John Mangrich wrote:
You never know with Google. There is also an Older Version/Newer Version
toggle at the top by the Settings link, if you're in the older version you
The problem though is the newer version is even slower than the older
version, not just a slower interface, slower to load,
Steve Hubert wrote:
Definitely still using it for now. There is a push for the cloud stuff
but so far it hasn't been announced that it is going to happen. I think
it is almost ready to happen for alumni mail, but that's just a guess,
I'm certainly not in the loop. Thanks.
The new buzz word,
Mark Crispin wrote:
starts to creek around that point as well, although the issues in mbx is more
with the number of messages than the raw mailbox size.
luckily those who have such huge mailboxes more than likely have a few
huge emails with attachments. It'll take a while for your mailbox to
Andrew Daviel wrote:
We run procmail rules for server-side spam filtering, using dmail as the
delivery agent for MIX format. Generally this works well.
Wouldn't spam filtering at the smtp level be more effective and cause
less traffic? It's important to be able to reject a message asap,
Brett Randall wrote:
What do you know... The latest version works perfectly. Can't believe Debian
Etch ships with such an old piece of software!
That's the nature of the beast I would think. The debian stable release
is not called stable without reason. I expect that at the time of
creating
Mark Crispin wrote:
a nice media player, but underwhelming as an email platform. I
certainly would not use such a limited device as a phone.
Actually it looks pretty impractical to use as a phone with regards to
ergonomics (even worse than most cellphones which already are bad in
that
David Morsberger wrote:
My INBOX appears to be corrupted. Every imap client now gives us an error
when we try to download a message. It appears the mbx header is missing.
Can anyone help recover my mail?
Since mbx format adds some data at the beginning of the file you will
mess it up if you
Richard Miller wrote:
There seems to be a couple of strategies we could employ to remove
this final dependancy on nfs - but none of the below seem ideal.
I have been toying with similar ideas a while ago. Short of spending
significant $ on an SAN system you could put the home directories on
Kaljio wrote:
Hello,
is it possible to move from mbox to mbx while keeping the old mbox
files (/var/mail/$username) _and_ let the users have their IMAP folders
in their home directory (/home/$username/...)?
Yes, it's what I did. On debian as user $username:
mailutil move INBOX
Jeroen van Aart wrote:
Kaljio wrote:
Hello,
is it possible to move from mbox to mbx while keeping the old mbox
files (/var/mail/$username) _and_ let the users have their IMAP folders
in their home directory (/home/$username/...)?
Yes, it's what I did. On debian as user $username:
mailutil
Kaljio wrote:
I have most (95%) of the users incoming mail boxes in
/var/mail/$username
I believe the only way to keep using those files is to have them in unix
format.
Summed up I'd like to
-convert from unix mbox files /var/mail/$username to mbx format
-keep the files at
Per Foreby wrote:
I also run debian on all servers (and clients), but I always compile the
imap daemon from source. The same goes for other important server
software, like sendmail, apache, php and mysql.
I tried that with uw-imapd but the compilation gave a bunch of errors,
most likely to
[EMAIL PROTECTED] wrote:
Oct 12 09:41:28 ice9 xinetd[7609]: START: imaps pid=12768 from=15.9.73.143
Oct 12 09:41:28 ice9 xinetd[7609]: EXIT: imaps status=1 pid=12768
duration=0(sec)
Any other suggestions or troubleshooting ideas?
Normally this would be caused either by the port already
Alexander Ten wrote:
I'm sorry for kind of a dumb question, I've read FAQ, and even compiled sources on WinXP, but I'm trying to figure
Debian linux to me has the best package system and works great as a
server (stable release called Etch). Installing imap is a matter of
apt-get install
Thanks to anyone who answered. It helps a lot finding a workable
solution. I did find out there exists a tool called imapsync. Don't
think it would work well to continuously mirror a live copy, it seems a
bit flaky.
Joel Reicher wrote:
In case you missed it for some reason, I replied to you
Hello,
Excuse me for posting this again, but now on imap-uw instead of
imap-use. I have given this quite some thought but haven't yet found a
satisfactory solution. Having multiple smtp servers and failover servers
is not a problem. But the problem is if the server which contains the
user's
Jeroen van Aart wrote:
If you check here it talks about replication for subversion:
http://svnbook.red-bean.com/en/1.4/svn.reposadmin.maint.html#svn.reposadmin.maint.replication
___
Imap-uw mailing list
Imap-uw@u.washington.edu
https://mailman1
Dan Pritts wrote:
On Sun, Sep 16, 2007 at 01:33:50PM -0700, Mark Crispin wrote:
My understanding is that this is what caused the spectacular failure of
the new mail system at a big 10 university last fall.
they had bought their fancy NFS servers from a large vendor known for
their PCs.
You
Mark Crispin wrote:
A more reasonable approach is to use soft quotas, not hard quotas, and
have mail delivery stop at soft quotas. Hard quotas are likely to cause
problems.
How would you stop mail delivery if a soft quota has been hit?
Regards,
Jeroen
Gregory Hicks wrote:
However, you'd better have a soft quota well below what you expect your
hard quota to be or the spool may be left in an unstable state
(read unstable state as corrupted.)
But as far as I know a soft quota can just be ignored by the user. And
as long as something can be
(reply originally sent to the wrong list, I believe :-)
Oscar del Rio wrote:
What's the recommended way to move a Unix INBOX to mbx format so that
POP3 clients (with keep messages on server for # days) don't download
duplicates the next time they connect?
I have used the same command
Oscar del Rio wrote:
I don't think there's need for it. mixcvt IS the way to go! :)
Unless of course you want to run a vanilla Debian stable install. Not
that it's a bad thing, it's not called stable for nothing.
Regards,
Jeroen
___
Imap-uw
24 matches
Mail list logo
