Re: Odd problem: IMAP/S suddenly not working, but no errors, and IMAP still works

2010-11-01 Thread Chris Pepper 
On 11/1/10 7:26 PM, Bron Gondwana wrote:
> On Sun, Oct 31, 2010 at 10:40:13PM -0400, Chris Pepper wrote:
>> Bron,
>>
>>  My Cyrus is from RPM, and I am just nursing it along until my users
>> finish migrating off and FastMail manages to complete my own
>> migration, so I don't want to build from source. Why would IMAP/S
>> block on empty /dev/random, while IMAP+STARTTLS works? FWIW, SASL2
>> seems to use urandom.
>
> I really don't know to be honest - we don't run any ssl enabled imapds,
> we do all the ssl in nginx on the frontend.  It sounds like Rob's
> workaround might be all you need though :)

Neither do I. I decided to re-enable pop3 (which I don't use or allow, 
and had recently commented out) in cyrus.conf and restarted cyrus-imapd, 
and IMAP/SSL is working again! I commented it out and restarted Cyrus, 
and port 993 is still working.

I'd say I just needed to restart the daemon, except I rebooted Saturday 
night after port 993 stopped working, so I don't know what's up.

One interesting & odd data point: after "service cyrus-imapd stop", I 
still had a couple active connections to an imap daemon which was 
listening on port 993. I killed the process, but again that couldn't 
have persisted across the reboot I performed 1d19h ago.

Bizarre! Thanks for everyone's suggestions.

Chris


Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/

Re: Odd problem: IMAP/S suddenly not working, but no errors, and IMAP still works

2010-11-01 Thread Bron Gondwana 
On Sun, Oct 31, 2010 at 10:40:13PM -0400, Chris Pepper wrote:
> Bron,
> 
>   My Cyrus is from RPM, and I am just nursing it along until my users
> finish migrating off and FastMail manages to complete my own
> migration, so I don't want to build from source. Why would IMAP/S
> block on empty /dev/random, while IMAP+STARTTLS works? FWIW, SASL2
> seems to use urandom.

I really don't know to be honest - we don't run any ssl enabled imapds,
we do all the ssl in nginx on the frontend.  It sounds like Rob's
workaround might be all you need though :)

Bron.

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/

Re: Odd problem: IMAP/S suddenly not working, but no errors, and IMAP still works

2010-11-01 Thread Dan White 
On 01/11/10 11:27 -0400, Chris Pepper wrote:
>On 11/1/10 10:41 AM, Dan White wrote:
>>On 31/10/10 20:51 -0400, Chris Pepper wrote:
>>>Alternatively, is there a way to make sure Cyrus requires STARTTLS on
>>>143? I was blocking external access to it to make sure users always use
>>>encryption to connect, but port 143 with STARTTLS required would be an
>>>acceptable alternative.
>>
>>You can set 'allowplaintext: 0' to disallow plaintext logins over port 143.
>>That would require clients to perform a STARTTLS, or negotiate a SASL
>>security layer which meets your 'sasl_minimum_layer:' setting.
>
>   Excellent, thanks!
>
>>allowplaintext: 0
>
>I am leaving sasl_minimum_layer at default for now. LOGINDISABLED before
>STARTTLS is encouraging, but I don't know why "Authentication failed.
>generic failure" *after* STARTTLS. On the other hand, with
>"allowplaintext: 0" and after restarting cyrus-imapd, I can still get
>mail, so I suspect this is exactly what I wanted.

After sending the first email, I noticed that you have a
sasl_pwcheck_method of saslauthd in your config. You probably also want a
'sasl_mech_list: plain login'. If you're depending on saslauthd to perform
your authentication, digest-md5 and cram-md5 should always fail.

-- 
Dan White

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/

Re: Odd problem: IMAP/S suddenly not working, but no errors, and IMAP still works

2010-11-01 Thread Chris Pepper 
On 11/1/10 11:21 AM, Simon Matter wrote:
>> On 11/1/10 10:46 AM, Simon Matter wrote:
 Bron,

My Cyrus is from RPM, and I am just nursing it along until my users
 finish migrating off and FastMail manages to complete my own migration,
 so I don't want to build from source. Why would IMAP/S block on empty
 /dev/random, while IMAP+STARTTLS works? FWIW, SASL2 seems to use
 urandom.
