Re: Force ipop3d to use TLS/SSL when running on odd port
On Fri, Jul 09, 2004 at 10:26:26AM -0400, Erik Kangas wrote: I think, that short of modifying the source for ipop3d, you could accomplish this task my using stunnel on the server to listen to the desired port for SSL connections and forward these to the pop3s port locally. This will ensure that you can have an SSL-only POP connection on an alternate port and will solve the ipop3d port issue. See stunnel.org. This seems rather extreme given the source code changes are changing 995 to another number (src/c-client/pop3.c line 35 of imap-2004 release). And it appears that you might be able to get away with simply changing the pop3s line in /etc/services. Neither is it overly complicated. Certainly less hassle than stunnel was (I have used it for imap over SSL before uw-imap supported SSL - builtin support is *so* much better). --- __o Bradley ArltSecurity Team Lead _ \_ [EMAIL PROTECTED] University Of Calgary (_)/(_) Las hojas de coca no son droga Computer Science
Re: Perdition IMAP Proxy
On Thu, Jul 08, 2004 at 11:16:19AM -0700, Mark Crispin wrote: On Thu, 8 Jul 2004, Brad Arlt wrote: Perdition is meant to allow you to have one imap server, as far as your users are concerned, and as many real IMAP servers as needed. Perdition chooses the correct server for each user, and proxies the connection to it for the user. This can also be handled using LOGIN-REFERRALS but sadly not all mail clients support this. That seems to be a lot of ongoing (and permanent) work and resources just to avoid a simple one-time user configuration. You can simply have a special DNS zone in which each user is registered and points to the correct IMAP server, and dispense with proxies. mrc.deskmail.washington.edu always points to mrc's IMAP server, even though the machine changes over time. Holy crap, that is a beautiful solution! Shifting all the fiddly bits to a PHP/perl script And no prolonged struggle with proxy software not supporting all the features it should! One thing I will stress to the folks still hooked on proxy software to solve this problem: Things that do not need to use the proxy (webmail for example) should contact your IMAP servers directly. This allows your users access to their email without the added point of failure. Plus it takes some load off the proxy. --- __o Bradley ArltSecurity Team Lead _ \_ [EMAIL PROTECTED] University Of Calgary (_)/(_) Las hojas de coca no son droga Computer Science
Re: hardwiring the IMAP folders directory
On Wed, May 26, 2004 at 08:02:01PM +0200, Nicolas Kowalski wrote: Thomas Lohman [EMAIL PROTECTED] writes: For my lab, I followed most of the instructions/patches found here: http://carumba.com/imap/ It worked well for me. Two caveats with that one, EMPTYPROTO should be set to use the Unix mailbox format, not MBX. And clever users may create subfolders with . as the first charactor. --- __o Bradley ArltSecurity Team Lead _ \_ [EMAIL PROTECTED] University Of Calgary (_)/(_) Las hojas de coca no es droga. Computer Science
Re: mbx performance
On Tue, May 25, 2004 at 02:30:58PM -0700, Thomas Smith wrote: As I understand it, mbx is more memory efficient than mbox. This being the case, shouldn't it consume less RAM while a mailbox is being read by an IMAP client? This doesn't seem to be happening in my situation. I'd say it should use more RAM, not less. Speed increases rarely mean memory footprint decreases. For example, I use SquirrellMail for webmail. There are system-wide resource restrictions on RAM usage preventing any user from utilizing more than 8 MB of RAM via SquirrellMail. My Sent folder would always exceed this amount when I selected View All--there are over 3700 emails stored there. I continue to get the error after the conversion to mbx. Am I missing something or did I misinterprete what I read? Me thinks you have. PHP has a default memory limit of 8MB. I used to increase this to 16MB, but of late was forced to make it 20MB - after which I have had no complaints. In your php.ini file you will want to change or add a memory_limit line to look something like: memory_limit = 20M Your magic number for a memory limit may vary, or you may want to remove the memory limit. --- __o Bradley ArltSecurity Team Lead _ \_ [EMAIL PROTECTED] University Of Calgary (_)/(_) Las hojas de coca no es droga. Computer Science
Re: Bug?
On Thu, Dec 18, 2003 at 08:10:37PM +0100, Lars Hallberg wrote: Anyway, I have a 'kill' option that removes the mailbox if it is empty after the mail in it has been resorted. But if it contains a pseudo messages, the removal of the folder fail becose it's not empty - but it is exept for the pseudo messages. It might be a matter of opinion, but I consider that a bug. Not a terable one, but a slightly anoying one. I don't consider this a bug. The message is real. Pine, mutt, and friends all see it as a message if you open the file directly. The IMAP and POP servers treat it special (I think, it may be the clients though), but I don't think c-client should. The solution is to examine this one remaining message and see if it counts. --- __o Bradley ArltSecurity Team Lead _ \_ [EMAIL PROTECTED] University Of Calgary (_)/(_) Joyously Canadian Computer Science
Re: Cygwin patches for 2002e
On Wed, Oct 22, 2003 at 10:52:22AM -0700, Eduardo Chappa wrote: *** Mark Crispin ([EMAIL PROTECTED]) wrote today: :) Once again... :) :) Simultaneous access in the mbx format requires meaningful file locking. :) :) There is no such thing as meaningful file locking in Windows 98. :) Windows 98 is not a real operating system. Nor are Windows 95, Windows :) Me, Windows 3.1, MS-DOS, Mac OS 9 (and earlier), etc. Mark, Does this mean that the changes that you are accepting into C-client will make Pine not work in Windows 9X when using mbx style folders?. I believe you are trying to say that, but it is not completely clear. Your answer is about locking, not about mbx style folders. I just want to be sure that the answer to my question is yes. Can you confirm or deny this, please? I'll take a stab at this... mbx needs file locking if it has any hope of mailbox integrity if there is concurrent access - like email delivery or the mailbox being open in two processes. If you don't have real file locking, you can't use mbx. There is a nice long rant/documentation on locking in the UW-imap distro (so I presume it is in the Pine distro as well) in docs/locking.txt So to spell it out for you: Windows Me/98/95/3.11/3.1/3.0, MacOS 9, and MS-DOS cannot use mbx format without great risk of data corruption. It may be you *can* use mbx, but you shouldn't. I have a feeling that the Unix mailbox format will work better for you under these OSes. Using Windows 2000/XP/2003 will allow you to use both Windows *and* mbx in without these problems. --- __o Bradley ArltSecurity Team Lead _ \_ [EMAIL PROTECTED] University Of Calgary (_)/(_) Joyously Canadian Computer Science
Re: newbie issues.....installing the utilities...getting an mbx mailbox to install!!
On Tue, Nov 19, 2002 at 09:06:52PM -0600, Oskar Teran wrote: hello people, I've been trying to make an mbx mailbox for a few departments but I just can't seem to get it to work. Ive read the o'reilly IMAP book, i've read the readme's and docs.but I still can't get it to work!! I've installed imap 2002 on a Redhat 7.3. I also downloaded the client utilities.did exactly as they suggest in their docs, but all I get is errors...directory does not exist...exit error 2 all over the place. What is the correct way to install this thing?? And can someone please point me to a clear documentation of how to create the mbx mailbox..I'd be so grateful for this!!! The rest of the email server is working.I just need to make department email boxes and the mbx format seems like the correct way to go...but I can't create it.!!! I am sure there are those who can give you a good answer, imap server specific answer. But my advice is use strace to find out the path the imap server is not finding. man strace to figure out how to use it. --- __o Bradley ArltSecurity Team Lead _ \_ [EMAIL PROTECTED] University Of Calgary (_)/(_) I should be biking right now. Computer Science
