- dovecot - dovecot.org

All over sudden dovecot thinks FS is read only
by Tobi 31 Oct '17

31 Oct '17

Hi list I have to dovecot instances running which host my mailboxes on Centos7 dovecot.x86_64 1:2.2.26.0-2.el7.centos installed dovecot-debuginfo.x86_64 1:2.2.26.0-2.el7.centos installed dovecot-mysql.x86_64 1:2.2.26.0-2.el7.centos installed dovecot-pigeonhole.x86_64 1:2.2.26.0-2.el7.centos installed all over sudden both dovecot "think" that the mailbox filesystem is read only and fill the logs with Oct 28 11:39:50 mbox1 dovecot: lmtp(tobster(a)brain-force.ch): Error: ssY/MGZQ9FnoLgAAC4IaJw:2: sieve: failed to open logfile (LOGGING TO STDERR): open(/home/vmail/brain-force.ch/tobster/.dovecot.sieve.log) failed: Read-only file system But a test at cli shows that I can write to the location $ echo "test" >/home/vmail/brain-force.ch/tobster/.dovecot.test $ cat /home/vmail/brain-force.ch/tobster/.dovecot.test test $ echo "test1" >/home/vmail/brain-force.ch/tobster/.dovecot.test $ cat /home/vmail/brain-force.ch/tobster/.dovecot.test test1 Mounts show that the FS should be rw /dev/vda2 / ext4 rw,relatime,data=ordered 0 0 I restarted dovecot several time already. As well I restarted the physical host on which the dovecot vms reside. Filesystems are not full and are not running out of inodes. Does anyone have an idea why dovecot suddenly behaves like that? Thanks a lot for any hint Regards tobi

4 6

Pigeonhole vacation and envelope extension recipient addresses
by David Zambonini 31 Oct '17

31 Oct '17

