similar to: Running doveadm without config file?

On Fri, 29 May 2020, Sami Ketola wrote: >> # echo plaintextpass | doveadm pw -s BLF-CRYPT >> doveadm(user): Fatal: Error reading configuration: stat(/etc/dovecot/dovecot.conf) failed: No such file or directory >> >> Is there a way to circumvent the need for a configuration file? > > I don't think so. But you can specify the location of the config file with -c

> On 29. May 2020, at 23.43, Joseph Tam <jtam.home at gmail.com> wrote: > > On Fri, 29 May 2020, Sami Ketola wrote: > >>> # echo plaintextpass | doveadm pw -s BLF-CRYPT >>> doveadm(user): Fatal: Error reading configuration: stat(/etc/dovecot/dovecot.conf) failed: No such file or directory >>> >>> Is there a way to circumvent the need for a

> On 29. May 2020, at 23.09, Joseph Tam <jtam.home at gmail.com> wrote: > > > It would be useful to run the "doveadm" utility on a non-dovecot server e.g. > generating password hashes: > > # echo plaintextpass | doveadm pw -s BLF-CRYPT > doveadm(user): Fatal: Error reading configuration: stat(/etc/dovecot/dovecot.conf) failed: No such file or directory

Not really. The suggestions in the post seemed to be: 1. Tar the whole directory, which I have tried in the past, but a 130G directory takes over 18 hours to tar. 2. It was also suggested to rsync the directory, but the question was brought up, and not answered, about whether it was advisable to copy live mail, thus the need for doveadm sync/backup. Based on what I?ve read about doveadm backup,

Aki Tuomi wrote: > The use of salt, today, is to prevent the attacker from directly seeing > who has same passwords. Of course it also will make a rainbow table > attack less useful, Not just less useful, but almost infeasible. Given the use of random salts, you would have to generate (number of possible salts) rainbow tables. This drastically changes the CPU/storage tradeoffs. >

On 08/04/2020 19.14, Ben Mulvihill wrote: > Thanks for the suggestion. I think my next step will be to investigate > imapsync, or maybe isync, which also looks promising. I've recently migrated a server with imapsync with 150Gb of email and 200+ accounts. I found the trick with this was the run imapsync in several runs: Messages older than 1 year; messages older than 6 months; messages

And here is mine. All dates are todays! # doveadm -f tab fetch -u test at example.org "uid date.saved" mailbox Trash uid date.saved 6829 2018-07-18 06:04:50 6830 2018-07-18 11:10:13 6831 2018-07-18 16:16:15 6832 2018-07-18 16:16:15 6833 2018-07-18 08:22:55 6834 2018-07-18 16:16:15 6835 2018-07-18 08:47:10 6836 2018-07-18 09:12:11 6837 2018-07-18 09:53:31 6838 2018-07-18 11:03:31 SNIP a

Adi Pircalabu writes: > For us it is, we're periodically getting hammered by iOS devices that > try to open 300+ simultaneous IMAP connections for a single user from > the same IP, while the average hovers usually below 50 for the busier > mailboxes with many folders. Oh yeah, I've seen this. I think this happens when someone does a global pattern search, which causes the

Thank you, Sami. I've made that change. Regards Philip On Mon, 17 Feb 2020 at 10:50, Sami Ketola <Sami.Ketola at open-xchange.com> wrote: > Hi, > > how about switching to use autoexpunge? > > https://wiki.dovecot.org/MailboxSettings > > Sami > > > On 17 Feb 2020, at 11.01, Philip Colmer <philip.colmer at linaro.org> wrote: > > We're

> doveadm who -1 2>/dev/null | wc -l You have to redirect stderr to /dev/null because that's where the first header line is written to. The default format style (table) is inconsistent with the other formats (flow,pager,tab) that write headers and data to stdout. The following patch will pick this nit. This patch will require modifications to scripts that rely on doveadm writing

On Thu, 10 Aug 2017, Larry Rosenman wrote: > Which mail client on iOS? Sorry, maybe not iOS, but definitely MacOSX Mail app. Joseph Tam <jtam.home at gmail.com>

Hi, Why did my 'doveadm expunge' command not clear the Trash out of a mailbox? The oldest messages was put into the Trash on the 26th June 2018 as shown in the file timestamp. -rw------- 1 vmail mail 33056 Jun 26 16:46 1530031582.M768773P18242.mx10,S=33056,W=33510:2,RS # doveadm -D expunge -u testuser at example.org mailbox Trash savedbefore 2d Debug: Loading modules from

I would like to run various doveadm commands that involves all (mail) users like doveadm expunge -A mailbox Trash savedbefore 30d but any doveadm command that uses "-A" to iterate through all users will stop processing at the first account with UID<first_valid_uid. doveadm(sysdaemon): Error: user sysdaemon: Couldn't drop privileges: Mail access for users with GID 5551

Hello, given the 2015 revision date, I was curious if anyone can confirm https://wiki2.dovecot.org/Timeouts is still accurate where the 'before login' IMAP timeout remains hard coded? We're having an issue where blocks of IP's from China and similar locations are crawling IP ranges trying common login credentials, and hanging the connections open in the process. We have clients

My gdb won't cooperate and produce a backtrace so I hope this dbx stack trace gives sufficient clues as to why it crashed. It happended when I was testing a doveadm command for a user which a large collection of mboxs: # dbx doveadm (dbx) run mailbox status -u user messages \* ... long list ... igel messages=1 INBOX messages=231 doveadm(user): Panic: Trying to deinit storage

Michael Felt <michael at felt.demon.nl> writes: >> I use acme.sh for all of my LetsEncrypt certs (web & mail), it is >> written in pure shell script, so no python dependencies. >> https://github.com/Neilpang/acme.sh > > Thanks - I might look at that, but as Ralph mentions in his reply - > Let's encrypt certs are only for three months - never ending circus.

Kevin writes: > Appreciate if you could help with this. I have been trying to address this > "slow search" issue for a while with very limited success(I was trying to > implement FTS also), so I will appreciate if you could support. When I'm stumped, one of the diagnostic tools I use is process tracing. Connect via IMAP, in another window/session process trace the IMAP

Dear Colleagues, I have made mailboxes in ~/Mail available via IMAP (Dovecot 2.3.2.1), that is: "mail_location = mbox:~/Mail:INBOX=/var/mail/%u" However, I often read and modify the mailboxes locally with mutt (e.g. append and delete mails). Should I expect any problems wit Dovecot indexes etc? What if I even do "rm ~/Mail/some/mailbox", will Dovecot be mad at me? --

A mail user reported that he filled up his INBOX (despite reminders he was approaching his filesystem quota), and furthermore, he could not fix the situation because he couldn't expunge message he marked for deletion. The dovecot logs revealed the cause dovecot: imap(user): Error: open(/var/mail/user.lock) failed: Disc quota exceeded This created an impasse where a user cannot free

On Fri, 22 Jun 2018, Aki Tuomi wrote: >> Do I need to make a fresh dh.pem? The upgrade doc tells how to convert >> ssl-parameters.dat but how to make a new one? > > ... or you can make a fresh one using openssl > gendh 4096 > dh.pem This also works openssl dhparam -out dh.pem 4096 > Note that this will require quite a lot of entropy, so you should > probably