>>>
>>> If this is really stock CentOS 5 then I think everything Cyrus related
>>> should use /dev/urandom and not /dev/random. But, could it be that other
>>> software you installed uses /dev/random and makes it "empty"?
>>
>>  Most things are CentOS RPMs (thanks for those! ;), with a few from
>> RPMforge.
>>
>>> [r...@inspector ~]# rpm -q cyrus-imapd amavisd-new clamav spamassassin
>>> postfix httpd mod_ssl
>>> cyrus-imapd-2.3.7-7.el5_4.3
>>> amavisd-new-2.6.4-3.el5.rf
>>> clamav-0.96.4-1.el5.rf
>>> spamassassin-3.3.1-3.el5.rf
>>> postfix-2.3.3-2.1.el5_2
>>> httpd-2.2.3-43.el5.centos.3
>>> mod_ssl-2.2.3-43.el5.centos.3
>>
>>  Which still leaves me thinking my port 993 problem isn't entropy, 
>> because
>> STARTTLS works fine.
>
> That's my impression from the beginning, because lack of entropy has not
> been a known problem on the RHEL/CentOS configs. That's not much help of
> course.
>
> If you already restarted master and you know it's not stuck somehow, then
> the only thing I could think to check is your
> /var/lib/imap/tls_sessions.db database. I don't know if a broken TLS db
> could result in what you see but better check it out.

Interesting. I moved tls_sessions.db aside & restarted IMAPd, and it's 
apparently in a new format -- perhaps the default format has changed since it 
was first created. But 993 is still open but not responsive. I am going to try 
disabling Cyrus' IMAP/SSL and swapping in stunnel, as Rob @ FastMail has 
suggested as a workaround.

Thanks,

Chris

> [r...@inspector imap]# ls -l tls*
> -rw--- 1 cyrus mail 8192 Nov  1 11:27 tls_sessions.db
> -rw--- 1 cyrus mail 1976 Nov  1 11:27 tls_sessions.db.BAD
> [r...@inspector imap]# file tls*
> tls_sessions.db: Berkeley DB (Btree, version 9, native byte-order)
> tls_sessions.db.BAD: Cyrus skiplist DB


-- 
Chris Pepper:
  


Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/

Re: Odd problem: IMAP/S suddenly not working, but no errors, and IMAP still works

2010-11-01 Thread Chris Pepper 
On 11/1/10 10:41 AM, Dan White wrote:
> On 31/10/10 20:51 -0400, Chris Pepper wrote:
>> Alternatively, is there a way to make sure Cyrus requires STARTTLS on
>> 143? I was blocking external access to it to make sure users always use
>> encryption to connect, but port 143 with STARTTLS required would be an
>> acceptable alternative.
>
> You can set 'allowplaintext: 0' to disallow plaintext logins over port 143.
> That would require clients to perform a STARTTLS, or negotiate a SASL
> security layer which meets your 'sasl_minimum_layer:' setting.

Excellent, thanks!

> allowplaintext: 0

I am leaving sasl_minimum_layer at default for now. LOGINDISABLED 
before STARTTLS is encouraging, but I don't know why "Authentication failed. 
generic failure" *after* STARTTLS. On the other hand, with "allowplaintext: 0" 
and after restarting cyrus-imapd, I can still get mail, so I suspect this is 
exactly what I wanted.

Thanks,

Chris

> [r...@inspector ~]# imtest -u pepper -t "" localhost
> S: * OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS LOGINDISABLED 
> AUTH=DIGEST-MD5 AUTH=CRAM-MD5 SASL-IR] mail.reppep.com Cyrus IMAP4 
> v2.3.7-Invoca-RPM-2.3.7-7.el5_4.3 server ready
> C: C01 CAPABILITY
> S: * CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS LOGINDISABLED 
> AUTH=DIGEST-MD5 AUTH=CRAM-MD5 SASL-IR ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS 
> NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT 
> SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE 
> CONDSTORE IDLE LISTEXT LIST-SUBSCRIBED X-NETSCAPE URLAUTH
> S: C01 OK Completed
> C: S01 STARTTLS
> S: S01 OK Begin TLS negotiation now
> verify error:num=19:self signed certificate in certificate chain
> TLS connection established: TLSv1 with cipher AES256-SHA (256/256 bits)
> C: C01 CAPABILITY
> S: * CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID AUTH=PLAIN AUTH=DIGEST-MD5 
> AUTH=CRAM-MD5 AUTH=LOGIN SASL-IR ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS 
> NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT 
> SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE 
> CONDSTORE IDLE LISTEXT LIST-SUBSCRIBED X-NETSCAPE URLAUTH
> S: C01 OK Completed
> Please enter your password:
> C: A01 AUTHENTICATE PLAIN 
> S: A01 NO authentication failure
> Authentication failed. generic failure
> Security strength factor: 256

-- 
Chris Pepper:
  


Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/

Re: Odd problem: IMAP/S suddenly not working, but no errors, and IMAP still works

