Re: detect suspicious logins
> On December 20, 2017 at 12:29 PM Marcus Rueckert wrote: > > > On Tue, 19 Dec 2017 17:13:10 + > Matthew Broadhead 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 > > 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 > > https://github.com/PowerDNS/weakforced > > -- > openSUSE - SUSE Linux is my linux > openSUSE is good for you > www.opensuse.org You could use weakforced with dovecot's auth policy https://wiki2.dovecot.org/Authentication/Policy Aki
Re: New Dovecot service: SMTP Submission (RFC6409)
> On December 20, 2017 at 4:39 PM Tanstaafl wrote: > > > On Sat Dec 16 2017 15:41:25 GMT-0500 (Eastern Standard Time), Tanstaafl > wrote: > > Ok, well, my ignorance is probably glaring here, but what I meant was, > > the make the BURL/URLAUTH pieces strictly between Dovecot and the > > backend SMTP server, make it invisible to the Client... > > So, I take it the no response to this means that there is no way to put > the BURL/URLAUTH parts such that only server support is needed, nothing > special on the client side? > > Bummer, that means it will be a looong time if ever that this feature is > usable. Tanstaafl, maybe you could explain what you think the BURL/URLAUTH stuff is for, or do you have some particular use case you would be using it? Client support already is not required, and yes, it might take a long time before clients support it. Aki
Re: Lua Auth
On Thu, Dec 21, 2017 at 9:51 PM, Aki Tuomi wrote: > > > On December 22, 2017 at 6:43 AM Mark Moseley > wrote: > > > > > > > > > > > > > > > > > > > 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(te...@test.com,10.20.103.32,): > > 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! > > > > > > Yeah, this is a bug we have fixed =) > > https://github.com/dovecot/core/commit/c86575ac9776d0995355d03719c82e > 7ceac802e6#diff-83374eeaee91d90e848390ba3c7b264a > > I'm on rc1, so I appear to already have that git commit (as part of rc1). # /usr/sbin/dovecot --version 2.3.0.rc1 (12aba5948) For testing this, I tried replacing my passdb lookup with this: function auth_passdb_lookup(req) passdb_table = {} passdb_table[ 'password' ] = 'test' passdb_table[ 'user' ] = 'te...@test.com' return dovecot.auth.PASSDB_RESULT_OK, passdb_table end and still get: Dec 22 01:17:17 auth-worker(9711): Info: lua(te...@test.com,10.20.103.32,): No password returned (and no nopassword) Replacing that return statement with this: return dovecot.auth.PASSDB_RESULT_OK, 'password=test user=te...@test.com' authenticates successfully.
Re: Dovecot 2.3-rc Logging Format
> On December 21, 2017 at 9:57 AM Thomas Leuxner wrote: > > > Hi, > > the release candidate defaults to a log format with session IDs. > > mail_log_prefix = "%s(%u)<%{pid}><%{session}>: " > > As the LMTP service seems to have the session ID hardcoded, the IDs get > duplicated in the logs: > > Dec 21 08:48:03 edi dovecot: lmtp(26573): Connect from local > Dec 21 08:48:03 edi dovecot: lmtp(t...@leuxner.net)[26573]: > : fCVaBjNnO1rNZwAAIROLbg: sieve: > msgid=<2323281.OorJHhdMHM@ylum>, time=158ms, status=stored mail into mailbox > ':public/Mailing-Lists/Debian-User' > Dec 21 08:48:03 edi dovecot: lmtp(26573): Disconnect from local: Client has > quit the connection (state = READY) > > Regards > Thomas Hi! Thank you for your report, we'll look into it. Aki
Re: Disable ssl validation for replication?
Thanks for letting us know, we'll check this. But, would it make sense to sign those certs with your own CA cert and distribute the CA cert to your systems? Aki > On December 21, 2017 at 4:56 PM Joseph Ward wrote: > > > I'd considered doing it at the internal DNS server level which I wasn't > a fan of because it's a separate server's config that I'd have to rely > on to make sure this server was working. The thought of the local hosts > file slipped my mind. That is a good idea; it meets my needs, and keeps > everything in the same "create mail server" ansible file. > > Thank you! > > -Joseph > > > On 12/20/2017 20:27, Joseph Tam wrote: > > 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 >
Re: Lua Auth
> On December 22, 2017 at 6:43 AM Mark Moseley wrote: > > > > > > > > > > > > 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(te...@test.com,10.20.103.32,): > 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! > > Yeah, this is a bug we have fixed =) https://github.com/dovecot/core/commit/c86575ac9776d0995355d03719c82e7ceac802e6#diff-83374eeaee91d90e848390ba3c7b264a Aki
Re: Lua Auth
> > > > > 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(te...@test.com,10.20.103.32,): 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 >
Re: Pigeonhole implicit keep gets unfiltered message
On 21 Dec, 2017, at 14:37, Stephan Bosch wrote: Op 12/19/2017 om 8:41 AM schreef Adam Weinberger: 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? I did a quick test, and I am not seeing any problems. However, what is that spamheaders test in your script? Hi Stephan, The block looks like this: ### BOGOFILTER filter "bogofilter_filter"; if header :contains "X-Bogosity" [ "Spam, tests=bogofilter, spamicity=1.00", "Spam, tests=bogofilter, spamicity=0.99" ] { fileinto "spam/totally"; stop; } elsif header :contains "X-Bogosity" "Spam," { fileinto "spam/probably"; stop; } elsif header :contains "X-Bogosity" "Unsure," { fileinto "spam/maybe"; stop; } Bogofilter adds an X-Bogosity header. With the block as it is, when it hits the implicit keep the message has no X-Bogosity header. When I add 'keep;' to the end, it does have the header. If it's just me, that's fine, as it's incredibly easy to work around. # Adam -- Adam Weinberger ad...@adamw.org http://www.adamw.org
Re: Dovecot 2.3-rc1 SMTP submission proxy always gives TLS required error even when already using TLS
Op 12/18/2017 om 9:44 PM schreef Michael Marley: > First of all, I apologize for my accidental empty message earlier. > > I just set up the SMTP submission proxy in Dovecot 2.3, but whenever I > try to connect to it, it always returns "530 5.7.0 TLS required." for > any sort of AUTH or MAIL command. This occurs even if TLS is being > used. It also occurs regardless of whether I connect with a real > client (Thunderbird) or manually with openssl s_client and regardless > of whether a loopback connection or a remote connection is used. Here > is the output of "dovecot -n". Please let me know if I can provide > any other data. Thanks! Confirmed. Working on a fix. Regards, Stephan.
Re: Pigeonhole implicit keep gets unfiltered message
Op 12/19/2017 om 8:41 AM schreef Adam Weinberger: > 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? I did a quick test, and I am not seeing any problems. However, what is that spamheaders test in your script? Regards, Stephan.
Re: Disable ssl validation for replication?
I'd considered doing it at the internal DNS server level which I wasn't a fan of because it's a separate server's config that I'd have to rely on to make sure this server was working. The thought of the local hosts file slipped my mind. That is a good idea; it meets my needs, and keeps everything in the same "create mail server" ansible file. Thank you! -Joseph On 12/20/2017 20:27, Joseph Tam wrote: > 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
Re: Disable ssl validation for replication?
I only have one public IP at each site, so having all internal services (and I have a lot of them) communicating over the internet to that single IP (on each side) would get pretty complex with a lot of rules and a lot of interesting port remapping and additional firewall rule complexity. That additional complexity also involves more chances to make mistakes that introduce security problems. So in general, I'm eager to keep things going directly to the proper service internally. Obviously I can work around that when it's necessary, but going outside the VPN is the last option I'm entertaining. Regards, Joseph Ward On 12/20/2017 20:24, Andrew Sullivan wrote: > I guess what I don't understand is why the IP address approach is more > attractive to you, and why you think the "public Internet" path is > less good. > > Best regards, > > A >
Re: v2.3.0 release candidate released
On Thu, 21 Dec 2017 13:50:06 +0300, Odhiambo Washington stated: >On 21 December 2017 at 01:16, Michael Grimm wrote: > >> Hi, >> >> Odhiambo Washington wrote: >> >> > What am I missing here: >> > >> > OS = FreeBSD 8.4 >> > >> > Here is how it fails during `gmake`: >> >> [snip] >> >> Hmm, FBSD 8.4 has reached End of Life a long time ago, namely on August 1, >> 2015. It has not seen security updates ever since :-( >> >> Thus, I am just curious: but why can't you upgrade to either 10.x or 11.x? >> >> Regards, >> Michael >Hi Michael, > >I know about that EoL, but I do believe it has nothing to do with the >failure to compile Dovecot, or does it? > >I am moving to new hardware and latest FreeBSD version soon. In the >meantime, I need to run Dovecot on it. FreeBSD is a very finicky creature. I have had problems in the past where newer programs either would not compile or failed to work as intended on older versions of FreeBSD. My advice to you would be to upgrade to the latest stable version of FreeBSD. Do it in a clean environment. Don't try and upgrade over an old installation. I have seen too many instances where old crap was left around and caused headaches later. I usually reformat the drive(s) first, but that is your call. Good luck! -- Jerry
Re: v2.3.0 release candidate released
Hi Michael, I know about that EoL, but I do believe it has nothing to do with the failure to compile Dovecot, or does it? I am moving to new hardware and latest FreeBSD version soon. In the meantime, I need to run Dovecot on it. On 21 December 2017 at 01:16, Michael Grimm wrote: > Hi, > > Odhiambo Washington wrote: > > > What am I missing here: > > > > OS = FreeBSD 8.4 > > > > Here is how it fails during `gmake`: > > [snip] > > Hmm, FBSD 8.4 has reached End of Life a long time ago, namely on August 1, > 2015. It has not seen security updates ever since :-( > > Thus, I am just curious: but why can't you upgrade to either 10.x or 11.x? > > Regards, > Michael > > -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft."