- dovecot - dovecot.org

Pigeonhole implicit keep gets unfiltered message
by Adam Weinberger 23 Dec '17

23 Dec '17

I'm getting a behaviour with pigeonhole that I wasn't expecting. Am I misunderstanding the design? I run my messages through a vnd.dovecot.filter. It's essentially this: filter "spam_filter"; if spamheaders { fileinto "spam"; stop; } Mail stored in the spam folder is the filtered version, but the implicit-keep message is the original, unfiltered message. If I add an explicit `keep;` to the end, it stores the filtered version into my inbox. Based on the filter RFC, I was expecting the implicit keep to retain the filtered version. Am I misinterpreting the spec? # Adam -- Adam Weinberger adamw(a)adamw.org http://www.adamw.org

2 4

Re: Lua Auth
by Mark Moseley 23 Dec '17

23 Dec '17

> > > > > 2) Is there an appropriate way to return data with spaces in it (or > presumably other non-alphanum chars. My quota name had a space in it, > which > somehow got interpreted as 'yes' , i.e.: > > imap: Error: Failed to initialize quota: Invalid quota root quota: Unknown > quota backend: yes > > I simply changed the space to an underscore as a workaround, but I'm > curious if there's a better way. I tried various quoting without success. > Didn't try escaping yet. > > > 2) Instead of string, return a key value table. you can have spaces in > values. > > > Does this work for auth_passdb_lookup too, or just auth_userdb_lookup? I've been returning a table with auth_userdb_lookup just fine. But when I try using it with passdb (and despite being very very sure that a 'password' key exists in the table I'm returning from auth_passdb_lookup() -- I'm logging it one line above the return), the passdb auth fails with this log entry: Dec 21 23:29:22 auth-worker(7779): Info: lua(test1(a)test.com,10.20.103.32,<dSvLQuZg+uIKFGcg>): No password returned (and no nopassword) I guess it's not seeing the password key in the table I'm returning. If I return a concat'd string ("password=... user=...") from auth_passdb_lookup(), it works just fine. I was also curious if there's a way to pass info between auth_userdb_lookup and auth_passdb_lookup. I was trying to use a table with auth_passdb_lookup() so I could take advantage of prefetch and thought that if auth_passdb_lookup didn't take a table, I could stash data away and then un-stash it in auth_userdb_lookup Thanks! > 3) response_from_template expands a key=value string into table by var > expanding values. > > > var_expand can be used to interpolation for any purposes. it returns a > string. see https://wiki.dovecot.org/Variables for details on how to use > it. > > > Individual variable access is more efficient to do directly. > > > --- > Aki Tuomi >

3 5

ot: how to block persistent same invalid account, different IPs
by Joseph Tam 22 Dec '17

22 Dec '17

"Voytek Eymont" <voytek(a)sbt.net.au> > I've installed fail2ban, it seems to be working as it identified my failed > test logins, BUT, my question is: > > what can I do when I see same invalid name trying to login to dovecot, > different IP each time, how can I say block each IP as used by this name ? If each IP is only used once in a long while, what would be the point? In general, distributed attacks are very hard to stop if you have a default accept stance. I've observed that most of the attacks to my site are from the enormous Chinese stated owned public network superblocks. I finally got sick of them so I now spiral these IMAP/POP connections into the Scharwzschild radius of my firewall. It's a prophylactic measure and not a reactive system like fail2ban, and may not work for you if you got road warriors that frequent that part of the world. However, it did get rid of a metric ton of BFD connections. Joseph Tam <jtam.home(a)gmail.com>

1 0

ot: how to block persistent same invalid account, different IPs
by Voytek Eymont 22 Dec '17

22 Dec '17

I've installed fail2ban, it seems to be working as it identified my failed test logins, BUT, my question is: what can I do when I see same invalid name trying to login to dovecot, different IP each time, how can I say block each IP as used by this name ? or it that a bad idea ? I can see two persistent attempts as so: I don't have such user 'ignacio' or 'julian' # grep ignacio.munoz /var/log/dovecot.log | wc 178 3436 35624 # grep ignacio.munoz /var/log/dovecot.log | grep 'auth fail' | wc 178 3436 35624 # grep julian /var/log/dovecot.log | wc 178 3432 34321 # grep julian /var/log/dovecot.log | grep 'auth fail' | wc 178 3432 34321 last 6 tries, sometimes have just : <ignacio.munoz>, sometimes, with tld Dec 22 17:00:33 imap-login: Info: Disconnected (auth failed, 1 attempts in 8 secs): user=<ignacio.munoz(a)aaa.com>, method=PLAIN, rip=157.122.183.218, lip=163.47.110.6, TLS, session=<Z4JniOdgkgCderfa> Dec 22 17:01:06 imap-login: Info: Disconnected (auth failed, 1 attempts in 7 secs): user=<ignacio.munoz>, method=PLAIN, rip=60.172.162.2, lip=163.47.110.6, TLS, session=<CsdriudgWAA8rKIC> Dec 22 18:58:26 imap-login: Info: Disconnected (auth failed, 1 attempts in 10 secs): user=<ignacio.munoz(a)aaa.com>, method=PLAIN, rip=60.30.224.189, lip=163.47.110.6, TLS: Disconnected, session=<kvLWLelg0QA8HuC9> Dec 22 18:58:59 imap-login: Info: Disconnected (auth failed, 1 attempts in 7 secs): user=<ignacio.munoz>, method=PLAIN, rip=220.164.2.138, lip=163.47.110.6, TLS: Disconnected, session=<T7T5L+lgRADcpAKK> Dec 22 19:30:28 imap-login: Info: Disconnected (auth failed, 1 attempts in 6 secs): user=<ignacio.munoz(a)aaa.com>, method=PLAIN, rip=113.8.194.3, lip=163.47.110.6, TLS, session=<jfSgoOlgswBxCMID> Dec 22 19:31:09 imap-login: Info: Disconnected (auth failed, 1 attempts in 6 secs): user=<ignacio.munoz>, method=PLAIN, rip=58.210.119.226, lip=163.47.110.6, TLS, session=<moAVo+lg8gA60nfi> -- Voytek

3 2

New Dovecot service: SMTP Submission (RFC6409)
by Stephan Bosch 22 Dec '17

22 Dec '17

Hi, As some of you know, I started implementing the SMTP submission proxy a few years ago. It acts as a front-end for any MTA, adding the necessary functionality for an SMTP submission service, also known as a Mail Submission Agent (MSA) (https://tools.ietf.org/html/rfc6409) The main reason I created this, back then, was implementing the BURL capability (https://tools.ietf.org/html/rfc4468) The main application of that capability -- together with IMAP URLAUTH -- is avoiding a duplicate upload of submitted e-mail messages; normally the message is both sent through SMTP and uploaded to the "Sent" folder through IMAP. Using BURL, the client can first upload the message to IMAP and then use BURL to make the SMTP server fetch the message from IMAP for submission, thereby avoiding a second upload. Apart from BURL, the submission proxy service also adds the required AUTH support, avoiding the need to configure the MTA for SASL authentication. More SMTP capabilities like CHUNKING and SIZE are supported, without requiring the backend MTA supporting these extensions. Other capabilities like DSN currently require support from the backend/relay MTA. At this point, the submission proxy is still pretty basic. However, it will provide a basis for adding all kinds of functionality in the (not so distant) future. For the first time, it will be possible to act upon message submission, rather than only message retrieval; e.g. plugins can be devised that process outgoing messages somehow. Examples of the things we could do are adding Sieve filtering support for outgoing messages, or implicitly storing submitted messages to the Sent folder. Once a plugin API is devised, you can create your own plugins. The reason I send this message now, is that this code is finally merged into the Dovecot master repository. This means that it is part of the upcoming 2.3 release. Now that it is merged, you can install and test it from Github if you like. Feedback is of course appreciated. The documentation is still pretty sparse, but there is currently not much to configure. Just add "submission" to the protocols and configure the relay MTA server. The configuration is currently only documented in the example configuration in doc/example-config/conf.d/20-submission.conf. The submission service is a login service, just like IMAP, POP3 and ManageSieve, so clients are required to authenticate. The same authentication configuration will also apply to submission, unless you're doing protocol-specific things, in which case you may need to amend your configuration for the new protocol. BURL support requires a working IMAP URLAUTH implementation. I've updated the automated Xi Debian package builder to create an additional dovecot-submissiond package. So, if you're using the Xi packages, you only need to install that package and configure the relay MTA. Regards, Stephan.

7 16

v2.3.0 released
by Timo Sirainen 22 Dec '17

22 Dec '17

https://dovecot.org/releases/2.3/dovecot-2.3.0.tar.gz https://dovecot.org/releases/2.3/dovecot-2.3.0.tar.gz.sig Some random notes: - This release is signed with a new PGP key 0x18A348AEED409DA1 (which is signed by the old key). - This fixes several compiling issues reported for the 2.3 release candidate. Also a few other fixes mainly for submission server and doveadm server. - We're still planning to make at least one (or two) more v2.2.x release before retiring it. It's now time for Christmas holidays though, so the next release will have to wait until the end of January. - We'll start distributing v2.3.x releases in apt/yum repositories in near future. There will be a separate email about it. Some repetition from the release candidate's announcement: There are several new and exciting features in v2.3.0. I'm especially happy about the new logging and statistics code, which will allow us to generate statistics for just about everything. We didn't have time to implement everything we wanted for them yet, and there especially aren't all that many logging events yet that can be used for statistics. We'll implement those to v2.3.1, which might also mean that some of the APIs might still change in v2.3.1 if that's required. We also have new lib-smtp server code, which was used to implement SMTP submission server and do a partial rewrite for LMTP server. Some of the larger changes: * Various setting changes, see https://wiki2.dovecot.org/Upgrading/2.3 * Logging rewrite started: Logging is now based on hierarchical events. This makes it possible to do various things, like: 1) giving consistent log prefixes, 2) enabling debug logging with finer granularity, 3) provide logs in more machine readable formats (e.g. json). Everything isn't finished yet, especially a lot of the old logging code still needs to be translated to the new way. * Statistics rewrite started: Stats are now based on (log) events. It's possible to gather statistics about any event that is logged. See http://wiki2.dovecot.org/Statistics for details * ssl_dh setting replaces the old generated ssl-parameters.dat * IMAP: When BINARY FETCH finds a broken mails, send [PARSE] error instead of [UNKNOWNCTE] * Linux: core dumping via PR_SET_DUMPABLE is no longer enabled by default due to potential security reasons (found by cPanel Security Team). + Added support for SMTP submission proxy server, which includes support for BURL and CHUNKING extension. + LMTP rewrite. Supports now CHUNKING extension and mixing of local/proxy recipients. + auth: Support libsodium to add support for ARGON2I and ARGON2ID password schemes. + auth: Support BLF-CRYPT password scheme in all platforms + auth: Added LUA scripting support for passdb/userdb. See https://wiki2.dovecot.org/AuthDatabase/Lua - Input streams are more reliable now when there are errors or when the maximum buffer size is reached. Previously in some situations this could have caused Dovecot to try to read already freed memory. - Output streams weren't previously handling failures when writing a trailer at the end of the stream. This mainly affected encrypt and zlib compress ostreams, which could have silently written truncated files if the last write happened to fail (which shouldn't normally have ever happened). - virtual plugin: Fixed panic when fetching mails from virtual mailboxes with IMAP BINARY extension. - doveadm-server: Fix potential hangs with SSL connections - doveadm proxy: Reading commands' output from v2.2.33+ servers could have caused the output to be corrupted or caused a crash. - Many other smaller fixes

1 0

detect suspicious logins
by Matthew Broadhead 22 Dec '17

22 Dec '17

does anyone know of a linux module (maybe similar to fail2ban) that could be installed which would monitor email logs (sign ins) and alert the user to any suspicious activity on their account? i suspect it would need to log geo location, device type and ip address to a database. it seems like a module like this would be very useful and should exist already? thanks in advance

4 3

Re: Disable ssl validation for replication?
by Joseph Tam 22 Dec '17

22 Dec '17

Joseph Ward writes: > I'm aware of at least a couple of fallback options: > ??? -have a self-signed cert for replication and use the Let's Encrypt > one for IMAP/POP > ??? - create firewall rules allowing them to connect to each other over > the public internet so that it can validate the proper cert > ? > These are both much less palatable than simply disabling the cert > validation if it's possible. Maybe instead of disabling the check, appease it by supplying (in /etc/hosts) an alternate mapping of the FQDN subject of your certificate to your internal IP: 10.x.x.x your.sync.target Joseph Tam <jtam.home(a)gmail.com>

3 2

Re: detect suspicious logins
by Joseph Tam 21 Dec '17

21 Dec '17

Matthew Broadhead <matthew.broadhead(a)nbmlaw.co.uk> wrote: >> does anyone know of a linux module (maybe similar to fail2ban) that >> could be installed which would monitor email logs (sign ins) and alert >> the user to any suspicious activity on their account? I just monitor straight from the logs using homebrew utilties. @lbutlr" <kremels(a)kreme.com> > Fail2ban can protect email logins. Alerting a user because random IP > in Korean Middle School tried to login seems no helpful. > >> i suspect it would need to log geo location, device type and ip >> address to a database. it seems like a module like this would be very >> useful > > How? > > Blacklist failed logins. That protects everyone and doesn't induce panic. I just went through a long thread elsewhere on this topic. Fail2ban is mainly a counter brute force measure. If you have a strong password policy, the net result of using it is that it makes your logs smaller, and maybe saves some CPU cycles or from DoS for really intense bouts, but otherwise, does not add to security as good passwords makes BFD infeasible. *However*, if the attacker knows the approximate password (e.g. shoulder surfing), this may help, but eventually, the password will succumb to a patient diligent attack. What the OP is considering is if the password is divulged e.g. phishing attack or snarfed from another source. In this case, an intruder's authentication will succeed immediately. If a monitor spots someone authenticating from another continent than where the owner is supposed to be, or from 2 locations thousands of miles apart, or from 5 different location simultaneously, or tried to send a huge number of messages with many bounces, or was using a different mail clients that one historically used), it can signal the admin/user for further investigation. For users, I think reporting a login origin audit will be helpful, regardless of circumstances. However, it should be done out of band, if the assumption is someone else has control of the account. Joseph Tam <jtam.home(a)gmail.com>

1 0

Logouts/disconnections not being logged?
by Joseph Tam 20 Dec '17

20 Dec '17

In a previous thread Subject: Re: iPhone/iPad IMAP connection bursts causes user+IP exceeded I reported the behaviour of MacOSX/iOS IMAP readers whereby it would use up all available connections (up to the mail_max_userip_connections setting) for mailbox searches, then log them all out, then repeat the cycle with another batch of mailbox searches, until all mailboxes were scanned. However, login/logout log counts don't square up. I would observe (for a particular user+ip) mail_max_userip_connections login entries, followed by *fewer* than mail_max_userip_connections logout entries. (I could not find any disconnections or other forms of termination.) The next peak connection count happened after another mail_max_userip_connections logins (implying the total connection count > mail_max_userip_connections), then another strings of logouts fewer than mail_max_userip_connections. For example, if mail_max_userip_connections=100, I would see 0 -> 100 logins -> 87 logouts -> 100 logins -> 87 logouts -> 100 logins -> 94 logouts -> 100 logins -> ... It appears that somewhere, somehow, IMAP session exits are not being logged. Is there a reason to explain this discrepancy? Joseph Tam <jtam.home(a)gmail.com>

1 0