Re: [Dovecot] dnsbl feature for dovecot
Am 03.07.2013 04:11, schrieb Stan Hoeppner: On 7/2/2013 8:32 PM, Professa Dementia wrote: On 7/2/2013 6:21 PM, John Fawcett wrote: dnsbl's are a popular method to prevent listed ips from making connections to mta software. cf. postscreen_dnsbl_sites in postfix Would it be possible to introduce such a feature in dovecot, so that connections can be denied based on a dnsbl lookup (where the precise dnsbls used are configurable)? John Let's back up a bit. This does not seem like a feature that Dovecot needs. Rather, what problem are you trying to solve? Maybe there is an existing or better way to accomplish it. Based on John's recent thread on postfix-users on the same general subject, I'd guess he's trying to stop rouge/malicious connections. so perhaps fail2ban might help, or construct something out of syslog and iptables recent, or use dovecot deny etc http://wiki2.dovecot.org/HowTo/Fail2Ban http://wiki2.dovecot.org/Authentication/RestrictAccess http://wiki2.dovecot.org/PasswordDatabase/ExtraFields/AllowNets only german, but code should understandable anyway for new coding ideas http://sys4.de/de/blog/2012/12/28/botnets-mit-rsyslog-und-iptables-recent-modul-abwehren/ usually fail2ban is enough for brute force pop3/imap, but blocking ips is a problem ever with nat clients Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: [Dovecot] dnsbl feature for dovecot
On 03/07/13 05:24, Professa Dementia wrote: On 7/2/2013 7:11 PM, Stan Hoeppner wrote: On 7/2/2013 8:32 PM, Professa Dementia wrote: On 7/2/2013 6:21 PM, John Fawcett wrote: dnsbl's are a popular method to prevent listed ips from making connections to mta software. cf. postscreen_dnsbl_sites in postfix Would it be possible to introduce such a feature in dovecot, so that connections can be denied based on a dnsbl lookup (where the precise dnsbls used are configurable)? John Let's back up a bit. This does not seem like a feature that Dovecot needs. Rather, what problem are you trying to solve? Maybe there is an existing or better way to accomplish it. Based on John's recent thread on postfix-users on the same general subject, I'd guess he's trying to stop rouge/malicious connections. That's my point. A self run IP blackhole list is almost useless. Distributed RBLs are much more effective. However, existing ones are based on spam sources, not malicious connections to POP or IMAP servers. Knowing the problem would be beneficial in determining a good solution. For certain types of connection abuse, Fail2Ban works remarkably well. But, without knowing his exact problem, it may not be the correct solution. Dem The point is to stop spambot connections to pop and imap (which are usually done to try and steal credentials). I already use fail2ban to stop brute force attacks but that means that each one has to be allowed to connect a specified number of times and trigger the filter. I was imagining a distributed solution which is already in use in many mtas applied also to imap and pop so that connections could be stopped from the first one. I am assuming that if there is such a feature then data is available (e.g. sorbs) or if not yet being collected that it could be done. John
Re: [Dovecot] dnsbl feature for dovecot
Am 03.07.2013 05:24, schrieb Professa Dementia: On 7/2/2013 7:11 PM, Stan Hoeppner wrote: On 7/2/2013 8:32 PM, Professa Dementia wrote: On 7/2/2013 6:21 PM, John Fawcett wrote: dnsbl's are a popular method to prevent listed ips from making connections to mta software. cf. postscreen_dnsbl_sites in postfix Would it be possible to introduce such a feature in dovecot, so that connections can be denied based on a dnsbl lookup (where the precise dnsbls used are configurable)? John Let's back up a bit. This does not seem like a feature that Dovecot needs. Rather, what problem are you trying to solve? Maybe there is an existing or better way to accomplish it. Based on John's recent thread on postfix-users on the same general subject, I'd guess he's trying to stop rouge/malicious connections. That's my point. A self run IP blackhole list is almost useless. Distributed RBLs are much more effective. However, existing ones are based on spam sources, not malicious connections to POP or IMAP servers. Knowing the problem would be beneficial in determining a good solution. For certain types of connection abuse, Fail2Ban works remarkably well. But, without knowing his exact problem, it may not be the correct solution. Dem i think an auto dynamic user/ip based con limit might be best , but i guess it will be difficult to implement, for this you need some log analyser counting wrong auth user/ip pairs, invoking some action on the fly , like throttle user from ip, and auto high user/ip login throttle by adjustable time periods , also there must be some whitelist possible Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: [Dovecot] dnsbl feature for dovecot
On 03/07/13 09:26, Robert Schetterer wrote: Am 03.07.2013 04:11, schrieb Stan Hoeppner: On 7/2/2013 8:32 PM, Professa Dementia wrote: On 7/2/2013 6:21 PM, John Fawcett wrote: dnsbl's are a popular method to prevent listed ips from making connections to mta software. cf. postscreen_dnsbl_sites in postfix Would it be possible to introduce such a feature in dovecot, so that connections can be denied based on a dnsbl lookup (where the precise dnsbls used are configurable)? John Let's back up a bit. This does not seem like a feature that Dovecot needs. Rather, what problem are you trying to solve? Maybe there is an existing or better way to accomplish it. Based on John's recent thread on postfix-users on the same general subject, I'd guess he's trying to stop rouge/malicious connections. so perhaps fail2ban might help, or construct something out of syslog and iptables recent, or use dovecot deny etc http://wiki2.dovecot.org/HowTo/Fail2Ban http://wiki2.dovecot.org/Authentication/RestrictAccess http://wiki2.dovecot.org/PasswordDatabase/ExtraFields/AllowNets only german, but code should understandable anyway for new coding ideas http://sys4.de/de/blog/2012/12/28/botnets-mit-rsyslog-und-iptables-recent-modul-abwehren/ usually fail2ban is enough for brute force pop3/imap, but blocking ips is a problem ever with nat clients Best Regards MfG Robert Schetterer Thanks Robert, I saw that article and implemented that in fail2ban to stop repeated hammering attempts on the server from the same clients already rejected by dnsbl in postfix. I was thinking of extending the mechanism to imap/pop. John
Re: [Dovecot] dnsbl feature for dovecot
On 03/07/13 03:27, Timo Sirainen wrote: On 3.7.2013, at 4.21, John Fawcett john...@erba.tv wrote: dnsbl's are a popular method to prevent listed ips from making connections to mta software. cf. postscreen_dnsbl_sites in postfix Would it be possible to introduce such a feature in dovecot, so that connections can be denied based on a dnsbl lookup (where the precise dnsbls used are configurable)? You're talking about IMAP/POP3 connections? Possible, yeah .. possibly even without code changes by using tcpwrappers. TImo, thanks for the reply. I will look into that suggestion. John
[Dovecot] Who all accessed my dovecot server?
Hi, I have set up a mail server with dovecot as IMAP/POP3 server, postfix as MTA and roundcube as web mail client. Other mail clients such as Thunderbird is also being used for mail access. Now as a security policy in our organization, I want to know the IP addresses of the machines from which my mail server was accessed. Is there any monitoring tools to get these details? Regards, Suja -- View this message in context: http://dovecot.2317879.n4.nabble.com/Who-all-accessed-my-dovecot-server-tp43102.html Sent from the Dovecot mailing list archive at Nabble.com.
Re: [Dovecot] lmtp: Disable Delivered-To header
Hi, using LMTP, is it possible to disable the addition of the Delivered-To header to messages? No. But why? Stupid customer, I migrated his Mailbox from Cyrus to Dovecot, and now this Delivered-To: Header is somehow shown as To: in his Client. I tried to Explain it to him, but he demands that I take out this Header, because he doesn't want it, and it breaks his e-mail. :-/ Customer is a Lawyer, so reasoning with him is probably a waste of time. Micha Krause
Re: [Dovecot] Who all accessed my dovecot server?
Am 03.07.2013 10:32, schrieb pvsuja: Hi, I have set up a mail server with dovecot as IMAP/POP3 server, postfix as MTA and roundcube as web mail client. Other mail clients such as Thunderbird is also being used for mail access. Now as a security policy in our organization, I want to know the IP addresses of the machines from which my mail server was accessed. Is there any monitoring tools to get these details? Regards, Suja -- View this message in context: http://dovecot.2317879.n4.nabble.com/Who-all-accessed-my-dovecot-server-tp43102.html Sent from the Dovecot mailing list archive at Nabble.com. logwatch gives you detailed report about ips pop3/imap also counts users/ip logins pop3/imap and shows delivers to imap folders, use it i.e daily with logrotate you might have to adjust dovecot logging level and use some logwatch ignores http://sourceforge.net/projects/logwatch/files/ Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: [Dovecot] Who all accessed my dovecot server?
Am 7/3/2013 10:32 AM, schrieb pvsuja: I have set up a mail server with dovecot as IMAP/POP3 server, postfix as MTA and roundcube as web mail client. Other mail clients such as Thunderbird is also being used for mail access. Now as a security policy in our organization, I want to know the IP addresses of the machines from which my mail server was accessed. Is there any monitoring tools to get these details? A cron job doing grep imap-login: Login: /var/log/maillog might do the job already. The 'rip=' part of the matches tells you the remote IP. Instead of /var/log/maillog you might have to check another file (it depends on your Dovecot setup). -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] dnsbl feature for dovecot
On Wed, 03 Jul 2013 09:37:14 +0200 Robert Schetterer r...@sys4.de wrote: Am 03.07.2013 05:24, schrieb Professa Dementia: On 7/2/2013 7:11 PM, Stan Hoeppner wrote: On 7/2/2013 8:32 PM, Professa Dementia wrote: On 7/2/2013 6:21 PM, John Fawcett wrote: dnsbl's are a popular method to prevent listed ips from making connections to mta software. cf. postscreen_dnsbl_sites in postfix Would it be possible to introduce such a feature in dovecot, so that connections can be denied based on a dnsbl lookup (where the precise dnsbls used are configurable)? John Let's back up a bit. This does not seem like a feature that Dovecot needs. Rather, what problem are you trying to solve? Maybe there is an existing or better way to accomplish it. Based on John's recent thread on postfix-users on the same general subject, I'd guess he's trying to stop rouge/malicious connections. That's my point. A self run IP blackhole list is almost useless. Distributed RBLs are much more effective. However, existing ones are based on spam sources, not malicious connections to POP or IMAP servers. Knowing the problem would be beneficial in determining a good solution. For certain types of connection abuse, Fail2Ban works remarkably well. But, without knowing his exact problem, it may not be the correct solution. Dem i think an auto dynamic user/ip based con limit might be best , but i guess it will be difficult to implement, for this you need some log analyser counting wrong auth user/ip pairs, invoking some action on the fly , like throttle user from ip, and auto high user/ip login throttle by adjustable time periods , also there must be some whitelist possible One possibility for the connection limiting could be using the iptables hashlimit module. Getting the correct values for it might be a bit tricky, but maybe initially you could do logging on a dedicated iptables chain instead of drops to get some sample usage statistics. Then again, you should also be careful with hashlimit if you have large number of users coming from the same IP address (ISPs using NAT etc). Best regards -- Branko Majic Jabber: bra...@majic.rs Please use only Free formats when sending attachments to me. Бранко Мајић Џабер: bra...@majic.rs Молим вас да додатке шаљете искључиво у слободним форматима. signature.asc Description: PGP signature
Re: [Dovecot] Who all accessed my dovecot server?
Am 03.07.2013 10:53, schrieb Frerich Raabe: Am 7/3/2013 10:32 AM, schrieb pvsuja: I have set up a mail server with dovecot as IMAP/POP3 server, postfix as MTA and roundcube as web mail client. Other mail clients such as Thunderbird is also being used for mail access. Now as a security policy in our organization, I want to know the IP addresses of the machines from which my mail server was accessed. Is there any monitoring tools to get these details? A cron job doing grep imap-login: Login: /var/log/maillog might do the job already. The 'rip=' part of the matches tells you the remote IP. Instead of /var/log/maillog you might have to check another file (it depends on your Dovecot setup). graphic realtime logging may also be done out of syslog by using some monitoring solution like nagios , xymon, zabbix etc this might give you ideas, hove to code your own stuff http://sys4.de/de/blog/2013/04/02/monitoring-logfile-entries-logwatch/ http://sys4.de/de/blog/2013/01/10/xymon-dovecot-count-imap-pop3-logins-graph-central-rsyslog-server-ubuntu-lucid/ Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: [Dovecot] lmtp: Disable Delivered-To header
Am 03.07.2013 10:43, schrieb Micha Krause: Hi, using LMTP, is it possible to disable the addition of the Delivered-To header to messages? No. But why? Stupid customer, I migrated his Mailbox from Cyrus to Dovecot, and now this Delivered-To: Header is somehow shown as To: in his Client. I tried to Explain it to him, but he demands that I take out this Header, because he doesn't want it, and it breaks his e-mail. :-/ Customer is a Lawyer, so reasoning with him is probably a waste of time. Micha Krause looks like he has to live with this, in general, i anounced at my customers that headers may change ever by urgent updates etc,in the past, cause at migration time customers noticed this with fetchmail like software Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: [Dovecot] dnsbl feature for dovecot
On 7/3/2013 12:35 AM, John Fawcett wrote: The point is to stop spambot connections to pop and imap (which are usually done to try and steal credentials). This is not the usual way spambots work. Generally, spambots scrape addresses from various sources in order to get lists of emails to send spam to. What you seem to be experiencing may be zombie nets trying to brute force credentials so they can then send spam from compromised accounts. This is a different beast with a different solution. Regardless, you have a spcific problem that needs addressing. I ran an ISP for almost two decades and have dealt with these issues myself. My recommendations: 1) Enforce strong user passwords. I use 12 characters minimum. 14 characters or more would be better, but this length starts to make it hard for mere humans to remember. Enforce a rule that the password contains at least 2 or 3 of the following: lower case letter, upper case letter, digit, and symbol which is not one of the prior three. Some systems require the user's password have all four. This actually weakens the password (if you care to know why, I can go into the math in a later post). After enforcing your chosen rules, run the password through cracklib before accepting it from the user. Or even better, what I started doing was having the system generate passwords and not let the user choose their own. Initially people grumbled a bit, but they soon got used to it and security was much better. 2) Fail2Ban with rules that seem like they are pretty weak, but trust me, they work fine and you limit complaints from users. a) If you get 3 invalid login attempts within a minute from more than 1 IP address, block that login for 10 minutes. If you have blocked a login and another attempt to log in to that account is made then tarpit that connection. Usually 60 seconds is sufficient. Do not extend the original block time past the original 10 minutes. b) If you get 5 invalid login attempts within a minute from the same IP, block that IP for 5 minutes. This is usually a valid user who forgot their password, as opposed to a) which is usually a malicious third party. Some of this you can do with off the shelf tools, some of it may require some glue code (Perl or Python works nicely) on your part. If you can implement this, it will stop the abuse cold. 1) provides security and makes brute forcing infeasible. 2) helps reduce load on your systems. I was imagining a distributed solution which is already in use in many mtas applied also to imap and pop so that connections could be stopped from the first one. I am assuming that if there is such a feature then data is available (e.g. sorbs) or if not yet being collected that it could be done. I feel your pain and frustration. I do not believe there is an RBL list of offending IP's for brute force attacks and I think one would be hard to build and keep up to date enough to be useful, since most of these systems are compromised home computers, but they get fixed and there is a lot of turnover - infected systems are repaired and new ones infected. Most of them are in the far east, so if you do not mind applying a cudgel to the problem, you can block entire ranges of IPs altogether. Of course, one of your users traveling to one of those areas would need to use some other method to access email (mobile device, webmail, etc). Dem
Re: [Dovecot] namespace delivery question
Thanks Steffen,
It mostly works.
my public namespace config:
--
namespace {
type = public
prefix = public/
separator = /
location = sdbox:/home/vmail/public/
list = no
subscriptions = no
}
--
If I rewrite i...@domain.com to vmail+public/i...@domain.com, then it saved to
/home/vmail/public/mailboxes/info however if I get mail to
vmail+public/i...@anotherdomain.com then it's saved to the same mailbox.
How can I set dovecot to save to different mailboxes?
Regards: Király László
-- Original Message ---
From: Steffen Kaiser skdove...@smail.inf.fh-brs.de
To: k...@madalbal.hu
Cc: dovecot@dovecot.org
Sent: Tue, 2 Jul 2013 14:28:41 +0200 (CEST)
Subject: Re: [Dovecot] namespace delivery question
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 27 Jun 2013, Laszlo Kiraly wrote:
i...@domain.com - public, readable by user2
us...@domain.com - private
us...@domain.com - private
The mailboxes are virtual, authentication through pam (kerberos).
The public mailbox doesn't have valid kerberos account.
I couldn't find solution in the documentation, how can I manage the email
delivery to the public namespace?
There is a -m option in the lda delivery where you can give namespace
prefix.
Maybe it's good for this, but I couldn't find any information how can I do
this with lmtp?
If you set:
lmtp_save_to_detail_mailbox = yes
recipient_delimiter = #
you could alias i...@domain.com to
user#public.mailbox.fol...@domain.com . 1st option tells LMTP to
use the detail (subaddress) as default mailbox, which is essentially
the same as the -m option of the LDA. 2nd options sets the delimiter
of user and detail. user must habe write permission to the folder.
Regards,
- --
Steffen Kaiser
Re: [Dovecot] namespace delivery question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 3 Jul 2013, Laszlo Kiraly wrote: It mostly works. location = sdbox:/home/vmail/public/ If I rewrite i...@domain.com to vmail+public/i...@domain.com, then it saved to /home/vmail/public/mailboxes/info however if I get mail to vmail+public/i...@anotherdomain.com then it's saved to the same mailbox. How can I set dovecot to save to different mailboxes? if both users vm...@domain.com and vm...@anotherdomain.com have append permission to public/info, vmail+public/i...@anotherdomain.com will save the message there, because that's the idea of lmtp_save_to_detail_mailbox . vmail+public/i...@anotherdomain.com means: do not save to INBOX of vm...@anotherdomain.com, but to public/info with the permission of user vm...@anotherdomain.com. That applies to all other users as well. If you want to store i...@anotherdomain.com somewhere else, create another SMTP alias to another mailbox, e.g.: i...@anotherdomain.com - vmail+public/info-anotherdom...@anotherdomain.com I think you should reject incoming mails from outside to vmail and handle all deliveries to public through local SMTP aliases. Because vmail is no valid recipient anyway, isn't it? - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBUdQo2F3r2wJMiz2NAQIO8ggAsnaAZaJjtClKzIYOXK2y5SvQzKdnOI03 UOeSf5e99AXWZKZSP+fC+pXra9pNQzicYYQoOabeLPCodvkGt8m2lDslksTSjN6P fzx0HSxxns1wWgUQtLjkBrgdCoKie4irgyCMfByFDmmLjeYVCWtME1cFazUWScLq n+x3qDSFUSHNJbN30X2/UnsIqS/HxMD/VX+8dplhX385z6ZR6XxgZHbjM28LOugS mgfaf42eaqTf/jDgIBJzF23zhITrMb3C4cjWi3pssv/DVc1cuKFchJttdSrTEsMt vgo791cjS+w+kuCZnZKAXiyLKzApk7akRD+kDtzcFpEeoXd5P6YhaA== =ILOl -END PGP SIGNATURE-
Re: [Dovecot] namespace delivery question
If I rewrite i...@domain.com to vmail+public/i...@domain.com, then it saved to /home/vmail/public/mailboxes/info however if I get mail to vmail+public/i...@anotherdomain.com then it's saved to the same mailbox. How can I set dovecot to save to different mailboxes? if both users vm...@domain.com and vm...@anotherdomain.com have append permission to public/info, vmail+public/i...@anotherdomain.com will save the message there, because that's the idea of lmtp_save_to_detail_mailbox . vmail+public/i...@anotherdomain.com means: do not save to INBOX of vm...@anotherdomain.com, but to public/info with the permission of user vm...@anotherdomain.com. That applies to all other users as well. If you want to store i...@anotherdomain.com somewhere else, create another SMTP alias to another mailbox, e.g.: i...@anotherdomain.com - vmail+public/info-anotherdom...@anotherdomain.com Thanks, that is the trick. I think you should reject incoming mails from outside to vmail and handle all deliveries to public through local SMTP aliases. Because vmail is no valid recipient anyway, isn't it? Do you think reject in SMTP time in exim? I think, I do exactly the same. I have a list with public mails and rewrite rules for them. I use this list in an acl to check it's a public mailbox or not. Of course vmail isn't a valid recipient. I have now a fully working system. :) Thank you all for the very useful answers. Regards: Laszlo Kiraly
[Dovecot] tcpwrappers
hi everybody
having I believe sort of plain-vanilla config with section
in 10-tcpwrapper.conf
as per docs
login_access_sockets = tcpwrap
service tcpwrap {
unix_listener login/tcpwrap {
group = $default_login_user
mode = 0600
user = $default_login_user
}
}
/etc/hosts.deny contains:
ALL: given_host
and yet dovecot logins IMAP client in
whereas other tcpwrapper aware services act as expected
what am I missing?
regards
[Dovecot] Creating an authenticated user master user
dovecot --version 1.1.18 mbox format We are trying to migrate from dovecot to another imap server and need some help migrating the user data to the new server. We have written a perl script to migrate the data but it seems that we need an authenticated or Master user in order for the script to access the user mail boxes without the users password. We are using PAM authentication, and root does not have access to the user's mail boxes. Any help would be appreciated. Chris
Re: [Dovecot] dnsbl feature for dovecot
John Fawcett skrev den 2013-07-03 03:21: dnsbl's are a popular method to prevent listed ips from making connections to mta software. hmm are pop3/imap clients not authed users ? well done -- 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] dnsbl feature for dovecot
Timo Sirainen skrev den 2013-07-03 03:27: You're talking about IMAP/POP3 connections? Possible, yeah .. possibly even without code changes by using tcpwrappers. why is it needed ? setup fail2ban to manange xtables-addons geoip csv files from abusers, then use this csv file as A0 list in iptables, end result is low memory footprint, it should not be a dovecot solotion -- 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] dnsbl feature for dovecot
John Fawcett skrev den 2013-07-03 09:40: Possible, yeah .. possibly even without code changes by using tcpwrappers. TImo, thanks for the reply. I will look into that suggestion. John if its implemented in dovecot possible use postfix memcached ?, so thay share cache data -- 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] dnsbl feature for dovecot
On 03/07/13 18:44, Benny Pedersen wrote: Timo Sirainen skrev den 2013-07-03 03:27: You're talking about IMAP/POP3 connections? Possible, yeah .. possibly even without code changes by using tcpwrappers. why is it needed ? setup fail2ban to manange xtables-addons geoip csv files from abusers, then use this csv file as A0 list in iptables, end result is low memory footprint, it should not be a dovecot solotion I would not see fail2ban as the only solution. On the mta I use both dnsbl and fail2ban and both help in their own ways to reduce/limit unwanted connections. I wouldn't consider adding large numbers of rules to iptables but I would consider querying a dnsbl which contained large numbers of ips, since the management of the data is then off the server. John
Re: [Dovecot] dnsbl feature for dovecot
On 03/07/13 18:40, Benny Pedersen wrote: John Fawcett skrev den 2013-07-03 03:21: dnsbl's are a popular method to prevent listed ips from making connections to mta software. hmm are pop3/imap clients not authed users ? well done in this case no, I am talking about connections from zombies.
Re: [Dovecot] dnsbl feature for dovecot
John Fawcett skrev den 2013-07-03 20:41: in this case no, I am talking about connections from zombies. block client ip of the zombies, this is what iptables is for, or change rules to only have ports open for clients location, well dovecot supports ipblocking, but imho its not the right place to setup -- 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] dnsbl feature for dovecot
Am 03.07.2013 20:41, schrieb John Fawcett: On 03/07/13 18:40, Benny Pedersen wrote: John Fawcett skrev den 2013-07-03 03:21: dnsbl's are a popular method to prevent listed ips from making connections to mta software. hmm are pop3/imap clients not authed users ? well done in this case no, I am talking about connections from zombies have fun - most RBL's contains a lot of dialup-addresses which makes sense to get rejected on a MTA until auth but stupid to block completly without abuse users signature.asc Description: OpenPGP digital signature
Re: [Dovecot] dnsbl feature for dovecot
On 03/07/13 12:47, Professa Dementia wrote: On 7/3/2013 12:35 AM, John Fawcett wrote: The point is to stop spambot connections to pop and imap (which are usually done to try and steal credentials). This is not the usual way spambots work. Generally, spambots scrape addresses from various sources in order to get lists of emails to send spam to. What you seem to be experiencing may be zombie nets trying to brute force credentials so they can then send spam from compromised accounts. This is a different beast with a different solution. Yes I have evidence that passwords found by brute force on pop3 were then used to send email via smtp. Regardless, you have a spcific problem that needs addressing. I ran an ISP for almost two decades and have dealt with these issues myself. My recommendations: 1) Enforce strong user passwords. I use 12 characters minimum. 14 characters or more would be better, but this length starts to make it hard for mere humans to remember. Enforce a rule that the password contains at least 2 or 3 of the following: lower case letter, upper case letter, digit, and symbol which is not one of the prior three. Some systems require the user's password have all four. This actually weakens the password (if you care to know why, I can go into the math in a later post). After enforcing your chosen rules, run the password through cracklib before accepting it from the user. Or even better, what I started doing was having the system generate passwords and not let the user choose their own. Initially people grumbled a bit, but they soon got used to it and security was much better. 2) Fail2Ban with rules that seem like they are pretty weak, but trust me, they work fine and you limit complaints from users. a) If you get 3 invalid login attempts within a minute from more than 1 IP address, block that login for 10 minutes. If you have blocked a login and another attempt to log in to that account is made then tarpit that connection. Usually 60 seconds is sufficient. Do not extend the original block time past the original 10 minutes. b) If you get 5 invalid login attempts within a minute from the same IP, block that IP for 5 minutes. This is usually a valid user who forgot their password, as opposed to a) which is usually a malicious third party. Some of this you can do with off the shelf tools, some of it may require some glue code (Perl or Python works nicely) on your part. If you can implement this, it will stop the abuse cold. 1) provides security and makes brute forcing infeasible. 2) helps reduce load on your systems. these look like good suggestions. I was imagining a distributed solution which is already in use in many mtas applied also to imap and pop so that connections could be stopped from the first one. I am assuming that if there is such a feature then data is available (e.g. sorbs) or if not yet being collected that it could be done. I feel your pain and frustration. I do not believe there is an RBL list of offending IP's for brute force attacks and I think one would be hard to build and keep up to date enough to be useful, since most of these systems are compromised home computers, but they get fixed and there is a lot of turnover - infected systems are repaired and new ones infected. Most of them are in the far east, so if you do not mind applying a cudgel to the problem, you can block entire ranges of IPs altogether. Of course, one of your users traveling to one of those areas would need to use some other method to access email (mobile device, webmail, etc). Dem I take the point that ips in such a dnsbl would probably have a short life span. However, whatever may be the difficulties, such a list would not make sense if there is no functionality in the server to use it. I am going to look into Timo's suggestion though on tcpwrappers to see how this would work. John
[Dovecot] Released Pigeonhole v0.4.1 for Dovecot v2.2.4.
Hello Dovecot users, Now that I am not preoccupied anymore, I quickly release a new version of Pigeonhole for Dovecot v2.2. This consists mainly of bug fixes. One new feature is that the Sieve plugin will try to pass temporary failures (e.g. from mail storage) back to LDA/LMTP as much as possible. However, this change turned out a little bigger than I would have liked, so experiment with it a bit before you deploy it in production. Changelog v0.4.1: + Added support for handling temporary failures. These are passed back to LDA/LTMP to produce an appropriate response towards the MTA. - Sieve storage: Removed PATH_MAX limitation for active symlink. This caused problems for GNU/Hurd. - Fixed line endings in X-Sieve headers added by redirect command. - ManageSieve: Fixed '[' ']' stupidity for response codes (only happened before login). - Fixed setting name in example-config/conf.d/20-managesieve.conf. - Sieve extprograms plugin: Fixed interaction between pipe command and remote script service. The output from the script service was never read, causing a broken pipe error at the script service. Apparently, this was broken since the I/O handling for extprograms was last revised. - Fixed assertion failure due to datastack problem in message header composition. The release is available as follows: http://www.rename-it.nl/dovecot/2.2/dovecot-2.2-pigeonhole-0.4.1.tar.gz http://www.rename-it.nl/dovecot/2.2/dovecot-2.2-pigeonhole-0.4.1.tar.gz.sig Refer to http://pigeonhole.dovecot.org and the Dovecot v2.x wiki for more information. Have fun testing this new release and don't hesitate to notify me when there are any problems. Regards, -- Stephan Bosch step...@rename-it.nl
[Dovecot] login_trusted_networks from webmail ?
I'd like to get the IP-address of the webmail-klient logged in my maillog (for being compliant with coming data retention policies). I've noticed that with login_trusted_networks pointing at my dovecot directors, we get rip=client-ip logged on the backends. How is the proxy providing this to the dovecot backends? Anybody know what magic we need to implement in our webmail-solution to be able to forward the webmail-client-ip and have it logged as rip= in dovecot? I belive it will be enough to have it logged as rip= on the directors, maybe not needed to be forwarded all the way to the backends (but that would be nice as well). -jf
Re: [Dovecot] login_trusted_networks from webmail ?
On 3.7.2013, at 23.29, Jan-Frode Myklebust janfr...@tanso.net wrote: I'd like to get the IP-address of the webmail-klient logged in my maillog (for being compliant with coming data retention policies). I've noticed that with login_trusted_networks pointing at my dovecot directors, we get rip=client-ip logged on the backends. How is the proxy providing this to the dovecot backends? Anybody know what magic we need to implement in our webmail-solution to be able to forward the webmail-client-ip and have it logged as rip= in dovecot? a ID (x-originating-ip 1.2.3.4) Other things you could send in the same command: x-originating-port, x-connected-ip, x-connected-port And in case others are wondering, POP3 and LMTP use: XCLIENT ADDR=1.2.3.4 PORT=12345 I belive it will be enough to have it logged as rip= on the directors, maybe not needed to be forwarded all the way to the backends (but that would be nice as well). If backend has login_trusted_networks pointing to directors, then the IP gets forwarded to backends as well.
Re: [Dovecot] login_trusted_networks from webmail ?
On Wed, Jul 03, 2013 at 11:34:56PM +0300, Timo Sirainen wrote: a ID (x-originating-ip 1.2.3.4) Perfect, thanks! Feature request for SOGo filed: http://www.sogo.nu/bugs/view.php?id=2366 -jf
Re: [Dovecot] login_trusted_networks from webmail ?
On 3.7.2013, at 23.50, Jan-Frode Myklebust janfr...@tanso.net wrote: On Wed, Jul 03, 2013 at 11:34:56PM +0300, Timo Sirainen wrote: a ID (x-originating-ip 1.2.3.4) Perfect, thanks! Feature request for SOGo filed: http://www.sogo.nu/bugs/view.php?id=2366 Oh and BTW the reason it was implemented with this kind of ID command was so that the client could detect the normal ID capability and based on that just send the IP address without any further figuring out if the backend supports it. The backends that didn't support it would simply ignore that parameter without any errors. So it should be easy for webmails to implement.
Re: [Dovecot] dnsbl feature for dovecot
Professa Dementia writes: 2) Fail2Ban with rules that seem like they are pretty weak, but trust me, they work fine and you limit complaints from users. a) If you get 3 invalid login attempts within a minute from more than 1 IP address, block that login for 10 minutes. If you have blocked a login and another attempt to log in to that account is made then tarpit that connection. Usually 60 seconds is sufficient. Do not extend the original block time past the original 10 minutes. b) If you get 5 invalid login attempts within a minute from the same IP, block that IP for 5 minutes. This is usually a valid user who forgot their password, as opposed to a) which is usually a malicious third party. Looking at my POP3/IMAP logs, users enter wrong passwords all the time, then their mail client keeps trying to re-authenticate, giving the appearance of a slow rolling BFD. For example, I just grabbed this typical sample Jul 2 13:24:48 dovecot: imap-login: Aborted login (auth failed, 1 attempts in 5 secs): user=x ... Jul 2 13:26:03 dovecot: imap-login: Aborted login (auth failed, 1 attempts in 5 secs): user=x ... Jul 2 13:26:13 dovecot: imap-login: Aborted login (auth failed, 1 attempts in 9 secs): user=x ... Jul 2 13:26:37 dovecot: imap-login: Aborted login (auth failed, 1 attempts in 5 secs): user=x ... Jul 2 13:26:43 dovecot: imap-login: Aborted login (auth failed, 1 attempts in 5 secs): user=x ... Jul 2 13:27:08 dovecot: imap-login: Aborted login (auth failed, 1 attempts in 5 secs): user=x ... Jul 2 13:27:14 dovecot: imap-login: Aborted login (auth failed, 1 attempts in 5 secs): user=x ... Jul 2 13:27:30 dovecot: imap-login: Aborted login (auth failed, 1 attempts in 5 secs): user=x ... Jul 2 13:27:36 dovecot: imap-login: Aborted login (auth failed, 1 attempts in 5 secs): user=x ... Jul 2 13:27:51 dovecot: imap-login: Aborted login (auth failed, 1 attempts in 5 secs): user=x ... Brute force attempts are more intense, so I think these rules can be set harder to not risk plunking your users into blacklist hell. Also, some common role account (that don't exist on my system e.g. admin) will trigger an immediate blacklist here -- an easy way to shortcut the process. I feel your pain and frustration. I do not believe there is an RBL list of offending IP's for brute force attacks ... Maybe http://www.blocklist.de/en/index.html I use it for ssh BFD blocking, and it detects 2/3 of the IPs trying to do attempts. On their web page, they also list FTP, Web, and Mail login brute forcers, although I'm not sure whether Mail logins means IMAP, POP, SMTP-AUTH, or all of them. You can also integrate this with fail2ban so that not only can you use it to block, but can also contribute to the global detection of brute forcers. Joseph Tam jtam.h...@gmail.com
Re: [Dovecot] dnsbl feature for dovecot
On 7/3/2013 2:30 PM, Joseph Tam wrote: Brute force attempts are more intense, so I think these rules can be set harder to not risk plunking your users into blacklist hell. Also, some common role account (that don't exist on my system e.g. admin) will trigger an immediate blacklist here -- an easy way to shortcut the process. Certainly, set the rules to whatever works for your system. My example is just what I used and it worked well for me. Your example is why I specified that an attempt to login as a blocked account does *not* extend the blocking time. Otherwise, you run the risk of a rolling block that goes on forever. Why are users on your system entering bad passwords all the time? Every major mail client can save passwords in a reasonably secure format so the feeble minded human is free of that burden. Even with webmail, the browser generally can save passwords. In fact, I feel this is safer. It eliminates keystroke loggers from getting the password. It also makes it easier to enforce strong passwords. If the user had to type in a 16 character strong password each time (such as HjY6##k,F8Dl9sy1), many of them would certainly complain loudly and often. However, if the user can enter that password once into their chosen software and not have to remember it again, you get good protection from brute force attacks and happy users. Typing a password once is much easier than even typing cat 50,000 times over the course of several years. Dem
Re: [Dovecot] flat file in tmpfs for dict quota
On 7/2/2013 8:48 AM, Steffen Kaiser wrote: On Thu, 27 Jun 2013, Ken A wrote: I'm using dict quota like so: quota = dict:User quota::file:/[path]/quotas/%u [path]/quotas/ is a tmpfs. The idea is to do less work on disk. Other than forcing dovecot to rebuild quotas on a reboot, are there any downsides? I would say no, but to recalc the quota file might be more difficult that you think, make sure no logins or deliveries or automatic scripts change the content of the mail storage. The quota files are per mailbox, and are created when the user logs in or LDA touches a mailbox. Most mailboxes are 1GB. Dovecot seems to handle it very quickly. Thanks, Ken Anderson Regards, -- Steffen Kaiser -- Ken Anderson Pacific Internet - http://www.pacific.net
Re: [Dovecot] flat file in tmpfs for dict quota
On 27.6.2013, at 19.44, Ken A k...@pacific.net wrote: I'm using dict quota like so: quota = dict:User quota::file:/[path]/quotas/%u [path]/quotas/ is a tmpfs. The idea is to do less work on disk. There are no fsync() or fdatasync() calls to quota files. Ideally if the system had enough memory and the disk IO wasn't used up all the time, it wouldn't waste any time on unnecessary disk writes. Now, whether the current OSes worked that way I don't really know.. I think there are quite a lot of settings for that though. Placing quota files (and maybe indexes) on a different mount point would allow changing such settings.
[Dovecot] CaCert certificate configuration help needed
I was not able to find specific help for configuring the crt file for CaCert. I gleaned from examples the following order: server certificate CaCert class 3 certificate Cacert root certificate However, when I try to configure my mail reading for IMAP, Dovecot shows the following error in the log: dovecot: imap-login: Aborted login (no auth attempts): I am assuming, based on searches for this error, that my crt file is not correct but I don't know what to do at this point. Can someone steer me in the right direction? TIA. -- View this message in context: http://dovecot.2317879.n4.nabble.com/CaCert-certificate-configuration-help-needed-tp43118.html Sent from the Dovecot mailing list archive at Nabble.com.