I have a situation where my LMTP RCPT TO: goes to a mailbox user account that does not reflect either the final (through aliasing) or envelope email address. SMTP RCPT TO: (envelope-local-part@envelope-domain) Final Recipient: (final-local-part@final-domain) LMTP RCPT TO: (mailbox-local-part@mailbox-domain) I'd like to use the final recipient as the vacation address, but also have the envelope recipient address used in place of the LTMP RCPT TO for the envelope extension. At the moment it looks like I can set one or the other? Let's say I add an x-final-to and x-envelope-to header to the email headers before delivering via LMTP. Then, setting: sieve_vacation_use_original_recipient = yes lda_original_recipient_header = x-final-to will get the vacation replies coming from where I'd like, but the envelope extension will not reflect the original SMTP envelope to. Conversely, setting: lda_original_recipient_header = x-envelope-to might get the envelope extension working correctly, but will not give vacation replies from where I'd like. Is there some way anyone is aware of to configure both final and envelope senders based on email headers (that doesn't involve lda flags, these are on different systems), or am I currently out of luck? I've tried playing with DSN ORCPT but it seems like a non-starter trying to get it passed through (exim) -- David Zambonini

3 2

antispam plugin with IMAPSieve
by j.emerlik 31 Oct '17

31 Oct '17

Hi, my dovecot is configured with IMAP Sieve antispam plugin (sa-learn), everything seems to be working correctly but in debug mode in my log file I noticed "dovecot: imap: Error". Last 14 lines od my log file: Oct 31 15:05:25 mnode1 dovecot: imap: Error: Oct 31 15:05:25.040 [10743] dbg: bayes: tokenized header: 90 tokens Oct 31 15:05:25 mnode1 dovecot: imap: Error: Oct 31 15:05:25.067 [10743] dbg: bayes: seen (8e031cc9fec44b6607dc7f6b37903fc49e9c8526@sa_generated) put Oct 31 15:05:25 mnode1 dovecot: imap: Error: Oct 31 15:05:25.067 [10743] dbg: bayes: learned '8e031cc9fec44b6607dc7f6b37903fc49e9c8526@sa_generated', atime: 1509457623 Oct 31 15:05:25 mnode1 dovecot: imap: Error: Oct 31 15:05:25.068 [10743] dbg: plugin: Mail::SpamAssassin::Plugin::Bayes=HASH(0x2adc340) implements 'learner_close', priority 0 Oct 31 15:05:25 mnode1 dovecot: imap: Error: Oct 31 15:05:25.033 [10743] dbg: bayes: using userid: 7 Oct 31 15:05:25 mnode1 dovecot: imap: Error: Oct 31 15:05:25.037 [10743] dbg: bayes: tokenized body: 174 tokens Oct 31 15:05:25 mnode1 dovecot: imap: Error: Oct 31 15:05:25.037 [10743] dbg: bayes: tokenized uri: 0 tokens Oct 31 15:05:25 mnode1 dovecot: imap: Error: Oct 31 15:05:25.037 [10743] dbg: bayes: tokenized invisible: 0 tokens Oct 31 15:05:25 mnode1 dovecot: imap: Error: Oct 31 15:05:25.040 [10743] dbg: bayes: tokenized header: 90 tokens Oct 31 15:05:25 mnode1 dovecot: imap: Error: Oct 31 15:05:25.067 [10743] dbg: bayes: seen (8e031cc9fec44b6607dc7f6b37903fc49e9c8526@sa_generated) put Oct 31 15:05:25 mnode1 dovecot: imap: Error: Oct 31 15:05:25.067 [10743] dbg: bayes: learned '8e031cc9fec44b6607dc7f6b37903fc49e9c8526@sa_generated', atime: 1509457623 Logs looks good and I don't understand "Error:" from log, It looks like sa-learn is connected to database and learned bayes. Error in log it's normal or It's means that it not work ? Regards, Jack

2 1

Re: Bug#876364: dovecot-sieve: Just discovered imap_sieve/sieve_imapsieve is not set up to work with virtual mailboxes.
by Apollon Oikonomopoulos 31 Oct '17

31 Oct '17

Control: tags -1 + moreinfo upstream [Forwarding this to the Dovecot mailing list, just in case someone can help] Hi, Thanks for the report! See my comments inline. On 11:56 Thu 21 Sep , Thurgood Angelou wrote: > Package: dovecot-core > Version: 1:2.2.32-2 > > I've just discovered a bug where the sieve plugin (especially IMAP) > will not work with a virtual mailbox. I recently found this out when > testing a virtual mailbox setup and I use imap_sieve for SPAM > filtering so to lose that would be painful. > > This is what is reported in dovecot's debug log... > > Sep 21 10:53:01 imap(personal(a)othersider92.com): Panic: file mail-index-map.c: line 549 (mail_index_map_lookup_seq_range): assertion failed: (first_uid > 0) > Sep 21 10:53:01 imap(personal(a)othersider92.com): Error: Raw backtrace: /usr/lib/dovecot/libdovecot.so.0(+0x9f0a2) [0x7f4226fd50a2] -> /usr/lib/dovecot/libdovecot.so.0(+0x9f19a) [0x7f4226fd519a] -> /usr/lib/dovecot/libdovecot.so.0(i_fatal+0) [0x7f4226f65cf8] -> /usr/lib/dovecot/libdovecot-storage.so.0(mail_index_map_lookup_seq_range+0x120) [0x7f422733dae0] -> /usr/lib/dovecot/libdovecot-storage.so.0(+0xe8d1d) [0x7f422734cd1d] -> /usr/lib/dovecot/libdovecot-storage.so.0(mail_index_lookup_seq+0xf) [0x7f4227350e9f] -> /usr/lib/dovecot/modules/lib20_virtual_plugin.so(+0x82aa) [0x7f422678a2aa] -> /usr/lib/dovecot/modules/lib95_imap_sieve_plugin.so(+0x708c) [0x7f422657d08c] -> /usr/lib/dovecot/libdovecot-storage.so.0(mailbox_transaction_commit_get_changes+0x52) [0x7f42272adca2] -> dovecot/imap(+0x10084) [0x556502adb084] -> dovecot/imap(command_exec+0x5c) [0x556502ae7d9c] -> dovecot/imap(+0x1b322) [0x556502ae6322] -> dovecot/imap(+0x1b3bc) [0x556502ae63bc] -> dovecot/imap(client_handle_input > +0x18d) [0x556502ae677d] -> dovecot/imap(client_input+0xac) [0x556502ae6ccc] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x52) [0x7f4226fea742] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0x12e) [0x7f4226febd8e] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0x36) [0x7f4226fea7d6] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_run+0x38) [0x7f4226fea988] -> /usr/lib/dovecot/libdovecot.so.0(master_service_run+0x13) [0x7f4226f70353] -> dovecot/imap(main+0x329) [0x556502ad9139] -> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f4226bb92e1] -> dovecot/imap(_start+0x2a) [0x556502ad92ca] After mixing in the debug symbols, this backtrace becomes: /usr/lib/dovecot/libdovecot.so.0(+0x9f0a2) [0x7f4226fd50a2] default_fatal_finish at ./src/lib/failures.c:195 /usr/lib/dovecot/libdovecot.so.0(+0x9f19a) [0x7f4226fd519a] ?? at ./src/lib/failures.c:670 /usr/lib/dovecot/libdovecot.so.0(i_fatal+0) [0x7f4226f65cf8] i_fatal at ./src/lib/failures.c:280 /usr/lib/dovecot/libdovecot-storage.so.0(mail_index_map_lookup_seq_range+0x120) [0x7f422733dae0] mail_index_map_lookup_seq_range at ./src/lib-index/mail-index-map.c:550 /usr/lib/dovecot/libdovecot-storage.so.0(+0xe8d1d) [0x7f422734cd1d] tview_lookup_seq_range at ./src/lib-index/mail-index-transaction-view.c:178 /usr/lib/dovecot/libdovecot-storage.so.0(mail_index_lookup_seq+0xf) [0x7f4227350e9f] mail_index_lookup_seq at ./src/lib-index/mail-index-view.c:522 /usr/lib/dovecot/modules/lib20_virtual_plugin.so(+0x82aa) [0x7f422678a2aa] virtual_mail_set_uid at ./src/plugins/virtual/virtual-mail.c:213 /usr/lib/dovecot/modules/lib95_imap_sieve_plugin.so(+0x708c) [0x7f422657d08c] imap_sieve_mailbox_transaction_run at ./pigeonhole/src/plugins/imapsieve/imap-sieve-storage.c:752 (inlined by: imap_sieve_mailbox_transaction_commit at ./pigeonhole/src/plugins/imapsieve/imap-sieve-storage.c:807) /usr/lib/dovecot/libdovecot-storage.so.0(mailbox_transaction_commit_get_changes+0x52) [0x7f42272adca2] mailbox_transaction_commit_get_changes at ./src/lib-storage/mail-storage.c:2083 dovecot/imap(+0x10084) [0x556502adb084] cmd_copy_full at ./src/imap/cmd-copy.c:146 dovecot/imap(command_exec+0x5c) [0x556502ae7d9c] command_exec at ./src/imap/imap-commands.c:200 dovecot/imap(+0x1b322) [0x556502ae6322] client_command_input at ./src/imap/imap-client.c:1088 dovecot/imap(+0x1b3bc) [0x556502ae63bc] client_command_input at ./src/imap/imap-client.c:1150 dovecot/imap(client_handle_input+0x18d) [0x556502ae677d] client_handle_input at ./src/imap/imap-client.c:1203 dovecot/imap(client_input+0xac) [0x556502ae6ccc] client_input at ./src/imap/imap-client.c:1249 /usr/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x52) [0x7f4226fea742] io_loop_call_io at ./src/lib/ioloop.c:600 /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0x12e) [0x7f4226febd8e] io_loop_handler_run_internal at ./src/lib/ioloop-epoll.c:223 /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0x36) [0x7f4226fea7d6] io_loop_handler_run at ./src/lib/ioloop.c:648 /usr/lib/dovecot/libdovecot.so.0(io_loop_run+0x38) [0x7f4226fea988] io_loop_run at ./src/lib/ioloop.c:622 /usr/lib/dovecot/libdovecot.so.0(master_service_run+0x13) [0x7f4226f70353] master_service_run at ./src/lib-master/master-service.c:667 dovecot/imap(main+0x329) [0x556502ad9139] main at ./src/imap/main.c:491 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f4226bb92e1] __libc_start_main at ../csu/libc-start.c:325 dovecot/imap(_start+0x2a) [0x556502ad92ca] start at ??:0 > -- System Information: > Debian Release: 8.2 > APT prefers oldstable-updates > APT policy: (500, 'oldstable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages dovecot-sieve depends on: > ii dovecot-core 1:2.2.32-2 > ii libc6 2.24-17 > ii ucf 3.0030 > > dovecot-sieve recommends no packages. > > dovecot-sieve suggests no packages. > > Versions of packages dovecot-sieve is related to: > ii dovecot-core [dovecot-common] 1:2.2.32-2 > pn dovecot-dbg <none> > pn dovecot-dev <none> > ii dovecot-gssapi 1:2.2.32-2 > ii dovecot-imapd 1:2.2.32-2 > ii dovecot-ldap 1:2.2.32-2 > ii dovecot-lmtpd 1:2.2.32-2 > ii dovecot-managesieved 1:2.2.32-2 > ii dovecot-mysql 1:2.2.32-2 > pn dovecot-pgsql <none> > pn dovecot-pop3d <none> > ii dovecot-sieve 1:2.2.32-2 > pn dovecot-sqlite <none> Could you also include the output of doveconf -n? Regards, Apollon

3 2

Re: Disconnected: Inactivity (no auth attempts in 180 secs)
by Joseph Tam 31 Oct '17

31 Oct '17

Alexandre <byalefp(a)yahoo.com.br> wrote: > I can send and receive mails using: > IMAP 143 with TLS OK, IMAP STARTTLS is working in some sense. (Your MTA handles SMTP, not dovecot.) > The hangup occours inside of my LAN using Outlook 2016, and Outside > also trying access on 4G from my Android smartphone. > > My goal is enable also POP3s and IMAPs using TLS. [voluminous diagnostics] I can't really see from what you present what the problem is. Can you report the output of openssl s_client -starttls imap {imap-server}:143 openssl s_client -starttls pop3 {imap-server}:110 (from both inside and outside), as well as any matching log entries. Joseph Tam <jtam.home(a)gmail.com>

1 0

Re: Password encription
by Joseph Tam 30 Oct '17

30 Oct '17

> Aki, (Not speaking for Aki) > I understand that salted passwords saved in my database and stronger hash > algorithm course that it will require more processor time/power to crack my > passwords. > > But only when hackers have direct access to my database what means that > hackers have access to my passwords hashes (eg. hackers stolen my database). > > My Dovecot use passwords saved in database as SHA256 and hackers can use > only SMTP, IMAP or POP3 services to try crack it using dictionary attack (I > understand that they using plain text dictionaty passwords). > > Stronger hash algorithm and salt is useful when hackers have direct access > to my database but when they use services as SMTP, IMAP or POP3 > to crack passwords only longer and more complicated password can be more > secure. > > I do not understand this correctly ? Yes, your understanding is basically correct. However, history gives lots of examples of broken systems that explicitly or implicitly relied on one critical system not failing -- they lacked defense in depth or resilience. Examples are "this system has no bugs", "my system does not leak hashes", "this algorithm is unbreakable", "we'll never see a CAT5 hurricane", etc. If these critical assumption ever becomes untrue, the foundation of your defense crumbles. If you narrow your attack definition to only include in-protocol remote brute forcing, then any decent password will take far too long to break that way (esp. with throttling controls that are built-in). Your log files will overflow recording the attempts long before you can expect a password to be cracked. However, you're still susceptable to the qwerty passwords. If this is your *only* line of defense, it is brittle. A robustly secure system will overlap protection: strong hashes, password compliance systems, brute force countermeasures, file permissions/OS hardening, network origins vetting, anti-DoS measures, etc. Keep this picture in mind that I found on CLCERT https://www.clcert.cl/humor/img/weakest-link-road.jpg Joseph Tam <jtam.home(a)gmail.com>

1 0

Dovecot and the Maildir path
by Will Merkens 30 Oct '17

30 Oct '17

System basics Centos 7.3 Dovecot 2.2.32 (dfbe293d4) I am working on a replacement mail server for work and one of the features I wanted was ldap authentication After much fiddling I got it to work. But I encountered a issue where two different methods of testing a mail account resulted in the mail_location being different I set mail_location = maildir:/var/spool/maildir/%d/%n/Maildir in dovecot.conf when I test the authentication and to see if the folders are created correctly on first use I have two results depending on how I test. First test was from openssl openssl s_client -connect mail2:993 I have no problem connecting, I issue the following commands * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE AUTH=PLAIN] Dovecot ready. a login testuser(a)userful.com ******** a OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS BINARY MOVE] Logged in a list "" * * LIST (\HasNoChildren) "." INBOX a OK List completed (0.001 + 0.000 secs). * BYE Disconnected for inactivity. closed But when I look in the mail server at /var/spool/maildir the testuser is not created inside of userful.com but at the same level as userful.com contrary to the %d in mail_location settings. Now second method doveadm -D mailbox list -u 'testuser(a)userful.com' This correctly creates the user under the domain as specified. for logs I have from journalctl for openssl Oct 30 07:37:12 mail2 dovecot[10722]: auth: Debug: client in: AUTH 2 PLAIN service=imap secured session=VgBmvMNcQoTAqHsn lip=192.168. 123.236 rip=192.168.123.39 lport=993 rport=33858 resp=AHRlc3R1c2VyQHVzZXJmdWwuY29tADk5dGVzdHVzZXI5OQ== (previous base64 data may contain sensitive data) Oct 30 07:37:12 mail2 dovecot[10722]: auth: Debug: ldap(testuser(a)userful.com,192.168.123.39,<VgBmvMNcQoTAqHsn>): bind search: base=ou=People,dc=userful,dc=ca filter=(&(objectClass=posixAccount)(uid=testuser)) Oct 30 07:37:12 mail2 dovecot[10722]: auth: Debug: ldap(testuser(a)userful.com,192.168.123.39,<VgBmvMNcQoTAqHsn>): result: uid=testuser; uid unused Oct 30 07:37:12 mail2 dovecot[10722]: auth: Debug: ldap(testuser(a)userful.com,192.168.123.39,<VgBmvMNcQoTAqHsn>): username changed testuser(a)userful.com -> testuser Oct 30 07:37:12 mail2 dovecot[10722]: auth: Debug: ldap(testuser,192.168.123.39,<VgBmvMNcQoTAqHsn>): result: uid=testuser Oct 30 07:37:12 mail2 dovecot[10722]: auth: Debug: client passdb out: OK 2 user=testuser original_user=testuser(a)userful.com Oct 30 07:37:12 mail2 dovecot[10722]: auth: Debug: master in: REQUEST 2784755713 10725 2 d4a357fe811a1da8bd725b82fc1da2ab session_pid=11051 request_auth_token Oct 30 07:37:12 mail2 dovecot[10722]: auth: Debug: ldap(testuser,192.168.123.39,<VgBmvMNcQoTAqHsn>): user search: base=ou=People,dc=userful,dc=ca scope=subtree filter=(&(objectClass=posixAccount)(uid=testuser)) fields=homeDirectory,uidNumber,gidNumber Oct 30 07:37:12 mail2 dovecot[10722]: auth: Debug: ldap(testuser,192.168.123.39,<VgBmvMNcQoTAqHsn>): result: homeDirectory=/nfs/home/test-user uidNumber=6000 gidNumber=1000; homeDirectory,uidNumber,gidNumber unused Oct 30 07:37:12 mail2 dovecot[10722]: auth: Debug: ldap(testuser,192.168.123.39,<VgBmvMNcQoTAqHsn>): result: homeDirectory=/nfs/home/test-user uidNumber=6000 gidNumber=1000 Oct 30 07:37:12 mail2 dovecot[10722]: auth: Debug: master userdb out: USER 2784755713 testuser home=/nfs/home/test-user uid=6000 gid=1000 auth_token=29e6ac32c85cf1b69eeabbe8e4f8e4810e9a3468 auth_user=testuser(a)userful.com Oct 30 07:37:12 mail2 dovecot[10722]: imap-login: Login: user=<testuser>, method=PLAIN, rip=192.168.123.39, lip=192.168.123.236, mpid=11051, TLS, session=<VgBmvMNcQoTAqHsn> for doveadm Oct 30 07:39:12 mail2 dovecot[10722]: auth: Debug: master in: USER 1 testuser(a)userful.com service=doveadm Oct 30 07:39:12 mail2 dovecot[10722]: auth: Debug: ldap(testuser(a)userful.com): user search: base=ou=People,dc=userful,dc=ca scope=subtree filter=(&(objectClass=posixAccount)(uid=testuser)) fields=homeDirectory,uidNumber,gidNumber Oct 30 07:39:12 mail2 dovecot[10722]: auth: Debug: ldap(testuser(a)userful.com): result: homeDirectory=/nfs/home/test-user uidNumber=6000 gidNumber=1000; homeDirectory,uidNumber,gidNumber unused Oct 30 07:39:12 mail2 dovecot[10722]: auth: Debug: ldap(testuser(a)userful.com): result: homeDirectory=/nfs/home/test-user uidNumber=6000 gidNumber=1000 Oct 30 07:39:12 mail2 dovecot[10722]: auth: Debug: userdb out: USER 1 testuser(a)userful.com home=/nfs/home/test-user uid=6000 gid=1000 Any ideas and any settings files that I need to post. -- William Merkens IT Support Analyst Userful Corporation +1 403.289.2177 ext.289 +1 866 USERFUL (1-866-873-7385) Suite 300, 736 8th Ave. SW Calgary AB T2P 1H4 Managed Desktops Done Right. http://www.userful.com