2010-11-01 Thread Simon Matter 
> On 11/1/10 10:46 AM, Simon Matter wrote:
>>> Bron,
>>>
>>> My Cyrus is from RPM, and I am just nursing it along until my users
>>> finish migrating off and FastMail manages to complete my own migration,
>>> so I don't want to build from source. Why would IMAP/S block on empty
>>> /dev/random, while IMAP+STARTTLS works? FWIW, SASL2 seems to use
>>> urandom.
>>
>> If this is really stock CentOS 5 then I think everything Cyrus related
>> should use /dev/urandom and not /dev/random. But, could it be that other
>> software you installed uses /dev/random and makes it "empty"?
>
>   Most things are CentOS RPMs (thanks for those! ;), with a few from
> RPMforge.
>
>> [r...@inspector ~]# rpm -q cyrus-imapd amavisd-new clamav spamassassin
>> postfix httpd mod_ssl
>> cyrus-imapd-2.3.7-7.el5_4.3
>> amavisd-new-2.6.4-3.el5.rf
>> clamav-0.96.4-1.el5.rf
>> spamassassin-3.3.1-3.el5.rf
>> postfix-2.3.3-2.1.el5_2
>> httpd-2.2.3-43.el5.centos.3
>> mod_ssl-2.2.3-43.el5.centos.3
>
>   Which still leaves me thinking my port 993 problem isn't entropy, 
> because
> STARTTLS works fine.

That's my impression from the beginning, because lack of entropy has not
been a known problem on the RHEL/CentOS configs. That's not much help of
course.

If you already restarted master and you know it's not stuck somehow, then
the only thing I could think to check is your
/var/lib/imap/tls_sessions.db database. I don't know if a broken TLS db
could result in what you see but better check it out.

Simon


Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/

Re: Odd problem: IMAP/S suddenly not working, but no errors, and IMAP still works

2010-11-01 Thread Jeroen van Meeuwen (Kolab Systems) 
On Monday, November 01, 2010 03:46:38 pm Simon Matter wrote:
> > Bron,
> > 
> > My Cyrus is from RPM, and I am just nursing it along until my users
> > 
> > finish migrating off and FastMail manages to complete my own migration,
> > so I don't want to build from source. Why would IMAP/S block on empty
> > /dev/random, while IMAP+STARTTLS works? FWIW, SASL2 seems to use urandom.
> 
> If this is really stock CentOS 5 then I think everything Cyrus related
> should use /dev/urandom and not /dev/random. But, could it be that other
> software you installed uses /dev/random and makes it "empty"?
> 

I think the stock CentOS packages do in fact use /dev/urandom.

Kind regards,

Jeroen van Meeuwen

-- 
Senior Engineer, Kolab Systems AG

e: vanmeeu...@kolabsys.com
t: +316 42 801 403
w: http://www.kolabsys.com

pgp: 9342 BF08

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/

Re: Odd problem: IMAP/S suddenly not working, but no errors, and IMAP still works

2010-11-01 Thread Chris Pepper 
On 11/1/10 10:46 AM, Simon Matter wrote:
>> Bron,
>>
>>  My Cyrus is from RPM, and I am just nursing it along until my users
>> finish migrating off and FastMail manages to complete my own migration,
>> so I don't want to build from source. Why would IMAP/S block on empty
>> /dev/random, while IMAP+STARTTLS works? FWIW, SASL2 seems to use urandom.
>
> If this is really stock CentOS 5 then I think everything Cyrus related
> should use /dev/urandom and not /dev/random. But, could it be that other
> software you installed uses /dev/random and makes it "empty"?

Most things are CentOS RPMs (thanks for those! ;), with a few from 
RPMforge.

> [r...@inspector ~]# rpm -q cyrus-imapd amavisd-new clamav spamassassin 
> postfix httpd mod_ssl
> cyrus-imapd-2.3.7-7.el5_4.3
> amavisd-new-2.6.4-3.el5.rf
> clamav-0.96.4-1.el5.rf
> spamassassin-3.3.1-3.el5.rf
> postfix-2.3.3-2.1.el5_2
> httpd-2.2.3-43.el5.centos.3
> mod_ssl-2.2.3-43.el5.centos.3

Which still leaves me thinking my port 993 problem isn't entropy, 
because STARTTLS works fine.

Chris

