Can any KMail IMAP users confirm the problem in bug report 467?
http://bugs.pearsoncomputing.net/show_bug.cgi?id=467
Thanks.
Darrell
On 06/29/2012 10:18 PM, Darrell Anderson wrote:
Can any KMail IMAP users confirm the problem in bug report 467?
http://bugs.pearsoncomputing.net/show_bug.cgi?id=467
Thanks.
Darrell
checking...
On 06/29/2012 11:15 PM, David C. Rankin wrote:
On 06/29/2012 10:18 PM, Darrell Anderson wrote:
Can any KMail IMAP users confirm the problem in bug report 467?
http://bugs.pearsoncomputing.net/show_bug.cgi?id=467
Thanks.
Darrell
checking...
Darrell,
I'm not sure there was much of a problem here to begin with. I have the build from a few days ago, well before Tim's patch and I didn't get much delay or increase in system load when I configured kmail (I have ~70 folders and lots of mail)
Now the folders did not automatically refresh, but clicking on one with ~300 messages for the first time took very little time.
However, there is something funky in kmail TLS recognition that causes it to falsely report TLS not supported, but then choose it anyway when clicking on "Check what the server supports" in the server settings dialog.
This was the first time I had configured any mail in this install. When prompted by the initial account setup dialog, I chose IMAP and SSL on incoming, nothing for outgoing. After starting kmail and attempting to access the account, I kept getting messages saying TLS was not supported and prompting me to check settings. When I went to the settings SSL was selected. I chose "Check what the server supports" and kmail chose TLS correctly. (I have it running on my mail server)
I don't know what kmail is initially checking to say TLS isn't supported, but there is a bug in the code there. I must have received 10 dialogs telling me no TLS before "Check what the server supports" selected it.
The relevant server settings (postfix/dovecot) are:
main.cf:
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, check_client_access hash:/etc/postfix/client_access, reject_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = $mydomain smtpd_sasl_path = private/auth smtpd_sasl_security_options = noanonymous smtpd_sasl_tls_security_options = noanonymous smtpd_sasl_type = dovecot smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/ssl/certs/dovecot.pem smtpd_tls_key_file = /etc/ssl/private/dovecot.pem unknown_local_recipient_reject_code = 550
master.cf:
smtp inet n - n - - smtpd submission inet n - n - - smtpd -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING
dovecot.conf:
auth_mechanisms = plain login passdb { driver = pam } passdb { driver = pam } service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } } ssl_cert = </etc/ssl/certs/dovecot.pem ssl_key = </etc/ssl/private/dovecot.pem userdb { driver = passwd } userdb { driver = passwd }
I don't know what if any relevant TDE logs or logs from the install may be relevant, but let me know if you want to see any of them.
I'm not sure there was much of a problem here to begin with. I have the build from a few days ago, well before Tim's patch and I didn't get much delay or increase in system load when I configured kmail (I have ~70 folders and lots of mail)
Now the folders did not automatically refresh, but clicking on one with ~300 messages for the first time took very little time.
However, there is something funky in kmail TLS recognition that causes it to falsely report TLS not supported, but then choose it anyway when clicking on "Check what the server supports" in the server settings dialog.
This was the first time I had configured any mail in this install. When prompted by the initial account setup dialog, I chose IMAP and SSL on incoming, nothing for outgoing. After starting kmail and attempting to access the account, I kept getting messages saying TLS was not supported and prompting me to check settings. When I went to the settings SSL was selected. I chose "Check what the server supports" and kmail chose TLS correctly. (I have it running on my mail server)
I don't know what kmail is initially checking to say TLS isn't supported, but there is a bug in the code there. I must have received 10 dialogs telling me no TLS before "Check what the server supports" selected it.
The relevant server settings (postfix/dovecot) are:
main.cf:
smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, check_client_access hash:/etc/postfix/client_access, reject_unauth_destination smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = $mydomain smtpd_sasl_path = private/auth smtpd_sasl_security_options = noanonymous smtpd_sasl_tls_security_options = noanonymous smtpd_sasl_type = dovecot smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/ssl/certs/dovecot.pem smtpd_tls_key_file = /etc/ssl/private/dovecot.pem unknown_local_recipient_reject_code = 550
master.cf:
smtp inet n
n
smtpd
submission inet n - n
smtpd-
-o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING
dovecot.conf:
auth_mechanisms = plain login passdb { driver = pam } passdb { driver = pam } service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } } ssl_cert = </etc/ssl/certs/dovecot.pem ssl_key = </etc/ssl/private/dovecot.pem userdb { driver = passwd } userdb { driver = passwd }
I don't know what if any relevant TDE logs or logs from the install may be relevant, but let me know if you want to see any of them.
300 messages? Wow, no wonder you struggle to keep pace. :-)
My original interest was to resolve the bug report.
I use POP3/SMTP. I can't confirm what you describe and all/most of my email accounts use TLS.
Maybe place this behavior on your "watch" list. I have items like that here --- observations that I am unsure about. :-)
Darrell
On 06/29/2012 10:18 PM, Darrell Anderson wrote:
Can any KMail IMAP users confirm the problem in bug report 467?
http://bugs.pearsoncomputing.net/show_bug.cgi?id=467
Thanks.
Darrell
Darrell,
Did I miss something -- or did Tim already fix this today??
Can any KMail IMAP users confirm the problem in bug report 467?
http://bugs.pearsoncomputing.net/show_bug.cgi?id=467
Thanks.
Did I miss something -- or did Tim already fix this today??
I don't know whether this was something from a Twilight Zone episode or whether Tim saw my question in the mail list and responded immediately thereafter. Looking at the time of the commit and the time of my post, I don't. Would be freaky if Tim decided to resolve the report the same time I was browsing the bug tracker.
I don't use IMAP. I was browsing the bug tracker to help prune items. I recall recently we reversed an IMAP related patch. I was curious whether the two reports were related. If current users could not confirm then I would have recommended closing the report.
Looks like water under the bridge at this point. :-)
Darrell
On 06/30/2012 11:36 AM, Darrell Anderson wrote:
I don't know whether this was something from a Twilight Zone episode or whether Tim saw my question in the mail list and responded immediately thereafter. Looking at the time of the commit and the time of my post, I don't. Would be freaky if Tim decided to resolve the report the same time I was browsing the bug tracker.
I don't use IMAP. I was browsing the bug tracker to help prune items. I recall recently we reversed an IMAP related patch. I was curious whether the two reports were related. If current users could not confirm then I would have recommended closing the report.
Looks like water under the bridge at this point. :-)
Darrell
The "twilight zone" was the nice gratuity Tim added when closing the bug. Got to keep the tracker looking nice :) (it was the dates that caught my eye)