2 1

dovecot-2.3 (-git) Warning and Fatal Compile Error
by Reuben Farrelly 30 Oct '17

30 Oct '17

I haven't been tracking dovecot-2.3 until now, but I've just given it a quick run, and there are a few things that may need some attention. Linux x86-64, Gentoo, GCC-7.2.0 Dovecot 2.3 @ commit 32c2612514a404ebc226f32bb88f28d76ceb1db1 Compiled with: ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking --disable-silent-rules --docdir=/usr/share/doc/dovecot-9999_p20171018 --htmldir=/usr/share/doc/dovecot-9999_p20171018/html --libdir=/usr/lib64 --localstatedir=/var --with-moduledir=/usr/lib64/dovecot --without-stemmer --disable-rpath --with-icu --with-systemdsystemunitdir=/usr/lib/systemd/system --enable-maintainer-mode --with-bzlib --without-libcap --without-gssapi --without-ldap --with-lucene --with-lz4 --with-lzma --without-mysql --with-pam --without-pgsql --without-sqlite --without-solr --with-ssl --with-libwrap --without-textcat --without-vpopmail --with-zlib --disable-static Warnings: (Lots of this one...) /bin/sh ../../../libtool --tag=CC --mode=compile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../../src/lib -I../../../src/lib-settings -I../../../src/lib-fts -I../../../src/lib-ssl-iostream -I../../../src/lib-http -I../../../src/lib-mail -I../../../src/lib-imap -I../../../src/lib-index -I../../../src/lib-storage -I../../../src/lib-storage/index -I../../../src/doveadm -std=gnu99 -O0 -g -pipe -march=native -mtune=native -ggdb -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -fno-builtin-strftime -Wstrict-aliasing=2 -c -o fts-user.lo fts-user.c libtool: compile: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../../src/lib -I../../../src/lib-settings -I../../../src/lib-fts -I../../../src/lib-ssl-iostream -I../../../src/lib-http -I../../../src/lib-mail -I../../../src/lib-imap -I../../../src/lib-index -I../../../src/lib-storage -I../../../src/lib-storage/index -I../../../src/doveadm -std=gnu99 -O0 -g -pipe -march=native -mtune=native -ggdb -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -fno-builtin-strftime -Wstrict-aliasing=2 -c fts-storage.c -fPIC -DPIC -o .libs/fts-storage.o <command-line>:0:0: warning: "_FORTIFY_SOURCE" redefined <built-in>: note: this is the location of the previous definition In file included from /usr/include/bits/libc-header-start.h:33:0, from /usr/include/stdlib.h:25, from ../../../src/lib/lib.h:11, from fts-storage.c:3: /usr/include/features.h:376:4: warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp] # warning _FORTIFY_SOURCE requires compiling with optimization (-O) ^~~~~~~ The build then fails entirely with this: /bin/sh ../../../libtool --tag=CC --mode=compile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../../.. -I/home/portage/portage/net-mail/dovecot-9999_p20171018/work/dovecot-9999_p20171018 -I/home/portage/portage/net-mail/dovecot-9999_p20171018/work/dovecot-9999_p20171018/src/lib -I/home/portage/portage/net-mail/dovecot-9999_p20171018/work/dovecot-9999_p20171018/src/lib-dict -I/home/portage/portage/net-mail/dovecot-9999_p20171018/work/dovecot-9999_p20171018/src/lib-dns -I/home/portage/portage/net-mail/dovecot-9999_p20171018/work/dovecot-9999_p20171018/src/lib-http -I/home/portage/portage/net-mail/dovecot-9999_p20171018/work/dovecot-9999_p20171018/src/lib-mail -I/home/portage/portage/net-mail/dovecot-9999_p20171018/work/dovecot-9999_p20171018/src/lib-smtp -I/home/portage/portage/net-mail/dovecot-9999_p20171018/work/dovecot-9999_p20171018/src/lib-imap -I/home/portage/portage/net-mail/dovecot-9999_p20171018/work/dovecot-9999_p20171018/src/lib-fs -I/home/portage/portage/net-mail/dovecot-9999_p20171018/work/dovecot-9999_p20171018/src/lib-charset -I/home/portage/portage/net-mail/dovecot-9999_p20171018/work/dovecot-9999_p20171018/src/lib-auth -I/home/portage/portage/net-mail/dovecot-9999_p20171018/work/dovecot-9999_p20171018/src/lib-master -I/home/portage/portage/net-mail/dovecot-9999_p20171018/work/dovecot-9999_p20171018/src/lib-ssl-iostream -I/home/portage/portage/net-mail/dovecot-9999_p20171018/work/dovecot-9999_p20171018/src/lib-compression -I/home/portage/portage/net-mail/dovecot-9999_p20171018/work/dovecot-9999_p20171018/src/lib-settings -I/home/portage/portage/net-mail/dovecot-9999_p20171018/work/dovecot-9999_p20171018/src/lib-test -I/home/portage/portage/net-mail/dovecot-9999_p20171018/work/dovecot-9999_p20171018/src/lib-sasl -I/home/portage/portage/net-mail/dovecot-9999_p20171018/work/dovecot-9999_p20171018/src/lib-stats -I/home/portage/portage/net-mail/dovecot-9999_p20171018/work/dovecot-9999_p20171018/src/lib-dcrypt -I/home/portage/portage/net-mail/dovecot-9999_p20171018/work/dovecot-9999_p20171018/src/lib-program-client -I/home/portage/portage/net-mail/dovecot-9999_p20171018/work/dovecot-9999_p20171018/src/lib-index -I/home/portage/portage/net-mail/dovecot-9999_p20171018/work/dovecot-9999_p20171018/src/lib-storage -I/home/portage/portage/net-mail/dovecot-9999_p20171018/work/dovecot-9999_p20171018/src/lib-storage/list -I/home/portage/portage/net-mail/dovecot-9999_p20171018/work/dovecot-9999_p20171018/src/lib-storage/index -I/home/portage/portage/net-mail/dovecot-9999_p20171018/work/dovecot-9999_p20171018/src/lib-storage/index/raw -I/home/portage/portage/net-mail/dovecot-9999_p20171018/work/dovecot-9999_p20171018/src/lib-imap-storage -I/home/portage/portage/net-mail/dovecot-9999_p20171018/work/dovecot-9999_p20171018/src/plugins/quota -DMODULEDIR=\""/usr/lib64/dovecot"\" -O0 -g -pipe -march=native -mtune=native -ggdb -c -o realpath.lo realpath.c edit-mail.c: In function ‘edit_mail_wrap’: edit-mail.c:235:14: error: too few arguments to function ‘mailbox_transaction_begin’ raw_trans = mailbox_transaction_begin(raw_box, 0); ^~~~~~~~~~~~~~~~~~~~~~~~~ In file included from /home/portage/portage/net-mail/dovecot-9999_p20171018/work/dovecot-9999_p20171018/src/lib-storage/mail-storage-private.h:7:0, from edit-mail.c:16: /home/portage/portage/net-mail/dovecot-9999_p20171018/work/dovecot-9999_p20171018/src/lib-storage/mail-storage.h:651:1: note: declared here mailbox_transaction_begin(struct mailbox *box, ^~~~~~~~~~~~~~~~~~~~~~~~~ edit-mail.c: In function ‘edit_mail_set_cache_corrupted’: edit-mail.c:1662:2: error: too few arguments to function ‘edmail->wrapped->v.set_cache_corrupted’ edmail->wrapped->v.set_cache_corrupted(&edmail->wrapped->mail, field); ^~~~~~ edit-mail.c: In function ‘edit_mail_set_cache_corrupted_reason’: edit-mail.c:1671:21: error: ‘struct mail_vfuncs’ has no member named ‘set_cache_corrupted_reason’; did you mean ‘set_cache_corrupted’? edmail->wrapped->v.set_cache_corrupted_reason ^~~~~~~~~~~~~~~~~~~~~~~~~~ set_cache_corrupted edit-mail.c: At top level: edit-mail.c:1701:2: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types] edit_mail_get_real_mail, ^~~~~~~~~~~~~~~~~~~~~~~ edit-mail.c:1701:2: note: (near initialization for ‘edit_mail_vfuncs.get_backend_mail’) edit-mail.c:1708:2: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types] edit_mail_set_cache_corrupted, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ edit-mail.c:1708:2: note: (near initialization for ‘edit_mail_vfuncs.set_cache_corrupted’) edit-mail.c:1710:2: warning: excess elements in struct initializer edit_mail_set_cache_corrupted_reason ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ edit-mail.c:1710:2: note: (near initialization for ‘edit_mail_vfuncs’) make[4]: *** [Makefile:481: edit-mail.lo] Error 1 make[4]: *** Waiting for unfinished jobs.... Reuben

