Re: The end of Dovecot Director?
One of our developers wrote the whole LDAP integration in Dovecot, and I for one am not happy with this move. Jan Hugo On November 2, 2022 6:16:21 PM GMT+01:00, Dave McGuire wrote: > > It would certainly be a shame if that sort of thing started happening with > Dovecot. Since day one, the Dovecot community has always been very pleasant, > friendly, and drama-free. If forks start happening due to profiteering, that > will irrevocably change the Dovecot community, with feelings of broken trust. > > That would be a shame. > > No one decries the commercial side of Dovecot wanting to make money. Timo > and others have worked very hard on this project for many years. I was a > very early adopter of Dovecot, a refugee from (the awful) Cyrus IMAP server, > and I watched it grow up to be a highly useful and widely respected package. > Creating a commercial version to reward the developers and fund future > development is fine; I applaud it. > > But it really smells like the current move with Director is crossing a line. > > Those in charge of making this decision would do well to pay very close > attention here. > >-Dave > >On 11/2/22 12:46, Jan Hugo Prins wrote: >> I think the only thing they will gain is a community that is angry and will >> in the end leave the product / fork the complete product. >> >> Jan Hugo >> >> On November 2, 2022 5:39:53 PM GMT+01:00, Brad Schuetz >> wrote: >> >> On 11/2/22 03:54, Aki Tuomi wrote: >> >> On 02/11/2022 11:55 EET Frank Wall wrote: >> >> On 2022-11-02 09:11, Aki Tuomi wrote: >> >> You can also see the email sent by others which shows >> how you can do >> this without replication, using proxy and passdb to >> direct users to >> right backend. Which is basically what director does. >> >> It's not the same thing. >> >> It is not critical functionality. You can feasibly run a >> two-node >> dovecot system on NFS without having director. >> >> It seems to be critical enough to offer a replacement for paying >> customers, while at the same time leaving the community edition >> with no valid replacement. >> >> >> Ciao >> - Frank >> >> Can you tell me what kind of functionality you are unable to >> achieve with the passdb solution? >> >> Aki >> >> >> Can you tell us what you are gaining (other than monitarily) by removing >> a completely functionally working feature that numerous people are using? >> >> Adding new paid features is one thing (i.e. nginx), taking away a >> feature to replace it with a paid feature is something completely different. >> >> -- Brad >> >> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. > >-- >Dave McGuire, AK4HZ >New Kensington, PA > > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: The end of Dovecot Director?
I think the only thing they will gain is a community that is angry and will in the end leave the product / fork the complete product. Jan Hugo On November 2, 2022 5:39:53 PM GMT+01:00, Brad Schuetz wrote: >On 11/2/22 03:54, Aki Tuomi wrote: >>> On 02/11/2022 11:55 EET Frank Wall wrote: >>> >>> On 2022-11-02 09:11, Aki Tuomi wrote: You can also see the email sent by others which shows how you can do this without replication, using proxy and passdb to direct users to right backend. Which is basically what director does. >>> It's not the same thing. >>> It is not critical functionality. You can feasibly run a two-node dovecot system on NFS without having director. >>> It seems to be critical enough to offer a replacement for paying >>> customers, while at the same time leaving the community edition >>> with no valid replacement. >>> >>> >>> Ciao >>> - Frank >> Can you tell me what kind of functionality you are unable to achieve with >> the passdb solution? >> >> Aki > >Can you tell us what you are gaining (other than monitarily) by removing a >completely functionally working feature that numerous people are using? > >Adding new paid features is one thing (i.e. nginx), taking away a feature to >replace it with a paid feature is something completely different. > >-- >Brad > > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: ot: how to t/s TBird problems ?
Even more easy, start by examining the mail headers to see where the mail was blocked. Jhp On October 23, 2022 4:05:51 PM GMT+02:00, Aki Tuomi wrote: >Hi! > >This is very unlikely to be a dovecot issue itself. There is nothing inside >dovecot that would horde your emails for 2 hours before "delivering" them. > >You should > > - Enable mail_log plugin. This will tell you when mails are delivered, when > deleted etc, see > https://doc.dovecot.org/configuration_manual/plugins/mail_event_logging > - Examine your logs > - Check `doveadm fetch 'date.received date.sent date.saved' mailbox INBOX > '*'` ( this will print you the last email in INBOX, note the quotes) > >Aki > >> On 23/10/2022 16:49 EEST Chris Wensink >> wrote: >> >> >> Over the last several months we have seen what seems like large delays in >> email delivery as well, we get emails at 11AM that are time stamped at >> 9:10. I thought it was a networking issue, but I can’t be sure. I wish I >> knew more about coding, to look under the hood to examine things further. >> >> Sent from my iPhone >> >> > On Oct 23, 2022, at 7:17 AM, Voytek Eymont wrote: >> > >> > >> > >> >> On Sat, October 22, 2022 11:29 am, Joseph Tam wrote: >> >> >> >> I haven't seen anyone else replying, but there doesn't seem anything >> >> anomalous with the output. The session commands-repliesd is is more or >> >> less what I expect, although to make sense of this, you'll have to splice >> >> the input and output files together using timestamps to see the sequential >> >> flow of data. >> > ... >> >> Typically, if some resource limit is hit, one side or the other will >> >> create a log or notification. Your INBOX is large, but not outrageous. >> >> You >> >> can test it directly by creating smaller subsets of the INBOX messages and >> >> see if the problem goes away. >> > >> > Joseph, >> > >> > thank you very much for the follow up! >> > you won't believe it, literally minutes before your email I got this email >> > from the 'problem user' (below) >> > >> > thank you to all who responded! >> > >> > - I guess if TB debug log was enabled (as was suggested)- maybe the issue >> > would become apparent from TB debug log ? >> > >> > - I guess i should encourage POP users to switch to IMAP anyhow ? >> > >> > got this from problem user: >> > --- >> > Mozilla Thunderbird released an update which I just installed. >> > >> > Problem solved. >> > >> > I guess Tbird had a problem that the new release addressed. >> > >> > I'm sorry for the inconvenience. >> > >> > I'm mystified why my issue was only with one account. Perhaps it was >> > something to do with the size of the database. >> > >> > --- >> > yesterday it was >> > --- >> > I'm still experiencing a 40 second delay to retrieve emails for >> > xxx >> > >> > I have changed the pop port to 110 for the server but that did not >> > work at all. >> > >> > I have reinstalled my email client TBird but no change, anyway all the >> > other accounts on TBird are working ok but they are MAPI not POP. >> > >> > >> > Voytek >> > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Force TCP socket disconnect on imap login failure?
Just a few comments. - The below commands drops ALL future connections to the IMAP ports and not just the one from that specific IP address. - It all depends on the ordering of the rest of your iptables rules. A lot of iptables setups have an accept related / established in the top of the INPUT chain and then indeed the traffic will continue as long as the connection is established. If you put a correct drop rule in the top of your iptables INPUT chain it will block all traffic including any related/established. Fail2Ban is able to insert such a drop rule in the top of the INPUT chain and thereby block all further tries. This is exactly how I have setup my fail2ban and it works. The first few lines of my iptables input chain look like this: 29M 2249M f2b-dovecot tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 110,143,993,995 9969K 2545M f2b-sasl tcp -- * * 0.0.0.0/0 0.0.0.0/0 multiport dports 25,465 9691K 2788M ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 134M 257G ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED Jan Hugo Prins On 5/23/22 23:16, 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: Force TCP socket disconnect on imap login failure?
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: running alternate dovecot instances on the same server
Hello Chris, Did you find a solutions for this problem? I also have to migrate some users to Office365 and was looking at exactly the same problem. I don't have that many users, and it is totally possible to ask all users to enter their password in the migration tool, but it would be a lot easier if we could do the migration without this. Jan Hugo Prins On 3/20/22 21:36, Chris Hoogendyk wrote: I'm posting to the list, but not on the list. I presume that means a reply-all to get to me as well as the list? We have two servers (dovecot --version: 2.2.22 (fe789d2)) that handle email for two different departments. We are transitioning mail service to the University central IT. They need to move accounts in an automated fashion and therefore need a master password to our dovecot servers. However, we are running with LDAP authentication, and I understand that a master password is not possible in that configuration. Would it be possible to run an alternate dovecot process that would use local account authentication, have a master password, and use an alternate port for connecting? Ideally it would only read accounts without changing anything, and would not interfere with the operation of the other dovecot process. I'm hoping that I could copy the configuration files, make these changes, and then launch it manually without any startup scripts in /etc/inetd.conf. Oh, by the way, we are running Ubuntu 16.04 LTS and have contracts with Ubuntu Advantage for ongoing patch support. The dovecot version is from the distribution, installed with aptitude.
