[Dovecot] Outlook 2010 very slow when using IMAP - are there any tweaks?
Hi,
though this is a bit of a side question, has anybody had an issue while running Outlook 2010 with Dovecot?
The reason why I am asking is that I have setup a Dovecot 2.1.7 server on FreeBSD which works fantastically with Thunderbird but Outlook seems to be twice as slow in transferring information across??
# dovecot -n # 2.1.7: /usr/local/etc/dovecot/dovecot.conf # OS: FreeBSD 8.2-RELEASE amd64 auth_debug = yes auth_mechanisms = plain ntlm login auth_use_winbind = yes auth_username_format = %n auth_verbose = yes auth_winbind_helper_path = /usr/local/bin/ntlm_auth disable_plaintext_auth = no info_log_path = /var/log/dovecot-info.log log_path = /var/log/dovecot.log mail_gid = mail_user mail_home = /mail/AD_Mail/%Ld/%Ln mail_location = maildir:~/Maildir mail_uid = mail_user passdb { args = failure_show_msg=yes driver = pam } pop3_fast_size_lookups = yes pop3_lock_session = yes pop3_no_flag_updates = yes protocols = imap pop3 ssl = no userdb { driver = static }
Since (like most corporate organizations out there) we solely run Outlook coupled to Exchange, this excersize was meant to be a way of getting rid of PST files. We don't run out own Exchange however, and don't have any control over it either.
My workaround was to simply use the Outlook GUI space to transfer emails between Exchange and Dovecot running the IMAPv4 protocol.
For whatever reason Outlook is being really garbage about dealing with stuff and since I don't know Outlook or MS products very well (being your typical average OpenSource guy) I was wondering if there were any tweaks that could be made within Outlook to speed it up or in Dovecot to work better with Outlook?
I guess one could get sidetracked into the argument of mdbox vs. Maildir from my config however, Thunderbird is really fast and transfers large amounts of data really easily. Reaches round 130Mbps using nload performance grapher, while Outlook only manages ~50kbps but spikes at 2-3Mbps on occassion.
Can anyone offer any guidence or assistance in this matter??
Actually wherever I run Dovecot, including my servers at home, it is fast and reliable. Yes I know MS is the polar opposite of anything worth using however, my company won't change and I'm stuck banging my head against the wall while trying to get MS to interface with ANYTHING.....
Regards,
Kaya
On 02/07/2012 15:34, Kaya Saman wrote:
Hi,
though this is a bit of a side question, has anybody had an issue while running Outlook 2010 with Dovecot?
Yes, as far as being an IMAP client Outlook 2010 has not been any good for me, slow, hangs, various non-intuitive issues...
Thunderbird works a treat and I use it all the time, until someone sends me a meeting request from an Outlook client.
-- Regards,
Giles Coochey, CCNA, CCNAS NetSecSpec Ltd +44 (0) 7983 877438 http://www.coochey.net http://www.netsecspec.co.uk giles@coochey.net
On Mon, Jul 2, 2012 at 3:37 PM, Giles Coochey <giles@coochey.net> wrote:
On 02/07/2012 15:34, Kaya Saman wrote:
Hi,
though this is a bit of a side question, has anybody had an issue while running Outlook 2010 with Dovecot?
Yes, as far as being an IMAP client Outlook 2010 has not been any good for me, slow, hangs, various non-intuitive issues...
Thunderbird works a treat and I use it all the time, until someone sends me a meeting request from an Outlook client.
-- Regards,
Giles Coochey, CCNA, CCNAS NetSecSpec Ltd +44 (0) 7983 877438 http://www.coochey.net http://www.netsecspec.co.uk giles@coochey.net
Thanks Giles, but unfortunately as stated before T-Bird won't connect to our remote Exchange server which doesn't have IMAP active for various reasons......
I prefer Alpine myself but try running that on Windows 7 (forced to at work :-( ).
Regards,
Kaya
Il 02/07/2012 16:34, Kaya Saman ha scritto:
Hi,
though this is a bit of a side question, has anybody had an issue while running Outlook 2010 with Dovecot?
The reason why I am asking is that I have setup a Dovecot 2.1.7 server on FreeBSD which works fantastically with Thunderbird but Outlook seems to be twice as slow in transferring information across??
# dovecot -n # 2.1.7: /usr/local/etc/dovecot/dovecot.conf # OS: FreeBSD 8.2-RELEASE amd64 auth_debug = yes auth_mechanisms = plain ntlm login auth_use_winbind = yes auth_username_format = %n auth_verbose = yes auth_winbind_helper_path = /usr/local/bin/ntlm_auth disable_plaintext_auth = no info_log_path = /var/log/dovecot-info.log log_path = /var/log/dovecot.log mail_gid = mail_user mail_home = /mail/AD_Mail/%Ld/%Ln mail_location = maildir:~/Maildir mail_uid = mail_user passdb { args = failure_show_msg=yes driver = pam } pop3_fast_size_lookups = yes pop3_lock_session = yes pop3_no_flag_updates = yes protocols = imap pop3 ssl = no userdb { driver = static }
Since (like most corporate organizations out there) we solely run Outlook coupled to Exchange, this excersize was meant to be a way of getting rid of PST files. We don't run out own Exchange however, and don't have any control over it either.
My workaround was to simply use the Outlook GUI space to transfer emails between Exchange and Dovecot running the IMAPv4 protocol.
For whatever reason Outlook is being really garbage about dealing with stuff and since I don't know Outlook or MS products very well (being your typical average OpenSource guy) I was wondering if there were any tweaks that could be made within Outlook to speed it up or in Dovecot to work better with Outlook?
I guess one could get sidetracked into the argument of mdbox vs. Maildir from my config however, Thunderbird is really fast and transfers large amounts of data really easily. Reaches round 130Mbps using nload performance grapher, while Outlook only manages ~50kbps but spikes at 2-3Mbps on occassion.
Try to understand (from dovecot logs) if there are difference between outlook and thunderbird, for example outlook connect over ssl and thunderbird no ecc..
Nicola
Can anyone offer any guidence or assistance in this matter??
Actually wherever I run Dovecot, including my servers at home, it is fast and reliable. Yes I know MS is the polar opposite of anything worth using however, my company won't change and I'm stuck banging my head against the wall while trying to get MS to interface with ANYTHING.....
Regards,
Kaya
On Mon, Jul 2, 2012 at 3:40 PM, Mailing List SVR <lists@svrinformatica.it> wrote:
Il 02/07/2012 16:34, Kaya Saman ha scritto:
Hi,
though this is a bit of a side question, has anybody had an issue while running Outlook 2010 with Dovecot?
The reason why I am asking is that I have setup a Dovecot 2.1.7 server on FreeBSD which works fantastically with Thunderbird but Outlook seems to be twice as slow in transferring information across??
# dovecot -n # 2.1.7: /usr/local/etc/dovecot/dovecot.conf # OS: FreeBSD 8.2-RELEASE amd64 auth_debug = yes auth_mechanisms = plain ntlm login auth_use_winbind = yes auth_username_format = %n auth_verbose = yes auth_winbind_helper_path = /usr/local/bin/ntlm_auth disable_plaintext_auth = no info_log_path = /var/log/dovecot-info.log log_path = /var/log/dovecot.log mail_gid = mail_user mail_home = /mail/AD_Mail/%Ld/%Ln mail_location = maildir:~/Maildir mail_uid = mail_user passdb { args = failure_show_msg=yes driver = pam } pop3_fast_size_lookups = yes pop3_lock_session = yes pop3_no_flag_updates = yes protocols = imap pop3 ssl = no userdb { driver = static }
Since (like most corporate organizations out there) we solely run Outlook coupled to Exchange, this excersize was meant to be a way of getting rid of PST files. We don't run out own Exchange however, and don't have any control over it either.
My workaround was to simply use the Outlook GUI space to transfer emails between Exchange and Dovecot running the IMAPv4 protocol.
For whatever reason Outlook is being really garbage about dealing with stuff and since I don't know Outlook or MS products very well (being your typical average OpenSource guy) I was wondering if there were any tweaks that could be made within Outlook to speed it up or in Dovecot to work better with Outlook?
I guess one could get sidetracked into the argument of mdbox vs. Maildir from my config however, Thunderbird is really fast and transfers large amounts of data really easily. Reaches round 130Mbps using nload performance grapher, while Outlook only manages ~50kbps but spikes at 2-3Mbps on occassion.
Try to understand (from dovecot logs) if there are difference between outlook and thunderbird, for example outlook connect over ssl and thunderbird no ecc..
Nicola
Hi Nicola,
there is no specific difference apart from seeing many of these errors:
Jun 26 15:10:11 imap(<user>): Error: Index /mail/AD_Mail//<user>/Maildir/.Archive/dovecot.index: Lost log for seq=2 offset=77008 Jun 26 15:10:11 imap(<user>): Warning: fscking index file /mail/AD_Mail//<user>/Maildir/.Archive/dovecot.index Jun 26 15:10:11 imap(<user>): Error: Fixed index file /mail/AD_Mail//<user>/Maildir/.Archive/dovecot.index: log_file_seq 2 -> 3 Jun 26 15:10:26 auth: Error: Got NTLMSSP neg_flags=0xa2088207 Jun 26 15:10:26 auth: Error: Got user=[<user>] domain=[] workstation=[WKS-41] len1=24 len2=278 Jun 26 15:10:26 auth: Error: Login for user []\[<user>]@[WKS-41] failed due to [Reading winbind reply failed!] Jun 26 15:10:32 auth: Error: Got NTLMSSP neg_flags=0xa2088207
Regards,
Kaya
On 02/07/2012 15:51, Kaya Saman wrote:
Hi Nicola,
there is no specific difference apart from seeing many of these errors:
Jun 26 15:10:11 imap(<user>): Error: Index /mail/AD_Mail//<user>/Maildir/.Archive/dovecot.index: Lost log for seq=2 offset=77008 Jun 26 15:10:11 imap(<user>): Warning: fscking index file /mail/AD_Mail//<user>/Maildir/.Archive/dovecot.index Jun 26 15:10:11 imap(<user>): Error: Fixed index file /mail/AD_Mail//<user>/Maildir/.Archive/dovecot.index: log_file_seq 2 -> 3 Jun 26 15:10:26 auth: Error: Got NTLMSSP neg_flags=0xa2088207 Jun 26 15:10:26 auth: Error: Got user=[<user>] domain=[] workstation=[WKS-41] len1=24 len2=278 Jun 26 15:10:26 auth: Error: Login for user []\[<user>]@[WKS-41] failed due to [Reading winbind reply failed!] Jun 26 15:10:32 auth: Error: Got NTLMSSP neg_flags=0xa2088207
From the Dovecot wiki about ntlm_auth:
Dovecot currently does blocking lookups, so if ntlm_auth is slow on responding (e.g. network problems), Dovecot blocks all other authentication requests until it's finished.
Just wondering if Outlook parallelises it's sessions and ntlm_auth is blocking because of the timing between the requests.
Have you tried a test user with local authentication?
-- Regards,
Giles Coochey, CCNA, CCNAS NetSecSpec Ltd +44 (0) 7983 877438 http://www.coochey.net http://www.netsecspec.co.uk giles@coochey.net
On 02/07/2012 16:02, Giles Coochey wrote:
On 02/07/2012 15:51, Kaya Saman wrote:
Hi Nicola,
there is no specific difference apart from seeing many of these errors:
Jun 26 15:10:11 imap(<user>): Error: Index /mail/AD_Mail//<user>/Maildir/.Archive/dovecot.index: Lost log for seq=2 offset=77008 Jun 26 15:10:11 imap(<user>): Warning: fscking index file /mail/AD_Mail//<user>/Maildir/.Archive/dovecot.index Jun 26 15:10:11 imap(<user>): Error: Fixed index file /mail/AD_Mail//<user>/Maildir/.Archive/dovecot.index: log_file_seq 2 -> 3 Jun 26 15:10:26 auth: Error: Got NTLMSSP neg_flags=0xa2088207 Jun 26 15:10:26 auth: Error: Got user=[<user>] domain=[] workstation=[WKS-41] len1=24 len2=278 Jun 26 15:10:26 auth: Error: Login for user []\[<user>]@[WKS-41] failed due to [Reading winbind reply failed!] Jun 26 15:10:32 auth: Error: Got NTLMSSP neg_flags=0xa2088207
From the Dovecot wiki about ntlm_auth:
Dovecot currently does blocking lookups, so if ntlm_auth is slow on responding (e.g. network problems), Dovecot blocks all other authentication requests until it's finished.
Just wondering if Outlook parallelises it's sessions and ntlm_auth is blocking because of the timing between the requests.
Have you tried a test user with local authentication?
Or perhaps try
auth_cache_size = 1024
To cache authentications.
-- Regards,
Giles Coochey, CCNA, CCNAS NetSecSpec Ltd +44 (0) 7983 877438 http://www.coochey.net http://www.netsecspec.co.uk giles@coochey.net
On Mon, Jul 2, 2012 at 4:06 PM, Giles Coochey <giles@coochey.net> wrote:
On 02/07/2012 16:02, Giles Coochey wrote:
On 02/07/2012 15:51, Kaya Saman wrote:
Hi Nicola,
there is no specific difference apart from seeing many of these errors:
Jun 26 15:10:11 imap(<user>): Error: Index /mail/AD_Mail//<user>/Maildir/.Archive/dovecot.index: Lost log for seq=2 offset=77008 Jun 26 15:10:11 imap(<user>): Warning: fscking index file /mail/AD_Mail//<user>/Maildir/.Archive/dovecot.index Jun 26 15:10:11 imap(<user>): Error: Fixed index file /mail/AD_Mail//<user>/Maildir/.Archive/dovecot.index: log_file_seq 2 -> 3 Jun 26 15:10:26 auth: Error: Got NTLMSSP neg_flags=0xa2088207 Jun 26 15:10:26 auth: Error: Got user=[<user>] domain=[] workstation=[WKS-41] len1=24 len2=278 Jun 26 15:10:26 auth: Error: Login for user []\[<user>]@[WKS-41] failed due to [Reading winbind reply failed!] Jun 26 15:10:32 auth: Error: Got NTLMSSP neg_flags=0xa2088207
From the Dovecot wiki about ntlm_auth:
Dovecot currently does blocking lookups, so if ntlm_auth is slow on responding (e.g. network problems), Dovecot blocks all other authentication requests until it's finished.
Just wondering if Outlook parallelises it's sessions and ntlm_auth is blocking because of the timing between the requests.
Have you tried a test user with local authentication?
Or perhaps try
auth_cache_size = 1024
To cache authentications.
-- Regards,
Giles Coochey, CCNA, CCNAS NetSecSpec Ltd +44 (0) 7983 877438 http://www.coochey.net http://www.netsecspec.co.uk giles@coochey.net
Thanks Giles :-)
I think that has made things a bit better......
In terms of the cache, is that measured in seconds??
Regards,
Kaya
On 02/07/2012 16:21, Kaya Saman wrote:
Or perhaps try
auth_cache_size = 1024
To cache authentications.
-- Regards,
Giles Coochey, CCNA, CCNAS NetSecSpec Ltd +44 (0) 7983 877438 http://www.coochey.net http://www.netsecspec.co.uk giles@coochey.net
Thanks Giles :-)
I think that has made things a bit better......
In terms of the cache, is that measured in seconds??
Regards,
Kaya
The size is in KB. I'm afraid cache-timeout and the inner workings would be something only Timo or the Source Code know :-)
-- Regards,
Giles Coochey, CCNA, CCNAS NetSecSpec Ltd +44 (0) 7983 877438 http://www.coochey.net http://www.netsecspec.co.uk giles@coochey.net
On 02/07/2012 16:22, Giles Coochey wrote:
The size is in KB. I'm afraid cache-timeout and the inner workings would be something only Timo or the Source Code know :-)
http://wiki2.dovecot.org/Authentication/Caching
the TTL setting is in seconds - perhaps what you are looking for?
-- Regards,
Giles Coochey, CCNA, CCNAS NetSecSpec Ltd +44 (0) 7983 877438 http://www.netsecspec.co.uk giles.coochey@netsecspec.co.uk
-- Regards,
Giles Coochey, CCNA, CCNAS NetSecSpec Ltd +44 (0) 7983 877438 http://www.coochey.net http://www.netsecspec.co.uk giles@coochey.net
On Mon, Jul 2, 2012 at 4:31 PM, Giles Coochey <giles@coochey.net> wrote:
On 02/07/2012 16:22, Giles Coochey wrote:
The size is in KB. I'm afraid cache-timeout and the inner workings would be something only Timo or the Source Code know :-)
http://wiki2.dovecot.org/Authentication/Caching
the TTL setting is in seconds - perhaps what you are looking for?
-- Regards,
Giles Coochey, CCNA, CCNAS NetSecSpec Ltd +44 (0) 7983 877438 http://www.netsecspec.co.uk giles.coochey@netsecspec.co.uk
-- Regards,
Giles Coochey, CCNA, CCNAS NetSecSpec Ltd +44 (0) 7983 877438 http://www.coochey.net http://www.netsecspec.co.uk giles@coochey.net
Thanks for that!
I added this:
auth_cache_size = 4096 auth_cache_ttl = 14400
to my config and checked with dovecot -n
I actually managed to knock 13 seconds of the original transfer time! :-)
Good but not good enough especially when some of our users have round 20GB of PST file :-(
Regards,
Kaya
Am 02.07.2012 17:43, schrieb Kaya Saman:
Good but not good enough especially when some of our users have round 20GB of PST file :-(
please describe where is the relation between a pst file and imap pst files are local
after all having 20 GB PST File is a user Problem ever, tell them to split up by year etc beyond sizes under 2 GB for each folder its no problem to work wich many pst files
Best Regards MfG Robert Schetterer
On 2 July 2012 13:21, Robert Schetterer <robert@schetterer.org> wrote:
Am 02.07.2012 17:43, schrieb Kaya Saman:
Good but not good enough especially when some of our users have round 20GB of PST file :-(
please describe where is the relation between a pst file and imap pst files are local
after all having 20 GB PST File is a user Problem ever, tell them to split up by year etc beyond sizes under 2 GB for each folder its no problem to work wich many pst files
And to add to Robert's excellent comments, perhaps the best policy change (since you're so keen on changing policy) would be educate your users to use email clients for email and not document storage/management systems. It's incredibly hard to get 20GB PSTs if they are stripping attachments.
Simon
On Mon, Jul 2, 2012 at 4:31 PM, Giles Coochey <giles@coochey.net> wrote:
On 02/07/2012 16:22, Giles Coochey wrote:
The size is in KB. I'm afraid cache-timeout and the inner workings would be something only Timo or the Source Code know :-)
http://wiki2.dovecot.org/Authentication/Caching
the TTL setting is in seconds - perhaps what you are looking for?
-- Regards,
Giles Coochey, CCNA, CCNAS NetSecSpec Ltd +44 (0) 7983 877438 http://www.netsecspec.co.uk giles.coochey@netsecspec.co.uk
-- Regards,
Giles Coochey, CCNA, CCNAS NetSecSpec Ltd +44 (0) 7983 877438 http://www.coochey.net http://www.netsecspec.co.uk giles@coochey.net
Giles,
what's really weird is that if I keep increasing the Cache TTL and Cache size, the speed of transfer starts dropping.
Perhaps I haven't hit the sweet spot yet however,
running:
auth_cache_size = 160000 B auth_cache_ttl = 8 hours
I am actually knocking off 4 seconds from half size values.
To be honest I just whish I could understand what is going on in order to get the transfer sub-3 minutes!
Regards,
Kaya
On Mon, Jul 2, 2012 at 4:31 PM, Giles Coochey <giles@coochey.net> wrote:
On 02/07/2012 16:22, Giles Coochey wrote:
The size is in KB. I'm afraid cache-timeout and the inner workings would be something only Timo or the Source Code know :-)
http://wiki2.dovecot.org/Authentication/Caching
the TTL setting is in seconds - perhaps what you are looking for?
-- Regards,
Giles Coochey, CCNA, CCNAS NetSecSpec Ltd +44 (0) 7983 877438 http://www.netsecspec.co.uk giles.coochey@netsecspec.co.uk
-- Regards,
Giles Coochey, CCNA, CCNAS NetSecSpec Ltd +44 (0) 7983 877438 http://www.coochey.net http://www.netsecspec.co.uk giles@coochey.net
Giles,
what's really weird is that if I keep increasing the Cache TTL and Cache size, the speed of transfer starts dropping.
Perhaps I haven't hit the sweet spot yet however,
running:
auth_cache_size = 160000 B auth_cache_ttl = 8 hours
I am actually knocking off 4 seconds from half size values.
To be honest I just whish I could understand what is going on in order to get the transfer sub-3 minutes!
Regards,
Kaya I would have thought that just enabling a simple cache would have given you a little performance increase, but unless you have a lot of users tweaking the values ought not to give you much more of a performance gain. In any case, the bottleneck appears to be your authentication mechanism, for which you're using a samba tool (presumably for AD integration). The key to this at the end would be to actually get a performance gain from
On 02/07/2012 17:12, Kaya Saman wrote: the authentication itself, but I guess that would be something for the Samba list.
-- Regards,
Giles Coochey, CCNA, CCNAS NetSecSpec Ltd +44 (0) 7983 877438 http://www.coochey.net http://www.netsecspec.co.uk giles@coochey.net
On 2.7.2012, at 19.12, Kaya Saman wrote:
what's really weird is that if I keep increasing the Cache TTL and Cache size, the speed of transfer starts dropping.
I think it may just be a coincidence that changing cache values appears to help, and the real reason maybe being just that Dovecot got restarted. Because if Outlook is using NTLM + winbind for authentication, the auth cache isn't used at all.
finally some clear answer :)
Trying dovecot to improve outlook is like using gold to improve shit. No matter how much gold is used, it will still stink.
I cannot understand that people.
On Tue, 3 Jul 2012, Timo Sirainen wrote:
On 2.7.2012, at 19.12, Kaya Saman wrote:
what's really weird is that if I keep increasing the Cache TTL and Cache size, the speed of transfer starts dropping.
I think it may just be a coincidence that changing cache values appears to help, and the real reason maybe being just that Dovecot got restarted. Because if Outlook is using NTLM + winbind for authentication, the auth cache isn't used at all.
On Mon, Jul 2, 2012 at 10:50 PM, Timo Sirainen <tss@iki.fi> wrote:
On 2.7.2012, at 19.12, Kaya Saman wrote:
what's really weird is that if I keep increasing the Cache TTL and Cache size, the speed of transfer starts dropping.
I think it may just be a coincidence that changing cache values appears to help, and the real reason maybe being just that Dovecot got restarted. Because if Outlook is using NTLM + winbind for authentication, the auth cache isn't used at all.
Thanks Giles and Timo :-)
So if I look at a different authentication mechanism say LDAP would it improve performance?
There is currently a local AD in the network which I think piggy-backs off the parent companies AD for mail.
If this is guarunteed to improve performance I don't mind taking the time to learn LDAP integration; though I must say it took me quite a while, several months in fact to learn NTLM and get it working - with very little or no help from anyone on any associated list :-( .
Regards,
Kaya
On 3.7.2012, at 9.38, Kaya Saman wrote:
So if I look at a different authentication mechanism say LDAP would it improve performance?
I doubt authentication has anything to do with why Outlook downloads mails slowly.
But you could configure Outlook to use plaintext authentication instead of NTLM authentication to see if it makes a difference. No need to change anything on Dovecot side then.
On Tue, Jul 3, 2012 at 7:46 AM, Timo Sirainen <tss@iki.fi> wrote:
On 3.7.2012, at 9.38, Kaya Saman wrote:
So if I look at a different authentication mechanism say LDAP would it improve performance?
I doubt authentication has anything to do with why Outlook downloads mails slowly.
But you could configure Outlook to use plaintext authentication instead of NTLM authentication to see if it makes a difference. No need to change anything on Dovecot side then.
I've just had a look and I don't think Outlook 2010 has that option.... ??
It might be that M$ decided to use auto authentication/negotiation as to take away the hastle from potentially confused end users?
This is frustrating, using Thunderbird this setup works really well however, my organization **requires** Outlook and the only contectivity is to a remotely managed Exchange server (being connected to over VPN to another country) and no **standard** protocols used, just **Exchange** meaning I can't even connect to the server using a 'normal' client.
:-S Am totally lost now! - BUMP!
Regards,
Kaya
Den 03.07.2012 08:58, skrev Kaya Saman:
On Tue, Jul 3, 2012 at 7:46 AM, Timo Sirainen <tss@iki.fi> wrote:
On 3.7.2012, at 9.38, Kaya Saman wrote:
So if I look at a different authentication mechanism say LDAP would it improve performance?
I doubt authentication has anything to do with why Outlook downloads mails slowly.
But you could configure Outlook to use plaintext authentication instead of NTLM authentication to see if it makes a difference. No need to change anything on Dovecot side then.
I've just had a look and I don't think Outlook 2010 has that option.... ??
I belive there is a checkbox there called something like "Use secure authentication - PKA(?)". Uncheck it, and you should have plaintext.
Arne
-- Arne K. Haaje http://www.drlinux.no/ ::: arne@drlinux.no LinkedIn: http://no.linkedin.com/pub/arne-haaje/27/189/bb
On Tue, Jul 3, 2012 at 8:07 AM, Arne K. Haaje <arne@drlinux.no> wrote:
Den 03.07.2012 08:58, skrev Kaya Saman:
On Tue, Jul 3, 2012 at 7:46 AM, Timo Sirainen <tss@iki.fi> wrote:
On 3.7.2012, at 9.38, Kaya Saman wrote:
So if I look at a different authentication mechanism say LDAP would it improve performance?
I doubt authentication has anything to do with why Outlook downloads mails slowly.
But you could configure Outlook to use plaintext authentication instead of NTLM authentication to see if it makes a difference. No need to change anything on Dovecot side then.
I've just had a look and I don't think Outlook 2010 has that option.... ??
I belive there is a checkbox there called something like "Use secure authentication - PKA(?)". Uncheck it, and you should have plaintext.
Arne
-- Arne K. Haaje http://www.drlinux.no/ ::: arne@drlinux.no LinkedIn: http://no.linkedin.com/pub/arne-haaje/27/189/bb
Thanks for that, however it wasn't checked initially.
Regards,
Kaya
On 3 Jul 2012, at 07:46, Timo Sirainen wrote:
On 3.7.2012, at 9.38, Kaya Saman wrote:
So if I look at a different authentication mechanism say LDAP would it improve performance?
I doubt authentication has anything to do with why Outlook downloads mails slowly.
But you could configure Outlook to use plaintext authentication instead of NTLM authentication to see if it makes a difference. No need to change anything on Dovecot side then.
It's a bit of a random tuppenyworth, but all my experience of slow Outlook clients seems to be local mail store sync work, perhaps garbage-collecting / defragmenting or something, but not actually getting the emails themselves . .
I have one particular client who reported issues yesterday as it happens -- all versions of Windows from XP thru Win7 running mostly older Outlook but a couple of 2010 clients -- and one particular user, logged in on only one particular workstation (Win7 & 2010 as it happens) experiences _colossal_ delays in waiting for mail to open or respond at times, and yet any other user, or moving to another machine, it's all swift and fine.
That smacks of a local desktop cache problem to me... All on the LAN, as well, no slow connections.
As I say, just 0.02 -- may not be overly relevant, but my instinct is that local storage with Outlook has significant possibility for issues.
J.
On Tue, Jul 3, 2012 at 7:59 AM, J E Lyon <role.Dovecot-Readers@jlassocs.com> wrote:
On 3 Jul 2012, at 07:46, Timo Sirainen wrote:
On 3.7.2012, at 9.38, Kaya Saman wrote:
So if I look at a different authentication mechanism say LDAP would it improve performance?
I doubt authentication has anything to do with why Outlook downloads mails slowly.
But you could configure Outlook to use plaintext authentication instead of NTLM authentication to see if it makes a difference. No need to change anything on Dovecot side then.
It's a bit of a random tuppenyworth, but all my experience of slow Outlook clients seems to be local mail store sync work, perhaps garbage-collecting / defragmenting or something, but not actually getting the emails themselves . .
I have one particular client who reported issues yesterday as it happens -- all versions of Windows from XP thru Win7 running mostly older Outlook but a couple of 2010 clients -- and one particular user, logged in on only one particular workstation (Win7 & 2010 as it happens) experiences _colossal_ delays in waiting for mail to open or respond at times, and yet any other user, or moving to another machine, it's all swift and fine.
That smacks of a local desktop cache problem to me... All on the LAN, as well, no slow connections.
As I say, just 0.02 -- may not be overly relevant, but my instinct is that local storage with Outlook has significant possibility for issues.
J.
Hmm... interesting point and had I been using a 'standard' filesystem type I would have to agree.
However this is a clean server with plenty of space left on the pool allocated for mail and it's additionally using ZFS too.
The point is that I am monitoring using nload as well as other things and the maximum bandwidth being got with Outlook is a few Mbps burst, average 50kbps; while with T-Bird I get way over 130Mbps???
Regards,
Kaya
On 3 Jul 2012, at 08:12, Kaya Saman wrote:
On Tue, Jul 3, 2012 at 7:59 AM, J E Lyon <role.Dovecot-Readers@jlassocs.com> wrote:
On 3 Jul 2012, at 07:46, Timo Sirainen wrote:
On 3.7.2012, at 9.38, Kaya Saman wrote:
So if I look at a different authentication mechanism say LDAP would it improve performance?
I doubt authentication has anything to do with why Outlook downloads mails slowly.
But you could configure Outlook to use plaintext authentication instead of NTLM authentication to see if it makes a difference. No need to change anything on Dovecot side then.
It's a bit of a random tuppenyworth, but all my experience of slow Outlook clients seems to be local mail store sync work, perhaps garbage-collecting / defragmenting or something, but not actually getting the emails themselves . .
I have one particular client who reported issues yesterday as it happens -- all versions of Windows from XP thru Win7 running mostly older Outlook but a couple of 2010 clients -- and one particular user, logged in on only one particular workstation (Win7 & 2010 as it happens) experiences _colossal_ delays in waiting for mail to open or respond at times, and yet any other user, or moving to another machine, it's all swift and fine.
That smacks of a local desktop cache problem to me... All on the LAN, as well, no slow connections.
As I say, just 0.02 -- may not be overly relevant, but my instinct is that local storage with Outlook has significant possibility for issues.
J.
Hmm... interesting point and had I been using a 'standard' filesystem type I would have to agree.
However this is a clean server with plenty of space left on the pool allocated for mail and it's additionally using ZFS too.
The point is that I am monitoring using nload as well as other things and the maximum bandwidth being got with Outlook is a few Mbps burst, average 50kbps; while with T-Bird I get way over 130Mbps???
Oh, I may have come into the thread a little late and missed some details :)
All the same, the customer I was mentioning has a fairly newish machine, though nothing fancy filesystem-wise. Sounds like you're monitoring what's actually happening anyway.
Having said that, I've _always_ seen Microsoft network activity fall way below other protocols, so it might not be so surprising -- and if the local store is busy shuffling every message each time a new one is added, that would explain a lower load on the network while the local client was busy chasing its own tail.
Do you mean that the clean install has very little email saved locally yet, and that Dovecot has little content for it to retrieve? So, there surely couldn't be any local file thrashing, there...
J.
Hi there,
as I recall you are using OL2010 in an enterprise environment? In many cases home directories etc. are residing then on network shares. And that’s where .pst files and .ost files most probably are being written, too. When profiles are being configured writing incoming mails to .pst files (so you have a "local" copy), you will run in a situation, MS does not support/recommend, as this slows down (yes, confirmed) the client and may have negative side effects to others on that share:
http://support.microsoft.com/kb/297019/en-us
Cheers Dirk
-- Dirk Jahnke-Zumbusch Deutsches Elektronen-Synchrotron DESY IT Information Fabrics Member of the Helmholtz Association D-22603 Hamburg Notkestrasse 85 / 22607 Hamburg
On Tue, Jul 3, 2012 at 8:26 AM, Jahnke-Zumbusch, Dirk <dirk.jahnke-zumbusch@desy.de> wrote:
Hi there,
as I recall you are using OL2010 in an enterprise environment? In many cases home directories etc. are residing then on network shares. And that’s where .pst files and .ost files most probably are being written, too. When profiles are being configured writing incoming mails to .pst files (so you have a "local" copy), you will run in a situation, MS does not support/recommend, as this slows down (yes, confirmed) the client and may have negative side effects to others on that share:
http://support.microsoft.com/kb/297019/en-us
Cheers Dirk
-- Dirk Jahnke-Zumbusch Deutsches Elektronen-Synchrotron DESY IT Information Fabrics Member of the Helmholtz Association D-22603 Hamburg Notkestrasse 85 / 22607 Hamburg
Yeah the disk is relatively empty:
# df -h Filesystem Size Used Avail Capacity Mounted on /dev/da0s1a 7.7G 5.2G 1.9G 74% / devfs 1.0K 1.0K 0B 100% /dev ZPOOL_1 9.8G 1.1G 8.7G 11% /mail
The PST's seem to be stored on local hard disk too.
It seems that there was an issue with Send/Recieve settings that my manager has made me aware of, basically turn off the Auto Send/Recieve and it seems to marginally improve performance??
Well thanks to all and I guess we'll keep testing ;-)
Dovecot rocks, it's just a pitty that there is so much poorly programmed corporate software out there!
Regards,
Kaya
On 2012-07-03 3:12 AM, Kaya Saman <kayasaman@gmail.com> wrote:
However this is a clean server with plenty of space left on the pool allocated for mail and it's additionally using ZFS too.
What OS? ZFS implementation/version? How is mail stored (maildir? mbox?)
While I don't think this is your problem, just fyi, my understanding is that it is fairly easy to implement ZFS wrong (which would cause serious performance problems), and that the only decent ZFS implementation is Suns (ie, what ships with Nexenta), or the latest FreeBSDs...
Also, my understanding is that ZFS isn't the snappiest of filesystems even when properly configured (you trade performance for data integrity).
Personally, I'd recommend trying this on a traditional FS (XFS or Reiserfs for maildir) and see if that changes things.
On 2012-07-03 3:12 AM, Kaya Saman <kayasaman@gmail.com> wrote:
The point is that I am monitoring using nload as well as other things and the maximum bandwidth being got with Outlook is a few Mbps burst, average 50kbps; while with T-Bird I get way over 130Mbps?
Congrats - there's your problem... now you need to find out *why* this is so slow... most likely a tcp dump analysis of a session is the only way - I think there are people here who could help you analyze one (but not me, sorry)...
On 2012-07-03 3:41 AM, Kaya Saman <kayasaman@gmail.com> wrote:
The PST's seem to be stored on local hard disk too.
'Seem' to be? You need to make sure, because if they aren't that could definitely cause, or at least contribute to this kind of problem.
--
Best regards,
Charles
On Tue, Jul 3, 2012 at 11:37 AM, Charles Marcus <CMarcus@media-brokers.com> wrote:
On 2012-07-03 3:12 AM, Kaya Saman <kayasaman@gmail.com> wrote:
However this is a clean server with plenty of space left on the pool allocated for mail and it's additionally using ZFS too.
What OS? ZFS implementation/version? How is mail stored (maildir? mbox?)
While I don't think this is your problem, just fyi, my understanding is that it is fairly easy to implement ZFS wrong (which would cause serious performance problems), and that the only decent ZFS implementation is Suns (ie, what ships with Nexenta), or the latest FreeBSDs...
Also, my understanding is that ZFS isn't the snappiest of filesystems even when properly configured (you trade performance for data integrity).
Personally, I'd recommend trying this on a traditional FS (XFS or Reiserfs for maildir) and see if that changes things.
FreeBSD 8.2 x64 using Maildir. ZFS is perfect no worries with that!!! Additionally the system is on a VMware cluster which is also fine - have checked all as diagnostics.
The usage here is minimal, and since I also use ZFS at home too with quite a larger file system then at work (I know I know) and really hammer the heck out of it there is no issue.
On 2012-07-03 3:12 AM, Kaya Saman <kayasaman@gmail.com> wrote:
The point is that I am monitoring using nload as well as other things and the maximum bandwidth being got with Outlook is a few Mbps burst, average 50kbps; while with T-Bird I get way over 130Mbps?
Congrats - there's your problem... now you need to find out *why* this is so slow... most likely a tcp dump analysis of a session is the only way - I think there are people here who could help you analyze one (but not me, sorry)...
Yeah, it seems to be M$ implementation of IMAP. I don't think that there's anything anyone can do.... Outlook seems to wait after each transmission (found using Wireshark).
On 2012-07-03 3:41 AM, Kaya Saman <kayasaman@gmail.com> wrote:
The PST's seem to be stored on local hard disk too.
'Seem' to be? You need to make sure, because if they aren't that could definitely cause, or at least contribute to this kind of problem.
It is definitely stored locally!
--
Best regards,
Charles
Regards,
Kaya
On 3 Jul 2012, at 11:51, Kaya Saman wrote:
Yeah, it seems to be M$ implementation of IMAP. I don't think that there's anything anyone can do.... Outlook seems to wait after each transmission (found using Wireshark).
Is the client syncing more than it has to? I mean, putting aside the delays in waiting on each transmission, is it generating traffic that shouldn't even be required? Still might not present a solution (short of unsubscribing much data) but I'm mindful of the oddity that disabling automatic send/receive makes such a difference.
James.
On Tue, Jul 3, 2012 at 11:57 AM, J E Lyon <role.Dovecot-Readers@jlassocs.com> wrote:
On 3 Jul 2012, at 11:51, Kaya Saman wrote:
Yeah, it seems to be M$ implementation of IMAP. I don't think that there's anything anyone can do.... Outlook seems to wait after each transmission (found using Wireshark).
Is the client syncing more than it has to? I mean, putting aside the delays in waiting on each transmission, is it generating traffic that shouldn't even be required? Still might not present a solution (short of unsubscribing much data) but I'm mindful of the oddity that disabling automatic send/receive makes such a difference.
James.
Actually disabling Send/recieve didn't do anything :-(
I held a stopwatch to it for both pre and post and no difference.
T-Bird transfers get 1 min. 35 secs for 1600 messages.
Outlook gets 3 min. 6 secs for the same amount of messages.
Regards,
Kaya
Am 03.07.2012 13:00, schrieb Kaya Saman:
On Tue, Jul 3, 2012 at 11:57 AM, J E Lyon <role.Dovecot-Readers@jlassocs.com> wrote:
On 3 Jul 2012, at 11:51, Kaya Saman wrote:
Yeah, it seems to be M$ implementation of IMAP. I don't think that there's anything anyone can do.... Outlook seems to wait after each transmission (found using Wireshark).
Is the client syncing more than it has to? I mean, putting aside the delays in waiting on each transmission, is it generating traffic that shouldn't even be required? Still might not present a solution (short of unsubscribing much data) but I'm mindful of the oddity that disabling automatic send/receive makes such a difference.
James.
Actually disabling Send/recieve didn't do anything :-(
I held a stopwatch to it for both pre and post and no difference.
T-Bird transfers get 1 min. 35 secs for 1600 messages.
Outlook gets 3 min. 6 secs for the same amount of messages.
Regards,
Kaya
meanwhile some workaround for the client
http://www.youtube.com/watch?v=-6wXTP1AIq8
-- Best Regards MfG Robert Schetterer
On Tue, Jul 3, 2012 at 12:25 PM, Robert Schetterer <robert@schetterer.org> wrote:
Am 03.07.2012 13:00, schrieb Kaya Saman:
On Tue, Jul 3, 2012 at 11:57 AM, J E Lyon <role.Dovecot-Readers@jlassocs.com> wrote:
On 3 Jul 2012, at 11:51, Kaya Saman wrote:
Yeah, it seems to be M$ implementation of IMAP. I don't think that there's anything anyone can do.... Outlook seems to wait after each transmission (found using Wireshark).
Is the client syncing more than it has to? I mean, putting aside the delays in waiting on each transmission, is it generating traffic that shouldn't even be required? Still might not present a solution (short of unsubscribing much data) but I'm mindful of the oddity that disabling automatic send/receive makes such a difference.
James.
Actually disabling Send/recieve didn't do anything :-(
I held a stopwatch to it for both pre and post and no difference.
T-Bird transfers get 1 min. 35 secs for 1600 messages.
Outlook gets 3 min. 6 secs for the same amount of messages.
Regards,
Kaya
meanwhile some workaround for the client
http://www.youtube.com/watch?v=-6wXTP1AIq8
-- Best Regards MfG Robert Schetterer
Thanks!
I tried disabling this for **all** accounts but found no perfomance benefit.
Regards,
Kaya
On Tue, Jul 3, 2012 at 11:51 AM, Kaya Saman <kayasaman@gmail.com> wrote:
On Tue, Jul 3, 2012 at 11:37 AM, Charles Marcus <CMarcus@media-brokers.com> wrote:
On 2012-07-03 3:12 AM, Kaya Saman <kayasaman@gmail.com> wrote:
However this is a clean server with plenty of space left on the pool allocated for mail and it's additionally using ZFS too.
What OS? ZFS implementation/version? How is mail stored (maildir? mbox?)
While I don't think this is your problem, just fyi, my understanding is that it is fairly easy to implement ZFS wrong (which would cause serious performance problems), and that the only decent ZFS implementation is Suns (ie, what ships with Nexenta), or the latest FreeBSDs...
Also, my understanding is that ZFS isn't the snappiest of filesystems even when properly configured (you trade performance for data integrity).
Personally, I'd recommend trying this on a traditional FS (XFS or Reiserfs for maildir) and see if that changes things.
FreeBSD 8.2 x64 using Maildir. ZFS is perfect no worries with that!!! Additionally the system is on a VMware cluster which is also fine - have checked all as diagnostics.
The usage here is minimal, and since I also use ZFS at home too with quite a larger file system then at work (I know I know) and really hammer the heck out of it there is no issue.
On 2012-07-03 3:12 AM, Kaya Saman <kayasaman@gmail.com> wrote:
The point is that I am monitoring using nload as well as other things and the maximum bandwidth being got with Outlook is a few Mbps burst, average 50kbps; while with T-Bird I get way over 130Mbps?
Congrats - there's your problem... now you need to find out *why* this is so slow... most likely a tcp dump analysis of a session is the only way - I think there are people here who could help you analyze one (but not me, sorry)...
Yeah, it seems to be M$ implementation of IMAP. I don't think that there's anything anyone can do.... Outlook seems to wait after each transmission (found using Wireshark).
On 2012-07-03 3:41 AM, Kaya Saman <kayasaman@gmail.com> wrote:
The PST's seem to be stored on local hard disk too.
'Seem' to be? You need to make sure, because if they aren't that could definitely cause, or at least contribute to this kind of problem.
It is definitely stored locally!
--
Best regards,
Charles
Regards,
Kaya
Ok now probably related to this is that some folders are not able to copy??
While dragging one folder from Outlook PST to the Dovecot IMAP server in Outlook 2010, the transfer keeps bombing out?
In the logs all I see are:
: Error: stat(/mail/AD_Mail//
errors.
My user was actually testing by copying the Inbox with many subdirectories into the INBOX on dovecot.
Is this another Outlook related quirk or is it something serverside which I need to change?
Regards,
Kaya
Am 03.07.2012 13:32, schrieb Kaya Saman:
On Tue, Jul 3, 2012 at 11:51 AM, Kaya Saman <kayasaman@gmail.com> wrote:
On Tue, Jul 3, 2012 at 11:37 AM, Charles Marcus <CMarcus@media-brokers.com> wrote:
On 2012-07-03 3:12 AM, Kaya Saman <kayasaman@gmail.com> wrote:
However this is a clean server with plenty of space left on the pool allocated for mail and it's additionally using ZFS too.
What OS? ZFS implementation/version? How is mail stored (maildir? mbox?)
While I don't think this is your problem, just fyi, my understanding is that it is fairly easy to implement ZFS wrong (which would cause serious performance problems), and that the only decent ZFS implementation is Suns (ie, what ships with Nexenta), or the latest FreeBSDs...
Also, my understanding is that ZFS isn't the snappiest of filesystems even when properly configured (you trade performance for data integrity).
Personally, I'd recommend trying this on a traditional FS (XFS or Reiserfs for maildir) and see if that changes things.
FreeBSD 8.2 x64 using Maildir. ZFS is perfect no worries with that!!! Additionally the system is on a VMware cluster which is also fine - have checked all as diagnostics.
The usage here is minimal, and since I also use ZFS at home too with quite a larger file system then at work (I know I know) and really hammer the heck out of it there is no issue.
On 2012-07-03 3:12 AM, Kaya Saman <kayasaman@gmail.com> wrote:
The point is that I am monitoring using nload as well as other things and the maximum bandwidth being got with Outlook is a few Mbps burst, average 50kbps; while with T-Bird I get way over 130Mbps?
Congrats - there's your problem... now you need to find out *why* this is so slow... most likely a tcp dump analysis of a session is the only way - I think there are people here who could help you analyze one (but not me, sorry)...
Yeah, it seems to be M$ implementation of IMAP. I don't think that there's anything anyone can do.... Outlook seems to wait after each transmission (found using Wireshark).
On 2012-07-03 3:41 AM, Kaya Saman <kayasaman@gmail.com> wrote:
The PST's seem to be stored on local hard disk too.
'Seem' to be? You need to make sure, because if they aren't that could definitely cause, or at least contribute to this kind of problem.
It is definitely stored locally!
--
Best regards,
Charles
Regards,
Kaya
Ok now probably related to this is that some folders are not able to copy??
While dragging one folder from Outlook PST to the Dovecot IMAP server in Outlook 2010, the transfer keeps bombing out?
In the logs all I see are:
: Error: stat(/mail/AD_Mail//
errors.
My user was actually testing by copying the Inbox with many subdirectories into the INBOX on dovecot.
check pst file is local , check if copy from local over imap with subdir in general possible with outlook check no virus scanner proxies are involved
Is this another Outlook related quirk or is it something serverside which I need to change?
Regards,
Kaya
-- Best Regards MfG Robert Schetterer
On Tue, Jul 3, 2012 at 12:36 PM, Robert Schetterer <robert@schetterer.org> wrote:
Am 03.07.2012 13:32, schrieb Kaya Saman:
On Tue, Jul 3, 2012 at 11:51 AM, Kaya Saman <kayasaman@gmail.com> wrote:
On Tue, Jul 3, 2012 at 11:37 AM, Charles Marcus <CMarcus@media-brokers.com> wrote:
On 2012-07-03 3:12 AM, Kaya Saman <kayasaman@gmail.com> wrote:
However this is a clean server with plenty of space left on the pool allocated for mail and it's additionally using ZFS too.
What OS? ZFS implementation/version? How is mail stored (maildir? mbox?)
While I don't think this is your problem, just fyi, my understanding is that it is fairly easy to implement ZFS wrong (which would cause serious performance problems), and that the only decent ZFS implementation is Suns (ie, what ships with Nexenta), or the latest FreeBSDs...
Also, my understanding is that ZFS isn't the snappiest of filesystems even when properly configured (you trade performance for data integrity).
Personally, I'd recommend trying this on a traditional FS (XFS or Reiserfs for maildir) and see if that changes things.
FreeBSD 8.2 x64 using Maildir. ZFS is perfect no worries with that!!! Additionally the system is on a VMware cluster which is also fine - have checked all as diagnostics.
The usage here is minimal, and since I also use ZFS at home too with quite a larger file system then at work (I know I know) and really hammer the heck out of it there is no issue.
On 2012-07-03 3:12 AM, Kaya Saman <kayasaman@gmail.com> wrote:
The point is that I am monitoring using nload as well as other things and the maximum bandwidth being got with Outlook is a few Mbps burst, average 50kbps; while with T-Bird I get way over 130Mbps?
Congrats - there's your problem... now you need to find out *why* this is so slow... most likely a tcp dump analysis of a session is the only way - I think there are people here who could help you analyze one (but not me, sorry)...
Yeah, it seems to be M$ implementation of IMAP. I don't think that there's anything anyone can do.... Outlook seems to wait after each transmission (found using Wireshark).
On 2012-07-03 3:41 AM, Kaya Saman <kayasaman@gmail.com> wrote:
The PST's seem to be stored on local hard disk too.
'Seem' to be? You need to make sure, because if they aren't that could definitely cause, or at least contribute to this kind of problem.
It is definitely stored locally!
--
Best regards,
Charles
Regards,
Kaya
Ok now probably related to this is that some folders are not able to copy??
While dragging one folder from Outlook PST to the Dovecot IMAP server in Outlook 2010, the transfer keeps bombing out?
In the logs all I see are:
: Error: stat(/mail/AD_Mail//
errors.
My user was actually testing by copying the Inbox with many subdirectories into the INBOX on dovecot.
check pst file is local , check if copy from local over imap with subdir in general possible with outlook check no virus scanner proxies are involved
Is this another Outlook related quirk or is it something serverside which I need to change?
Regards,
Kaya
-- Best Regards MfG Robert Schetterer
I attempted this myself as a check or test and Outlook claimed "Unable to open Deleted Items"?
PST is local, subdirs are supported, no virus scanner or proxy in the way.
Regards,
Kaya
On Tue, Jul 3, 2012 at 12:47 PM, Kaya Saman <kayasaman@gmail.com> wrote:
On Tue, Jul 3, 2012 at 12:36 PM, Robert Schetterer <robert@schetterer.org> wrote:
Am 03.07.2012 13:32, schrieb Kaya Saman:
On Tue, Jul 3, 2012 at 11:51 AM, Kaya Saman <kayasaman@gmail.com> wrote:
On Tue, Jul 3, 2012 at 11:37 AM, Charles Marcus <CMarcus@media-brokers.com> wrote:
On 2012-07-03 3:12 AM, Kaya Saman <kayasaman@gmail.com> wrote:
However this is a clean server with plenty of space left on the pool allocated for mail and it's additionally using ZFS too.
What OS? ZFS implementation/version? How is mail stored (maildir? mbox?)
While I don't think this is your problem, just fyi, my understanding is that it is fairly easy to implement ZFS wrong (which would cause serious performance problems), and that the only decent ZFS implementation is Suns (ie, what ships with Nexenta), or the latest FreeBSDs...
Also, my understanding is that ZFS isn't the snappiest of filesystems even when properly configured (you trade performance for data integrity).
Personally, I'd recommend trying this on a traditional FS (XFS or Reiserfs for maildir) and see if that changes things.
FreeBSD 8.2 x64 using Maildir. ZFS is perfect no worries with that!!! Additionally the system is on a VMware cluster which is also fine - have checked all as diagnostics.
The usage here is minimal, and since I also use ZFS at home too with quite a larger file system then at work (I know I know) and really hammer the heck out of it there is no issue.
On 2012-07-03 3:12 AM, Kaya Saman <kayasaman@gmail.com> wrote:
The point is that I am monitoring using nload as well as other things and the maximum bandwidth being got with Outlook is a few Mbps burst, average 50kbps; while with T-Bird I get way over 130Mbps?
Congrats - there's your problem... now you need to find out *why* this is so slow... most likely a tcp dump analysis of a session is the only way - I think there are people here who could help you analyze one (but not me, sorry)...
Yeah, it seems to be M$ implementation of IMAP. I don't think that there's anything anyone can do.... Outlook seems to wait after each transmission (found using Wireshark).
On 2012-07-03 3:41 AM, Kaya Saman <kayasaman@gmail.com> wrote:
The PST's seem to be stored on local hard disk too.
'Seem' to be? You need to make sure, because if they aren't that could definitely cause, or at least contribute to this kind of problem.
It is definitely stored locally!
--
Best regards,
Charles
Regards,
Kaya
Ok now probably related to this is that some folders are not able to copy??
While dragging one folder from Outlook PST to the Dovecot IMAP server in Outlook 2010, the transfer keeps bombing out?
In the logs all I see are:
: Error: stat(/mail/AD_Mail//
errors.
My user was actually testing by copying the Inbox with many subdirectories into the INBOX on dovecot.
check pst file is local , check if copy from local over imap with subdir in general possible with outlook check no virus scanner proxies are involved
Is this another Outlook related quirk or is it something serverside which I need to change?
Regards,
Kaya
-- Best Regards MfG Robert Schetterer
I attempted this myself as a check or test and Outlook claimed "Unable to open Deleted Items"?
PST is local, subdirs are supported, no virus scanner or proxy in the way.
Regards,
Kaya
Quick update:
when transfering from Dovecot to Dovecot via Outlook I got a message popping up saying:
"The move operation cannot be completed. It is possible that the destination server is unavailable or does not support subfolders"
I think this is the standard error being seen....
Regards,
Kaya
On 3 Jul 2012, at 12:32, Kaya Saman wrote:
Ok now probably related to this is that some folders are not able to copy??
While dragging one folder from Outlook PST to the Dovecot IMAP server in Outlook 2010, the transfer keeps bombing out?
In the logs all I see are:
: Error: stat(/mail/AD_Mail//
errors.
My user was actually testing by copying the Inbox with many subdirectories into the INBOX on dovecot.
Is this another Outlook related quirk or is it something serverside which I need to change?
That's not something as simple as permissions on the server end, is it? You mentioned the INBOX... If you're talking Maildir then that means .../cur/ and not the "INBOX" directory itself of course, though I suspect it needs to exist. I'm trying to remember back when I had something like that happen and found the (unused) "INBOX" does need to exist. Something like that.
J.
On Tue, Jul 3, 2012 at 1:03 PM, J E Lyon <role.Dovecot-Readers@jlassocs.com> wrote:
On 3 Jul 2012, at 12:32, Kaya Saman wrote:
Ok now probably related to this is that some folders are not able to copy??
While dragging one folder from Outlook PST to the Dovecot IMAP server in Outlook 2010, the transfer keeps bombing out?
In the logs all I see are:
: Error: stat(/mail/AD_Mail//
errors.
My user was actually testing by copying the Inbox with many subdirectories into the INBOX on dovecot.
Is this another Outlook related quirk or is it something serverside which I need to change?
That's not something as simple as permissions on the server end, is it? You mentioned the INBOX... If you're talking Maildir then that means .../cur/ and not the "INBOX" directory itself of course, though I suspect it needs to exist. I'm trying to remember back when I had something like that happen and found the (unused) "INBOX" does need to exist. Something like that.
J.
It is Maildir I am using, checked permissions - they're all ok. Yeah would be cur.... When connecting to this, do I need to put something like Inbox or INBOX as the mail root folder?
I remember historically one needed to do that, however, with TBird one doens't need to any more though you still can.....
Now to just get the Deleted Items working!
Regards,
Kaya
On 3 Jul 2012, at 13:11, Kaya Saman wrote:
It is Maildir I am using, checked permissions - they're all ok. Yeah would be cur.... When connecting to this, do I need to put something like Inbox or INBOX as the mail root folder?
I remember historically one needed to do that, however, with TBird one doens't need to any more though you still can.....
I'm sure the INBOX directory is created automatically for me, but I do have a script that sets up directories, permissions and I've taken care of SELinux issues in the past . . might be a red herring, was just mindful of the mention of INBOX -- does it work if you copy to another folder, or try to create a folder?
Now to just get the Deleted Items working!
Ah well, I joined the list originally because of a query about the Deleted Items . . On Outlook pre-2010, that was a major headache, there's a plugin but it's one of only ?two not bundled by default with Dovecot (CentOS servers here, so using the default RPMs from there) . .
I thought it was supposed to be better-behaved in 2010 thought . . . .
J.
On Tue, Jul 3, 2012 at 1:21 PM, J E Lyon <role.Dovecot-Readers@jlassocs.com> wrote:
On 3 Jul 2012, at 13:11, Kaya Saman wrote:
It is Maildir I am using, checked permissions - they're all ok. Yeah would be cur.... When connecting to this, do I need to put something like Inbox or INBOX as the mail root folder?
I remember historically one needed to do that, however, with TBird one doens't need to any more though you still can.....
I'm sure the INBOX directory is created automatically for me, but I do have a script that sets up directories, permissions and I've taken care of SELinux issues in the past . . might be a red herring, was just mindful of the mention of INBOX -- does it work if you copy to another folder, or try to create a folder?
Creating folders is fine and copying seems fine however, with quirks.
Now to just get the Deleted Items working!
Ah well, I joined the list originally because of a query about the Deleted Items . . On Outlook pre-2010, that was a major headache, there's a plugin but it's one of only ?two not bundled by default with Dovecot (CentOS servers here, so using the default RPMs from there) . .
It's strange I just deleted some stuff in the "Deleted Items' folder through TBird which worked fine. However, previously nothing worked so I had to clear the whole dir out by diving into the server's file system and using rm -rf *
I thought it was supposed to be better-behaved in 2010 thought . . . .
J.
Regards,
Kaya
[...]
That's not something as simple as permissions on the server end, is it?
I have my Maildir and parent folder permissions setup as:
rwx-- mail_user:mail_user
This should be ok shouldn't it or would I need to use rwxrwx- ??
By default it is created as stated at top of posting.....
What confused me is that I was browsing around and people had different permissions settings on their Maildirs.
Regards,
Kaya
On 3 Jul 2012, at 13:20, Kaya Saman wrote:
[...]
That's not something as simple as permissions on the server end, is it?
I have my Maildir and parent folder permissions setup as:
rwx-- mail_user:mail_user
I don't know what is strictly necessary, but I actually use rwxrws--- for my Maildir hierarchy, note the "s", don't think it's so important in more recent Dovecots but I set up my design originally on a Dovecot 0.99 and tweaked only slightly when moving to 1.x
J.
Am 02.07.2012 16:34, schrieb Kaya Saman:
Hi,
though this is a bit of a side question, has anybody had an issue while running Outlook 2010 with Dovecot?
The reason why I am asking is that I have setup a Dovecot 2.1.7 server on FreeBSD which works fantastically with Thunderbird but Outlook seems to be twice as slow in transferring information across??
Hi, must be your setup no Problems here with Outlook 2010, sorry no time recent for analyse your posted config
Best Regards MfG Robert Schetterer
On Mon, 02 Jul 2012 17:00:07 +0200 Robert Schetterer articulated:
Am 02.07.2012 16:34, schrieb Kaya Saman:
Hi,
though this is a bit of a side question, has anybody had an issue while running Outlook 2010 with Dovecot?
The reason why I am asking is that I have setup a Dovecot 2.1.7 server on FreeBSD which works fantastically with Thunderbird but Outlook seems to be twice as slow in transferring information across??
Hi, must be your setup no Problems here with Outlook 2010, sorry no time recent for analyse your posted config
I don't have any problems with it either. sounds like it could be a networking problem. I have also heard on the Postfix list about some AV programs causing problems.
-- Jerry ♔
Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header.
Hi, must be your setup no Problems here with Outlook 2010, sorry no time recent for analyse your posted config
I don't have any problems with it either. sounds like it could be a networking problem. I have also heard on the Postfix list about some AV programs causing problems. If you don't have problems with outlook then you have very little mail per user.
Try this shit with 20GB mailbox. It is really funny i promise :)
On Mon, Jul 2, 2012 at 6:55 PM, Wojciech Puchar < wojtek@wojtek.tensor.gdynia.pl> wrote:
Hi, must be your setup no Problems here with
Outlook 2010, sorry no time recent for analyse your posted config
I don't have any problems with it either. sounds like it could be a networking problem. I have also heard on the Postfix list about some AV programs causing problems.
If you don't have problems with outlook then you have very little mail per user.
Try this shit with 20GB mailbox. It is really funny i promise :)
It's not funny at all, using certain references as you like doing. I don't remember when I last heard such words on this list. Please, if you cannot resist the temptation, s#s.*#crap#g. It keeps this list cleaner.
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223
I can't hear you -- I'm using the scrambler.
though this is a bit of a side question, has anybody had an issue while running Outlook 2010 with Dovecot? No because i don't use that shit and enforce anyone not to do this.
Outlook is terrible and even worse with imap. It is not Dovecot fault and have nothing to Dovecot.
Just replace Outlook with real MUA that actually works.
If someone wants to continue using that shit then it is not your problem but his/her problem, and all responsibility of doing this should go to the user.
The only tweak is to install real mail client. period.
On Mon, Jul 2, 2012 at 6:39 PM, Wojciech Puchar < wojtek@wojtek.tensor.gdynia.pl> wrote:
though this is a bit of a side question, has anybody had an issue while
running Outlook 2010 with Dovecot?
No because i don't use that shit and enforce anyone not to do this.
Outlook is terrible and even worse with imap. It is not Dovecot fault and have nothing to Dovecot.
Just replace Outlook with real MUA that actually works.
If someone wants to continue using that shit then it is not your problem but his/her problem, and all responsibility of doing this should go to the user.
The only tweak is to install real mail client. period.
Wojciech,
I believe you do recognize that this may be something that requires policy changes to take effect.
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223
I can't hear you -- I'm using the scrambler.
Wojciech,
I believe you do recognize that this may be something that requires policy changes to take effect. Of course i do!
If you are not the one deciding with policy then state clearly that this shit simply doesn't work, so if the policy is to use it, then the same policy should state "don't expect e-mail to work".
No policy can override truth and facts.
On 02/07/2012 16:54, Wojciech Puchar wrote:
Wojciech,
I believe you do recognize that this may be something that requires policy changes to take effect. Of course i do!
If you are not the one deciding with policy then state clearly that this shit simply doesn't work, so if the policy is to use it, then the same policy should state "don't expect e-mail to work".
No policy can override truth and facts.
I'm not going to comment other than say that this sub-thread probably needs to continue on:
alt.flames.anti-microsoft.linux.jihad
They love these types of thread there :-D
-- Regards,
Giles Coochey, CCNA, CCNAS NetSecSpec Ltd +44 (0) 7983 877438 http://www.coochey.net http://www.netsecspec.co.uk giles@coochey.net
No policy can override truth and facts.
I'm not going to comment other than say that this sub-thread probably needs to continue on:
alt.flames.anti-microsoft.linux.jihad
no. no jihad. No linux actually (i don't use linux).
That's fact. If someone want to use outlook then fine, but should not expect anyone else than microsoft to fix it's problems and speed.
It is nothing to do with dovecot.
All my experience with that shit now is remote.
I quite often handle complaints from users that
a) "my mail wasn't delivered to somebody."
After checking logs i found that recipent's server received mail with success. But mail disappeared then.
Sometimes reappeared after a week, sometimes many times, or never ;)
The reason was microsoft exchange on recipient side. Sometimes - badly configured antispam.
b) reverse - "i don't receive mail from someone".
Because someone's MS exchange server didn't even try to send it.
c) i'm getting some strange attachment that i cannot open. (winmail.dat)
my answer: Ask sender to send attachments according to standards
On 07/02/2012 12:06 PM, Wojciech Puchar wrote:
No policy can override truth and facts.
I'm not going to comment other than say that this sub-thread probably needs to continue on:
alt.flames.anti-microsoft.linux.jihad
no. no jihad. No linux actually (i don't use linux).
That's fact. If someone want to use outlook then fine, but should not expect anyone else than microsoft to fix it's problems and speed.
It is nothing to do with dovecot.
All my experience with that shit now is remote.
I quite often handle complaints from users that
a) "my mail wasn't delivered to somebody."
After checking logs i found that recipent's server received mail with success. But mail disappeared then.
Sometimes reappeared after a week, sometimes many times, or never ;)
The reason was microsoft exchange on recipient side. Sometimes - badly configured antispam.
b) reverse - "i don't receive mail from someone".
Because someone's MS exchange server didn't even try to send it.
c) i'm getting some strange attachment that i cannot open. (winmail.dat)
my answer: Ask sender to send attachments according to standards
Equivalents of all these can be presented the other way around against badly configured free software solutions. I'd rather say that the real problem is that Microsoft programs require the same level of knowledge and expertise that, ehhhm, computer systems require. They are just not presented that way, and create a culture of "oh sure I can do this, so easy". Exchange *can* be configured to actually deliver mail, it just attracts all the wrong admins. And capable admins will just naturally opt for other solutions.
Equivalents of all these can be presented the other way around against badly configured free software solutions.
Fortunately not microsoft sets open standard and have to conform to them or there will be microsoft only mail. And more fortunately not these admins.
OK response from exchange server getting properly my e-mail is enough proof that email was delivered to it. No attempts (including tcpdump trace) of sending e-mail from exchange serverr to me is too a proof of email not being delivered by it.
Yet fortunately it is really easy to fight it - EXPLAIN people.
Most people just don't know what they are doing wrong and not willingly want to make things more complicated. Simply explaining them is from my experience enough in 99% of cases. YES really it works but most people here never tried it!
As for latter - maybe it is possible to make exchange actually work, but statistics shows that it is not possible, or incredibly hard or people that are exchange administrators have no knowledge.
For any of my clients asking if exchange or outlook would be good solution i just recommend visiting any company that actually use it and ask average employee (not boss). This always work.
The other false statement is that such solution are designed for large scale businesses. The larger case the less chance it may work at all.
Seems i am the only one here that do not fear the truth. I don't risk being fired :) as i work for those that (most often) already got at least one of that "enterprise" solutions and wanted something that actually work.
And this is what i recommend to all of you.
I recommend ending this topic altogether, as it is not dovecot related at all - unless anyone will find a problem with Dovecot implementation of IMAP that is clearly not confirming to standards, and (possibly) affect microsoft outlook.
Highly unlikely but possible.
Dovecot is high performance IMAP server, but will not fix bad client software.
Am 02.07.2012 19:10, schrieb Wojciech Puchar:
Equivalents of all these can be presented the other way around against badly configured free software solutions.
Fortunately not microsoft sets open standard and have to conform to them or there will be microsoft only mail. And more fortunately not these admins.
OK response from exchange server getting properly my e-mail is enough proof that email was delivered to it. No attempts (including tcpdump trace) of sending e-mail from exchange serverr to me is too a proof of email not being delivered by it.
Yet fortunately it is really easy to fight it - EXPLAIN people.
Most people just don't know what they are doing wrong and not willingly want to make things more complicated. Simply explaining them is from my experience enough in 99% of cases. YES really it works but most people here never tried it!
As for latter - maybe it is possible to make exchange actually work, but statistics shows that it is not possible, or incredibly hard or people that are exchange administrators have no knowledge.
For any of my clients asking if exchange or outlook would be good solution i just recommend visiting any company that actually use it and ask average employee (not boss). This always work.
The other false statement is that such solution are designed for large scale businesses. The larger case the less chance it may work at all.
Seems i am the only one here that do not fear the truth. I don't risk being fired :) as i work for those that (most often) already got at least one of that "enterprise" solutions and wanted something that actually work.
And this is what i recommend to all of you.
I recommend ending this topic altogether, as it is not dovecot related at all - unless anyone will find a problem with Dovecot implementation of IMAP that is clearly not confirming to standards, and (possibly) affect microsoft outlook.
Highly unlikely but possible.
Dovecot is high performance IMAP server, but will not fix bad client software.
Hi , as i said million times before dont compare the incomparable
Outlook is the client of Exchange , it can do smtp,imap,pop3 too
its sold as a solution, with os , server, auth system ,client , support people etc
There is no reason for M$ to make Qutlook fit in a perfect imap client cause this would goal in less reason for exchange
Nevertheless if you have good admins and money to buy licences and good support, outlook and exchange are good company solutions for intranet mail and groupware ( like calendering etc )
dont flame by m$ is earning money, help making free solutions to get better specially in groupware functions with cross os clients like thunderbird etc
dovecot is an imap server it has allready nearly all features comparable to the "exchange imap part", like folder acl etc nothing more is the job of dovecot
customers want to do calendering with sharing ,adressbooks with sharings etc all with one client ( for sure mostly they are Outlook junkies ) but this isnt the real problem
The real problem is that there arent full working and comparable groupware funktions in one client yet, also on the server side there arent complete free solutions cal/carddav is on the way, as well as syncml and other stuff so the goal is near to have all stuff needed to get comparable and much better
meanwhile help dovecot users in fix their tec problems not in flame the shouldnt use a client whatever , most of the times this isnt what server admin can press sombody too
Outlook works fine with dovecot if your setup is right dont think thunderbird is a bugless imap client
At the end know your enemy, dont talk about outlook if you never worked around it, dont expect things from stuff which it was never made for solve
Best Regards MfG Robert Schetterer
Outlook is the client of Exchange , it can do smtp,imap,pop3 too
its sold as a solution, with os , server, auth system ,client , support people etc
and that solution - as a common example - doesn't work.
There is no reason for M$ to make Qutlook fit in a perfect imap client cause this would goal in less reason for exchange
as well as it's own product.
But it is by design, as more money can ge acquired by constantly servicing non working product.
Nevertheless if you have good admins and money to buy licences and good support, outlook and exchange are good company solutions for intranet mail and groupware ( like calendering etc )
Show me working case. i would like to see it :)
Still - it have nothing to Dovecot and Dovecot, no matter how great would be, will not improve it.
"Tweaks" can overcome some bugs or deficiences but not whole product.
On Jul 2, 2012, at 10:54 AM, Wojciech Puchar wrote:
Wojciech, I believe you do recognize that this may be something that requires policy changes to take effect. Of course i do!
If you are not the one deciding with policy then state clearly that this shit simply doesn't work, so if the policy is to use it, then the same policy should state "don't expect e-mail to work".
Speaking of truth and facts, you've had a lot of advice here lately for someone who clearly has never worked on anything but toy projects with users that you're free to bully into submission. If you don't have something useful to contribute, why not just keep it to yourself?
-Brian
Speaking of truth and facts, you've had a lot of advice here lately for someone who clearly has never worked on anything but toy projects with users that you're free to bully into submission. If you don't have something useful to contribute, why not just keep it to yourself?
If you show me outlook actually working on large projects then i will stop.
On Jul 2, 2012, at 11:06 AM, Wojciech Puchar wrote:
Speaking of truth and facts, you've had a lot of advice here lately for someone who clearly has never worked on anything but toy projects with users that you're free to bully into submission. If you don't have something useful to contribute, why not just keep it to yourself?
If you show me outlook actually working on large projects then i will stop.
You're not necessarily wrong about Outlook vis-a-vis IMAP. You're very wrong about how much power an email admin has in a real organization. Please take the non-constructive flaming and cursing somewhere else, as others have suggested.
-Brian
You're not necessarily wrong about Outlook vis-a-vis IMAP. You're very wrong about how much power an email admin has in a real organization. Please take the non-constructive flaming and cursing somewhere else, as others have suggested. Still you can't improve trash program by better IMAP server.
On 2012-07-02 11:39 AM, Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> wrote:
though this is a bit of a side question, has anybody had an issue while running Outlook 2010 with Dovecot?
No because i don't use that shit and enforce anyone not to do this.
Outlook is terrible and even worse with imap. It is not Dovecot fault and have nothing to Dovecot.
Just replace Outlook with real MUA that actually works.
Please don't be an ass - if you can't help with the actual problem, just keep comments like this to yourself.
Many companies require Outlook, and the fact is, as an EXCHANGE client, Outlook works extremely well. I agree that as a standalone IMAP client it isn't the best, but 2010 is much better than 2003 and earlier versions...
--
Best regards,
Charles
On Mon, 02 Jul 2012 11:54:07 -0400 Charles Marcus articulated:
On 2012-07-02 11:39 AM, Wojciech Puchar <wojtek@wojtek.tensor.gdynia.pl> wrote:
though this is a bit of a side question, has anybody had an issue while running Outlook 2010 with Dovecot?
No because i don't use that shit and enforce anyone not to do this.
Outlook is terrible and even worse with imap. It is not Dovecot fault and have nothing to Dovecot.
Just replace Outlook with real MUA that actually works.
Please don't be an ass - if you can't help with the actual problem, just keep comments like this to yourself.
Many companies require Outlook, and the fact is, as an EXCHANGE client, Outlook works extremely well. I agree that as a standalone IMAP client it isn't the best, but 2010 is much better than 2003 and earlier versions...
Wojciech has been Spamming up several forums lately. I finally set up a kill filter to eliminate him on those forums. I see that I am going to have to make one for the Dovecot mailing list also. Perhaps I should simple write a rule to have Postfix reject his mail. He NEVER has anything constructive to say and has been labeled a TROLL numerous times. His language is extremely vulgar and hateful. He likes to imply that he is knowledgeable yet fails to display any of that alleged knowledge. His abilities do not seem to fit within the pandect of modern system administration. Following his postings on other forums has led me to discover that he is simply a Microsoft antagonist with none of the required prerequisites to be one. I am sure his unnamed (mythical) company is proud of him.
-- Jerry ♔
Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header.
Many companies require Outlook, and the fact is, as an EXCHANGE client, Outlook works extremely well. I agree that as a standalone
Show me this.
I actually migrated many places OUT of this crap because it doesn't work, with great success.
participants (16)
-
Arne K. Haaje
-
Brian Hayden
-
Charles Marcus
-
Gedalya
-
Giles Coochey
-
J E Lyon
-
J E Lyon
-
Jahnke-Zumbusch, Dirk
-
Jerry
-
Kaya Saman
-
Mailing List SVR
-
Odhiambo Washington
-
Robert Schetterer
-
Simon Brereton
-
Timo Sirainen
-
Wojciech Puchar