Re: [courier-users] No SPF reject during DNS outage. How come?
Hey Alessandro - did you receive any replies not cc'd to the list? Just thinking out loud here... does courier cache lookups or is it possible your local resolver did? Maybe something cached the lookup of your SPF for your domain - and then the non-cached lookup of the IP failed... Could that result in the behaviour you see? Maybe you would have to have timed your test to occur during the cache lifetime of the spf record? Mitch -Original Message- From: Alessandro Vesely [mailto:ves...@tana.it] Sent: November-12-15 3:23 AM To: Courier Users Subject: [courier-users] No SPF reject during DNS outage. How come? Hi! I received a bunch of spam marked like this: Return-Path: Received: from [210.205.1.118] (softdnserr [210.205.1.118]) by wmail.tana.it with ESMTP; Thu, 12 Nov 2015 09:55:57 +0100 id 005DC042.56445431.5BFC Received-SPF: error (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=zl...@tana.it; remoteip=210.205.1.118; remotehost=softdnserr; helo=[210.205.1.118]; receiver=wmail.tana.it; The "softdnserr" presumably came from DNS outage. The NS was disconnected for quite some time, so only internal stuff was being resolved during reception. Thus, Courier could get a -all SPF record for tana.it, but not the reverse IP for that Korean address. However, I tried to reproduce that behavior to no avail. At the console, I always got _517 SPF fail_ after MAIL FROM:, even if I disconnected the NS again. My Courier version is getting old, but this doesn't seem to be related to the recent SPF fix, does it? Any other idea? TIA Ale -- ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users -- ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] performance question
On 11/12/2015 04:45 AM, Jan Müller wrote: > 13gb email in user inboxes (6 users) ... > Also, we are having problems with Thunderbird, our current imap > client. It's slow. It's global index, which should speed up searching, > has many UX problems and does not find every message. Any suggestions > for good windows imap client would be appreciated too. As you evaluate other clients, you should keep in mind the possibility that the problem isn't in Thunderbird, at all. When an IMAP client synchronizes with a server, it retrieves a complete list of messages in the folder that it's synchronizing from the server. It compares that list to the data on disk, removes messages from disk that aren't on the server any longer, and fetches individual messages that it doesn't have. There are a couple of things that could be very slow about that. The first is that Thunderbird defaults to an mbox storage for mail folders. In order to do anything but append new messages, it has to re-write the entire file. That'll happen occasionally when Thunderbird "compacts folders," and when that happens it's going to be a prolonged, disk-intensive process for multi-gigabyte folders. The other is that every time Thunderbird opens a folder with tens of thousands of messages, the sync process can create a lot of network traffic, and a lot of disk activity on the server. You might be able to find a client with better local storage than Thunderbird, but you can't avoid the latter problem as long as you're using IMAP. Big folders will always suck. There's really only one good way to use IMAP: The Inbox should have only messages that require action. Once a message has been handled, or read with no required action, it should be archived. Thunderbird makes that process easy. Just press 'a' on the keyboard when you're done with a message. And used in that way, I've seen very large accounts perform very well and have no problems with the search tool. No matter what your client is, huge Inboxes are difficult to support. Good luck. -- ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] performance question
Jan Müller writes: Our courier server works mostly ok, but searching in large inboxes takes couple of seconds. Is there a way how to speed up search? Our server is a virtual machine on current generation xeon server: 1 virtual cpu 1gb ram We have disk on 7.2k rpm drive: 5gb email in shared inboxes 13gb email in user inboxes (6 users) We have less than 100 new emails daily. I think imap search is mostly disk bound and adding cpu or memory won't help. Is this true? Correct. IMAP search is mostly disk bound. If it is so, than moving to ssd should be greatly beneficial. Or would more cpu or ram be benefical? Another option is RAID, specifically RAID-1. The more spindles you have, the better the latency. pgp3Utvk7V4LL.pgp Description: PGP signature -- ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Re: [courier-users] No SPF reject during DNS outage. How come?
Alessandro Vesely writes: Hi! I received a bunch of spam marked like this: Return-Path: Received: from [210.205.1.118] (softdnserr [210.205.1.118]) by wmail.tana.it with ESMTP; Thu, 12 Nov 2015 09:55:57 +0100 id 005DC042.56445431.5BFC Received-SPF: error (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=zl...@tana.it; remoteip=210.205.1.118; remotehost=softdnserr; helo=[210.205.1.118]; receiver=wmail.tana.it; The "softdnserr" presumably came from DNS outage. The NS was disconnected for quite some time, so only internal stuff was being resolved during reception. Thus, Courier could get a -all SPF record for tana.it, but not the reverse IP for that Korean address. However, I tried to reproduce that behavior to no avail. At the console, I always got _517 SPF fail_ after MAIL FROM:, even if I disconnected the NS again. My Courier version is getting old, but this doesn't seem to be related to the recent SPF fix, does it? Any other idea? A failed SPF DNS lookup results in a status of "error". Check your "error" status handling. If you have "error" included in the BOFHSPF settings, it is considered a pass. pgpIh7qEXCkYV.pgp Description: PGP signature -- ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
[courier-users] performance question
Hi, I kindly ask for a performance tip. Our courier server works mostly ok, but searching in large inboxes takes couple of seconds. Is there a way how to speed up search? Our server is a virtual machine on current generation xeon server: 1 virtual cpu 1gb ram We have disk on 7.2k rpm drive: 5gb email in shared inboxes 13gb email in user inboxes (6 users) We have less than 100 new emails daily. I think imap search is mostly disk bound and adding cpu or memory won't help. Is this true? If it is so, than moving to ssd should be greatly beneficial. Or would more cpu or ram be benefical? Also, we are having problems with Thunderbird, our current imap client. It's slow. It's global index, which should speed up searching, has many UX problems and does not find every message. Any suggestions for good windows imap client would be appreciated too. Thank you very much. Regards, Jan Müller -- ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
[courier-users] No SPF reject during DNS outage. How come?
Hi! I received a bunch of spam marked like this: Return-Path: Received: from [210.205.1.118] (softdnserr [210.205.1.118]) by wmail.tana.it with ESMTP; Thu, 12 Nov 2015 09:55:57 +0100 id 005DC042.56445431.5BFC Received-SPF: error (Address does not pass the Sender Policy Framework) SPF=MAILFROM; sender=zl...@tana.it; remoteip=210.205.1.118; remotehost=softdnserr; helo=[210.205.1.118]; receiver=wmail.tana.it; The "softdnserr" presumably came from DNS outage. The NS was disconnected for quite some time, so only internal stuff was being resolved during reception. Thus, Courier could get a -all SPF record for tana.it, but not the reverse IP for that Korean address. However, I tried to reproduce that behavior to no avail. At the console, I always got _517 SPF fail_ after MAIL FROM:, even if I disconnected the NS again. My Courier version is getting old, but this doesn't seem to be related to the recent SPF fix, does it? Any other idea? TIA Ale -- ___ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
