RE: Save user passwords in clear text
> Is it possible to save user passwords as clear text through dovecot? I am > currently using MD5 passwords and I allow only "plain and login” > mechanisms but I want to switch my database to clear text as this will > give me the ability to use more mechanisms such as CRAM-MD5. Is this > possible? I'm not sure if this is what you mean by saving passwords "through dovecot". But here's how to save a clear-text password when the passdb scheme is not plaintext. Use the {PLAIN} prefix. Example: 10-auth.conf: passdb { driver = passwd-file args = scheme=cram-md5 username_format=%n /path/passdb } /path/passdb: username:{PLAIN}secret User "username" can log in with password "secret" Michael
RE: Dovecot password policy
> A lot of “bots” try very simple passwords say less than X > characters; over and over and over again before they give up. > > I realize Dovecot mitigates this by slowing them down; but always nice to > have another optional layer of defense to clip this kind of garbage closer > to the door. Check out fail2ban. It's very useful for that sort of repeated bot attack. Michael
Save user passwords in clear text
Is it possible to save user passwords as clear text through dovecot? I am currently using MD5 passwords and I allow only "plain and login” mechanisms but I want to switch my database to clear text as this will give me the ability to use more mechanisms such as CRAM-MD5. Is this possible? Thank you
Re: Dovecot password policy
Robert Blayzorwrites: Is there a way to configure Dovecot to perhaps filter/enforce which passwords are accepted before authenticating? Ie: Reject immediately (without a database lookup) if password is not X characters in length? Yes, use the checkpassword hook. http://wiki.dovecot.org/AuthDatabase/CheckPassword I think there also some PAM module that you can stack into your system that will enforce password policies. Joseph Tam
Re: Dovecot password policy
> On August 5, 2016 at 9:10 PM Robert Blayzorwrote: > > > On Aug 5, 2016, at 12:12 PM, Aki Tuomi wrote: > > > > The response time will be same anyways. > > > > Anyways. It is better to enforce this kind of thing when users define the > > password than during login. > > > The idea would be to mitigate unnecessary database dips for password that > don’t clearly pass said password policy. Sure you can enforce what passwords > users use; but you can’t enforce what is being attempted to authenticate. A > lot of “bots” try very simple passwords say less than X characters; over and > over and over again before they give up. > > I realize Dovecot mitigates this by slowing them down; but always nice to > have another optional layer of defense to clip this kind of garbage closer to > the door. > > At the very least have a reject empty password option. > > -- > Robert > inoc.net!rblayzor > XMPP: rblayzor.AT.inoc.net > PGP Key: 78BEDCE1 @ pgp.mit.edu I would like to mention the new auth policy server support. It works with weakforced. See http://wiki2.dovecot.org/Authentication/Policy And https://github.com/PowerDNS/weakforced Correct usage should help you more than your plan, I promise. Aki
Re: Dovecot password policy
On Aug 5, 2016, at 12:12 PM, Aki Tuomiwrote: > > The response time will be same anyways. > > Anyways. It is better to enforce this kind of thing when users define the > password than during login. The idea would be to mitigate unnecessary database dips for password that don’t clearly pass said password policy. Sure you can enforce what passwords users use; but you can’t enforce what is being attempted to authenticate. A lot of “bots” try very simple passwords say less than X characters; over and over and over again before they give up. I realize Dovecot mitigates this by slowing them down; but always nice to have another optional layer of defense to clip this kind of garbage closer to the door. At the very least have a reject empty password option. -- Robert inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP Key: 78BEDCE1 @ pgp.mit.edu
Re: Dovecot password policy
> On August 5, 2016 at 6:47 PM "Michael A. Peters"> wrote: > > > On 08/05/2016 08:41 AM, Robert Blayzor wrote: > > Is there a way to configure Dovecot to perhaps filter/enforce which > > passwords are accepted before authenticating? > > > > Ie: Reject immediately (without a database lookup) if password is not X > > characters in length? > > > > ? > > > > Not sure what the benefit would be, other than helping automated bots > figure out your minimum password length based upon the response time. The response time will be same anyways. Anyways. It is better to enforce this kind of thing when users define the password than during login. Aki
Re: Dovecot password policy
On 08/05/2016 08:41 AM, Robert Blayzor wrote: Is there a way to configure Dovecot to perhaps filter/enforce which passwords are accepted before authenticating? Ie: Reject immediately (without a database lookup) if password is not X characters in length? ? Not sure what the benefit would be, other than helping automated bots figure out your minimum password length based upon the response time.
Re: Dovecot and Solr 6
On 7/7/2016 2:31 PM, KSB wrote: On 2016.07.06. 22:51, KSB wrote: Hi! Dovecot 2.2.24 Had set up solr and new schema collection. Copied dovecot provided schema. There was an error with booleans (while getting schema via http), which I "solved" by removing "add-unknown-fields-to-the-schema" from solrconfig.xml. It is correct way to solve this? Anyway, I run tcpdump to see network activity between dovecot and solr: #tcpdump -i lo port 8983 and see nothing while doing: #doveadm fts rescan -u usern...@domain.tld no output also from doveadm. Noticed that dovecot.index.log reapears in user mail root if deleted. plugin { fts = solr fts_solr = url=http://localhost:8983/solr/dovecot/ debug .. } -- KSB After some fiddling around, come in to conclusion that doveadm fts rescan is nothing to do about real indexing. So, it is working. Anyway, now thinking about what really differs when fts is used vs not used. 1 argument is speed, what else? -- KSB "doveadm fts rescan" resets pointers but does not itself trigger a re-index. But it makes the next actual index scan the full mailbox. The whole point of FTS is "full-text-search". So if you don't use it - you don't need it. But when large mailboxes are involved, searches involving solr indexes are extremely fast compared to non-fts searches. -- Daniel
Dovecot password policy
Is there a way to configure Dovecot to perhaps filter/enforce which passwords are accepted before authenticating? Ie: Reject immediately (without a database lookup) if password is not X characters in length? ? -- Robert inoc.net!rblayzor XMPP: rblayzor.AT.inoc.net PGP Key: 78BEDCE1 @ pgp.mit.edu
Re: Problem with sieve configuration on dovecot+debian_jessie+ISPC3
Thunderbird shows this message as only a picture. Had to view the source to read it. I'm new-ish to dovecot and sieve (haven't used it extensively till now) and I'm not sure that I configured everything propperly. The problem is that we're trying to get the following sieve code to run: [...] But we're constantly getting the following error: sieve: info: started log at Aug 02 08:13:21. main script: line 5: error: require command: unknown Sieve capability `duplicate'. main script: line 6: error: unknown test 'duplicate' (only reported once at first occurence). main script: error: validation failed. Both me and my collegue can't find what's wrong with the system. I would appreciate any kind of help on this matter. Below's my configuration. # dovecot --version 2.2.13 That version is very old. I am not sure which Pigeonhole version Debian used with that. The standard "duplicate" extension was introduced around that time. It could be that it is still called "vnd.dovecot.duplicate" at your end. So, try `require "vnd.dovecot.duplicate";' instead of `require "duplicate";'. Regards, Stephan.
Re: Problem with sieve configuration on dovecot+debian_jessie+ISPC3
Well that's not a problem with the mailing list. The problem is that I'm trying to do a forwarding system between 6 emails that all have to receive each other's emails but without the duplicates. So we have emails: A, B, C, D, E, and F; And whenever someone sends an email to A; B, C, D, E, and F should receive the emails. But B automatically forwards everything to A again, and to everyone else, etc. ad infinitum. So I get a loop. I'm trying to fix that all duplicates aren't forwarded to anyone else. So that people can put B, C, and E into the CC without getting duplicates. Thanks in advance. PS: Those were the experimental rules on the system, not this email. On 5 August 2016 at 11:05, Benny Pedersenwrote: > On 2016-08-02 10:25, Filip Loncar [WarpMax | FederationServers] wrote: > > require "duplicate"; >>if duplicate :header "message-id" { >> discard; >>} >> > > this sieve rule will discard your own postings on maillists when you get > them back > > bummer > > This e-mail, including all attached files, if any, is confidential and >> > > this is a public maillist, no need to make a policy on that > > please cut it down or remove it when you post to maillists >
Re: New password hashing scheme as plugin
2016-08-05 10:59 GMT+02:00 Aki Tuomi: > > > On 02.08.2016 00:46, Andreas Meyer wrote: > > 2016-08-01 15:58 GMT+02:00 : > > > >>> On August 1, 2016 at 4:38 PM aki.tu...@dovecot.fi wrote: > >>> > >>> > >>> > On August 1, 2016 at 3:45 PM Andreas Meyer > >> wrote: > > 2016-07-31 16:39 GMT+02:00 : > > >> On July 27, 2016 at 2:08 AM Andreas Meyer > wrote: > >> > >> Hi, > >> > >> > >> I want to add a new password hashing scheme as plugin and provide > >> it for > >> the dovecot project, so that it will be included as optional > >> plugin in > >> future releases. > >> > >> Yet the plugin compiles fine and the .so file gets created. > >> > >> My approach is to call the functions password_scheme_register() and > >> password_scheme_unregister() (src/auth/password-scheme.c) inside > >> the > >> plugin's _init() and _deinit() functions. > >> > >> When a client tries to login via imap the log shows an error > >> message: > >> Error: Couldn't load required plugin > >> /usr/local/lib/dovecot/lib20_newauth_plugin.so: dlopen() failed: > >> /usr/local/lib/dovecot/lib20_newauth_plugin.so: undefined symbol: > >> password_scheme_unregister > >> > >> That error obviously occurs, because the required lib is not > >> linked into > >> the plugin. > >> > >> > >> Now my problem is to understand, whether this approach (via .so > >> file) can > >> be successful at all and if so, how? > >> Do I need to link libs into it? Which would that be and how do I > >> specify > >> them in the Makefile.am? > >> > >> I assume, I don't need to link a lib, but need to use a hook to > >> register > >> the new hashing scheme, since the plugin is loaded into an already > > existing > >> process, which needs to get extended. If this is true, which hook > >> would > >> that be and how do I register the new scheme? > >> > >> Or is there no way to accomplish this via a separated .so plugin? > >> Should > > I > >> extend the sources in /src/auth instead? (separat file for the > >> hashing > >> scheme with preprocessor instructions to include it only on demand) > >> > >> > >> > >> Thank you very much, > >> > >> Andreas > > Can you publish your code in, say, github.com and provide link to > >> it? > > New password scheme is doable as plugin but it needs to placed in > >> different > > place and it will be autoloaded. > > > > Aki > > > > > > I created two branches. Both compile fine with the option: > >> --with-libsodium > Branch #1) > > > >> https://github.com/LuckyFellow/dovecot-core-libsodium/tree/2.2.25_ > libsodium_plugin > This is my try to add libsodium support as plugin. When the plugin is > loaded, it exits with the mentioned error message "undefined symbol: > password_scheme_unregister" > > > Branch #2) > > > >> https://github.com/LuckyFellow/dovecot-core-libsodium/tree/2.2.25_ > libsodium_auth > This compiles fine and also works. The new hashing schemes SCRYPT and > ARGON2 are available to dovecot. > Libsodium support is not created as module, but only added if the > --with-libsodium option was passed to configure. > > > > Regards, > Andreas > >>> Hi! > >>> > >>> I had a look at your code and noticed you had tried to put it in > >> dovecot's tree. I would recommend making completely separate plugin of > it. > >> It's not very hard, I can help you out there. It does not need to be in > >> src/plugins, the source supports fully external plugins that you can > then > >> install separately. > >>> This would make it lot more easier to develop the plugin. I'll see if I > >> can make you a little skeleton to help you out with this, you can then > use > >> it as basis for your auth plugin. > >>> Aki > >> https://github.com/cmouse/dovecot-password-scheme-plugin > >> > >> is the plugin template you can use. please see if it helps you out. > >> > >> Aki > >> > > > > > > Thank you very much for the skeleton. It really helped a lot. > > > > I created this repository and checked in my changes: > > https://github.com/LuckyFellow/dovecot-libsodium-plugin > > It compiles and installs fine. The auth module loads the plugin > > automatically on demand, the hashing schemes are available and they work. > > > > What do I need to do, so that you can include it as plugin? > > > > > > Regards, > > Andreas > We don't need to include it ourselves, you can tell people it exists > there, and they can compile it with their dovecot installation. We can > add wiki page for the plugin to guide people to your page. > > It will be automatically included after make install, you can try it out > with > > doveadm pw -s >
Re: Problem with sieve configuration on dovecot+debian_jessie+ISPC3
On 2016-08-02 10:25, Filip Loncar [WarpMax | FederationServers] wrote: require "duplicate"; if duplicate :header "message-id" { discard; } this sieve rule will discard your own postings on maillists when you get them back bummer This e-mail, including all attached files, if any, is confidential and this is a public maillist, no need to make a policy on that please cut it down or remove it when you post to maillists
Re: New password hashing scheme as plugin
On 02.08.2016 00:46, Andreas Meyer wrote: > 2016-08-01 15:58 GMT+02:00: > >>> On August 1, 2016 at 4:38 PM aki.tu...@dovecot.fi wrote: >>> >>> >>> On August 1, 2016 at 3:45 PM Andreas Meyer >> wrote: 2016-07-31 16:39 GMT+02:00 : >> On July 27, 2016 at 2:08 AM Andreas Meyer wrote: >> >> Hi, >> >> >> I want to add a new password hashing scheme as plugin and provide >> it for >> the dovecot project, so that it will be included as optional >> plugin in >> future releases. >> >> Yet the plugin compiles fine and the .so file gets created. >> >> My approach is to call the functions password_scheme_register() and >> password_scheme_unregister() (src/auth/password-scheme.c) inside >> the >> plugin's _init() and _deinit() functions. >> >> When a client tries to login via imap the log shows an error >> message: >> Error: Couldn't load required plugin >> /usr/local/lib/dovecot/lib20_newauth_plugin.so: dlopen() failed: >> /usr/local/lib/dovecot/lib20_newauth_plugin.so: undefined symbol: >> password_scheme_unregister >> >> That error obviously occurs, because the required lib is not >> linked into >> the plugin. >> >> >> Now my problem is to understand, whether this approach (via .so >> file) can >> be successful at all and if so, how? >> Do I need to link libs into it? Which would that be and how do I >> specify >> them in the Makefile.am? >> >> I assume, I don't need to link a lib, but need to use a hook to >> register >> the new hashing scheme, since the plugin is loaded into an already > existing >> process, which needs to get extended. If this is true, which hook >> would >> that be and how do I register the new scheme? >> >> Or is there no way to accomplish this via a separated .so plugin? >> Should > I >> extend the sources in /src/auth instead? (separat file for the >> hashing >> scheme with preprocessor instructions to include it only on demand) >> >> >> >> Thank you very much, >> >> Andreas > Can you publish your code in, say, github.com and provide link to >> it? > New password scheme is doable as plugin but it needs to placed in >> different > place and it will be autoloaded. > > Aki > I created two branches. Both compile fine with the option: >> --with-libsodium Branch #1) >> https://github.com/LuckyFellow/dovecot-core-libsodium/tree/2.2.25_libsodium_plugin This is my try to add libsodium support as plugin. When the plugin is loaded, it exits with the mentioned error message "undefined symbol: password_scheme_unregister" Branch #2) >> https://github.com/LuckyFellow/dovecot-core-libsodium/tree/2.2.25_libsodium_auth This compiles fine and also works. The new hashing schemes SCRYPT and ARGON2 are available to dovecot. Libsodium support is not created as module, but only added if the --with-libsodium option was passed to configure. Regards, Andreas >>> Hi! >>> >>> I had a look at your code and noticed you had tried to put it in >> dovecot's tree. I would recommend making completely separate plugin of it. >> It's not very hard, I can help you out there. It does not need to be in >> src/plugins, the source supports fully external plugins that you can then >> install separately. >>> This would make it lot more easier to develop the plugin. I'll see if I >> can make you a little skeleton to help you out with this, you can then use >> it as basis for your auth plugin. >>> Aki >> https://github.com/cmouse/dovecot-password-scheme-plugin >> >> is the plugin template you can use. please see if it helps you out. >> >> Aki >> > > > Thank you very much for the skeleton. It really helped a lot. > > I created this repository and checked in my changes: > https://github.com/LuckyFellow/dovecot-libsodium-plugin > It compiles and installs fine. The auth module loads the plugin > automatically on demand, the hashing schemes are available and they work. > > What do I need to do, so that you can include it as plugin? > > > Regards, > Andreas We don't need to include it ourselves, you can tell people it exists there, and they can compile it with their dovecot installation. We can add wiki page for the plugin to guide people to your page. It will be automatically included after make install, you can try it out with doveadm pw -s Aki
Problem with sieve configuration on dovecot+debian_jessie+ISPC3
I'm new-ish to dovecot and sieve (haven't used it extensively till now) and I'm not sure that I configured everything propperly. The problem is that we're trying to get the following sieve code to run: require ["fileinto", "regex", "date", "relational", "vacation", "duplicate"]; require "duplicate"; if duplicate :header "message-id" { discard; } else { redirect ""; redirect ""; redirect ""; redirect ""; redirect ""; redirect ""; keep; } keep; But we're constantly getting the following error: sieve: info: started log at Aug 02 08:13:21. main script: line 5: error: require command: unknown Sieve capability `duplicate'. main script: line 6: error: unknown test 'duplicate' (only reported once at first occurence). main script: error: validation failed. Both me and my collegue can't find what's wrong with the system. I would appreciate any kind of help on this matter. Below's my configuration. # dovecot --version 2.2.13 # dovecot -n # 2.2.13: /etc/dovecot/dovecot.conf # OS: Linux 2.6.32-45-pve x86_64 Debian 8.5 auth_mechanisms = plain login disable_plaintext_auth = no listen = *,[::] log_timestamp = "%Y-%m-%d %H:%M:%S " mail_privileged_group = vmail managesieve_notify_capability = mailto managesieve_sieve_capability = fileinto reject envelope encoded-character vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy include variables body enotify environment mailbox date ihave vnd.dovecot.duplicate passdb { args = /etc/dovecot/dovecot-sql.conf driver = sql } plugin { quota = dict:user::file:/var/vmail/%d/%n/.quotausage sieve = /var/vmail/%d/%n/.sieve sieve_duplicate_default_period = 14d sieve_extensions = +vnd.dovecot.duplicate sieve_max_redirects = 6 sieve_plugins = sieve_extprograms } protocols = imap pop3 service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } unix_listener auth-userdb { group = vmail mode = 0600 user = vmail } user = root } service imap-login { client_limit = 1000 process_limit = 500 } ssl_cert = Linux fero 2.6.32-45-pve #1 SMP Wed Mar 30 12:22:08 CEST 2016 x86_64 GNU/Linux It's a Debain Jessie VM running ISPC3. -- Srdac(an pozdrav | Best regards Filip Lonc(ar ___ WarpMax hosting *WarpMax hosting* *A* Tehnolos(ki park Varaz(din, Zagrebac(ka 89, Varaz(din, Croatia - Europe *T * +385 42 492 129, 490 090, +385 99 5896 123 ___ Ova elektronic(ka poruka, kao i svi eventualni privici, su povjerljivi i namijenjeni iskljuc(ivo naznac(enom primatelju(ima). Ukoliko niste naznac(eni primatelj(i) ove elektronic(ke poruke, molimo da odmah obavijestite pos(iljatelja, a sve kopije ove elektronic(ke poruke (ukljuc(ujuc'i i privitke) trajno obris(ete. Svaka neovlas(tena upotreba, distribucija, reprodukcija ili priopc'avanje ove poruke zabranjeno je. WarpMax hosting ne preuzima odgovornost za sadrz(aj ove poruke i eventualnu s(tetu nastalu primitkom ove poruke i priloga sadrz(anih u poruci. Ne jamc(imo da je ova elektronic(ka poruka slobodna od virusa. WarpMax hosting ne preuzima odgovornost za bilo kakav gubitak ili s(tetu koja nastane zbog prisutnosti virusa u elektronic(koj poruci. This e-mail, including all attached files, if any, is confidential and intended for the sole use by the person(s) mentioned as recipient(s). If you are not the named recipient(s) indicated in this message, please notify the sender immediately, and permanently delete all copies of this message (including any attachments). Any review, use, distribution, disclosure, printing or copying of this e-mail other than by the intended recipient(s) is prohibited. WarpMax hosting accepts no liability for content of this message and any potential damage caused by this message and files attached to it. No warranty is given that this email is free of viruses. WarpMax hosting accepts no liability for any loss or damage caused by presence of a virus.
Re: file/folder perms permissions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 4 Aug 2016, Jim Pazarena wrote: Forgive me if I am blind, but I cannot find default folder permissions. there are no "default"s, because it depends on your installation heavily. For the home directories, with the sub of mail: and deeper, I see some files with 660, some with 600, some folders with 770 some with 660 If you have folders with permission 660, they are wrong, because they miss access perm for all, even the owner. I am a bit confused. I manually messed with some files, and my MUA complained about permissions. So I got that mess fixed, and in doing so I noticed the seemingly contradictory permissions. The user must be able to access the files, so: user/owner: + if you use system users, Dovecot uses the user's system id to access the files, + if you use virtual users, Dovecot uses the mail_uid specified in the conf file or userdb, group (usually): + for some operations additional permissions might be necessary, those are *usually* given via group "mail", e.g. sharing of mailboxes with system users, direct deliviering of messages without Dovecot LDA or LMTP, ... usually you get very descriptive hints, what permissions are required, by reading the logs. Dovecot 2 even walks up directories, if an access perm is missing. Very convient! If you have trouble with mailboxes (rather than the complete mail store of an user), create a new mailbox within an account, that has no problems and use the permissions given there for problematic mailboxes. - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEVAwUBV6QtxXz1H7kL/d9rAQLB1Qf/ezS2Go1khR9D69IeAKSQ+V1Vd/7pQb2G 8HJFB8QgnLBMpmwN3vrz3+t0kWqNhW+TKusYIl70kkDYzUCC+oBeNHHVb94d20s+ sN6Up1kdLbuPJ926QiW0Sb8n6pOAyXels4L4RrKqpX4PafhtumsltOiPI82pfUpY Mel69RRh23TAepV2CnEyeWxfQ+ffJrumsVu00FR0EAd8pFw3LsKStBfQr4qA/f/+ G2aXNHPDQK2fzmP0SFK3uxk/AXgl5cbUqxEvf7n7STxaCZpcSH3DVrK7Nt0aQEBa dHm6dc+TgcY0GhJRmtKyLhnRQhZyiPW1vIBs3YS8uMcBQKG+cY9Bsw== =BIxI -END PGP SIGNATURE-