>>> [r...@inspector random]# strings /usr/lib/libsasl* |grep random
>>> /dev/urandom
>>> /dev/urandom
>>
>>
>>  But my /dev/random does seem quite low. Still surfing and looking for a
>> good way to fill it on a mostly headless server -- I haven't found a
>> good solution yet.
>>
>> Chris
>>
>>> [r...@inspector ~]# ls -l /dev/*random
>>> crw-rw-rw- 1 root root 1, 8 Oct 31 02:05 /dev/random
>>> cr--r--r-- 1 root root 1, 9 Oct 31 02:05 /dev/urandom
>>> [r...@inspector ~]# cd /proc/sys/kernel/random
>>> [r...@inspector random]# more *|cat
>>> ::
>>> boot_id
>>> ::
>>> d3724e19-7462-4224-960b-49d5d3a18d7a
>>> ::
>>> entropy_avail
>>> ::
>>> 17
>>> ::
>>> poolsize
>>> ::
>>> 4096
>>> ::
>>> read_wakeup_threshold
>>> ::
>>> 64
>>> ::
>>> uuid
>>> ::
>>> a3ed2323-e04d-4034-a72a-76b5d4b697f7
>>> ::
>>> write_wakeup_threshold
>>> ::
>>> 128
>>
>>
>> On 10/31/10 9:26 PM, Bron Gondwana wrote:
>>> Sounds like your /dev/random is empty. You can compile with /dev/urandom
>>> or add a source of entropy...
>>>
>>> "Chris Pepper"   wrote:
>>>
mail.reppep.com (CentOS 5) is running cyrus-imapd-2.3.7-7.el5_4.3,
 along with SquirrelMail, postfix, etc. Last night, I noticed that when
 I
 sent mail from Thunderbird, it was not able to file copies in the Sent
 mailbox, although they did reach the recipients, so postfix was
 accepting mail on 587/tcp.

I restarted Cyrus IMAPd but don't see any error messages in
 /var/log/maillog, and the cert&   key look fine. SquirrelMail is fine
 using plain IMAP. I opened 143/tcp in the firewall, and am able to
 fetch
 mail via IMAP with STARTTLS, so it looks like the cert and key are
 fine.

But "telnet mail.reppep.com 993" and openssl fail to get any response.
 Port 993 is open to the Internet, FWIW.

Does anyone have any suggestions for what went wrong and/or how to
 fix?
 I'll try tcpdump next to see if it's responding at all.

Alternatively, is there a way to make sure Cyrus requires STARTTLS on
 143? I was blocking external access to it to make sure users always use
 encryption to connect, but port 143 with STARTTLS required would be an
 acceptable alternative.

 Thanks,

 Chris Pepper

> pep...@imp:~$ !openssl
> openssl s_client -connect www.reppep.com:993
> CONNECTED(0003)
> 4284:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
> failure:/SourceCache/OpenSSL098/OpenSSL098-32/src/ssl/s23_lib.c:188:


> [r...@inspector ~]# cat /etc/imapd.conf
> admins: cyrus
> altnamespace: yes
> configdirectory: /var/lib/imap
> duplicatesuppression: yes
> hashimapspool: no
> partition-default: /var/spool/imap
> servername: mail.reppep.com
> singleinstancestore: yes
> #syslog_prefix: cyrus
> unixhierarchysep: yes
>
> lmtp_downcase_rcpt: yes
> maxmessagesize: 20971520
> sendmail: /usr/sbin/sendmail
> #quotawarn: 80
>
> #allowplaintext: yes
> #allowplainwithouttls: yes
> sasl_pwcheck_method: saslauthd
> #imap_auth_login: yes
> #imap_auth_cram_md5: yes
> #imap_auth_plain: yes
>
> autocreateinboxfolders:  Junk
> autocreatequota: -1
> #autocreate_sieve_script: /etc/junk.sieve
> autocreate_sieve_compiledscript: /etc/sieve.bc
> autosievefolders: Junk
> autosubscribeinboxfolders:   Junk
> createonpost: yes
> #sievedir: /var/lib/imap/sieve
> sieveusehomedir: true
>
> tls_ca_file:   /etc/pki/tls/certs/mail.reppep.com.20100115.crt
> tls_cert_file: /etc/pki/tls/certs/mail.reppep.com.20100115.crt
> tls_key_file:  /etc/pki/tls/private/mail.reppep.com.20080219.key
> tls_cipher_list: SSLv3:TLSv1:!NULL

Re: Odd problem: IMAP/S suddenly not working, but no errors, and IMAP still works

2010-11-01 Thread Simon Matter 
> Bron,
>
>   My Cyrus is from RPM, and I am just nursing it along until my users
> finish migrating off and FastMail manages to complete my own migration,
> so I don't want to build from source. Why would IMAP/S block on empty
> /dev/random, while IMAP+STARTTLS works? FWIW, SASL2 seems to use urandom.

If this is really stock CentOS 5 then I think everything Cyrus related
should use /dev/urandom and not /dev/random. But, could it be that other
software you installed uses /dev/random and makes it "empty"?

Simon