5 9

Re: Password encription
by Joseph Tam 29 Oct '17

29 Oct '17

Aki Tuomi wrote: > The use of salt, today, is to prevent the attacker from directly seeing > who has same passwords. Of course it also will make a rainbow table > attack less useful, Not just less useful, but almost infeasible. Given the use of random salts, you would have to generate (number of possible salts) rainbow tables. This drastically changes the CPU/storage tradeoffs. > but then again, no one uses rainbow tables anymore > since it takes about few minutes to brute force a password in the cloud > or on your home computer GPU. SHA512-CRYPT uses by default 4000 rounds > on dovecot, to make it more computationally expensive, but still it's > not very strong protection anymore. I know it is theoretically possible, but really, how feasible is it? The way people talk about it, they make it sound trivial. As a test, I just generated a hash using "doveadm pw". Any takers? {SHA512-CRYPT}$6$qyQANQFbQGqOSqHh$Z4YVIe.QakXtWs63lWUmzlseKpiFzfPCKhwM0NQk8jP6QeRmk6POkCdSrFBmVO2wh.dgPCPA7Gq3sNUeKOZLM/ > MD5 with or without salt can be ATTAcked at passwords per second speed, > so using CRAM-MD5 of DIGEST-MD5 is very very poor choice. Anything with > MD5 should not be used for passwords these days. > > With Dovecot 2.3 we are making BLF-CRYPT available on all platforms, and > also adding support for ARGON2 when you have libsodium available. Straight hashes, without question, are weak. I routinely break NTLM hashes with rainbow tables. I'm *not* arguing against the use of stronger hashes, I'm just skeptical of the FUD surrounding the user of older salted hashes. This is especially true if the hashes are guarded against leakage, as most are. Strong crypt-hashes are an extra layer of protection (defense in depth). This page (if you trust 3rd parties) will report whether a password was ever found in a breached databases. You can also download the SHA1 hashes of all their known cracked passwords. It's big -- 5.3Gb 7-zipped file. https://haveibeenpwned.com/Passwords "j.emerlik" further asks: > You mean that today they using encrypted passwords to seeing > who has same passwords using brute force, hashes dictionary attack ? They precompute hashes for large number of password candidates, then look up hashes in that table. Rainbow tables are a way of folding large tables into a smaller ones, trading off space for extra CPU time. However, for hashes that use non-trivial salts, you would need to precompute an astronomically large number of tables. An attacker might be better off with a straight CPU-bound brute force search. Joseph Tam <jtam.home(a)gmail.com>

