[Dovecot] Pigeonhole: Typo in 20-managesieve.conf
Line 33:#process_count = 1024 Probably you mean process_limit
Re: [Dovecot] Any way to let dovecot block pop3 attempts?
Steve Campbell skrev den 2013-05-10 14:17: Is there a way using dovecot facilities to block an IP from attempting POP3 connections (similar to the sendmail access file for smtp connections)? I usually do this at my border firewall, but if there's a quick and dirty way in dovecot to do this, it'd make life a little simpler. google fail2ban, if you using still not using ssl/tls then change to ssl/tls will help aswell, it worked for me, kids still not handle ssl/tls very well these days :) when ssl/tls works drop service on ports without it -- senders that put my email into body content will deliver it to my own trashcan, so if you like to get reply, dont do it
Re: [Dovecot] Looking for a good way to manage passwords for CRAM-MD5
On 5/12/2013 4:17 AM, Steinar Bang wrote: I prefer not to use clear text passwords, even over an encrypted connection. Why? Enforce the encrypted link by not allowing unencrypted connections. The simplest is iptables to block ports 110 and 143, while allowing 993 and 995. As long as the underlying SSL/TLS connection utilizes strong mechanisms, everything in the connection is secure, including passwords. CRAM adds complexity, without adding security if the connection is already secure. Just make sure that you have something like fail2ban to block or slow down dictionary and brute force attacks and make sure you use strong passwords. While it seems that adding encryption on top of encryption adds more security, the problem is in how the algorithms interact. There is a reason there is no Double-DES. DES has 56 bits of entropy. You would assume Double-DES had 112 and Triple-DES had 168 bits. However, due to complex and non-obvious interactions between the different layers, Double-DES only adds one bit, effectively, making 57 bits of entropy. Triple-DES adds another 56 for a total of 113. Quadruple-DES would only add another single bit, for a total of 114 - with a required key of 224 bits. Not a good use of key material, plus it is slow. Also note that MD5, the basis for CRAM-MD5, is considered weak and no longer recommended. Thus, if you face an attacker that is sophisticated enough to crack the SSL / TLS connection, they very likely will have little problem with the CRAM-MD5 mechanism. Does anyone have a similar situation, and a solution they would like to share (config/HOWTO)? Here are the possibilities that comes to mind: 1. Create a web interface to change the password (does anyone know of a ready-made solution for this that they could recommend?) Many webmail systems have plugins that allow the user to change their password. Look into Squirrelmail or Roundcube. You have your choice, depending on how your passwords are stored. You can use the poppassd plugin for both of these, but note IT IS NOT SECURE, so it should *only* be used to change passwords over the loopback interface (127.0.0.1). This has been the easiest to set up in my experience, but the added complexity of securing the daemon and domain socket may not be worth it. There are also plugins that interface with PAM, which I find the second easiest to set up. There are plugins that allow you to call some glue logic (Perl, Python, shell scripts, etc) which enables you to interface to pretty much any method (SQL, LDAP, shadow files, etc) you have chosen to save passwords - that is, as long as you are capable of writing the glue logic yourself. But I am aware that this assumption could be wrong. It could e.g. be easier to make the web interface idea work with a database manager, than messing around with setuid bits to safely update a passwd file owned and touchable only by the dovecot user. Ouch! Do not do this! Use the system provided command line tools for changing passwords, or better yet, the PAM API. Actually a database or LDAP is the best way to go. Shadow files are used for more than just email authentication. Adding users to the shadow files who are just supposed to get email can create all sorts of security holes. Not something you want to do, seeing as how you are trying to improve security. My recommendation: Install a webmail system and password update plugin. Disable port 80 and only allow access via port 443. Block ports 110 and 143 and only allow access to email via ports 993 and 995. You can access your webmail server via the same hostname as the mail server. Example: mailhost.mydomain.com can be access from a web browser as https://mailhost.mydomain.com. This way, you can use the same certificate for the mail server and webmail. I usually recommend separating services on physically different hardware, due to the use of a shared certificate, this is an exception. HOWEVER, only run the webmail system on your web server, do not host any other sites on this machine. The more sites you add the more chance one of them will have a vulnerability that could be used to compromise the entire machine. Think a house of cards crashing down. Avoid using a self signed certificate. Get a properly signed certificate for your server. CheapSSLS.com has them for less then $10. Unless you have experience with CRAM-MD5, I would stay away from it. The problem with security, and why it is so difficult, is that you cannot prove something to be secure, only that it is insecure. One tiny mistake and the security of your system is compromised. Unless you have experience with CRAM-MD5, the extra complexity means you have a higher chance of making a mistake that compromises your security. Stick with a simple authentication method that is easy to set up. Less chance for mistakes. Dem
Re: [Dovecot] Looking for a good way to manage passwords for CRAM-MD5
On 05/12/2013 08:40 AM, Professa Dementia wrote: Avoid using a self signed certificate. Get a properly signed certificate for your server. CheapSSLS.com has them for less then $10. Look also at https://www.startssl.com/
Re: [Dovecot] Looking for a good way to manage passwords for CRAM-MD5
On 5/12/2013 6:18 AM, Gedalya wrote: On 05/12/2013 08:40 AM, Professa Dementia wrote: Avoid using a self signed certificate. Get a properly signed certificate for your server. CheapSSLS.com has them for less than $10. Look also at https://www.startssl.com/ StartSSL is good - and free. I have used them in the past. The reason I did not list them was that I find their interface a bit clunky and odd to navigate. Also, in order to get a free cert, it has to be for non-commercial use. They tend to turn down certs for hosts that do not begin with www and you have no recourse to convince them that your mailhost.xyz.com cert is for personal use. But, give them a try first. For free, there is nothing to lose. Dem
Re: [Dovecot] Looking for a good way to manage passwords for CRAM-MD5
Professa Dementia profe...@dementianati.com: Also note that MD5, the basis for CRAM-MD5, is considered weak and no longer recommended. Thus, if you face an attacker that is sophisticated enough to crack the SSL / TLS connection, they very likely will have little problem with the CRAM-MD5 mechanism. Well, yes. But the CRAM in CRAM-MD5 means that the password itself never crosses the wire, and that is the thing I'm trying to avoid. Of course the flip side of that is that you need to have a (more or less) clear text storage of the password itself on either side. Still... that feels better somehow, to passing it over the wire. [snip!] Many webmail systems have plugins that allow the user to change their password. Look into Squirrelmail or Roundcube. You have your choice, depending on how your passwords are stored. You can use the poppassd plugin for both of these, but note IT IS NOT SECURE, so it should *only* be used to change passwords over the loopback interface (127.0.0.1). This has been the easiest to set up in my experience, but the added complexity of securing the daemon and domain socket may not be worth it. poppassd was a useful google search word. There is a debian package for poppasd, and also a package called poppassd-cgi. The poppassd of debian uses PAM, so that gives me a easy web based password change solution for basic auth. There are also plugins that interface with PAM, which I find the second easiest to set up. Yes. Using PAM is the default for debian dovecot, so if I decide to go with basic auth things get easy. There are plugins that allow you to call some glue logic (Perl, Python, shell scripts, etc) which enables you to interface to pretty much any method (SQL, LDAP, shadow files, etc) you have chosen to save passwords - that is, as long as you are capable of writing the glue logic yourself. Thanks for the tip. That let me narrow down the googling to find this: https://metacpan.org/module/Authen::PAM::Module [snip! Changing passwd files from CGI scripts] Ouch! Do not do this! Use the system provided command line tools for changing passwords, or better yet, the PAM API. Yes, but both of those only allow for basic auth. Actually a database or LDAP is the best way to go. Shadow files are used for more than just email authentication. Adding users to the shadow files who are just supposed to get email can create all sorts of security holes. Not something you want to do, seeing as how you are trying to improve security. Quite. However I had no intention of touching /etc/passwd or /etc/shadow. Just the HMAC-MD5 passwd file used by dovecot. My recommendation: Install a webmail system and password update plugin. Disable port 80 and only allow access via port 443. Block ports 110 and 143 and only allow access to email via ports 993 and 995. You can access your webmail server via the same hostname as the mail server. Example: mailhost.mydomain.com can be access from a web browser as https://mailhost.mydomain.com. This way, you can use the same certificate for the mail server and webmail. I usually recommend separating services on physically different hardware, due to the use of a shared certificate, this is an exception. HOWEVER, only run the webmail system on your web server, do not host any other sites on this machine. The more sites you add the more chance one of them will have a vulnerability that could be used to compromise the entire machine. Think a house of cards crashing down. Yes... however, this is an immediate family email server, so it is neither a high profile, nor a high traffic site. :-) (cost is also a factor) Avoid using a self signed certificate. Get a properly signed certificate for your server. CheapSSLS.com has them for less then $10. I have a Cacert.org signed certificate. Works fine on a debian client (has the CA cert built-in), and the CA cert can be installed for Windows MUAs like Opera and Thunderbird. But it's not possible to install the CA cert on iOS versions 4 (rumor has it the capability was present in late betas of iOS 5, but diseappeared from the final release). Also, installing a CA cert was a real pain on Android last time I looked into it. I haven't looked recently. Unless you have experience with CRAM-MD5, I would stay away from it. I have been using CRAM-MD5 first on cyrus, later on dovecot, from 2000/2001 or thereabouts. The problem with security, and why it is so difficult, is that you cannot prove something to be secure, only that it is insecure. One tiny mistake and the security of your system is compromised. Unless you have experience with CRAM-MD5, the extra complexity means you have a higher chance of making a mistake that compromises your security. Stick with a simple authentication method that is easy to set up. Less chance for mistakes. True. Thanks for your input! There are many ways forward that are easy, if I go for basic auth. Very few,
Re: [Dovecot] Looking for a good way to manage passwords for CRAM-MD5
Professa Dementia skrev den 2013-05-12 14:40: On 5/12/2013 4:17 AM, Steinar Bang wrote: I prefer not to use clear text passwords, even over an encrypted connection. Why? Enforce the encrypted link by not allowing unencrypted connections. The simplest is iptables to block ports 110 and 143, while allowing 993 and 995. why not disable 110, 143 in dovecot ?, its waste leas in firewalls to not provide service on blocked ips :) As long as the underlying SSL/TLS connection utilizes strong mechanisms, everything in the connection is secure, including passwords. plain passwords have no problem in treverse in ssl/tls, but it might still be possible to store unencrypted cookies on webmail, so this question is still valid, but this is not a dovecot problem to resolve more like to remove so bad writed webmail client first CRAM adds complexity, without adding security if the connection is already secure. yes, avoid pam auth, use unix auth if its unix mailboxes, and setup eg postfixadmin for virtual users, follow readme in there and it mostly done with all possible powers of dovecot / postfix, (postfixadmin does not really need postfix but an sql mta that can make the same querys in sql) Just make sure that you have something like fail2ban to block or slow down dictionary and brute force attacks and make sure you use strong passwords. seen in ssl/tls ports ? -- senders that put my email into body content will deliver it to my own trashcan, so if you like to get reply, dont do it
[Dovecot] Quota not working with dict proxy
Hello all,
I'm sure this has been covered somewhere before, but my googlefu is not up
to the challenge.
Basically, I'm trying to configure quota plugin to use a dictionary
service (specifically proxy with mysql) so that I can store the quota
usage in a database and use that information in a lookup for postfix to
reject mail if over quota. I'm doing this because postfix+avamis+dovecot
setup with amavis re-injecting into postfix results in mail being
effectively accepted before dovecot lmtp knows if mailbox is full.
I'm currently using quota maildir:
quota = maildir:User quota
and this works;
doveadm -Df tab quota get -u 'user@domain'
Quota name TypeValue Limit %
User quota STORAGE 55388 204800 27
User quota MESSAGE 4883- 0
When I use quota dict:
quota = dict:User quota:%u:proxy::quota
I get this:
doveadm -f tab quota get -u user@domain
Quota name TypeValue Limit %
User quota STORAGE 0 204800 0
User quota MESSAGE 0 - 0
So far so good.
But manually setting database entry to values retrieved above with maildir
quota results in this:
Quota name TypeValue Limit %
User quota STORAGE 54 204800 0
User quota MESSAGE 4883- 0
I'm guessing this is returning values in KB, so that makes sense, I guess.
Attempting to recalc quota on one account using command:
doveadm -f tab quota recalc -u user@domain
returns with nothing, and when I repeat 'quota get' command, it says:
doveadm(user@domain): Fatal: User doesn't exist
Errwhat?!
Indeed, looking in the database shows the account in question was actually
DELETED!
Obviously, I've got something messed here, but I don't know what.
I need some guidance here.
Dovecot version is 2.1.12
Here is my config:
# 2.1.12: /etc/dovecot/dovecot.conf
# OS: Linux 3.7.5-hardened-r1 x86_64 Gentoo Base System release 2.1 ext4
auth_master_user_separator = *
auth_mechanisms = plain login
auth_username_chars =
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@
auth_verbose_passwords = plain
default_process_limit = 200
dict {
quota = mysql:/etc/dovecot/dovecot-dict-sql.conf.ext
}
disable_plaintext_auth = no
login_greeting = Awaiting command...
mail_location = maildir:/home/vmail/%d/%n/Maildir
mail_plugins = quota
mail_privileged_group = 100
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character
vacation subaddress comparator-i;ascii-numeric relational regex imap4flags
copy include variables body enotify environment mailbox date ihave
namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox Sent Messages {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix = INBOX.
separator = .
type = private
}
passdb {
args = /etc/dovecot/dovecot-sql.conf.ext
driver = sql
}
plugin {
expire = Trash 7
expire2 = Trash/* 7
expire3 = Spam 7
quota = dict:User quota:%u:proxy::quota
quota_rule = *:storage=200M
quota_warning = storage=99%% quota-warning 99 %n %d
quota_warning2 = storage=95%% quota-warning 95 %n %d
quota_warning3 = storage=80%% quota-warning 80 %n %d
quota_warning4 = -storage=95%% quota-warning 'less than 95' %n %d
sieve = ~/.dovecot.sieve
sieve_default = /home/vmail/dovecot/sieve/default.sieve
sieve_dir = ~/sieve
sieve_global_dir = /home/vmail/dovecot/sieve
}
protocols = imap pop3 sieve lmtp
service auth-worker {
user = $default_internal_user
}
service auth {
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0666
user = postfix
}
unix_listener auth-userdb {
group = dovecot
mode = 0666
user = dovecot
}
user = $default_internal_user
}
service dict {
unix_listener dict {
mode = 0600
user = vmail
}
}
service lmtp {
unix_listener /var/spool/postfix/private/dovecot-lmtp {
group = postfix
mode = 0600
user = postfix
}
}
service quota-warning {
executable = script /etc/dovecot/quota-warning.sh
unix_listener quota-warning {
user = vmail
}
user = dovecot
}
ssl_cert = /etc/ssl/dovecot/server.pem
ssl_key = /etc/ssl/dovecot/server.key
userdb {
driver = prefetch
}
userdb {
args = /etc/dovecot/dovecot-sql.conf.ext
driver = sql
}
protocol lmtp {
mail_plugins = sieve quota
postmaster_address = postmaster@domain
}
protocol lda {
mail_plugins = quota sieve quota
}
protocol imap {
mail_max_userip_connections = 20
mail_plugins = quota quota imap_quota
}
protocol pop3 {
mail_plugins = quota quota
}
From dovecot-dict-sql.conf.ext:
connect = host=localhost dbname=maildb user=dbuser password=dbpass
# CREATE TABLE quota (
# username varchar(100) not null,
# bytes bigint not null default 0,
# messages integer not null default 0,
# primary key (username)
# );
map {
pattern =
Re: [Dovecot] Looking for a good way to manage passwords for CRAM-MD5
Steinar Bang s...@dod.no: Professa Dementia profe...@dementianati.com: There are plugins that allow you to call some glue logic (Perl, Python, shell scripts, etc) which enables you to interface to pretty much any method (SQL, LDAP, shadow files, etc) you have chosen to save passwords - that is, as long as you are capable of writing the glue logic yourself. Thanks for the tip. That let me narrow down the googling to find this: https://metacpan.org/module/Authen::PAM::Module There are claims in Authen::PAM that it can be used to write PAM modules in perl, but I have yet to find an example showing how. It is available as a debian package: http://packages.debian.org/wheezy/libauthen-pam-perl (however, while that package contains an .so, it looks like that .so is meant for inclusion into perl, rather than being an .so meant for inclusion into PAM, that would start a perl interpreter and run a script) The pam_python module is more obviously what I was looking for (ie. an .so residing in /lib/security that runs a python script) http://packages.debian.org/wheezy/libpam-python However, I'm not really all that familiar with Python, so it may just be simpler to write a module in C or C++. Here are three articles that look like they might be useful to accomplish this. http://www.linuxdevcenter.com/pub/a/linux/2002/05/02/pam_modules.html http://www.linuxdevcenter.com/pub/a/linux/2002/05/23/pam_modules.html http://www.linuxdevcenter.com/pub/a/linux/2002/05/30/pam_modules.html (The articles are 11 years old, though, so they may be a bit out of date)
Re: [Dovecot] Quota not working with dict proxy
On Sun, May 12, 2013 12:24 pm, Chris Richards wrote: Hello all, I'm sure this has been covered somewhere before, but my googlefu is not up to the challenge. More info; this is the debug output from the doveadm command: doveadm -Df tab quota recalc -u 'user@domain' doveadm(root): Debug: Loading modules from directory: /usr/lib64/dovecot doveadm(root): Debug: Module loaded: usr/lib64/dovecot/lib10_quota_plugin.so doveadm(root): Debug: Loading modules from directory: /usr/lib64/dovecot/doveadm doveadm(root): Debug: Skipping module doveadm_acl_plugin, because dlopen() failed: /usr/lib64/dovecot/doveadm/lib10_doveadm_acl_plugin.so: undefined symbol: acl_user_module (this is usually intentional, so just ignore this message) doveadm(root): Debug: Skipping module doveadm_expire_plugin, because dlopen() failed: /usr/lib64/dovecot/doveadm/lib10_doveadm_expire_plugin.so: undefined symbol: expire_set_deinit (this is usually intentional, so just ignore this message) doveadm(root): Debug: Module loaded: /usr/lib64/dovecot/doveadm/lib10_doveadm_quota_plugin.so doveadm(root): Debug: Skipping module doveadm_zlib_plugin, because dlopen() failed: /usr/lib64/dovecot/doveadm/lib10_doveadm_zlib_plugin.so: undefined symbol: i_stream_create_deflate (this is usually intentional, so just ignore this message) doveadm(root): Debug: Skipping module doveadm_fts_plugin, because dlopen() failed: /usr/lib64/dovecot/doveadm/lib20_ doveadm_fts_plugin.so: undefined symbol: fts_backend_rescan (this is usually intentional, so just ignore this message) doveadm(user@domain): Debug: auth input: user@domain home=/home/vmail/domains/domain/user/ mail=maildir:/home/vmail/domains/domain/user/Maildir/ uid=1004 gid=100 quota_rule=*:storage=200M doveadm(user@domain): Debug: Added userdb setting: mail=maildir:/home/vmail/domains/domain/user/Maildir/ doveadm(user@domain): Debug: Added userdb setting: plugin/quota_rule=*:storage=200M doveadm(user@domain): Debug: Effective uid=1004, gid=100, home=/home/vmail/domains/domain/user/ doveadm(user@domain): Debug: Quota root: name=User quota backend=dict args=user@domain:proxy::quota doveadm(user@domain): Debug: Quota rule: root=User quota mailbox=* bytes=209715200 messages=0 doveadm(user@domain): Debug: Quota warning: bytes=207618048 (99%) messages=0 reverse=no command=quota-warning 99 user domain doveadm(user@domain): Debug: Quota warning: bytes=199229440 (95%) messages=0 reverse=no command=quota-warning 95 user domain doveadm(user@domain): Debug: Quota warning: bytes=167772160 (80%) messages=0 reverse=no command=quota-warning 80 user domain doveadm(user@domain): Debug: Quota warning: bytes=199229440 (95%) messages=0 reverse=yes command=quota-warning 'less than 95' user domain doveadm(user@domain): Debug: dict quota: user=user@domain, uri=proxy::quota, noenforcing=0 doveadm(user@domain): Debug: Namespace inbox: type=private, prefix=INBOX., sep=., inbox=yes, hidden=no, list=yes, subscriptions=yes location=maildir:/home/vmail/domains/domain/user/Maildir/ doveadm(user@domain): Debug: maildir++: root=/home/vmail/domains/domain/user/Maildir, index=, control=, inbox=/home/vmail/domains/domain/user/Maildir, alt= I don't see anything here that would explain why it is deleting my user account, but I can tell you with certainty that this command is doing SOMETHING that is resulting in the deletion of my account.
Re: [Dovecot] Pigeonhole: Typo in 20-managesieve.conf
On 5/12/2013 10:03 AM, Gedalya wrote: Line 33:#process_count = 1024 Probably you mean process_limit Yes, thanks. This name changed at some point in Dovecot and I forgot to update it for ManageSieve. http://hg.rename-it.nl/dovecot-2.1-pigeonhole/rev/7319f0becc98 Regards, Stephan.