>
>> [r...@inspector random]# strings /usr/lib/libsasl* |grep random
>> /dev/urandom
>> /dev/urandom
>
>
>   But my /dev/random does seem quite low. Still surfing and looking for a
> good way to fill it on a mostly headless server -- I haven't found a
> good solution yet.
>
> Chris
>
>> [r...@inspector ~]# ls -l /dev/*random
>> crw-rw-rw- 1 root root 1, 8 Oct 31 02:05 /dev/random
>> cr--r--r-- 1 root root 1, 9 Oct 31 02:05 /dev/urandom
>> [r...@inspector ~]# cd /proc/sys/kernel/random
>> [r...@inspector random]# more *|cat
>> ::
>> boot_id
>> ::
>> d3724e19-7462-4224-960b-49d5d3a18d7a
>> ::
>> entropy_avail
>> ::
>> 17
>> ::
>> poolsize
>> ::
>> 4096
>> ::
>> read_wakeup_threshold
>> ::
>> 64
>> ::
>> uuid
>> ::
>> a3ed2323-e04d-4034-a72a-76b5d4b697f7
>> ::
>> write_wakeup_threshold
>> ::
>> 128
>
>
> On 10/31/10 9:26 PM, Bron Gondwana wrote:
>> Sounds like your /dev/random is empty. You can compile with /dev/urandom
>> or add a source of entropy...
>>
>> "Chris Pepper"  wrote:
>>
>>> mail.reppep.com (CentOS 5) is running cyrus-imapd-2.3.7-7.el5_4.3,
>>> along with SquirrelMail, postfix, etc. Last night, I noticed that when
>>> I
>>> sent mail from Thunderbird, it was not able to file copies in the Sent
>>> mailbox, although they did reach the recipients, so postfix was
>>> accepting mail on 587/tcp.
>>>
>>> I restarted Cyrus IMAPd but don't see any error messages in
>>> /var/log/maillog, and the cert&  key look fine. SquirrelMail is fine
>>> using plain IMAP. I opened 143/tcp in the firewall, and am able to
>>> fetch
>>> mail via IMAP with STARTTLS, so it looks like the cert and key are
>>> fine.
>>>
>>> But "telnet mail.reppep.com 993" and openssl fail to get any response.
>>> Port 993 is open to the Internet, FWIW.
>>>
>>> Does anyone have any suggestions for what went wrong and/or how to
>>> fix?
>>> I'll try tcpdump next to see if it's responding at all.
>>>
>>> Alternatively, is there a way to make sure Cyrus requires STARTTLS on
>>> 143? I was blocking external access to it to make sure users always use
>>> encryption to connect, but port 143 with STARTTLS required would be an
>>> acceptable alternative.
>>>
>>> Thanks,
>>>
>>> Chris Pepper
>>>
 pep...@imp:~$ !openssl
 openssl s_client -connect www.reppep.com:993
 CONNECTED(0003)
 4284:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
 failure:/SourceCache/OpenSSL098/OpenSSL098-32/src/ssl/s23_lib.c:188:
>>>
>>>
 [r...@inspector ~]# cat /etc/imapd.conf
 admins: cyrus
 altnamespace: yes
 configdirectory: /var/lib/imap
 duplicatesuppression: yes
 hashimapspool: no
 partition-default: /var/spool/imap
 servername: mail.reppep.com
 singleinstancestore: yes
 #syslog_prefix: cyrus
 unixhierarchysep: yes

 lmtp_downcase_rcpt: yes
 maxmessagesize: 20971520
 sendmail: /usr/sbin/sendmail
 #quotawarn: 80

 #allowplaintext: yes
 #allowplainwithouttls: yes
 sasl_pwcheck_method: saslauthd
 #imap_auth_login: yes
 #imap_auth_cram_md5: yes
 #imap_auth_plain: yes

 autocreateinboxfolders:  Junk
 autocreatequota: -1
 #autocreate_sieve_script: /etc/junk.sieve
 autocreate_sieve_compiledscript: /etc/sieve.bc
 autosievefolders: Junk
 autosubscribeinboxfolders:   Junk
 createonpost: yes
 #sievedir: /var/lib/imap/sieve
 sieveusehomedir: true

 tls_ca_file:   /etc/pki/tls/certs/mail.reppep.com.20100115.crt
 tls_cert_file: /etc/pki/tls/certs/mail.reppep.com.20100115.crt
 tls_key_file:  /etc/pki/tls/private/mail.reppep.com.20080219.key
 tls_cipher_list: SSLv3:TLSv1:!NULL:!EXPORT:!DES:!LOW:@STRENGTH
 [r...@inspector ~]# ls -l
 /etc/pki/tls/certs/mail.reppep.com.20100115.crt
 /etc/pki/tls/private/mail.reppep.com.20080219.key
 -rw-r--r-- 1 root root 6466 Oct  1 17:13
 /etc/pki/tls/certs/mail.reppep.com.20100115.crt
 -rw-r- 1 root mail  497 Feb 19  2008
 /etc/pki/tls/private/mail.reppep.com.20080219.key
 [r...@inspector ~]# netstat -an|grep LIST|grep tcp|sort -n
 tcp0  0 0.0.0.0:110 0.0.0.0:*
  LISTEN
 tcp0  0 0.0.0.0:111 0.0.0.0:*
  LISTEN
 tcp0  0 0.0.0.0:139 0.0.0.0:*

Re: Odd problem: IMAP/S suddenly not working, but no errors, and IMAP still works

2010-11-01 Thread Dan White 
On 31/10/10 20:51 -0400, Chris Pepper wrote:
>   Alternatively, is there a way to make sure Cyrus requires STARTTLS on
>143? I was blocking external access to it to make sure users always use
>encryption to connect, but port 143 with STARTTLS required would be an
>acceptable alternative.

You can set 'allowplaintext: 0' to disallow plaintext logins over port 143.
That would require clients to perform a STARTTLS, or negotiate a SASL
security layer which meets your 'sasl_minimum_layer:' setting.

-- 
Dan White

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/

Re: Odd problem: IMAP/S suddenly not working, but no errors, and IMAP still works

2010-11-01 Thread Henrique de Moraes Holschuh 
On Sun, 31 Oct 2010, Chris Pepper wrote:
>   But my /dev/random does seem quite low. Still surfing and looking for a 
> good way to fill it on a mostly headless server -- I haven't found a 
> good solution yet.

http://www.entropykey.co.uk/

Very good hardware, first-class Linux support, and will fit on the
internal USB ports of most 1U/2U servers and workstations (where it will
be safe from physical accidents during server maintenance, and far more
protected against tampering).

I'm one of their happy customers (and not otherwise affiliated with them
in any way).  Just like I am a happy customer of fastmail.fm :-)

That said, you should always use /dev/urandom unless you're generating
long-term keys, even if you add one or more entropy keys.  Otherwise, it
gets easier to DoS the service.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/

Re: Odd problem: IMAP/S suddenly not working, but no errors, and IMAP still works

2010-10-31 Thread Chris Pepper 
Bron,

My Cyrus is from RPM, and I am just nursing it along until my users 
finish migrating off and FastMail manages to complete my own migration, 
so I don't want to build from source. Why would IMAP/S block on empty 
/dev/random, while IMAP+STARTTLS works? FWIW, SASL2 seems to use urandom.

> [r...@inspector random]# strings /usr/lib/libsasl* |grep random
> /dev/urandom
> /dev/urandom


But my /dev/random does seem quite low. Still surfing and looking for a 
good way to fill it on a mostly headless server -- I haven't found a 
good solution yet.

Chris

> [r...@inspector ~]# ls -l /dev/*random
> crw-rw-rw- 1 root root 1, 8 Oct 31 02:05 /dev/random
> cr--r--r-- 1 root root 1, 9 Oct 31 02:05 /dev/urandom
> [r...@inspector ~]# cd /proc/sys/kernel/random
> [r...@inspector random]# more *|cat
> ::
> boot_id
> ::
> d3724e19-7462-4224-960b-49d5d3a18d7a
> ::
> entropy_avail
> ::
> 17
> ::
> poolsize
> ::
> 4096
> ::
> read_wakeup_threshold
> ::
> 64
> ::
> uuid
> ::
> a3ed2323-e04d-4034-a72a-76b5d4b697f7
> ::
> write_wakeup_threshold
> ::
> 128


