Re: IP drop list
On 3/4/2015 12:45 PM, Dave McGuire wrote: There is. But I already have a firewall, running on bulletproof hardware that doesn't depend on spinning disks. I don't want to add ANOTHER firewall when I already have a perfectly good one. Besides, my mail server is built for...serving mail. Not being a firewall. You can implement whatever type of security you are comfortable with, however, best practices is to have layered security, also known as the belt and suspenders method of keeping your pants up. A perimeter firewall and local firewalls (iptables usually) on each machine is the minimum level of security I set up. A perimeter firewall alone does not protect you from an attacker who is able to compromise one machine and install a scanner which then scan all the systems on your internal network looking for exploitable weaknesses. All the while the perimeter firewall is oblivious to the attack going on internally and utterly incapable of mitigating it even if it were aware. Dem
Re: Authenticating Virtual Users without domain
On 12/30/2014 6:49 PM, Leon Kyneur wrote:
Hi,
I'm trying to migrate a large number of users to a new Dovecot
cluster. The existing mail system allows a user to authenticate with a
bare username if they have connected to the correct local IP on the
server.
e.g.
imap.somedomain.com = 1.1.1.1
imap.anotheromain.com = 2.2.2.2
charlie@somedomain can authnenticate as 'charlie' or
'char...@somedomain.com' as long as he is connected to
imap.somedomain.com (1.1.1.1)
likewise for bare usernames if they connect to imap.anotherdomain.com.
A previous colleague actually achieved this by hacking with the
Dovecot source code and writing in a lookup table feature. The code is
very old and won't patch cleanly to the latest 2.2.15 source. Another
platform we are using (commercial product) also has this feature but
we also need to migrate these users to Dovecot.
I already have a Dovecot proxy layer for mailbox lookup - so ideally I
would like to do this on my Dovecot proxies.
I know I can also do this kind of thing if I swapped my dovecot proxy
for Perdition, however I don't really want to do that.
I've looked into checkpassword scripts and could possibly make
something work (albeit ugly) - is this the right direction to take
here?
Using SQL as the user database, set up a table for the mail users. The
following example uses the table named mail_users with the following
fields:
user_name = part left of @ in email address (EX: joe)
user_domain = part right of @ in email address( EX: mydomain.com)
domain_ip = the IP they connect to for their domain (EX: 1.1.1.1)
password = hashed password
home = full path to user's home directory
uid = user's uid
gid = user's gid
In dovecot-sql.conf.ext: (line breaks and indenting are added to improve
readability but your statement should be all one line in the
dovecot-sql.conf.ext file)
password_query =
SELECT
CONCAT(user_name, '@', user_domain) AS user,
password,
home AS userdb_home,
CONCAT('maildir:', home) AS userdb_mail,
uid AS userdb_uid,
gid AS userdb_gid
FROM mail_users
WHERE user_name = '%Lu'
AND domain_ip = '%l'
NOTE: %Lu is used on purpose, rather than %Ln. %Lu will fail the lookup
if the user provides a full email address, and this is deliberate. If
you also want to allow the user to connect to *any* IP with their full
email address as their login, use:
password_query =
SELECT
CONCAT(user_name, '@', user_domain) AS user,
password,
home AS userdb_home,
CONCAT('maildir:', home) AS userdb_mail,
uid AS userdb_uid,
gid AS userdb_gid
FROM mail_users
WHERE ( user_name = '%Lu' AND domain_ip = '%l' )
OR ( user_name = '%Ln' AND user_domain = '%Ld' )
With this query, the user can log in as joe by connecting to their
domain's specific IP, or they can log in as j...@mydomain.com by
connecting to any IP the server is listening on.
This is just a simple example to get started. You will probably want to
expand this by adding fields to specify if the account is active and so
on. Also, you can put the domain to local IP mapping in another table
and use a JOIN in your SELECT query, so you can eliminate the
domain_ip field from the mail_users table. This is an exercise left
to the reader. The mail_users table should have a primary index on
the combined user_name and user_domain fields, which should be unique.
In your dovecot-sql.conf.ext file, you will need to create a
user_query statement similar to your finalized password_query
statement, as well as an appropriate iterate_query statement. See the
Dovecot documentation.
Cheers.
Dem
Re: Request to list owner
On 10/14/2014 1:28 AM, Jorge Bastos wrote: Also the [Dovecot] on the subject would be handy. The list used to do this. I agree with you, and the matter was debated, but the list is not a democracy and Timo, as the owner, changed the list unilaterally. The problem is that changing the subject conflicts with DKIM. DKIM is a broken standard for several reasons; it does not have allowances for mailing lists to add their name to the subject - a very common and useful practice - and these days spam filters do a far superior job than DKIM, making it too little, too late. I do not use DKIM and get no spam. That last spam I got was about 4 months ago, then another 2 months before that. 2 spams over the course of 6 months is pretty good, and that is without DKIM. Depending on your mail client, you can set up a filter that detects the mailing-list headers and adds the name back to the subject line. I do something similar and it adds back the lost functionality. :-) Best of luck. Dem
Re: Subject tag [Dovecot] is gone
On 6/11/2014 1:51 AM, Frerich Raabe wrote: On 2014-06-10 17:23, Koenraad Lelong wrote: op 10-06-14 17:12, Reindl Harald schreef: than you have crap software somewhere on your side What did I do to get such reply ? Don't bother paying too much attention, Harald has been quite the primadonna ever since I joined this list. Pretty sure he's one of those fellows who are doing the 'grumpy curmudgeon' on the Internet but then turn out to be rather quiet/shy guys in real life. ;-) If he bothers you, a suggestion to make your life simpler. Set up a filter to simply delete any messages from him before they get to your inbox. Notice that most regulars, myself included, never reply to him. That is because we do not even see his messages except in someone else's reply to him. It really improves the quality, value and enjoyment of the list. Life is too short to put up with someone who is abrasive, obnoxious and rarely contributes anything helpful. Dem
Re: Subject tag [Dovecot] is gone
On 6/9/2014 7:26 PM, Timo Sirainen wrote: The main reason is DKIM, which is starting to be a real problem. I have not used DKIM much. My mail server and client mostly deal with SPF. I have a filter that colorizes messages that have no SPF or a missing DKIM or bad DKIM signature. I *have* noticed that a lot of messages from the list get marked in such manner, but it never really bothered me and I never thought about it much. Now I understand why that happens (the [Dovecot] identifier in the subject). When trying to solve a problem, the first thing is to correctly identify the problem. You cannot solve a problem if you do not even know what it is. The underlying problem is to identify and classify emails as ones you want and ones you do not want. This is not easy and involves reading a person's mind. A person may, depending on their mood, classify the same email differently at different times, which complicates things. DKIM assumes that you can, in many cases, classify emails this way based on authenticating the *domain* of the sender. This has some serious flaws in that it does not address this issue, even though it purports to. One way to classify an email as wanted is if it comes from someone you know and want to communicate with. Signing based on a domain does nothing to address this. If my girlfriend is j...@yahoo.com, I want to receive her emails. That does not means I want to receive all emails from the yahoo.com domain. I do not want someone else to impersonate her. If later, we break up and I no longer want to receive her emails, DKIM does nothing to help with that, either. That could be OK if such functionality is beyond its scope. DKIM erroneously bundles sender authentication with message validation. I want to know that it really was j...@yahoo.com that sent me the message and not someone trying to impersonate her. However, as a separate function, I would like to know that the message I received is not the one she sent. These functions should not be integrated. As it is now, if the signature does not verify, I do not know why. Was the sender spoofed? Was some part of the message modified in some way? And just for the record, I believe that the subject line should conceptually be treated as part of the message, along with the date. DKIM is too strict. If I want to present a legal document (email) in court, I may want to prove that the document I present to the court is exactly as it was when it was sent to me. However, this is not a common occurrence. The real world is messy and imperfect and often, changes to emails are innocuous and legitimate. Mailing lists are an example of this. A mailing list or anti-virus scanner *should* be able to add a footer or add a mailing list identifier to the subject line, as long as those changes can be marked as later additions that the original sender is not accountable for. An email program should make it clear to the recipient which parts are not accountable to the original sender. I am not proposing a new standard, simply pointing out that breaking an established protocol (by removing the [Dovecot] subject identifier) because of a flawed anti-spam system is not in people's best interest. Can a spammer spoof messages from the list? Sure. Has it happened? Not that I am aware of. Is it a problem? Not so far. So why, then, make people go through all this trouble of setting up new filters and rules, mail routing, software upgrades, etc, just to appease a standard that is clearly broken? Dem
Re: [Dovecot] Slackware 14 config
Sorry just seen my typo I meant ports 143 and 993. Irrelevant. Take a step back and think about it logically. The error messages did not say that you could not connect to these ports. In fact, it seems you can, so clearly, this is not your problem. A netstat -nat will show if something is listening on these ports. doveadm(root): Error: Timeout waiting for handshake from auth server. my pid=8881, input bytes=0 doveadm(root): Fatal: Couldn't connect to auth socket This is what you should be looking into - Timeout waiting for handshake from auth server The second message cannot connect ... is the generic error if the entire connect fails. However, the primary error is the timeout error. That is the key. It is not getting a response from the other end of the socket. What is supposed to be connecting to the other end? Are you using SASL or something else to do authentication? What does lsof | grep auth-userdb show? Two things should have that file open. If not, there is your problem. A pipe, named or otherwise, is like a chatroom. It is very lonely when you are the only one. Standard problem solving techniques. All the information you need is right in front of you. Dem
Re: [Dovecot] dovecot perl sasl ejabberd
On 11/19/2013 8:48 PM, Костырев Александр Алексеевич wrote:
Good day to all!
We would like to authenticate our ejabberd against Dovecot with perl
there's such a script
http://www.ejabberd.im/files/contributions/check_dovecot.pl.txt
that script uses following perl library -
http://cpansearch.perl.org/src/SASHA/Authen-SASL-Authd-0.04/lib/Authen/SASL/Authd.pm
Authentication is OK, but sub user_dovecot wich queues information about a
specific user doesn't work with error
dovecot: auth: Error: BUG: Authentication client sent unknown handshake
command: USER?1?use...@atlas-2.ru
could someone help with this ?
thanks in advance!
I started to look through the script to find the problem, however, it
quickly became obvious that whoever wrote it knew very little about
programming Perl or security.
Do not use this script. It is only one page long and yet contains so
many problems, bugs and security holes, that it would take much more
than that to describe. It is easier just to write it correctly from
scratch.
- First, it does not have the warning flag turned on, which would have
caught a lot of problems.
- Second, it is used for data coming in over the Internet, and yet it
does not run in taint mode. This allows a lot of programming mistakes
to slip by and hackers can exploit this fact.
- Third, the section that supposedly filters dangerous characters, does
not. Best security practice says that you allow a safe set of
characters and discard the rest, *not* the other way around (discarding
just the dangerous characters, keeping the rest). What if the
localized character set has a quote character that the shell recognizes,
but is not in your list of banned characters?
Also, it is much easier to comprehend and visualize a list of characters
that are allowed, versus trying to figure out which ones aren't by
elimination. Do you have the entire set of localized characters
memorized and can you mentally figure which of them are left after
removing a specific few? What happens in a different localization?
- Fourth, clearly the author of this knows C, but does not know Perl.
Perl has no switch statement. The simulated switch statement in this
script is just a named block with a series of commands that have gotos
escaping the block (the last statement). This is confusing and hides
sneaky bugs.
For instance, each command is really of the form:
$op eq 'xyz' and do { ... }, last SWITCH;
This is a compound statement, which often has hidden, unintended side
effects.
How will this be evaluated; in scalar context or list context? What are
the side effects of each? What is the operator precedence of the and
compared to the comma operator at the end? Why should you even need to
worry about such things? They just lead to hard-to-find programming bugs.
This statement hides an if statement as a fake switch statement. Just
use a real if / elsif / elsif / else construct. Perl knows how to
optimize such things and a genuine if / elsif cascade will execute
faster than this simulated switch statement and be less confusing to
understand.
- Fifth, the variable $result is set to the barewords true or false.
1) Barewords are bad and would have generated errors if the warnings
flag was on, which it should have been.
2) In Perl, these are not keywords. As such, they are treated as normal
strings, so in both cases you are setting the variable to a string of
either true or false, both of which are true when evaluated in
boolean context. At the end, when setting the $out variable, YOU ALWAYS
RETURN TRUE!!! regardless of whether the user authenticated correctly or
not.
This just scratches the surface and there are a lot more problems:
cuddled elses, not checking return values, not trapping errors, using
negative conditionals, confusing and ambiguous use of the ternary
operator, etc.
Do not use this script. That is, unless you are setting up a hacking
contest and inviting people to hack your system, in which case, go right
ahead.
For more information, get a copy of the book Perl Best Practices.
Cheers.
Dem
Re: [Dovecot] Bizarre permissions problem
On 8/29/2013 2:17 PM, Bill Oliver wrote: Help! The user is newuser and the uid is (actual name and number changed to protect the innocent). Since you gave a fake UID, and no GID it is hard to tell. When posting, you can change the username, but leave the UID as is. If that number is so critically sensitive, then you should probably not ask your question in a public forum and instead seek assistance via more private communications. Special UIDs- Is the actual UID below a threshold so that the system thinks it is a system or admin user, subject to different restrictions? These thresholds vary, but 1000, 500 and 100 are common. SELinux- Are you running the SELinux extensions which would impose additional restrictions? ACLs- Do you have ACLs (filesystem or Dovecot) that would affect this user differently? Groups- You stated that the user is a Roundcube admin. Is the user in the same group as the rest of your normal mail users or a special group for the Roundcube functions? Do you need to manually add the user to the group for regular mail users? What are the group settings on your directories? Could it be the group permissions that is giving access to most users? Dem
Re: [Dovecot] Wrong remote IP (rip) in mail.log using IMAP login
On 8/1/2013 8:41 PM, pvsuja wrote: Hi, I am also facing the same problem. When dovecot is accessed through a web mail, the rip is logged as 127.0.0.1 (localhost). /Aug 1 16:28:04 mailspace dovecot: imap-login: Aborted login (auth failed, 1 attempts in 2 secs): user=suja, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, TLS, session=XllGt+DiPQB/AAAB/ So I am also unable to configure fail2ban with dovecot. Is there a way we can log the actual remote IP ? Dovecot has no way of determining the remote IP when a proxy is the system making the connection, which is what is happening. Your webmail is the proxy in this case. Have fail2ban scan your web server logs, not the mail logs. Dem
Re: [Dovecot] trying to configre dovecot
On 7/14/2013 9:03 PM, Gene Heskett wrote: Hi all; Thinking I'd like to have a bit of security, I followed the example for dovecot from allgoodthings.org Guessing between the lines I made a few substitutions to localize it for me, but when I run the line to dump the configs, the output is very short because I do not have the *.pem files. Where can a usable set of these ssl 'keyfiles' be obtained? $ openssl genrsa -out server.key 2048 $ openssl req -sha256 -new -key server.key -out server.csr $ openssl x509 -req -days 3650 -in server.csr -signkey server.key -out server.crt $ cat server.key server.crt server.pem Run the four commands. You will have a key file, certificate signing request file, a self signed cert and a pem file which is the concatenation of the key and cert (some systems need this, and some are ok with the key and cert being separate). This is everything you will need to get the server working with SSL or TLS. The third command generates a self signed certificate. If you are playing around or this is for internal / personal use, this is ok, but if you want real security, you need to have your cert signed by a real certificate authority (CA). If you are going to do this, the way you answer the questions in step two is important. You should do some research into the requirements of your chosen CA, but for example, the question about the state usually must be answered with the full state name, properly capitalized, and not an abbreviation. Example: Florida is correct, FL is not. If any doubts, contact your CA first before generating your csr. Dem
Re: [Dovecot] SSL cert problem
On 7/11/2013 11:47 AM, Peter von Nostrand wrote: Hi, I'm running a new dovecot 2.0.9 under Centos 6.4. I'm having an issue with SSL certificate not being accepted by the email client. I have my own CA and I have generated certificates for web usage without a problem. For imaps and pop3s what I did was generate a certificate for the hostname of my dovecot server and then cat that cert with the intermediate and root CA certificates. No matter what thunderbird still complains with Unknown identity. If you have access to a Unix / Linux system, you can use openssl with the s_client command to connect to your mail server, much as you would have done with telnet in the old days. openssl shows all of the key exchange in detail and should be more than enough for you to be able to debug your problem. Compare fingerprints of the keys you have stored with those being sent to/from the server. Example: openssl s_client -connect mail.mydomain.com:995 Dem
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] 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] dnsbl feature for dovecot
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. Dem
Re: [Dovecot] dnsbl feature for dovecot
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
Re: [Dovecot] Problems with Apple Mail: Enter Password for Account ...
On 5/22/2013 7:44 AM, Frank Röhm wrote: Hello I have on Ubuntu 12.04 a postfix 2.9.3-2 mailserver with dovecot 2.0.19 I get email from my pc (thunderbird), my smartphone (k9mail) and my MacBook (Apple Mail 4.6 - 1085 on Mac OS 10.6.8) all with IMAP and SSL. All is working normally but sometimes I get an error message from my MacBook, which is irritating. It says this (more or less): Enter Password for Account ... The IMAP-Server ... rejected the password for user ... Enter your password again or cancel. ... o Remember this password in my keychain The password was NOT wrong, but anyway, if reenter it, Apple Mail won't accept it, the message will come again and again. This is one of my pet peeves about Apple Mail and to some extent, outlook. If *any* error occurs during the authentication phase, Apple Mail, usually mistakenly, displays the error about bad login credentials. These errors may include such things as network problems, DNS issues, local mailstore errors or corruption, issues with the mail server not related to authentication, such as file locks, etc. Besides being annoying, and misleading, Apple Mail will invalidate your saved password, requiring you to enter it again. If you have chosen a strong password, you may not remember it, which can be a real pain in the tuchus. First look in your logs (Finder Applications/Utilities Console) to see if there are any errors. Second, if you can and it does not create a security problem for you, temporarily use a non-SSL connection for mail and a network sniffer like Wireshark to watch the transaction. Right click on a packet and select Follow TCP Stream, which is particularly useful to see the interaction and any errors that may occur during the interaction between Mail and the server. The above also applies to similar problems with outlook. Wireshark also runs on windows, although mail error logging is not quite as good on windows. Dem
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 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] Any way to let dovecot block pop3 attempts?
On 5/10/2013 6:17 AM, Steve Campbell wrote: But I believe fail2ban uses iptables, and I don't run a local firewall on the server. I'd prefer not to use a separate server to inject firewall rules on the border firewall. I might be wrong about fail2ban, though. I was hoping there was a file for pop and imap in dovecot similar to the smtp access file in sendmail (which is what I use, BTW) I run both - a border firewall and iptables on individual systems. The border firewall allows or denies traffic to specific systems; for instance, web traffic can go to web servers, but web traffic destined for mail servers is dropped. Local servers also have basic rules like this (mail servers drop all web traffic), but they also have more specific rules, such as the fail2ban abuse detection rules. This is called the belt and suspenders approach to security, and is a good idea. With your current method, if a hacker gains access to one system, they can launch attacks at other systems on the same network which they would not be able to do from outside the network. Belt and suspends mitigates much of that. Just having local iptables, but no border firewall means that a hacker that gains access to a system can disable iptables and use the system to launch attacks at other systems, use the system as a malware repository that is accessed on non-standard ports, etc. Belt and suspenders mitigates this also. If you are able, you should consider running iptables locally on each system. This would then let you run fail2ban, also. FWIW, I also run an invisible IDS at the border and local IDS's that are not so invisible, but that is beyond the scope of your comment. Dem
Re: [Dovecot] Idea: POP3 deletion as a flag
On 5/5/2013 11:20 AM, Oscar del Rio wrote: On 03/05/2013 12:14 PM, Timo Sirainen wrote: GMail doesn't delete mails when POP3 client issues a DELE command for it. Instead they just become invisible for future POP3 sessions, but they still exist for IMAP/webmail. The same could be implemented pretty easily for Dovecot: - Add a new setting to enable this: pop3_deleted_flag = $POP3Deleted - When DELEting a message, add this flag to the message. - When listing messages, skip all messages that have this flag. - Also hide this flag from IMAP clients(?) Thoughts? Probably 20 lines of new code. Outlook live.com webmail has a special (virtual) folder called Deleted/POP and the following option: If you use POP to download Outlook messages to another program, that program could make it so you can't read your messages on Outlook. (For example, this might happen if you use Mac Mail or Mozilla Thunderbird.) - Don't let another program delete messages from Outlook. (If your other program is set to delete messages from the server, we'll simply move them to a special POP folder. They won't be deleted.) - Do what my other program says—if it says to delete messages, then delete them. This is fine. The user is informed and makes a choice about the behavior of the server. The problem I have with the proposed changes by Timo is that the user is *not* informed and has no choice. The user may expect that the server behaves in a standard manner, but it may not, based on decisions of the system admin. The user has no way of knowing this behavior - only the system admin knows. Dem
Re: [Dovecot] Idea: POP3 deletion as a flag
On 5/3/2013 7:38 PM, Noel Butler wrote: Incidentally, the last time I read the pop3 RFC, admittedly some decade or so ago (and yeah it's likely been updated since?) I can not recall there ever being a MUST or SHOULD when it comes to deleting messages (it might have been deliberately omitted) apart from the server MUST NOT delete messages that are not marked for deletion. FYI: In addition to the significant privacy and legal concerns, adding and enabling this option makes the server non-compliant. The section under The UPDATE State is clear about the behavior of the server: The POP3 server removes all messages marked as deleted from the maildrop Also note that I am only referring to the public version of the server. Whatever Timo wants to do for a special version for his client is up to him. It is he and his client who are legally responsible for their actions. Similarly, if some third party wants to take the source and modify it for themselves to make it non-compliant, then that is their business. They are legally responsible for their actions and have to answer for those actions if they end up violating any laws. I do not feel that an option like this should be in the public version of the server, however, even if it is off by default. Dem RFC 1939 Post Office Protocol - Version 3 Under section 5 The TRANSACTION State, Pages 7-8. DELE msg Arguments: a message-number (required) which may NOT refer to a message marked as deleted Restrictions: may only be given in the TRANSACTION state Discussion: The POP3 server marks the message as deleted. Any future reference to the message-number associated with the message in a POP3 command generates an error. The POP3 server does not actually delete the message until the POP3 session enters the UPDATE state. Under section 6 The UPDATE State, Page 9. When the client issues the QUIT command from the TRANSACTION state, the POP3 session enters the UPDATE state. QUIT Arguments: none Restrictions: none Discussion: The POP3 server removes all messages marked as deleted from the maildrop and replies as to the status of this operation.
Re: [Dovecot] Idea: POP3 deletion as a flag
On 5/3/2013 11:36 AM, Timo Sirainen wrote: On 3.5.2013, at 19.55, Robert Schetterer r...@sys4.de wrote: Am 03.05.2013 18:14, schrieb Timo Sirainen: GMail doesn't delete mails when POP3 client issues a DELE command for it. Instead they just become invisible for future POP3 sessions, but they still exist for IMAP/webmail. The same could be implemented pretty easily for Dovecot: - Add a new setting to enable this: pop3_deleted_flag = $POP3Deleted - When DELEting a message, add this flag to the message. - When listing messages, skip all messages that have this flag. My vote, do it , if it doesnt break anything else, but a wiki help should be offered too. - Also hide this flag from IMAP clients(?) wouldnt do this, that may end in user confusion Just about zero IMAP clients make IMAP keywords visible to users, so I'm not really sure which way to go here. I'm more thinking of it as an internal POP3 state which doesn't really need to be visible to IMAP clients, but then again I guess it wouldn't really hurt either. Be careful about adding features just for the sake of adding features. Dovecot is already a powerful, but quite complex. This would make it even more complex and non-standard. POP and IMAP clients do not expect this behavior from the server. Also, I have never heard anyone request this feature. Google has already admitted that they do not delete email, even when those emails are deleted from the Trash. Google states that emails may be archived for a minimum of 2 months past when they are deleted - emails, may, however, be saved forever. You do not know. Google has lots of storage and their business is marketing, which means selling people's personal information. Google is large enough that they are under scrutiny and have to obey EU privacy laws. However, adding this feature to Dovecot could put smaller email operators in violation of those laws. Not deleting emails when the client says to, is effectively archiving, and data that is archived is regulated by EU privacy laws. Lots of legal problems have arisen as a result of this. http://arstechnica.com/tech-policy/2011/12/patriot-act-and-privacy-laws-take-a-bite-out-of-us-cloud-business/ http://uk.news.yahoo.com/eu-judges-hear-arguments-google-test-privacy-case-102608029--finance.html http://www.afterdawn.com/news/article.cfm/2012/03/02/google_in_breach_of_eu_privacy_laws_commissioner_says The problem is already solved by the POP client. Most have a setting that allow emails to remain on the server for a period of time. The default is generally 5 days, but can be set to any value desired. Apple Mail, Thunderbird and outlook all have this feature. Most smartphones also have this feature, including the iPhone, Blackberry and Android devices, and even though the settings are generally not easily accessible, it defaults to being turned on. So in conclusion, in my experience, this feature is not one that has been requested, it makes Dovecot more complex and behave in ways not expected by the client, and it may have privacy and legal problems. I would recommend not doing it. I think it would be better to concentrate on features that people ask for. As awful as exchange is, the reason people give me why they use it over a normal email solution is for the groupware features, which standard POP and IMAP email is still lacking. Dem
Re: [Dovecot] Idea: POP3 deletion as a flag
On 5/3/2013 3:44 PM, Timo Sirainen wrote: On 4.5.2013, at 1.27, Kelsey Cummings k...@corp.sonic.net wrote: On 2013-05-03 09:14, Timo Sirainen wrote: GMail doesn't delete mails when POP3 client issues a DELE command for it. Instead they just become invisible for future POP3 sessions, but they still exist for IMAP/webmail. The same could be implemented pretty easily for Dovecot: How does the usage case by your large customer differ from that allowed by the lazy_expunge plugin? I didn't ask what their main reason for this was, but for me it would be: Oops, I accidentally configured my new email client as POP3 instead of IMAP, and now it deleted everything from my INBOX. With lazy_expunge the user would have to explicitly go and undelete the mails, and it would also undelete those mails that were intentionally deleted. With this feature nothing at all would go wrong on IMAP/webmail side. I agree with AJAX. This seems to be a matter of convenience and features versus privacy rights. Do the desires of the mail handling organization outweigh the privacy needs of individuals. This is a long standing argument. I am glad that this was brought up. History is littered with inventions and creations that were designed for one purpose, but misused for another. It seems this mod was designed to deal with stupid users who are unable to set up their email correctly, and the IT departments who are too lazy to manage the situation properly. I think this attempt to make the software idiot proof will fail, however. There is a saying the goes something like You cannot make anything idiot proof because idiots are so ingenious. If someone is worried about end users setting up POP accidentally and deleting emails, then firewall ports 110 and 995. Simple solution. Problem solved with no inadvertent introduction of privacy and legal violations. What worries me, is that as an end user, I now have no idea if this feature is turned on or not. When I specify that an email be deleted from the server, I expect that it is *deleted*. I feel that a feature like this is ripe for abuse. Is there any way for the end user to know that this feature is turned on? What if a hacker got access to the server and changed the value of this setting? As pointed out by AJAX, POP3 comes with an expectation of privacy. There should be some way that the end user gets notified that his deleted POP emails are not actually deleted. If Timo wants to add these features to private copies of the software for specific organizations, that is a matter between him, his client and the law. However, I do not feel it belongs in the mainstream release. Dem
Re: [Dovecot] Feature request: Configure CONFIG_MODULE_DIR and AUTH_MODULE_DIR at runtime
If you start/stop dovecot with an initscript or some other related system, you can do what SuSE does, since this problem occurs in lots of situations, not just dovecot. Since you know where all the config files are, you could either have the initscript set up a directory with symlinks, as Timo said, or you could collect them together and place them all in one file that is in the correct location. Multiple config files for dovecot can be concatenated together if you are careful to scan for and accommodate include directives. Dem
Re: [Dovecot] Probs authenticating to Dovecot
Turn on the following directives: auth_verbose = yes auth_debug_passwords = yes Restart, then reconnect with your mail client. You should have much better logging to determine the source of the problem. Dem
Re: [Dovecot] How to manually generate a password hash
On 4/13/2013 7:10 PM, David Murphy wrote:
Hi folks. I've recently set up a Postfix 2.9.6/Dovecot 2.0.19 IMAPS/SMTPS setup
on Ubuntu 12.04.2 (Mysql backend). I'm new to all this, so I apologize if this
is fairly basic. I've attempted to the best of my ability to search for an
answer, but no luck so far.
What I'm trying to do is generate a password hash that I can inject directly
into my Mysql database (disaster recovery sort of situation). Towards that
goal, I'm trying to use 'doveadm pw' to generate a hash that matches a known
password in my database. Unfortunately, I'm coming up empty.
My default_pass_scheme in dovecot-sql.conf is set to MD5-CRYPT, and the
passwords in the database have no scheme prefixes. I'm attempting to generate a
hash with:
sudo doveadm pw -s 'MD5-CRYPT'
but the hash generated does not match the user's password hash in the database,
which is known to be a good password. I'm able to log into this account
successfully in both Roundcube and a remote IMAP client. I've also tried using
the -p flag and including the password in the command, and that doesn't do it
either, though it oddly gives a different response than using the prompt. (What
causes this? Newlines?)
So... what am I missing? If the hash was salted, it would seem the hashes in
the database would be longer than the ones generated at the command line, but
that isn't the case. I'm out of ideas. Any guidance appreciated.
-Dave
1) If your passwords are of the format $1$..., then they are in standard
crypt md5 format. They are salted. The salt is between the second and
third $ and the actual hash follows the third $.
2) The version of Dovecot you are running has several bugs in doveadm
pw that you might be encountering. This will prevent you from
verifying the hashes. Some of these have been fixed in the current release.
Try the following command. This should give you a verified response
on a patched version of doveadm. (NOTE this command is all on one line,
but may wrap in the email).
doveadm pw -s MD5-CRYPT -p abc123 -t '$1$85P5.CAv$tqx.O2iZwnIZjuMQ7fo6m1'
It should reply:
$1$85P5.CAv$tqx.O2iZwnIZjuMQ7fo6m1 (verified)
Or possibly (depending on the version of dovecot you run):
{MD5-CRYPT}$1$85P5.CAv$tqx.O2iZwnIZjuMQ7fo6m1 (verified)
If you do not get one of the above responses to the test, you should
upgrade, since your doveadm is broken.
To test your hashes, use the above command format substituting your
password after -p and your hash after -t. This is only if your hashes
begin with $1$..., however. If they do not, then they are not in crypt
md5 format and you will need to figure out what format they are.
Once again, however, you need to be running at least 2.1.17, I believe,
or maybe a recent release of 2.2 that has the doveadm patches.
Dem
Re: [Dovecot] How to manually generate a password hash
On 4/13/2013 7:10 PM, David Murphy wrote: Hi folks. I've recently set up a Postfix 2.9.6/Dovecot 2.0.19 IMAPS/SMTPS setup on Ubuntu 12.04.2 (Mysql backend). I'm new to all this, so I apologize if this is fairly basic. I've attempted to the best of my ability to search for an answer, but no luck so far. What I'm trying to do is generate a password hash that I can inject directly into my Mysql database (disaster recovery sort of situation). Towards that goal, I'm trying to use 'doveadm pw' to generate a hash that matches a known password in my database. Unfortunately, I'm coming up empty. My default_pass_scheme in dovecot-sql.conf is set to MD5-CRYPT, and the passwords in the database have no scheme prefixes. I'm attempting to generate a hash with: sudo doveadm pw -s 'MD5-CRYPT' but the hash generated does not match the user's password hash in the database, which is known to be a good password. I'm able to log into this account successfully in both Roundcube and a remote IMAP client. I've also tried using the -p flag and including the password in the command, and that doesn't do it either, though it oddly gives a different response than using the prompt. (What causes this? Newlines?) So... what am I missing? If the hash was salted, it would seem the hashes in the database would be longer than the ones generated at the command line, but that isn't the case. I'm out of ideas. Any guidance appreciated. -Dave Can you post one of your hashes? Dem
Re: [Dovecot] password encryption
On 4/5/2013 11:36 PM, Jim Pazarena wrote: I have just come to the realization that password encryption using the crypt function in linux, ONLY USES THE FIRST 8 CHARS. I have written routines using crypt allowing 16+ chars, and find that anything past 8 is ignored. Wow. Is there a way around this that can be used in dovecot, as well as encryption routines for an email front end? (not system users). It's the integration with dovecot which is the most important. Dovecot supports *many* password hashing algorithms. Switch to SHA512 if you want good security. Generally the system figures out what hash a password is stored in, so you can mix and match. Set a default and all new passwords plus whenever a user changes their password, will generate a hash in the new format. Dem
Re: [Dovecot] script to detect dictionary attacks
On 4/6/2013 2:13 PM, Max Pyziur wrote: On Sat, 6 Apr 2013, Reindl Harald wrote: if it is some ISP from a country far away - block it if it is the fivth attempt from this ISP - block the whole subnet if it is a major ISP of the country i live (asutria) - only absue mail to the ISP I understand the logic; I set a low threshold to label something being a threat for anything originating in China; the threshold is higher for things closer to home, since most of the traffic to the one server I control is from there. The problem with a non-automated system, such as manually blocking China, is that it does not easily and quickly adapt. Both of the following I have experienced: 1) Excessive spam and hacking from China. I blocked China. Then I got a client that did business in China and had a branch office there. Suddenly I cannot block login attempts from China. And the users complains loudly about the excessive reject rate of legitimate emails from Chinese customers due to the spam filters. Also, legitimate users in China pick weak passwords which get hacked. Convincing the customer to improve passwords, security, use a VPN for Chinese users to access email so I can block China again were unsuccessful. While this is a bit beyond the scope of this list, the underlying problem is that in many far east countries, hacking is not illegal and thus there is no fear of getting caught, since there is no punishment. The real solution is to change those laws and have those countries enforce the laws. Good luck with that, however. 2) I tried compiling a list of IPs used for hacking. As a test, I manually put them into the firewall to see if that stops anything. Results were that a single IP will attempt to brute force several hundred passwords, but then I never hear from that IP again, so the firewall block was pointless. However another, seemingly unrelated IP, takes up the brute force attack. Without an automated system, like fail2ban, I am just playing Whack-A-Mole and never actually manage to block any attempts. In a different scenario, I also see 1-2 attempts from each IP in a group of thousands of IPs. These IPs do have legitimate users within them, so I cannot block whole IP ranges. All these indicate that the brute force attacks are being implemented on zombie nets. I do not see a perfect solution, or even a good one. A mediocre solution is a combination of fail2ban (which I have implemented), and enforcing strong passwords. A feature that would be nice is if Dovecot could detect that X bad attempts for a given User ID happen in Y time, then that User ID is blocked (always gives back a bad authentication, even if the correct password is entered) for Z time. Also, Dovecot could slow down its reply, much like a tarpit. These would be configurable. For example, if 3 bad password attempts are received for u...@domain.com within 2 minutes, then the user is blocked for 10 minutes. That with strong passwords will make the system reasonably safe from zombie net attacks. Also, the tarpit feature would slow down the attacks and ease the bandwidth issue. I am very willing to work with anyone on a solution that works better than these methods. As I see it, in order for a blacklist to work, it has to be large and distributed, like the spam blacklists are. Dovecot would need to report to the blacklist cloud, any IPs that it detects are being used to launch attacks. This is a big undertaking. Dem
Re: [Dovecot] Question regarding Postfix and Dovecot
On 3/17/2013 3:20 AM, Daniel Reinhardt wrote: I really find the lack of error logging, and the virtual lack of documentation for Dovecot very disturbing. I am so close to dropping this side project of being able to support multiple domains on a mail server. It is in my utmost respectful opinion to have multiple files to edit just to get this working in basic mode. Why cant dovecot combine all configuration parameters into one config like that of postfix main.cf for server config, and the master.cf for sockets and listeners? If there are multiple files to be edited then the error logging should mention what file contains the log, and where so you can easily locate the issue. I find this software to be very lack luster and very difficult to use. Dovecot has given me nothing but headache and grief, and as far as I am concerned not a finished product. We are very sorry you are not satisfied with the software. Please feel free to return the software for a full refund of all the money you paid. If you do not like the multiple config files, you can always combine them. Documentation is online at http://www.dovecot.org/documentation.html Welcome to the world of open source. Software is provided through the generous contributions of many people, all of whom have regular jobs and do this because they enjoy it. With open source, if there is something you do not like, you can change the software to your liking. Try that with proprietary software. And just a friendly word of advice: change your attitude or you will find your cries fall on deaf ears. Dem
Re: [Dovecot] Question regarding Postfix and Dovecot
On 3/17/2013 3:10 PM, David Benfell wrote: I don't know if the [original poster] is fully familiar with the open source model or not, but I would save the rest of this response as a gem. The formulaic response, which I have seen again and again in the over ten years I've been working with open source software, really assumes that all users are programmers--or should be programmers--and are responsible for submitting fixes when something is wrong. Because what it really says is, if you don't like it, fix it yourself. Too many times, I've heard this referred to as freedom. And like some other notions of freedom advanced in our society, it is only freedom for a limited class of people. Imagine this: You live near a mechanic. He has an extra car that he got from the junk yard and fixed up. It works fairly well and you need a car so he generously gives it to you for free. After a time, something breaks. What do you do? If you are mechanically inclined you can fix it yourself - that is, if you are part of that limited class of people known as mechanics. If not, you can go back to the original mechanic or maybe a completely different mechanic. However, if you scream at him, call him names, tell him the car is total garbage that was never fixed right in the first place, then demand he fix it, how do you think he would respond? It is much better to ask politely. Everything you say above is perfectly valid. However, I have been part of quite a few open source projects and this list has much more than its share of trolls and flame wars. Why is that? A little civility goes a long way, especially if you are not part of the limited class of people and are asking for their help with something that you were given for free to begin with. Dem
Re: [Dovecot] Dovecot with sasl/imaps/postfix and thunderbird
I just verified that TB (17.0.4) won't do STARTTLS on TCP 143 without first accepting the self signed cert. I'm really hoping someone can help me to clarify more specifically what's going on here. You've already clarified it. You simply can't do account auto configuration with a self signed cert, at least not with a vanilla TB setup. The only possible solution I can think of would be to preload the user profile with the certificate. I don't know how you'd do this. I think you have some research ahead of you. You can. 1) Select Menu Tools Account Settings... 2) Below the left pane click the Account Actions button, then select Add Mail Account... 3) Fill in the first name and email address. Uncheck Remember password and leave the password field blank. Click the Continue button. 4) VERY QUICKLY!!! As soon as the next window opens, click the Manual Config button at the bottom. 5) Fill in the proper data. Under SSL select None and None. Under Authentication, select Normal Password for both fields. 6) Make sure the ports have real numbers, not Auto. For POP use 110, for IMAP use 143, for SMTP use 25. 7) The Done button should undim and be clickable. Click it. 8) You will get a red window warning about no encryption. Check the I understand ... box and click Done. 9) Select the account you just created in the left pane, then fix all the settings to use SSL, etc. Dem
Re: [Dovecot] doveadm password check
On 3/11/2013 12:20 PM, Thomas Pries wrote:
Hi,
I want to write some php code that users can change there dovecot
password via a roundcube plugin. I'm using php function crypt(...) to
generate the hashes and everything works well so far.
I'm using doveadm pw to generate testhashes e.g.:
srv:~ # doveadm pw -r 5 -s BLF-CRYPT -p abc
{BLF-CRYPT}$2a$05$W82/Vw4ZEcHBC00M8cNwe.g8fOHuAeV7L5Q/q4W6VWl9V5kjoiz8y
I expected an ok when using -t the hash when entering abc as a
password, but I got:
srv:~ # doveadm pw -r 5 -s BLF-CRYPT -t
\{BLF-CRYPT}$2a$05$W82/Vw4ZEcHBC00M8cNwe.g8fOHuAeV7L5Q/q4W6VWl9V5kjoiz8y
Enter password to verify:
doveadm(root): Fatal: reverse password verification check failed:
Password mismatch
There are several bugs dealing with what you are doing. They are
currently in the works and will be fixed in a future release of Dovecot.
1) Crypt hashes should not have the {...} prefix. The $2a$ is the
prefix that specifies the Eksblowfish crypt hash, just like $1$
specifies the MD5 crypt hash. doveadm blindly puts the {...} in front
of all hashes, which is a bug. When the program goes to verify the
hash, it passes the entire string including the {...} part to crypt,
which fails, since it does not know what to do with it.
2) The Eksblowfish hash (the $2a$) was originally written on OpenBSD by
Niels Provos and David Mazières and was called Bcrypt (Bcrypt is the
correct name, not BLF-CRYPT as is used in Dovecot). It was rewritten by
Alexander Peslyak. This rewritten version became more popular with
Linux distros. This version, however, turned out to have a bug, which
Peslyak later fixed, but it means that $2a$ hashes were incompatible
based on which library they used: the original OpenBSD, or the buggy
Peslyak one. A new hash type, $2y was used to specify the correct hash.
Even OpenBSD switched to the new system to maintain compatibility,
even though their original libraries were correct.
Depending on whether your Eksblowfish (Bcrypt) libraries have been
updated or not, there could be a problem with the $2a$ hash.
First try to remove the {BLF-CRYPT} from your hash. It is not needed,
and may be enough for it to verify. If it still does not verify, then
you may have an issue with your crypt libraries. You might, then try
changing the $2a$ to $2y$ and see if that makes the Eksblowfish
libraries happy.
Dem
Re: [Dovecot] dovecot: imap-login: Aborted login (auth failed, 1 attempts in 2 secs): user=xxx, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, TLS, session=1pBG/03XogB/AAAB
On 3/8/2013 1:04 AM, pvsuja wrote: Yes, I know that. When I am telnetting to my ImapcProxy over 143, the capabilities are listed .. STARTTLS AUTH=PLAIN AUTH=LOGIN . I need the AUTH capability to be enabled only after STARTTLS I have done this in Postfix. Is there a way to do it in Dovecot? From the template /etc/dovecot/conf.d/10-auth.conf # Disable LOGIN command and all other plaintext authentications unless # SSL/TLS is used (LOGINDISABLED capability). Note that if the remote IP # matches the local IP (ie. you're connecting from the same computer), the # connection is considered secure and plaintext authentication is allowed. #disable_plaintext_auth = yes Dem
Re: [Dovecot] question regarding rw-access on mailbox on creation/login (dovecot 1.2.17)
On 3/6/2013 12:15 AM, Götz Reinicke - IT Koordinator wrote: Hi, currently I have one new user with a problem. When she logs in to dovecot with pop3 from her apple mail, dovecot tells problems with the +w permission. Error: open(/var/mail/**) failed: Permission denied (euid=3462(**) egid=548(dozenten) missing +w perm: /var/mail) /var/mail is rw by root.mail I cant see why just this particular user has that problem/gets that messages. AFAIK no one changed any default permissions on directories or set different users. What could be wrong? Any suggestions is welcome. Filesystem ACLs? Dem
Re: [Dovecot] Upgrading 1.2 to 2.x
On 3/5/2013 6:30 AM, Simon Brereton wrote: I'd prefer to have a semi-decent config to work from without having to research 100 new variable names and values. The migration tool exists for a reason. I just went through the same thing - converting from 1.2.10 to 2.1.15. Trust me, you are better off starting from scratch. Use the default template then modify it for your customizations. I thought the same thing as you, but in the end, trying to convert the old config file turned out to be much more work. Dem
Re: [Dovecot] Upgrading 1.2 to 2.x
On 3/5/2013 7:34 AM, Simon Brereton wrote: What's the recommended approach then? Pack it all into dovecot.conf as it was before, or use the split config files under conf.d/ - is this even a choice? Split configs are nicer and easier to work with and I am all for nicer and easier. Dem
Re: [Dovecot] Upgrading 1.2 to 2.x
On 3/5/2013 3:06 PM, Daniel Parthey wrote: We're using a single file too, since this can be easily managed by a configuration management system and avoids unexpected changes. Split files might get accidentally updated or added on package updates and change the behaviour of your whole mail system. This is a valid point, however, the same type of argument can be made for a single file. Updates, changes or bugs can corrupt your entire configuration all at once. With split files, you can set permissions so specific utilities or scripts can only access certain parts. There is better granularity that can be assigned to permissions. I am basing most of this on my experience of RedHat vs. the SuSE configuration for Apache. The split files of SuSE were always easier to manage and had less problems. And when there was a problem, I knew exactly where to go to look, and that file generally fit on one editor screen so I could see all the applicable directives all at once, instead of wading through a huge file, scrolling up and down, accidentally changing the wrong stanza, etc. Dem
Re: [Dovecot] help needed with dovecot authentication
On 2/28/2013 12:50 PM, peter lawrie wrote: Hi I have been asked to configure an dedicated rhel6 server for a customer. I did not realise when I took this on how complicated it was going to be! The purpose of the server is to host a group of websites for small businesses. It came with postfix-2.6.6-2.2 dovecot-2.0.9 and mysql-2.1.67-1 I have installed virtualmin 3.98, usermin1.540-1 and horde 5 About a dozen currently inactive websites have been set up, mail is in /home/domain/Maildir My problem is that I can telnet to postfix to send and receive emails and can see these within postfix in webmin I have been having many problems getting dovecot to connect successfully to postfix. I have also installed horde 5 which requires to authenticate to an imap server - that is dovecot. This one server is intended to provide all services, so plain authentication is fine. Do consider that since you have been tasked with setting up the server, you are responsible for doing it correctly. I see this configuration all the time and it is why so many servers get hacked. Only necessary services should be run in a single environment. The problem is that the more services that are run together, the more likely one will be found with a flaw, which then can be exploited to take down the whole server. It does no good to run Dovecot in a chroot jail when Apache has access to the whole filesystem. Best: separate hardware - one web server, one DNS server (if you need to run DNS), one mail server, on SQL server, etc. Good: some virtualizer, like Xen and run virtual instances of each of the above. OK: run all servers daemons carefully chroot jailed, with no common filesystem sharing. Interprocess communication can easily be accomplished via sockets. Bad: Run everything in a big soup. The traps is that for a small company, the belief is that no one want to target them. That may be true sort of, but opportunistic hackers will take any third party machine because it gives them anonymity when attacking other more valuable targets. Put a sniffer on your Internet connection and you will see an average of three attacks / scans / probes per minute. As Simon and Reindl have already covered some of your configuration questions, I will not repeat their answers. Best of luck. Dem
Re: [Dovecot] Disallow Deletion from Trash Folder
On 2/28/2013 12:40 PM, Bradley Rintoul wrote: Hello: I've been tasked with trying to find a way to keep users from ever permanently deleting emails. The users are running Thunderbird and are using the Archive option for when emails are deleted. However, they are still able to delete emails from the Archive folders... I'm wondering if there's any way that I can configure Dovecot to make sure that emails *never* get removed from the filesystem. I know it's probably kind of a bizarre request, but is there any way that Dovecot can help me out in this regard? In addition to the answer of locking the Archive folder, provided by Michael, consider that requests of this kind often are the result of a client or customer having a problem for which they came up with the proposed solution. I hope the machine has a lot of disk space. Depending on where the machine is, laws may require keeping emails for a certain period of time, keeping them then purging them after a period of time, etc. By asking the requester what problem they have that this solution is trying to solve, you can often get to the root of the problem and offer a solution that may work better. Forbidding archive deletion is going to require more work from the admin, because unless the admin is willing to regularly go through and manually delete old emails, eventually, the disk will fill up with all sorts of resulting problems. Also, consider how this may impact mail server behavior if any quotas are in effect. Could be a clash. Depending on what the original problem is, several solutions might be adding a dummy account and have all emails copied to it, on a separate drive (NFS, sshfs or dsync, maybe?) or using shared mailboxes. Cheers. Dem
Re: [Dovecot] Support for PolarSSL?
On 2/28/2013 4:09 PM, Reindl Harald wrote: Am 01.03.2013 01:02, schrieb Jerry: On Thu, 28 Feb 2013 23:26:43 + Ed W articulated: I believe the high profile user of polarssl is the Dutch government who have approved OpenVPN + PolarSSL for use. (The point being that openssl is just too huge to audit for security) Just because a program has a large footprint does not equate to it being a security risk. In fact, that might be one of the dumber statements I have heard in awhile. Unless you have proof of a specific and reproducible security exploit, your statement is pointless you did not understand the statement or refuse to understand what auditing means - a code audit is the seek for UNKNOWN implementation weakness and bugs - you can guess which is easier to audit: 1000 LOC, 1 LOC or 100 LOC. there are common known statistics of hidden errors in a defined count of codelines - the statistic remains always the same: having 3 times more code means mostly 3 times more of unknown bugs and NO this DOES NOT say anyhting about the quality of OpenSSL, these are only statistics and facts for audits not more and not less There are two statements, which apply here. They appear to be contradictory, but they are not. 1) You can never prove something is secure, only that it is insecure. Proving something is insecure is easy; find an insecure case. Q.E.D. Proving something is secure involves finding no cases that are insecure, but that could mean it is secure, or that it is not secure and you have not looked hard enough for the insecure case. This cannot be done in finite time and thus cannot be done in the real world. 2) Programs *can*, in fact be proven correct. There is a whole area of computer science dedicated to it, and has been for several decades now. The reason that these two statements are not contradictory is that the second one states you can prove a program correct; that given a set of parameters and criteria that it must meet, that the program meets these. However, secure can never be one of the criteria, since it is unprovable. Enough theoretical discussion. In the real world, most coders do not have the background to prove programs, thus it is generally not done. What is done, rather, is use good programming techniques and extensive testing. After that, it is subjected to attacks. The longer it resists the attacks, the more confidence is placed in its security. Both OpenSSL and PolarSSL can be proven correct (or not). This is not dependent on the size of the code. It is merely a function of mathematics and logic. However, OpenSSL has been in use much longer and has withstood more attacks. Confidence in it, then, is higher than for PolarSSL. If both were the same age and had the same number of attacks, then it would appear that the smaller code base would have less hiding places for bugs, but if both were proven correct by the same set of standards, then neither could be considered more secure than the other. In regards to the Dutch government, unless they have gone through the process of proving PolarSSL, which I suspect they have not, they are merely saying that due to sheer size, they suspect less bugs could be hiding in the smaller code base. I cannot say that I disagree with this method, but I do fault it. It is the wrong approach. Both code bases need to be proven before you can really do a comparison of which might have more security flaws. If both can be proven to the same set of criteria, then any flaws would be due to the underlying algorithms involved (MD5, SHA, Diffie-Hellman, etc) and would exist in both equally. Dem
