Re: saslauthd vs auxprop
On Sun, 2011-01-09 at 23:38 -0800, Andrew Morgan wrote: On Sun, 9 Jan 2011, j...@destar.net wrote: I cannot wrap my mind around saslauthd and auxprop. Does auxprop use the sasldb file to authenticate users that have been added using the 'saslpasswd2' command? What is saslauthd trying to use for authentication, would it be the mechs shown in a 'saslauthd -v' output? What does changing the value in the Sendmail.conf file from saslauthd to auxprop or vice versa doing? Running a ps I see that saslauthd is using the shadow mech: /usr/sbin/saslauthd -m /var/run/saslauthd -a shadow But I have no users in the shadow file other than cyrus and my users for my mail server are in the sasldb file? I have read the documentation on the cyrus site, the man pages and searched the mailing list but I still cannot grasp what seems to be a simple concept. Can someone shed some light or at least point me in the right direction? Hopefully I get this right! There are basically 2 high-level choices to make: saslauthd or auxprop. saslauthd is an external daemon process that your program communicates with via a unix socket. auxprop uses C library modules that are loaded by libsasl into your program. saslauthd support a few different authentication mechanisms. The most popular are PAM and passwd/shadow. The most important part here is that saslauthd [much like PAM] can only provide chat-expect authentication mechanisms - like LOGIN and PLAIN. So, in short, only insecure authentication mechanisms. Auxprop is usually used for sasldb, but I think there are several different modules that can be used. I'm fuzzy on auxprop so maybe someone else can fill in more detail here. auxprop is used to implement 'real' SASL mechanisms [Kerberos, digest, otp, etcc...] The purpose is to tie external servers [your MTA, DSA, etc...] into the SASL framework. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
RE: Disallow cleartext on the wire
On Sun, 2011-01-09 at 14:40 -0800, Dudi Goldenberg wrote:
I am using Thunderbird to test with. I want completely disallow logins
without TLS for IMAP.
Have a look at /etc/cyrus.conf:
SERVICES {
# --- Normal cyrus spool, or Murder backends ---
# add or remove based on preferences
imapcmd=imapd -U 30 listen=imap prefork=0 maxchild=100
imaps cmd=imapd -s -U 30 listen=imaps prefork=0
maxchild=100
# pop3cmd=pop3d -U 30 listen=pop3 prefork=0 maxchild=50
#pop3s cmd=pop3d -s -U 30 listen=pop3s prefork=0
maxchild=50
#nntp cmd=nntpd -U 30 listen=nntp prefork=0 maxchild=100
#nntps cmd=nntpd -s -U 30 listen=nntps prefork=0
maxchild=100
Just hash out imap and restart cyrus.
Incorrect. That disables IMAP (TCP/143) and leaves IMAP-over-SSL.
Secure IMAP (IMAP w/TLS) still uses TCP/143. IMAP-over-SSL is rather
hackish.
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Detecting last login IMAP and expire old messages
On Sat, 2011-01-08 at 23:35 -0200, Lucas Zinato Carraro wrote:
Is there a way to get messages from a user account automatic expire if
account is not in used for 6 months ?
Yes, set the expire annotation on the folder. For example, we set
this to 365 on the user's sent-mail folder and to 14 for the users SPAM
folder.
You can also use the ipurge command, like -
EVENTS {
...
sentPurge cmd=ipurge -s -X -f -d 365 user.*.sent-mail at=
trashPurge cmd=ipurge -s -X -f -d 45 user.*.Trash at=0100
spamPurge cmd=ipurge -s -X -f -d 14 user.*.SPAM at=0200
...
} - in cyrus.conf
( i see last update, but this parameter is updated by lmtpd, pop login
and etc ... )
How is the best way to detect users that are not using your account ?
---
If not exist a simple sollution , i suggest to be implemented a
annotate like:
/vendor/cmu/cyrus-imapd/expirenoactive days
and a option for cyr_expire.
--
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Disallow cleartext on the wire
On Mon, Jan 10, 2011 at 07:00:13AM -0500, Adam Tauno Williams wrote: On Sun, 2011-01-09 at 14:40 -0800, Dudi Goldenberg wrote: I am using Thunderbird to test with. I want completely disallow logins without TLS for IMAP. Have a look at /etc/cyrus.conf: Just hash out imap and restart cyrus. Incorrect. That disables IMAP (TCP/143) and leaves IMAP-over-SSL. Secure IMAP (IMAP w/TLS) still uses TCP/143. IMAP-over-SSL is rather hackish. What war are you trying to win here? Stopping people using plaintext connections, or stopping passwords being potentially exposed to snoopers? Because Secure IMAP on port 143 just means that once the user has sent their plaintext password over the wire already, you tell them to get lost rather than let them in. It doesn't stop stupid client programs sending the plaintext password out in the first place. IMAP-over-SSL does, because no client sends the password over the network until it has a TCP connection - and it doesn't get one of them if it tries to connect to port 143 and you don't have it turned on. So what's so hackish about IMAP-over-SSL precisely? Bron. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Detecting last login IMAP and expire old messages
On 01/10/2011 08:03 AM, Adam Tauno Williams wrote:
On Sat, 2011-01-08 at 23:35 -0200, Lucas Zinato Carraro wrote:
Is there a way to get messages from a user account automatic expire if
account is not in used for 6 months ?
Yes, set the expire annotation on the folder. For example, we set
this to 365 on the user's sent-mail folder and to 14 for the users SPAM
folder.
But he only wants to expire messages if the user has not logged in in
the last 6 months.
You can also use the ipurge command, like -
EVENTS {
...
sentPurge cmd=ipurge -s -X -f -d 365 user.*.sent-mail at=
trashPurge cmd=ipurge -s -X -f -d 45 user.*.Trash at=0100
spamPurge cmd=ipurge -s -X -f -d 14 user.*.SPAM at=0200
...
} - in cyrus.conf
( i see last update, but this parameter is updated by lmtpd, pop login
and etc ... )
How is the best way to detect users that are not using your account ?
---
If not exist a simple sollution , i suggest to be implemented a
annotate like:
/vendor/cmu/cyrus-imapd/expirenoactivedays
and a option for cyr_expire.
--
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
attachment: boutilpj.vcf
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Detecting last login IMAP and expire old messages
On Mon, 2011-01-10 at 09:13 -0400, Patrick Boutilier wrote: On 01/10/2011 08:03 AM, Adam Tauno Williams wrote: On Sat, 2011-01-08 at 23:35 -0200, Lucas Zinato Carraro wrote: Is there a way to get messages from a user account automatic expire if account is not in used for 6 months ? Yes, set the expire annotation on the folder. For example, we set this to 365 on the user's sent-mail folder and to 14 for the users SPAM folder. But he only wants to expire messages if the user has not logged in in the last 6 months. Ah, my bad. I suppose then it is really an authentication question and not a mailbox question. Hrm it would be nice to have a reliable and standard way to determine when the last time user xyz was authenticated; but I'm not aware of any such thing. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Detecting last login IMAP and expire old messages
On 01/10/2011 09:37 AM, Adam Tauno Williams wrote: On Mon, 2011-01-10 at 09:13 -0400, Patrick Boutilier wrote: On 01/10/2011 08:03 AM, Adam Tauno Williams wrote: On Sat, 2011-01-08 at 23:35 -0200, Lucas Zinato Carraro wrote: Is there a way to get messages from a user account automatic expire if account is not in used for 6 months ? Yes, set the expire annotation on the folder. For example, we set this to 365 on the user's sent-mail folder and to 14 for the users SPAM folder. But he only wants to expire messages if the user has not logged in in the last 6 months. Ah, my bad. I suppose then it is really an authentication question and not a mailbox question. Hrm it would be nice to have a reliable and standard way to determine when the last time user xyz was authenticated; but I'm not aware of any such thing. I don't know of a Cyrus way to do it. What we do is use a modified version of pam_mysql to insert a time stamp into the MySQL DB we use for authentication when a user successfully logs in. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ attachment: boutilpj.vcf Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Detecting last login IMAP and expire old messages
In my case authentication is with saslauthd with ldap. ( OpenLDAP ) And this LDAP is used for another systems. User can use LDAP for UNIX authentication for example and not use LDAP dor imap. Aby other idea ? --- Cyrus IMAP has the annotation /vendor/cmu/cyrus-imapd/lastpop with the last pop login hour. But i don't see: /vendor/cmu/cyrus-imapd/lastimap - Exist a way to execute a script an get some parameters $login, $hour and etc .. after a succesful connection in cyrus imap or saslauthd ? Regards Zinato On Mon, Jan 10, 2011 at 12:00 PM, steff...@gmx.de wrote: Original-Nachricht Datum: Mon, 10 Jan 2011 08:37:14 -0500 Von: Adam Tauno Williams awill...@whitemice.org An: info-cyrus@lists.andrew.cmu.edu Betreff: Re: Detecting last login IMAP and expire old messages On Mon, 2011-01-10 at 09:13 -0400, Patrick Boutilier wrote: On 01/10/2011 08:03 AM, Adam Tauno Williams wrote: On Sat, 2011-01-08 at 23:35 -0200, Lucas Zinato Carraro wrote: Is there a way to get messages from a user account automatic expire if account is not in used for 6 months ? Yes, set the expire annotation on the folder. For example, we set this to 365 on the user's sent-mail folder and to 14 for the users SPAM folder. But he only wants to expire messages if the user has not logged in in the last 6 months. Ah, my bad. I suppose then it is really an authentication question and not a mailbox question. Hrm it would be nice to have a reliable and standard way to determine when the last time user xyz was authenticated; but I'm not aware of any such thing. If pam is being used (I don't have the original mail here) you could use pam_lastlog with the 'silent' option so it just updates /var/log/lastlog each time the user logs in via imap or pop. Naturally if you allow other forms of login like ssh etc. lastlog might get updated each time someone logs in (depending on the other pam configurations). If you then say lastlog -b 180 it will show you all the usernames which haven't logged in for at least 180 days. -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Disallow cleartext on the wire
On 10/01/11 23:32 +1100, Bron Gondwana wrote: On Mon, Jan 10, 2011 at 07:00:13AM -0500, Adam Tauno Williams wrote: On Sun, 2011-01-09 at 14:40 -0800, Dudi Goldenberg wrote: I am using Thunderbird to test with. I want completely disallow logins without TLS for IMAP. Have a look at /etc/cyrus.conf: Just hash out imap and restart cyrus. Incorrect. That disables IMAP (TCP/143) and leaves IMAP-over-SSL. Secure IMAP (IMAP w/TLS) still uses TCP/143. IMAP-over-SSL is rather hackish. What war are you trying to win here? Stopping people using plaintext connections, or stopping passwords being potentially exposed to snoopers? Because Secure IMAP on port 143 just means that once the user has sent their plaintext password over the wire already, you tell them to get lost rather than let them in. It doesn't stop stupid client programs sending the plaintext password out in the first place. That was addressed in RFC 3501, section 7.2.1 and presumably why the LOGINDISBLED response was created. If there are any imap clients that send over-the-wire cleartext passwords when server policy forbids it, then that would be grounds for a CVE report on that client. Running IMAP over 143 should be safe from over the wire snooping, if the server is properly configured. IMAP-over-SSL does, because no client sends the password over the network until it has a TCP connection - and it doesn't get one of them if it tries to connect to port 143 and you don't have it turned on. So what's so hackish about IMAP-over-SSL precisely? RFC 2595 discourages it and lists some reasons. -- Dan White Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Detecting last login IMAP and expire old messages
On 10/01/11 14:04 -0200, Lucas Zinato Carraro wrote: In my case authentication is with saslauthd with ldap. ( OpenLDAP ) And this LDAP is used for another systems. User can use LDAP for UNIX authentication for example and not use LDAP dor imap. Are you saying that authentication is not working at all with your imap server? Can you post your saslauthd.conf file, if it exists? What parameters are you starting saslauthd with? Aby other idea ? --- Cyrus IMAP has the annotation /vendor/cmu/cyrus-imapd/lastpop with the last pop login hour. But i don't see: /vendor/cmu/cyrus-imapd/lastimap - Exist a way to execute a script an get some parameters $login, $hour and etc .. after a succesful connection in cyrus imap or saslauthd ? arbitron claims to be able to report statistics of when mailboxes are opened, but I haven't figured out the correct way to run it. -- Dan White Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Fwd: Detecting last login IMAP and expire old messages
On Mon, Jan 10, 2011 at 3:29 PM, Dan White dwh...@olp.net wrote: Are you saying that authentication is not working at all with your imap server? Can you post your saslauthd.conf file, if it exists? No Dan, no problem with authentication. My problem is that i don't find a away to discover if user are not using imap. I can't use my ldap service to discover this , because this service is used for several systems. -- arbitron claims to be able to report statistics of when mailboxes are opened, but I haven't figured out the correct way to run it. I try arbitron but receive a error: arbitron -u -d 30 -l user/lucaszc Loading Mailboxes...Done Loading Users..Bus error Thanks Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Fwd: Detecting last login IMAP and expire old messages
On 10/01/11 16:30 -0200, Lucas Zinato Carraro wrote: I try arbitron but receive a error: arbitron -u -d 30 -l user/lucaszc Loading Mailboxes...Done Loading Users..Bus error Are you running the command as the cyrus user? Arbitron uses the internal mailbox naming scheme (for virtual domains), which was tripping me up. Both of these formats work for me: /usr/sbin/arbitron '*dwhite*' /usr/sbin/arbitron 'olp/net!user/dwhite' However, I'm not getting the output expected - it reports that only the user 'anyone' opened my mailbox, which isn't right. -- Dan White Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Disallow cleartext on the wire
On Mon, Jan 10, 2011 at 11:22:51AM -0600, Dan White wrote: On 10/01/11 23:32 +1100, Bron Gondwana wrote: On Mon, Jan 10, 2011 at 07:00:13AM -0500, Adam Tauno Williams wrote: On Sun, 2011-01-09 at 14:40 -0800, Dudi Goldenberg wrote: I am using Thunderbird to test with. I want completely disallow logins without TLS for IMAP. Have a look at /etc/cyrus.conf: Just hash out imap and restart cyrus. Incorrect. That disables IMAP (TCP/143) and leaves IMAP-over-SSL. Secure IMAP (IMAP w/TLS) still uses TCP/143. IMAP-over-SSL is rather hackish. What war are you trying to win here? Stopping people using plaintext connections, or stopping passwords being potentially exposed to snoopers? Because Secure IMAP on port 143 just means that once the user has sent their plaintext password over the wire already, you tell them to get lost rather than let them in. It doesn't stop stupid client programs sending the plaintext password out in the first place. That was addressed in RFC 3501, section 7.2.1 and presumably why the LOGINDISBLED response was created. If there are any imap clients that send over-the-wire cleartext passwords when server policy forbids it, then that would be grounds for a CVE report on that client. Running IMAP over 143 should be safe from over the wire snooping, if the server is properly configured. Yeah, that's what's known as wishful thinking I suspect. Has anyone actually done any testing on this? IMAP-over-SSL does, because no client sends the password over the network until it has a TCP connection - and it doesn't get one of them if it tries to connect to port 143 and you don't have it turned on. So what's so hackish about IMAP-over-SSL precisely? RFC 2595 discourages it and lists some reasons. Sorry, I don't buy any of those reasons. The server may be using a low grade cipher - so layer a better one inside, or don't use such an ancient server. I think that's a past artifact. The Secure vs Non-Secure client interface issues is a boat that's sailed sorry. Besides more clients are auto-configuring anyway (see Thunderbird's ability to query a URL to get configuration parameters) - or just probing both ports one-off and selecting the SSL one if available. Port numbers are a limited resource - ok, I'll credit that one - but the fact is that you can't really take them back now. They're in use widely enough that it's not going to change any time soon. Sorry - there's wishful thinking, and there's the reality - and the reality is that enabling just port 993 is safe against poor implementation in the way that hoping everyone checked for LOGINDISABLED isn't. Bron. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
imapd and pop3d processes accumulate when clients disappear
I've noticed on our murder front end that imapd and pop3d processes
gradually accumulate. Some of these can be several months old. In
both cases, the reason seems to be that the process is listening on
standard input, but the client has disappeared. Here's a typical
stack trace:
# pstack 5802
5802: imapd -s
feb1a8f5 read (0, 822dd48, 5)
fec2dfaf sock_read () + 3f
This only seems to happen when the client is using SSL or STARTTLS.
The read() never times out. Of course, restarting the Cyrus service
does clean up these abandoned processes, but there should be a better
way. I've found that a simple modification to the daemons that
enables TCP keepalives solves the problem. We also shorten the
keepalive interval with a global setting, but that shouldn't affect
the results once the client has disappeared.
I'll attach the two patches. They are for cyrus-imapd-2.3.8. It
would be better to have a Cyrus master option to enable these socket
options, but these certainly work.
--
-Gary Mills--Unix Group--Computer and Network Services-
--- pop3d.c-nokeep Wed Apr 11 10:49:59 2007
+++ pop3d.c Mon May 17 18:17:22 2010
@@ -494,6 +494,12 @@
if (getsockname(0, (struct sockaddr *)popd_localaddr, salen) == 0) {
popd_haveaddr = 1;
}
+ /* Set keepalive option */
+ {
+ int oval = 1;
+ (void)setsockopt(0, SOL_SOCKET, SO_KEEPALIVE, (const void *)oval,
+sizeof(oval));
+ }
}
/* other params should be filled in */
--- imapd.c-nokeep Sun May 13 08:41:16 2007
+++ imapd.c Tue Jan 4 08:03:05 2011
@@ -786,6 +786,12 @@
imapd_haveaddr = 1;
}
}
+ /* Set keepalive option */
+ {
+ int oval = 1;
+ (void)setsockopt(0, SOL_SOCKET, SO_KEEPALIVE, (const void *)oval,
+sizeof(oval));
+ }
#ifdef DRAC_AUTH
if (((struct sockaddr *)imapd_remoteaddr)-sa_family == AF_INET)
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: imapd and pop3d processes accumulate when clients disappear
That was fixed quite a while ago ... we had the same problem, so I worked with one of the developers to debug and fix it. Am 10.01.2011 um 23:23 schrieb Gary Mills mi...@cc.umanitoba.ca: I've noticed on our murder front end that imapd and pop3d processes gradually accumulate. Some of these can be several months old. In both cases, the reason seems to be that the process is listening on standard input, but the client has disappeared. Here's a typical stack trace: # pstack 5802 5802: imapd -s feb1a8f5 read (0, 822dd48, 5) fec2dfaf sock_read () + 3f This only seems to happen when the client is using SSL or STARTTLS. The read() never times out. Of course, restarting the Cyrus service does clean up these abandoned processes, but there should be a better way. I've found that a simple modification to the daemons that enables TCP keepalives solves the problem. We also shorten the keepalive interval with a global setting, but that shouldn't affect the results once the client has disappeared. I'll attach the two patches. They are for cyrus-imapd-2.3.8. It would be better to have a Cyrus master option to enable these socket options, but these certainly work. -- -Gary Mills--Unix Group--Computer and Network Services- pop3d.c.diff4 imapd.c.diff4 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Disallow cleartext on the wire
Quoting Bron Gondwana br...@fastmail.fm: On Mon, Jan 10, 2011 at 11:22:51AM -0600, Dan White wrote: On 10/01/11 23:32 +1100, Bron Gondwana wrote: On Mon, Jan 10, 2011 at 07:00:13AM -0500, Adam Tauno Williams wrote: On Sun, 2011-01-09 at 14:40 -0800, Dudi Goldenberg wrote: I am using Thunderbird to test with. I want completely disallow logins without TLS for IMAP. Have a look at /etc/cyrus.conf: Just hash out imap and restart cyrus. Incorrect. That disables IMAP (TCP/143) and leaves IMAP-over-SSL. Secure IMAP (IMAP w/TLS) still uses TCP/143. IMAP-over-SSL is rather hackish. What war are you trying to win here? Stopping people using plaintext connections, or stopping passwords being potentially exposed to snoopers? Because Secure IMAP on port 143 just means that once the user has sent their plaintext password over the wire already, you tell them to get lost rather than let them in. It doesn't stop stupid client programs sending the plaintext password out in the first place. That was addressed in RFC 3501, section 7.2.1 and presumably why the LOGINDISBLED response was created. If there are any imap clients that send over-the-wire cleartext passwords when server policy forbids it, then that would be grounds for a CVE report on that client. Running IMAP over 143 should be safe from over the wire snooping, if the server is properly configured. Yeah, that's what's known as wishful thinking I suspect. Has anyone actually done any testing on this? IMAP-over-SSL does, because no client sends the password over the network until it has a TCP connection - and it doesn't get one of them if it tries to connect to port 143 and you don't have it turned on. So what's so hackish about IMAP-over-SSL precisely? RFC 2595 discourages it and lists some reasons. Sorry, I don't buy any of those reasons. The server may be using a low grade cipher - so layer a better one inside, or don't use such an ancient server. I think that's a past artifact. The Secure vs Non-Secure client interface issues is a boat that's sailed sorry. Besides more clients are auto-configuring anyway (see Thunderbird's ability to query a URL to get configuration parameters) - or just probing both ports one-off and selecting the SSL one if available. Port numbers are a limited resource - ok, I'll credit that one - but the fact is that you can't really take them back now. They're in use widely enough that it's not going to change any time soon. Sorry - there's wishful thinking, and there's the reality - and the reality is that enabling just port 993 is safe against poor implementation in the way that hoping everyone checked for LOGINDISABLED isn't. So are you saying that because a MUA might not check for LOGINDISABLED and send the password anyway that if I want secure authentication then only use ports 465, 993 and 995? So because a MUA might not honor the LOGINDISABLED that using TLS on ports 25,110 and 143 is not a good idea? Jon Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Disallow cleartext on the wire
RFC2595 - not recommended IMAPs, but I disagree in some points. imaps and pop3s ports Separate imaps and pop3s ports were registered for use with SSL. Use of these ports is discouraged in favor of the STARTTLS or STLScommands. .. - Separate ports lead to a separate URL scheme which intrudes into the user interface in inappropriate ways. For example, many web pages use language like click here if your browser supports SSL. This is a decision the browser is often more capable of making than the user. But many clients has option to confirm if server certificate is correct. - Separate ports imply a model of either secure or not secure. This can be misleading in a number of ways. First, the secure port may not in fact be acceptably secure as an export-crippled cipher suite might be in use. This can mislead users into a false sense of security. Second, the normal port might in fact be secured by using a SASL mechanism which includes a security layer. Thus the separate port distinction makes the complex topic of security policy even more confusing. One common result of this confusion is that firewall administrators are often misled into permitting the secure port and blocking the standard port. This could be a poor choice given the common use of SSL with a 40-bit key encryption layer and plain-text password authentication is less secure than strong SASL mechanisms such as GSSAPI with Kerberos 5. Again, many clients has option to confirm if connection is secure. Use of SSL with a 40-bit key can be used with other connections too. I do'nt see a serious provider implementing this. - Use of separate ports for SSL has caused clients to implement only two security policies: use SSL or don't use SSL. The desirable security policy use TLS when available would be cumbersome with the separate port model, but is simple with STARTTLS. Clients implement several methods and not only one or two. I do'nt see any modern mail client that not implement imaps but i see clients that not implement STARTTLS. - Port numbers are a limited resource. While they are not yet in short supply, it is unwise to set a precedent that could double (or worse) the speed of their consumption. But IMAPs and SMTPs use only 2 ports. Zinato On Mon, Jan 10, 2011 at 9:08 PM, j...@destar.net wrote: Quoting Bron Gondwana br...@fastmail.fm: On Mon, Jan 10, 2011 at 11:22:51AM -0600, Dan White wrote: On 10/01/11 23:32 +1100, Bron Gondwana wrote: On Mon, Jan 10, 2011 at 07:00:13AM -0500, Adam Tauno Williams wrote: On Sun, 2011-01-09 at 14:40 -0800, Dudi Goldenberg wrote: I am using Thunderbird to test with. I want completely disallow logins without TLS for IMAP. Have a look at /etc/cyrus.conf: Just hash out imap and restart cyrus. Incorrect. That disables IMAP (TCP/143) and leaves IMAP-over-SSL. Secure IMAP (IMAP w/TLS) still uses TCP/143. IMAP-over-SSL is rather hackish. What war are you trying to win here? Stopping people using plaintext connections, or stopping passwords being potentially exposed to snoopers? Because Secure IMAP on port 143 just means that once the user has sent their plaintext password over the wire already, you tell them to get lost rather than let them in. It doesn't stop stupid client programs sending the plaintext password out in the first place. That was addressed in RFC 3501, section 7.2.1 and presumably why the LOGINDISBLED response was created. If there are any imap clients that send over-the-wire cleartext passwords when server policy forbids it, then that would be grounds for a CVE report on that client. Running IMAP over 143 should be safe from over the wire snooping, if the server is properly configured. Yeah, that's what's known as wishful thinking I suspect. Has anyone actually done any testing on this? IMAP-over-SSL does, because no client sends the password over the network until it has a TCP connection - and it doesn't get one of them if it tries to connect to port 143 and you don't have it turned on. So what's so hackish about IMAP-over-SSL precisely? RFC 2595 discourages it and lists some reasons. Sorry, I don't buy any of those reasons. The server may be using a low grade cipher - so layer a better one inside, or don't use such an ancient server. I think that's a past artifact. The Secure vs Non-Secure client interface issues is a boat that's sailed sorry. Besides more clients are auto-configuring anyway (see Thunderbird's ability to query a URL to get configuration parameters) - or just probing both ports one-off and selecting the SSL one if available. Port numbers are a limited resource - ok, I'll credit that one - but the fact is that you can't
Re: Disallow cleartext on the wire
Quoting Lucas Zinato Carraro luca...@gmail.com: RFC2595 - not recommended IMAPs, but I disagree in some points. imaps and pop3s ports Separate imaps and pop3s ports were registered for use with SSL. Use of these ports is discouraged in favor of the STARTTLS or STLScommands. .. - Separate ports lead to a separate URL scheme which intrudes into the user interface in inappropriate ways. For example, many web pages use language like click here if your browser supports SSL. This is a decision the browser is often more capable of making than the user. But many clients has option to confirm if server certificate is correct. - Separate ports imply a model of either secure or not secure. This can be misleading in a number of ways. First, the secure port may not in fact be acceptably secure as an export-crippled cipher suite might be in use. This can mislead users into a false sense of security. Second, the normal port might in fact be secured by using a SASL mechanism which includes a security layer. Thus the separate port distinction makes the complex topic of security policy even more confusing. One common result of this confusion is that firewall administrators are often misled into permitting the secure port and blocking the standard port. This could be a poor choice given the common use of SSL with a 40-bit key encryption layer and plain-text password authentication is less secure than strong SASL mechanisms such as GSSAPI with Kerberos 5. Again, many clients has option to confirm if connection is secure. Use of SSL with a 40-bit key can be used with other connections too. I do'nt see a serious provider implementing this. - Use of separate ports for SSL has caused clients to implement only two security policies: use SSL or don't use SSL. The desirable security policy use TLS when available would be cumbersome with the separate port model, but is simple with STARTTLS. Clients implement several methods and not only one or two. I do'nt see any modern mail client that not implement imaps but i see clients that not implement STARTTLS. - Port numbers are a limited resource. While they are not yet in short supply, it is unwise to set a precedent that could double (or worse) the speed of their consumption. But IMAPs and SMTPs use only 2 ports. Ok, so I am using SASL and am using the max/min SSF in the imapd.conf file. I have TLS and SSL open for authentication and I do not allow plaintext logins without using TLS or SSL. Ports 25,110,143,465,993 and 995 are open on the server the first three for TLS aware MUAs and the last three for those that can't do TLS(MS Outlook 2003). Am I wrong in thinking this will encrypt my logins and keep them from being snooped off the wire? If a MUA does try to jam a passwd in and not honor the LOGINDISABLED flag they will still not be authenticated. I could then send an error message back alerting the user of their non-compliant MUA and why they were denied, correct? Am I missing something obvious here? Thanks again for all the help, Jon Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Disallow cleartext on the wire
On Tue, Jan 11, 2011 at 08:56:01AM +1100, Bron Gondwana wrote: Running IMAP over 143 should be safe from over the wire snooping, if the server is properly configured. Yeah, that's what's known as wishful thinking I suspect. Has anyone actually done any testing on this? And it's certainly not safe from a man-in-the-middle attack which strips the LOGINDISABLED from the CAPABILITY response, while SSL with a client that checks certificates is. True - a client that refuses to use non-TLS sessions is similarly safe, but in that case why not just use SSL and avoid the extra round-trip? Bron. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Detecting last login IMAP and expire old messages
On Mon, Jan 10, 2011 at 08:37:14AM -0500, Adam Tauno Williams wrote: On Mon, 2011-01-10 at 09:13 -0400, Patrick Boutilier wrote: On 01/10/2011 08:03 AM, Adam Tauno Williams wrote: On Sat, 2011-01-08 at 23:35 -0200, Lucas Zinato Carraro wrote: Is there a way to get messages from a user account automatic expire if account is not in used for 6 months ? Yes, set the expire annotation on the folder. For example, we set this to 365 on the user's sent-mail folder and to 14 for the users SPAM folder. But he only wants to expire messages if the user has not logged in in the last 6 months. Ah, my bad. I suppose then it is really an authentication question and not a mailbox question. Hrm it would be nice to have a reliable and standard way to determine when the last time user xyz was authenticated; but I'm not aware of any such thing. We update a few database records from our custom saslauthd, which is used by nearly everything now (web, ftp, dav, imap, pop, smtp, jabber, etc) - it actually speaks 5 different authentication protocols! So you not only know how long since any login, but also what sort of login it was. Bron. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