On 10/31/10 9:26 PM, Bron Gondwana wrote:
> Sounds like your /dev/random is empty. You can compile with /dev/urandom or 
> add a source of entropy...
>
> "Chris Pepper"  wrote:
>
>>  mail.reppep.com (CentOS 5) is running cyrus-imapd-2.3.7-7.el5_4.3,
>> along with SquirrelMail, postfix, etc. Last night, I noticed that when I
>> sent mail from Thunderbird, it was not able to file copies in the Sent
>> mailbox, although they did reach the recipients, so postfix was
>> accepting mail on 587/tcp.
>>
>>  I restarted Cyrus IMAPd but don't see any error messages in
>> /var/log/maillog, and the cert&  key look fine. SquirrelMail is fine
>> using plain IMAP. I opened 143/tcp in the firewall, and am able to fetch
>> mail via IMAP with STARTTLS, so it looks like the cert and key are fine.
>>
>>  But "telnet mail.reppep.com 993" and openssl fail to get any response.
>> Port 993 is open to the Internet, FWIW.
>>
>>  Does anyone have any suggestions for what went wrong and/or how to fix?
>> I'll try tcpdump next to see if it's responding at all.
>>
>>  Alternatively, is there a way to make sure Cyrus requires STARTTLS on
>> 143? I was blocking external access to it to make sure users always use
>> encryption to connect, but port 143 with STARTTLS required would be an
>> acceptable alternative.
>>
>> Thanks,
>>
>> Chris Pepper
>>
>>> pep...@imp:~$ !openssl
>>> openssl s_client -connect www.reppep.com:993
>>> CONNECTED(0003)
>>> 4284:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake 
>>> failure:/SourceCache/OpenSSL098/OpenSSL098-32/src/ssl/s23_lib.c:188:
>>
>>
>>> [r...@inspector ~]# cat /etc/imapd.conf
>>> admins: cyrus
>>> altnamespace: yes
>>> configdirectory: /var/lib/imap
>>> duplicatesuppression: yes
>>> hashimapspool: no
>>> partition-default: /var/spool/imap
>>> servername: mail.reppep.com
>>> singleinstancestore: yes
>>> #syslog_prefix: cyrus
>>> unixhierarchysep: yes
>>>
>>> lmtp_downcase_rcpt: yes
>>> maxmessagesize: 20971520
>>> sendmail: /usr/sbin/sendmail
>>> #quotawarn: 80
>>>
>>> #allowplaintext: yes
>>> #allowplainwithouttls: yes
>>> sasl_pwcheck_method: saslauthd
>>> #imap_auth_login: yes
>>> #imap_auth_cram_md5: yes
>>> #imap_auth_plain: yes
>>>
>>> autocreateinboxfolders:  Junk
>>> autocreatequota: -1
>>> #autocreate_sieve_script: /etc/junk.sieve
>>> autocreate_sieve_compiledscript: /etc/sieve.bc
>>> autosievefolders: Junk
>>> autosubscribeinboxfolders:   Junk
>>> createonpost: yes
>>> #sievedir: /var/lib/imap/sieve
>>> sieveusehomedir: true
>>>
>>> tls_ca_file:   /etc/pki/tls/certs/mail.reppep.com.20100115.crt
>>> tls_cert_file: /etc/pki/tls/certs/mail.reppep.com.20100115.crt
>>> tls_key_file:  /etc/pki/tls/private/mail.reppep.com.20080219.key
>>> tls_cipher_list: SSLv3:TLSv1:!NULL:!EXPORT:!DES:!LOW:@STRENGTH
>>> [r...@inspector ~]# ls -l /etc/pki/tls/certs/mail.reppep.com.20100115.crt 
>>> /etc/pki/tls/private/mail.reppep.com.20080219.key
>>> -rw-r--r-- 1 root root 6466 Oct  1 17:13 
>>> /etc/pki/tls/certs/mail.reppep.com.20100115.crt
>>> -rw-r- 1 root mail  497 Feb 19  2008 
>>> /etc/pki/tls/private/mail.reppep.com.20080219.key
>>> [r...@inspector ~]# netstat -an|grep LIST|grep tcp|sort -n
>>> tcp0  0 0.0.0.0:110 0.0.0.0:*   
>>> LISTEN
>>> tcp0  0 0.0.0.0:111 0.0.0.0:*   
>>> LISTEN
>>> tcp0  0 0.0.0.0:139 0.0.0.0:*   
>>> LISTEN
>>> tcp0  0 0.0.0.0:143 0.0.0.0:*   
>>> LISTEN
>>> tcp0  0 0.0.0.0:20000.0.0.0:*   
>>> LISTEN
>>> tcp0  0 0.0.0.0:25  0.0.0.0:*   
>>> LISTEN
>>> tcp0  0 0.0.0.0:3306

Odd problem: IMAP/S suddenly not working, but no errors, and IMAP still works

2010-10-31 Thread Chris Pepper 
mail.reppep.com (CentOS 5) is running cyrus-imapd-2.3.7-7.el5_4.3, 
along with SquirrelMail, postfix, etc. Last night, I noticed that when I 
sent mail from Thunderbird, it was not able to file copies in the Sent 
mailbox, although they did reach the recipients, so postfix was 
accepting mail on 587/tcp.

I restarted Cyrus IMAPd but don't see any error messages in 
/var/log/maillog, and the cert & key look fine. SquirrelMail is fine 
using plain IMAP. I opened 143/tcp in the firewall, and am able to fetch 
mail via IMAP with STARTTLS, so it looks like the cert and key are fine.

But "telnet mail.reppep.com 993" and openssl fail to get any response. 
Port 993 is open to the Internet, FWIW.

