Pathetic Upgrade Question: 2.0.9 to 2.3.0
My version output is below, under the heading "My actual question". Background to my woes: === I installed a new virtual machine with CentOS 6.9 (I'll refer to it as xxserverxx) and included the postfix server. I configured a virtual network, did a decent job of hardening firewalls for both physical host and virtual guests. I was able to get mail / mailx to send and receive mail on the command line using postfix using Maildir delivery. Sent and received email to/from self as well as from an external email address hosted elsewhere. But not being satisfied enough with mailx mail client... wanting an IMAP client on the same 192 virtual private subnet, I used yum to install dovecot package from CentOS repositories on the virtual mail guest server. Configured mail client (Evolution installled via graphical interface on a CentOS 6.9 workstation on the same subnet), and configured dovecot, used mbox delivery, struggled with documentation to understand how server mail directories/files are actually used, fixed a problem or two, but did not have IMAP send and receive working. Then, wanting to be on the latest stable version of dovecot anyway, I downloaded dovecot 2.3.0 from dovecot.org and attempted to follow the instructions on building from source, but in the end all I could really find was the simple sequence of steps, make configure, make and make install, so that's what I did. Continued struggling with configuration (needing to be somewhat certain that defaults would not create a completely wide open mail server that would be hacked in 10 minutes, since this is on a real physical host with a public ip. I actually got an email to get appended to the users mbox file. Evolution Email client at one point actually logged into dovecot/IMAP and retrieved 3 received emails. The problem is that Email client is now failing on permissions in creating index files. I've gotten to the point of going to extreme measures to "fix" that file creation problem, but to no avail. Now unfortunately I've found an underlying problem to everything, going back to the beginning where I upgraded dovecot. My actual question: I don't want troubleshooting help, but help with documentation. It appears that make install has not replaced the old 2.0.9 binaries with new 2.3.0 binaries, even though it faithfully created everying under the /usr directories, e.g., /usr/bin, etc., and make install did not set some variable or otherwise configure for the new version to run instead of the old. Well, maybe. Very scary (to me) in my maillog file, starting up and shutting down doevcot... Jan 6 16:15:59 xxserverxx dovecot: master: Dovecot v2.0.9 starting up (core dumps disabled) Jan 6 16:16:05 xxserverxx dovecot: master: Warning: Killed with signal 15 (by pid=5983 uid=0 code=kill) Jan 6 16:16:16 xxserverxx dovecot: master: Dovecot v2.0.9 starting up (core dumps disabled) Jan 6 16:21:02 xxserverxx dovecot: master: Warning: Killed with signal 15 (by pid=6056 uid=0 code=kill) Jan 6 16:23:39 xxserverxx dovecot: master: Dovecot v2.0.9 starting up (core dumps disabled) Precisely how should this 2.3.0, built from source, be properly installed and configured to actually run the new version ? Here is what I currently get from --version and -n, just running in my root directory: [root@xxserverxx ~]# dovecot --version 2.3.0 (c8b89eb) [root@xxserverxx ~]# dovecot -n # 2.3.0 (c8b89eb): /usr/local/etc/dovecot/dovecot.conf doveconf: Fatal: open(/usr/local/etc/dovecot/dovecot.conf) failed: No such file or directory (copy example configs from /usr/local/share/doc/dovecot/example-config/) Here is root's path: [root@xxserverxx ~]# env|grep -i path PATH=/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin Perhaps, of course, the new versions are running. Of course, it appears that the dovecot executable can't find config files. So why would my maillog say that the old version is running ? Perhaps it's the new executable running with some leftover config from the old version ? Obviously I have not a clue as to the following, and these are my questions: a) what determines from which directories are each and every dovecot executable runs (i.e., normal plus any oddball) ? b) under what userid is each one run ? c) what determines from which directories are each and every dovecot config file is read ? d) when I install a new version of dovecot, how do I control which versions of config and executables are used at runtime ? Is there a place in the documentation where all this is contained in one place in a nice organized table ? My mitigating workaround: = I can of course start over, creating a brand new mail server VM, WITHOUT installing dovecot 2.0.6, and then JUST download the 2.3.0 and build and install it. At least then I will only have 1 version of dovecot present on the virtual machine to deal wit
Re: Restricting sending mail to domain or group
Can the groups send and receive from outside the domain ? If so, it's going to be difficult to prevent groups from seeing each others emails because an email that originated from group A could be sent to some other domain (out on the internet), then get forwarded to a user in group B. Just a thought. On Wed, 2018-12-05 at 18:57 +0100, admin wrote: > Hi folks, > > has anybody a simple solution for the following request? > > I have a group alias (a...@company.com). > (1) Only company.com accounts should be able to send an email to everybody in > that company via a...@company.com. > (2) - rather optional: refine the restrictions, e.g. two groups, > g...@company.com and g...@company.com. Grp1 members should be able to send > mails to grp2 but not vice versa. > > What else than sieve would keep dealing with that demands as simple as > possible? > > Thanks in advance and sorry for abusing this list for this kind of „problem“ > which is not a bug. > > Regards, > -M
Re: Solr
On Wed, 2019-01-02 at 00:59 -0800, M. Balridge wrote: > > The main problem is : After some time of indexing from Dovecot, Dovecot > > returns errors (invalid SID, etc...) and Solr return "out of range > > indexes" errors > > I've been watching the progress of this thread with no small concern, mainly > because I've been tasked with providing a server-side email search facility > with a budget and manpower level that comes down to mainly *1*, i.e., me. > > I was expecting, given the strongly worded language about "just use > lucene/SOLR" and "ignore squat", that I should invest time + effort into this > JAVA nightmare that is SOLR. > > I started with squat and another word-indexor system that used out-of-band > (not a dovecot plugin) software to provide rapid (sub-second) searches through > tens-of-GB-scale mailboxes. > > Unlike what I was led to believe, the squat indexes worked surprisingly well, > once you sorted out the odd resource size (ulimit-related) issues (vsz & > friends) limitations. I did notice the "worst-case" search performance have > worryingly high O(x) increases in time, but I'd not seen anything that was a > dealbreaker. It goes without saying that various substring searches worked as > expected, for the most part. > > My experiences with SOLR were similar to Messr. Moreau's: lots of startup > errors with provided schemata files. Lots of JAVA nonsense issues. Lots of > sensitivity to WHICH Java runtime, etc, etc. I finally fixated a specific JVM, > version of SOLR, and dovecot to find the "best" working combination, only to > find that the searches didn't work out as expected. I expected to be able to > do date-ranging based searches. Didn't work. I expected to search CONTENTS of > emails, and despite many days of tweaks, I couldn't get it to index even the > basics like filenames/types of attachments, so I could exposed > attachment-based searching to my users. > > So, without rancour or antipathy, I ask the entire list: has ANYONE gotten a > Dovecot/solr-fts-plugin setup to work that provides as a BASELINE, all of the > following functionality: > > 1) The ability to search for a string within any of the structured fields > (from/subject) that returns correct results? > > 2) The ability to search for any string within the BODY of emails, including > the MIME attachment boundaries? > > 3) The ability to do "ranging" searches for structures within emails that > decompose to "dates" or other simple-numeric data? > > OPTIONALLY, and this is probably way outside of the scope of the above, > despite the fact that it's listed as a "selling point" of SOLR versus other > full text search engines: > > 4) The ability to do searches against any attachments that are able to be > post-processed and hyper-indexed by SOLR+Tika? > > - > > SOLR seems to have "brand cachet", so presumably it actually works (for > somebody). > > Dovecot has not a little "brand cachet", and for me, I have innate faith and > trust in Timo and his software. I am no stranger to the "costs" of "free" > software, in that you sacrifice your own blood, sweat, and tears just to get > these disparate pieces to work together. > > I *DO* respect that Timo has to keep the lights (and sauna) on in Finland. > Maybe there's a super-secret (no advertised prices, "carrier-only" price list) > with _Dovecot, Oy_ wherein the above ARE actually available for something less > than 6.022 x 10^23 Euros per centi-second of licencing fees. > > But please, level with us faithful users. Does this morass of Java B.S. > actually work, and if not, please just deprecate and remove this moribund > software, and stop trying to bury the only FTS plugin many of us HAVE actually > gotten to work. (Pretty please?) > > I respect that Messr. Moreau has made an earnest effort to get this JAVA B.S. > to actually work, as I have. > > He persevered where I'd given up. He's vocal about it, and now I'm chiming in > that this ornate collection of switchblades only cuts those who try to use > them. > > Respectfully, > =M= > Fascinating... SOLR says the following are powered by SOLR... https://wiki.apache.org/solr/PublicServers Perhaps if you could find out from that list which of them are using SOLR in conjunction with Dovecot... food for thought...
Re: invalid vsize-hdr
added by default, they're listed only as examples.
> # Paths are also just examples with the real defaults being based on
> configure
> # options. The paths listed here are for configure --prefix=/usr
> # --sysconfdir=/etc --localstatedir=/var
>
> # Protocols we want to be serving.
> #protocols = imap pop3 lmtp
> protocols = imap pop3
> # A comma separated list of IPs or hosts where to listen in for connections.
> # "*" listens in all IPv4 interfaces, "::" listens in all IPv6 interfaces.
> # If you want to specify non-default ports or anything more complex,
> # edit conf.d/master.conf.
> #listen = *, ::
> listen = *, ::
>
> # Base directory where to store runtime data.
> #base_dir = /var/run/dovecot/
>
> # Name of this instance. In multi-instance setup doveadm and other commands
> # can use -i to select which instance is used (an
> alternative
> # to -c ). The instance name is also added to Dovecot processes
> # in ps output.
> #instance_name = dovecot
>
> # Greeting message for clients.
> #login_greeting = Dovecot ready.
>
> # Space separated list of trusted network ranges. Connections from these
> # IPs are allowed to override their IP addresses and ports (for logging and
> # for authentication checks). disable_plaintext_auth is also ignored for
> # these networks. Typically you'd specify your IMAP proxy servers here.
> #login_trusted_networks =
> login_trusted_networks = 10.5.1.0/24
> # Space separated list of login access check sockets (e.g. tcpwrap)
> #login_access_sockets =
>
> # With proxy_maybe=yes if proxy destination matches any of these IPs,
> don't do
> # proxying. This isn't necessary normally, but may be useful if the
> destination
> # IP is e.g. a load balancer's IP.
> #auth_proxy_self =
>
> # Show more verbose process titles (in ps). Currently shows user name and
> # IP address. Useful for seeing who are actually using the IMAP processes
> # (eg. shared mailboxes or if same uid is used for multiple accounts).
> #verbose_proctitle = no
>
> # Should all processes be killed when Dovecot master process shuts down.
> # Setting this to "no" means that Dovecot can be upgraded without
> # forcing existing client connections to close (although that could also be
> # a problem if the upgrade is e.g. because of a security fix).
> #shutdown_clients = yes
>
> # If non-zero, run mail commands via this many connections to doveadm
> server,
> # instead of running them directly in the same process.
> #doveadm_worker_count = 0
> # UNIX socket or host:port used for connecting to doveadm server
> #doveadm_socket_path = doveadm-server
>
> # Space separated list of environment variables that are preserved on
> Dovecot
> # startup and passed down to all of its child processes. You can also give
> # key=value pairs to always set specific settings.
> #import_environment = TZ
>
> ##
> ## Dictionary server settings
> ##
>
> # Dictionary can be used to store key=value lists. This is used by several
> # plugins. The dictionary can be accessed either directly or though a
> # dictionary server. The following dict block maps dictionary names to URIs
> # when the server is used. These can then be referenced using URIs in format
> # "proxy::".
>
> dict {
>#quota = mysql:/etc/dovecot/dovecot-dict-sql.conf.ext
>#expire = sqlite:/etc/dovecot/dovecot-dict-sql.conf.ext
> }
>
> # Most of the actual configuration gets included below. The filenames are
> # first sorted by their ASCII value and parsed in that order. The
> 00-prefixes
> # in filenames are intended to make it easier to understand the ordering.
> !include conf.d/*.conf
>
> # A config file can also tried to be included without giving an error if
> # it's not found:
> !include_try local.conf
> ---
>
> I need assistance. I appreciate the help.
>
> Chris
>
>
>
> --
> Christopher Wensink
> IS Administrator
> Five Star Plastics, Inc
> 1339 Continental Drive
> Eau Claire, WI 54701
> Office: 715-831-1682
> Mobile: 715-563-3112
> Fax: 715-831-6075
> cwens...@five-star-plastics.com
> www.five-star-plastics.com
>
>
For what it's worth... I know less than nothing, but a quick search
turned up an apparent issue with cpanel which sounds similar:
https://forums.cpanel.net/threads/dovecot-errors.626131/
John Tulp
Re: invalid vsize-hdr
On Tue, 2021-03-09 at 19:03 -0600, Chris Wensink wrote: > We don’t have Cpanel. > > Sent from my iPhone > > > On Mar 9, 2021, at 6:47 PM, John Tulp wrote: > > > > > >> On Tue, 2021-03-09 at 16:26 -0600, Christopher Wensink wrote: > >> Good afternoon everyone, > >> > >> I have one account on our internal dovecot server that keeps throwing > >> the same repeated error: > >> > >> The user is on a Windows 10 computer running the latest version of > >> Thunderbird. Here's the log: > >> > >> > >> Mar 9 13:03:16 mario2 dovecot: imap(pstrangfeld): Error: vsize-hdr has > >> invalid size: 36 > >> Mar 9 13:09:53 mario2 dovecot: imap(user): Error: vsize-hdr has invalid > >> size: 36 > >> Mar 9 13:18:57 mario2 dovecot: imap(user): Error: vsize-hdr has invalid > >> size: 36 > >> Mar 9 13:25:09 mario2 dovecot: imap(user): Error: vsize-hdr has invalid > >> size: 36 > >> Mar 9 13:29:07 mario2 dovecot: imap(user): Error: vsize-hdr has invalid > >> size: 36 > >> Mar 9 13:31:03 mario2 dovecot: imap(user): Error: vsize-hdr has invalid > >> size: 36 > >> Mar 9 13:37:20 mario2 dovecot: imap(user): Error: vsize-hdr has invalid > >> size: 36 > >> Mar 9 13:42:26 mario2 dovecot: imap(user): Error: vsize-hdr has invalid > >> size: 36 > >> Mar 9 13:47:21 mario2 dovecot: imap(user): Error: vsize-hdr has invalid > >> size: 36 > >> Mar 9 13:50:11 mario2 dovecot: imap(user): Error: vsize-hdr has invalid > >> size: 36 > >> Mar 9 13:53:46 mario2 dovecot: imap(user): Error: vsize-hdr has invalid > >> size: 36 > >> Mar 9 13:59:40 mario2 dovecot: imap(user): Error: vsize-hdr has invalid > >> size: 36 > >> Mar 9 14:03:52 mario2 dovecot: imap(user): Error: vsize-hdr has invalid > >> size: 36 > >> Mar 9 14:08:54 mario2 dovecot: imap(user): Error: vsize-hdr has invalid > >> size: 36 > >> Mar 9 14:11:53 mario2 dovecot: imap(user): Error: vsize-hdr has invalid > >> size: 36 > >> Mar 9 14:17:02 mario2 dovecot: imap(user): Error: vsize-hdr has invalid > >> size: 36 > >> Mar 9 14:21:14 mario2 dovecot: imap(user): Error: vsize-hdr has invalid > >> size: 36 > >> Mar 9 14:24:00 mario2 dovecot: imap(user): Error: vsize-hdr has invalid > >> size: 36 > >> Mar 9 14:28:43 mario2 dovecot: imap(user): Error: vsize-hdr has invalid > >> size: 36 > >> Mar 9 14:33:00 mario2 dovecot: imap(user): Error: vsize-hdr has invalid > >> size: 36 > >> Mar 9 14:38:24 mario2 dovecot: imap(user): Connection closed (IDLE > >> running for 0.001 + waiting input for 0.001 secs, 2 B in + 10+10 B out, > >> state=wait-input) in=1578244 out=2878370 > >> Mar 9 14:40:51 mario2 dovecot: imap-login: Login: user=, > >> method=PLAIN, rip=10.5.1.77, lip=10.5.1.17, mpid=97537, TLS, > >> session= > >> Mar 9 14:41:30 mario2 dovecot: imap(user): Error: vsize-hdr has invalid > >> size: 36 > >> Mar 9 14:44:14 mario2 dovecot: imap(user): Connection closed (IDLE > >> running for 0.002 + waiting input for 0.001 secs, 2 B in + 10+10 B out, > >> state=wait-input) in=319541 out=1272761 > >> Mar 9 14:44:14 mario2 dovecot: imap-login: Login: user=, > >> method=PLAIN, rip=10.5.1.77, lip=10.5.1.17, mpid=97671, TLS, > >> session=<85YInSC95NkKBQFN> > >> Mar 9 14:46:37 mario2 dovecot: imap(user): Error: vsize-hdr has invalid > >> size: 36 > >> --- > >> > >> I have tried the following: > >> -Restarting the workstation > >> - Compacting folders in Thunderbird > >> - Repaired the Inbox Folder in Thunderbird > >> - Restarting the dovecot service > >> - Set the connections in Thunderbird Account settings to not check for > >> messages automatically (manual only) > >> - Set the user to own all folders and sub-folders in his home > >> directory on the server > >> > >> I found old message in the archives from 2017 that had the same error > >> but I did not see a posted solution. > >> > >> dovecot --version 2.2.36 (lfl0bfa63) > >> > >> config file: > >> > >> [root@mario2 dovecot]# cat dovecot.conf > >> ## Dovecot configuration file > >> >
Re: Force TCP socket disconnect on imap login failure?
i googled a little, i was just curious about your question. found a stackoverflow question which, answered, says that using gdb one can close the fd, after using lsof to find it out. oh, and your iptables command... you have the address aaa. etc with a -d, i think you mean the source ip address of the connection, -s, right ? if you want, i can provide that link. On Mon, 2022-05-23 at 17:16 -0400, Hippo Man wrote: > OOPS! I incorrectly copied and pasted the iptables command in my > previous message. Here is the correct iptables command: > > iptables -I INPUT -p tcp -m multiport --destination-port 143,993 -d > aaa.bbb.ccc.ddd -j DROP > > > This command successfully blocks *future* connections to ports 143 and > 993 from that IP address, but as I mentioned, it doesn't kill the > currently open connection. > > > > -- > hippo...@gmail.com > Take a hippopotamus to lunch today. > > > > > On Mon, May 23, 2022 at 4:54 PM Hippo Man wrote: > > Thank you, but fail2ban doesn't do what I need. Here is > why ... > > > I have used fail2ban and also my own homegrown log monitor > program for this purpose. In both cases, I can detect the > failed imap logins and then cause the following command to be > run ... > > > iptables -I INPUT -p tcp --destination-port aaa.bbb.ccc.ddd -j > DROP > > > However, this does not drop connections that are existing and > already open. It will only drop *future* connections from that > IP address to port 143. > > > > This is why I want to kill the existing connection. Even after > that "iptables" command is issued, the entity which is > connected to the imap port can continue to send more and more > imap commands. > > > If I can drop the TCP connection as soon as an imap login > fails and also issue that kind of "iptables" command, then the > client would have to reconnect in order to retry other login > attempts. Those future connections would then be successfully > blocked by that iptables rule. > > > And even if I issue a "tcpdrop" command instead of just the > "iptables" command, it doesn't kill the already-open > connection. It just force-blocks future connections. > > > I'm thinking of patching the dovecot source code to create a > personal version which immediately disconnects from the socket > after login failure. Of course, I would prefer not to do that, > if there is another way to accomplish this. > > > > -- > hippo...@gmail.com > Take a hippopotamus to lunch today. > > > > > On Mon, May 23, 2022 at 4:24 PM Jan Hugo Prins > wrote: > > Look at fail2ban. > Should be able to do that for you. > > Jan Hugo > > > On 5/23/22 21:11, Lloyd Zusman wrote: > > > I'm running dovecot 2.2.13 under Debian 8. > > I'd like to force an immediate TCP socket disconnect > > after any imap login attempt that fails. > > > > Right now, if invalid credentials are supplied > > during an imap login, the client can keep retrying > > logins with different credentials. However, I want > > to prevent that from occurring by causing the socket > > connection to be closed as soon as there is any > > failed login attempt. > > > > I haven't been able to find any dovecot > > configuration setting which could control this > > behavior, but I'm hoping that I just missed > > something. > > > > Thank you very much for any suggestions. > > > > > > -- > > hippo...@gmail.com > > Take a hippopotamus to lunch today. > > > >
Re: Dovecot mail-crypt webmail can't read encrypted messages
I find this conversation "interesting". Serveria, i think some can't see the attack scenario where the attacker's goal is simply to get email passwords, and nothing else. it would make sense for their strategy to do nothing else "bad" on the server to attract attention to their intrusion. In that case, all they would do is send back the treasure trove of passwords to their home server(s), and sit there, remaining possibly for years, hiding, exploiting the fact that dovecot, with no code modification, will allow them to grab email passwords. If a dovecot server has thousands of email accounts, that represents thousands of other devices they could target, which is worth much more to the attacker than a single dovecot server. Oh well, food for thought. On Tue, 2022-10-11 at 15:11 +0300, Serveria Support wrote: > Yes, I realize that. But I can't think of a reason this password is > necessary in the logs. It's kind of a backdoor and has to be removed > from code. Why make intruder's life easier? > > On 2022-10-11 13:39, Arjen de Korte wrote: > > Citeren Serveria Support : > > > >> Yes, there is a tiny problem letting the attacker change this value > >> back to yes and instantly get access to users' passwords in plain > >> text. Apart from that - no problems at all. :) > > > > If an attacker is able to modify your Dovecot configuration, you have > > bigger problems than leaking your users' password. Much bigger...
Re: Dovecot mail-crypt webmail can't read encrypted messages
What i'm saying is... if the attackers goal is only to get passwords, you will not be dealing with a bigger problem. In that hypothetical there would not be a bigger problem or any other problem. the only problem is passwords leaking in that case. The attacker goes out of their way to not cause any other problems on the server. they do this to avoid getting noticed by admins. as long as admin does not know there is malware on their server, the malware could run for years harvesting passwords. That would be the hypothetical attackers only goal on that server - not to bother anything, just to harvest user email passwords. and the admin will not be dealing with a "bigger problem", because the admin will not know they've been hacked, because hacker does not cause any problems on the server. admin will think everything is fine on their server. there could be email servers right now that are compromised and yielding passwords in this way, and if dovecot suddenly started writing those passwords the logs in some scrambled way - the malware would suddenly stop being able to harvest clear text passwords. hacker then could either quietly go away, or start doing something else on the machine, which the admins may or may not become aware of. might get a big surprise that they've been hacked. This type of "quiet" malware of course definitely exists in the real world, for example, on phones. Many people's phones have been hacked and they are unaware of it, and they continue using the phone for years without realizing it's been hacked. Sometimes attackers mess up the devices they hack, sometimes they don't, they just quietly use the hacked device for their own purposes (which of course are the hacks to really worry about). whenever there are big announcements of hacks to major organizations, the story always unfolds that the hackers had access for quite a while before admins became aware. this is the timeframe that really puts one's "security efforts" to the test - after machine is compromised, but before admins are aware. it makes no sense to make things easy for hackers during this time when they are operating in the target machines/network and the admins are not yet aware that devices have been compromised. in mitigating such risk, why not go for the "low hanging fruit" by simply not storing passwords on disk in clear text ? unless there is some reason why clear text passwords actually have to be written to disk. -- John Tulp tulpex On Tue, 2022-10-11 at 17:58 +0300, Odhiambo Washington wrote: > @Tulp - the attacker has to 0wn your server first. In which case they > will have found a password to SSH in - regardless of dovecot being > there or not. > > You will be dealing with a bigger problem than dovecot. > > > > On Tue, Oct 11, 2022 at 5:39 PM John Tulp > wrote: > > I find this conversation "interesting". > > Serveria, i think some can't see the attack scenario where the > attacker's goal is simply to get email passwords, and nothing > else. it > would make sense for their strategy to do nothing else "bad" > on the > server to attract attention to their intrusion. In that case, > all they > would do is send back the treasure trove of passwords to their > home > server(s), and sit there, remaining possibly for years, > hiding, > exploiting the fact that dovecot, with no code modification, > will allow > them to grab email passwords. If a dovecot server has > thousands of > email accounts, that represents thousands of other devices > they could > target, which is worth much more to the attacker than a single > dovecot > server. > > Oh well, food for thought. > > > On Tue, 2022-10-11 at 15:11 +0300, Serveria Support wrote: > > Yes, I realize that. But I can't think of a reason this > password is > > necessary in the logs. It's kind of a backdoor and has to be > removed > > from code. Why make intruder's life easier? > > > > On 2022-10-11 13:39, Arjen de Korte wrote: > > > Citeren Serveria Support : > > > > > >> Yes, there is a tiny problem letting the attacker change > this value > > >> back to yes and instantly get access to users' passwords > in plain > > >> text. Apart from that - no problems at all. :) > > > > > > If an attacker is able to modify your Dovecot > configuration, you have > > > bigger problems than leaking your users' password. Much > bigger... > > > > > -- > Best regards, > Odhiambo WASHINGTON, > Nairobi,KE > +254 7 3200 0004/+254 7 2274 3223 > "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)
Re: Backups
On Fri, 2022-12-09 at 20:03 -0800, Doug Hardie wrote: > > On Dec 4, 2022, at 1:42 PM, Doug Hardie wrote: > > > > > On Dec 3, 2022, at 11:50 PM, Doug Hardie wrote: > > > > > > I started to investigate using doveadm backup to backup my mail > > > system. I have a small number of users and the mail store is not > > > large. It uses maildir format. I setup a test system that is not > > > connected to the internet and started up dovecot. I used the > > > following command to backup one user: > > > > > > doveadm backup -u ben remote:test > > > > > > ben is the user is in the mail store. Test is the actual server > > > name. That worked just fine. The maildir was copied completely > > > (as best as I can tell with ls). Then I tried the second user: > > > > > > doveadm backup -u jean remote:test > > > > > > This gives 2 error messages: > > > > > > doveadm(jean)[]: Error: Mailbox INBOX: > > > Failed to get attribute > > > vendor/vendor.dovecot/pvt/server/sieve/files/.dovecot: Mailbox > > > attributes not enabled > > > > > > doveadm(jean)[]<0IwxIlI0jGMgUwAAZU03Dg>: Error: Remote command > > > returned error 65: ssh test doveadm dsync-server -ujean -U > > > > > > In addition, the maildir directories are created, but there are no > > > emails in any of them (e.g., cur). What is the problem with the > > > 2nd and why does it behave differently from the first? > > > > I managed to resolve most of the issue. I use pigeonhole on the > > primary server. Apparently not having pigeonhole installed on the > > test machine caused the errors above. The test machine was never > > intended to receive mail hence, no need to install pigeonhole as the > > LDA would never be used. However, when the backup was running, it > > choked on transferring the sieve file. I have no idea where the > > mentioned file resides as I couldn't find it anywhere on the primary > > server. Installing pigeonhole resolved the issue for all but one > > user. With that user, I get the following error messages: > > > > doveadm(doug)[]: Panic: file > > istream-seekable.c: line 238 (read_from_buffer): assertion failed: > > (*ret_r > 0) > > Abort > > > > doveadm(doug)[]: Error: read(test) failed: > > EOF (last sent=mail, last recv=mail_request (EOL)) > > > > doveadm(doug)[]: Error: Remote command > > returned error 134: ssh test doveadm dsync-server -udoug -U > > > > In addition, only a few cur files are transferred in INBOX. > > Repeating the backup generates the same errors and no additional > > emails are transferred. I am wondering if the problem is something > > in the INBOX. > > > > > I have pretty much reached a dead end. I am unable to determine the > cause of this abnormal termination. The logged messages don't give > much help. I can't tell if it is the primary server or test machine > that is terminating ssh. I have setup a second test machine. Both of > the test machines are raspberry pi 4s. The real backup machine is > intel. On both the test machines, 2 of the three users are backedup > properly with no errors. Only one use has the issue. It builds the > directory structure correctly then starts transferring the INBOX cur > files. Eight files are transferred correctly before it stop. It is > the same set of 8 on both test machines. That leads me to believe > there is something funny in one of the messages, but which one. There > are over 100 messages in that directory. The order of file transfer > is not by date. > > > How do I get doveadm to tell me which file is being transferred when > the problem occurs? if the problem is in one of the messages, perhaps change the test set. for convenience, can temporarily rename/move things to get them out of the way. divide test set in half, then in half again, etc., to zero in on the one causing the issue, that'll show if a particular message is problem or not. once you find a problem message, if the why isn't obvious, i'd try looking at it in hex, check permissions, etc. j
Re: Backups
-- John Tulp tulpex On Sun, 2022-12-11 at 00:05 -0800, Doug Hardie wrote: > > On Dec 10, 2022, at 11:09 AM, John Tulp wrote: > > > > > > > > On Fri, 2022-12-09 at 20:03 -0800, Doug Hardie wrote: > >>> On Dec 4, 2022, at 1:42 PM, Doug Hardie wrote: > >>> > >>>> On Dec 3, 2022, at 11:50 PM, Doug Hardie wrote: > >>>> > >>>> I started to investigate using doveadm backup to backup my mail > >>>> system. I have a small number of users and the mail store is not > >>>> large. It uses maildir format. I setup a test system that is not > >>>> connected to the internet and started up dovecot. I used the > >>>> following command to backup one user: > >>>> > >>>> doveadm backup -u ben remote:test > >>>> > >>>> ben is the user is in the mail store. Test is the actual server > >>>> name. That worked just fine. The maildir was copied completely > >>>> (as best as I can tell with ls). Then I tried the second user: > >>>> > >>>> doveadm backup -u jean remote:test > >>>> > >>>> This gives 2 error messages: > >>>> > >>>> doveadm(jean)[]: Error: Mailbox INBOX: > >>>> Failed to get attribute > >>>> vendor/vendor.dovecot/pvt/server/sieve/files/.dovecot: Mailbox > >>>> attributes not enabled > >>>> > >>>> doveadm(jean)[]<0IwxIlI0jGMgUwAAZU03Dg>: Error: Remote command > >>>> returned error 65: ssh test doveadm dsync-server -ujean -U > >>>> > >>>> In addition, the maildir directories are created, but there are no > >>>> emails in any of them (e.g., cur). What is the problem with the > >>>> 2nd and why does it behave differently from the first? > >>> > >>> I managed to resolve most of the issue. I use pigeonhole on the > >>> primary server. Apparently not having pigeonhole installed on the > >>> test machine caused the errors above. The test machine was never > >>> intended to receive mail hence, no need to install pigeonhole as the > >>> LDA would never be used. However, when the backup was running, it > >>> choked on transferring the sieve file. I have no idea where the > >>> mentioned file resides as I couldn't find it anywhere on the primary > >>> server. Installing pigeonhole resolved the issue for all but one > >>> user. With that user, I get the following error messages: > >>> > >>> doveadm(doug)[]: Panic: file > >>> istream-seekable.c: line 238 (read_from_buffer): assertion failed: > >>> (*ret_r > 0) > >>> Abort > >>> > >>> doveadm(doug)[]: Error: read(test) failed: > >>> EOF (last sent=mail, last recv=mail_request (EOL)) > >>> > >>> doveadm(doug)[]: Error: Remote command > >>> returned error 134: ssh test doveadm dsync-server -udoug -U > >>> > >>> In addition, only a few cur files are transferred in INBOX. > >>> Repeating the backup generates the same errors and no additional > >>> emails are transferred. I am wondering if the problem is something > >>> in the INBOX. > >> > >> > >> > >> > >> I have pretty much reached a dead end. I am unable to determine the > >> cause of this abnormal termination. The logged messages don't give > >> much help. I can't tell if it is the primary server or test machine > >> that is terminating ssh. I have setup a second test machine. Both of > >> the test machines are raspberry pi 4s. The real backup machine is > >> intel. On both the test machines, 2 of the three users are backedup > >> properly with no errors. Only one use has the issue. It builds the > >> directory structure correctly then starts transferring the INBOX cur > >> files. Eight files are transferred correctly before it stop. It is > >> the same set of 8 on both test machines. That leads me to believe > >> there is something funny in one of the messages, but which one. There > >> are over 100 messages in that directory. The order of file transfer > >> is not by date. > >> > >> > >> How do I get doveadm to tell me which file is being transferred when > >> the problem occurs? > > > > if the problem is in one of the messages, perhaps change the test set. >
Re: regarding ssl certificates
On Thu, 2019-03-14 at 15:08 +0100, Stephan von Krawczynski via dovecot wrote: > On Thu, 14 Mar 2019 09:51:14 -0400 > Phil Turmel via dovecot wrote: > > > On 3/14/19 7:40 AM, Stephan von Krawczynski via dovecot wrote: > > > > > Sorry I have to write this, but this is again pointing people in a fake > > > security direction. > > > > You should be sorry, because you are wrong. > > > > > The only valid authority for a certificate is the party using it. Any > > > third > > > party with unknown participants cannot be a "Certificate Authority" in its > > > true sense. This is why you should see "Let's Encrypt" simply as a cheap > > > way to fake security. It is a US entity, which means it _must_ hand out > > > all > > > necessary keys to fake certificates to the US authorities _by law_. > > > > Certificate authorities, including Let's Encrypt, operate on Certificate > > Signing Requests, not Private Keys. Some CAs do offer private key > > generation in their services for the user's convenience, but it is not > > recommended (obviously) and in no way required. Getting a CA to sign a > > CSR in no way exposes keys to that CA, and therefore not to any government. > > > > While there are weakness in the CA trust system, they aren't anything > > related to replacing a snakeoil cert with one from Let's Encrypt. > > > > [rest of ignorant rant trimmed] > > Some facts for you, as obviously you have not understood what a CA is worth > that is compromised by either hackers or "authorities". > If you want to know more, read articles about closing of CA DigiNotar, like: > https://en.wikipedia.org/wiki/DigiNotar > > Then read US export laws concerning security devices. > Then judge your US-issued certs... > > > Phil > I concur Stephan; I apologize to others if I seem ignorant. Just an FYI, a founder of Let's Encrypt, and host of it's website is Akamai, which also hosts nsa.gov, cia.gov, etc. Akami principal founders were a US guy and a US/Israeli spy guy. I once did a traceroute on the mailserver that sent me an email (from a bank); the route went over to Europe, to Virginia, back to Europe, then back to me (in the US). It made me laugh it was so obvious. The bank's service provider that provided the email service ? Akamai. Any time you're using the "internet", well, let's just say that many very intelligent people are quite naive when it comes to internet security. Encryption is just really not that much of a barrier any more. Developers are always told "don't roll your own encryption". Well, to even set up encryption software (algo selection, etc.), it's something that is beyond most of us. I always try to do at least some minimal research to see "what's what", and with encryption it always boils down to having very low confidence that what I'm setting up would take more than a few minutes for a serious "invader" to totally break through. Encryption is being used to promote a false sense of security. It could only be more obvious if NSA directly sold certificates themselves. I'm sure there would be many very intelligent folks who would happily purchase them and think they were the greatest thing since sliced bread. To close rant, in my humble opinion sure, encrypt if you like, give it your best effort, but don't assume that anything is "secure".
Re: Password issue
See comment in context below: On Fri, 2019-10-11 at 19:26 -0600, @lbutlr via dovecot wrote: > On Oct 11, 2019, at 2:00 PM, Joseph Tam wrote: > > On Fri, 11 Oct 2019, @lbutlr wrote: > > > Oct 09 16:02:50 imap-login: Info: Aborted login (auth failed, 5 attempts > in 33 secs): user=, xx.xx.xx.xx, PLAIN, TLS > >> > >> This turns out to have been caused by the MUA attempting to connect to > >> port 25 (despite clearly showing port 587 in the MUA settings). Thanks > >> to Mac/iOS account syncing, merely trying to change the port never > >> seemed to work, but removing the account entirely and recreating it got > >> it to connect to port 587 as configured. > > > > Yes, MacOSX Mail.app seems to bumble around, even ignoring your > > port settings to find the "correct" configuration. (This happens, > > for example, when there is a transient network problem). You need to > > disable "Automatically manage connections" to stop these mail readers > > from wandering around and strictly use your settings. > > There is no such setting in iOS or iPadOS though, and setting the explicit > port for SMTP and.or IMAP advanced settings didn’t change the port it > actually tried connecting go until I removed the account and re-added it. > > No problems on iOS 12 or macOS 10.14 so far. > > > This behaviour can be exploited to grab credentials using a MITM attacks, > > by convincing MacOSX clients that the target server does not support > > SSL/TLS, then providing a cleartext listener or proxy. > > I have filed a suggestion to have a setting for never connecting to a mail > server without security, but nothing so far. Perhaps I should refile it as a > critical security flaw? > > I run my mail server with no security. So-called security provides only a false sense of security, as state-sponsored attacks are beyond the ability of small organizations to prevent, since encryption to them is easy to understand with thousands of employees working on it, where for the lay person it's virtually impossible to understand well enough to thwart state-sponsored attacks that compromise the encryption configured on the lay person's machine. Once encryption is compromised, the lay person's machine would be at the mercy of the attacker. In fact, I just received an attack email this week which revealed that one of my friend's address book was used, thus I knew his machine had been compromised. Of course he had no idea, had difficulty even believing what I said was true, etc., but I digress. If I do not rely on a third party to issue a certificate to permit me to run my mail server, I can run my mail server according to my own policy. If I need to get a cert from a third party, I am subject to their policies. If a nation-state wishes to prevent a person from running their own web server, denying a digital cert would accomplish that if the digital cert were required. We've seen in the news frequently how many large tech companies are quite willing to do the bidding of governments. Digital certs are nothing more than leading down the path of total state censorship, as well as the very dangerous path of given deep-pocketed actors the ability to fake/break certs and create false transactions that for the innocent people involved become non-repudiable. How does one run a mail server without implementing security, that is - how do I know that senders sending me email are who they say they are ? Simple answer: I don't care who they are. I simply use my firewall to ban rogue IP's, even whole ranges of rogue IP's. MY policy is to assign RESPONSIBILITY to public IP addresses. If an IP address does not behave ethically towards my server, I simply DROP all packets between me and them. (Interestingly, every time I run my scripts and ban all the current bad actors, the attacks in general slow way down - which proves that the rogue IPs on not all acting independently). This approach works extremely well, especially since SO MANY datacenters, both in the US and in other countries simply laugh off abuse reports. Thus we can see that THEY are SUPPORTING rogue activity on the internet. Without this support, the rogue activity could not continue. Case in point: providers of mobile phone networks do not do proper EGRESS filtering from THEIR cell phone networks, otherwise, they would NOT ALLOW mobile phones on their network to pretend to be mail servers (MTA) and send packets to DEST PORT 25, when they should be using MAIL CLIENT ports. Thus, mobile providers provide support for hacking that they very easily could drop support for by doing proper egress filtering. Not to mention, if they see such activity, they could NOTIFY their CUSTOMER that their phone was probably hacked ! What a great service for their customers. But, sadly, they simply do not do egress filtering. Of course, allowing submits at all on port 25 is the root of the problem, but we'll be careful to not fix the real issue and simply move mail relay to it's
Re: Password issue
I am the only user and I can only connect my mail client from 1 ip address. On Sat, 2019-10-12 at 18:43 -0600, @lbutlr via dovecot wrote: > On Oct 12, 2019, at 8:10 AM, johnt...@tulpex.com wrote: > > I run my mail server with no security. > > This is extremely foolish and your “reasons” are even more foolish. If you > allow unauthenticated users to send mail from your server then you *will* be > blacklisted, and rightly so. > > (For example, it is trivial to get a free and automated certificate for your > server that allows you to encrypt all of your connections). > >
Re: Password issue
And what i meant to say by "no security" is no encryption on port 25, sending and receiving from other MTA. On Sat, 2019-10-12 at 18:43 -0600, @lbutlr via dovecot wrote: > On Oct 12, 2019, at 8:10 AM, johnt...@tulpex.com wrote: > > I run my mail server with no security. > > This is extremely foolish and your “reasons” are even more foolish. If you > allow unauthenticated users to send mail from your server then you *will* be > blacklisted, and rightly so. > > (For example, it is trivial to get a free and automated certificate for your > server that allows you to encrypt all of your connections). > >