3 3

Need help in understanding auth digest-md5 and realm
by Admin Beckspaced 28 Oct '17

28 Oct '17

Hello dovecot community, I've setup dovecot and need a bit help in understanding the auth mechanism digest-md5 and realm in 10-auth.conf I got auth_mechanisms = plain login digest-md5 cram-md5 apop #auth_realms = #auth_default_realm = So i got empty realms. Auth normally works fine and clients can auth with mechanism digest-md5 and I see the following log entries: dovecot: auth: Debug: sql(user(a)temizbau.de,46.85.229.153,<klUjO3FcTy8uVeWZ>): Generating DIGEST-MD5 from user 'user(a)temizbau.de', password 'xxxx' dovecot: auth: Debug: sql(user(a)gruene-wiesentheid.de,87.168.26.5,<ISVLQXFcT/xXqBoF>): Generating DIGEST-MD5 from user 'user@gruene-wiesentheid.de@', password 'xxxxxxxxxx' dovecot: auth: Debug: sql(user(a)vitaler-genuss.de,81.209.203.170,<tzxyT3FcT9RR0cuq>): Generating DIGEST-MD5 from user 'user(a)vitaler-genuss.de', password 'xxxxxxxxxxx' But sometimes clients get a password mismatch and I the see the following log entries: dovecot: auth: Debug: sql(user(a)temizbau.de,80.187.103.15,<adzhAnVclmxQu2cP>): Generating DIGEST-MD5 from user 'user@temizbau.de@mail.beckspaced.com', password 'xxxx' dovecot: auth: Debug: sql(user(a)thansadet.com,87.218.86.165,<LWItYHVc6r1X2lal>): Generating DIGEST-MD5 from user 'user@thansadet.com@mail.beckspaced.com', password 'xxxxxxxxxx' dovecot: auth: Debug: sql(user(a)plaa-thansadetresort.com,110.164.127.146,<aGhcvHBcStJupH+S>): Generating DIGEST-MD5 from user 'user@plaa-thansadetresort.com@imap.beckspaced.com', password 'xxxxxxxxxx' when there's a password mismatch I see a different user string for generating the digest-md5 hash. i suppose users use a different mail client and the mail client does things differently? How can I fix this password mismatch thing? Do i just need to set an auth_realms of some random string in the 10-auth.conifig Or does the auth_realms need to be a host name? Domain name of some sort? For the moment I just removed the digest-md5 mechanism ... Or could I just simply not offer that mechanism? If someone could shed some light on this I would be more than grateful ;) Thanks & greetings Becki

4 6