Does anyone have any suggestions for what went wrong and/or how to fix? 
I'll try tcpdump next to see if it's responding at all.

Alternatively, is there a way to make sure Cyrus requires STARTTLS on 
143? I was blocking external access to it to make sure users always use 
encryption to connect, but port 143 with STARTTLS required would be an 
acceptable alternative.

Thanks,

Chris Pepper

> pep...@imp:~$ !openssl
> openssl s_client -connect www.reppep.com:993
> CONNECTED(0003)
> 4284:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake 
> failure:/SourceCache/OpenSSL098/OpenSSL098-32/src/ssl/s23_lib.c:188:


> [r...@inspector ~]# cat /etc/imapd.conf
> admins: cyrus
> altnamespace: yes
> configdirectory: /var/lib/imap
> duplicatesuppression: yes
> hashimapspool: no
> partition-default: /var/spool/imap
> servername: mail.reppep.com
> singleinstancestore: yes
> #syslog_prefix: cyrus
> unixhierarchysep: yes
>
> lmtp_downcase_rcpt: yes
> maxmessagesize: 20971520
> sendmail: /usr/sbin/sendmail
> #quotawarn: 80
>
> #allowplaintext: yes
> #allowplainwithouttls: yes
> sasl_pwcheck_method: saslauthd
> #imap_auth_login: yes
> #imap_auth_cram_md5: yes
> #imap_auth_plain: yes
>
> autocreateinboxfolders:  Junk
> autocreatequota: -1
> #autocreate_sieve_script: /etc/junk.sieve
> autocreate_sieve_compiledscript: /etc/sieve.bc
> autosievefolders: Junk
> autosubscribeinboxfolders:   Junk
> createonpost: yes
> #sievedir: /var/lib/imap/sieve
> sieveusehomedir: true
>
> tls_ca_file:   /etc/pki/tls/certs/mail.reppep.com.20100115.crt
> tls_cert_file: /etc/pki/tls/certs/mail.reppep.com.20100115.crt
> tls_key_file:  /etc/pki/tls/private/mail.reppep.com.20080219.key
> tls_cipher_list: SSLv3:TLSv1:!NULL:!EXPORT:!DES:!LOW:@STRENGTH
> [r...@inspector ~]# ls -l /etc/pki/tls/certs/mail.reppep.com.20100115.crt 
> /etc/pki/tls/private/mail.reppep.com.20080219.key
> -rw-r--r-- 1 root root 6466 Oct  1 17:13 
> /etc/pki/tls/certs/mail.reppep.com.20100115.crt
> -rw-r- 1 root mail  497 Feb 19  2008 
> /etc/pki/tls/private/mail.reppep.com.20080219.key
> [r...@inspector ~]# netstat -an|grep LIST|grep tcp|sort -n
> tcp0  0 0.0.0.0:110 0.0.0.0:*   
> LISTEN
> tcp0  0 0.0.0.0:111 0.0.0.0:*   
> LISTEN
> tcp0  0 0.0.0.0:139 0.0.0.0:*   
> LISTEN
> tcp0  0 0.0.0.0:143 0.0.0.0:*   
> LISTEN
> tcp0  0 0.0.0.0:20000.0.0.0:*   
> LISTEN
> tcp0  0 0.0.0.0:25  0.0.0.0:*   
> LISTEN
> tcp0  0 0.0.0.0:33060.0.0.0:*   
> LISTEN
> tcp0  0 0.0.0.0:445 0.0.0.0:*   
> LISTEN
> tcp0  0 0.0.0.0:587 0.0.0.0:*   
> LISTEN
> tcp0  0 0.0.0.0:993 0.0.0.0:*   
> LISTEN
> tcp0  0 0.0.0.0:995 0.0.0.0:*   
> LISTEN
> tcp0  0 10.0.104.200:53 0.0.0.0:*   
> LISTEN
> tcp0  0 :::110  :::*
> LISTEN
> tcp0  0 127.0.0.1:10024 0.0.0.0:*   
> LISTEN
> tcp0  0 127.0.0.1:10025 0.0.0.0:*   
> LISTEN
> tcp0  0 127.0.0.1:530.0.0.0:*   
> LISTEN
> tcp0  0 127.0.0.1:953   0.0.0.0:*   
> LISTEN
> tcp0  0 :::143  :::*
> LISTEN
> tcp0  0 ::1:953 :::*
> LISTEN
> tcp0  0 :::2000 :::*
> LISTEN
> tcp0  0 :::22   :::*
> LISTEN
> tcp0  0 :::4242 :::*
> LISTEN
> tcp0  0 :::443  :::*
> LISTEN
> tcp0  0 :::5222 :::*
> LISTEN
> tcp0  0 ::