similar to: LMTP delivery segfaults when user is over quota.

On 04.03.2018 16:25, Reio Remma wrote: > Hello! > > I'm having crashes with LMTP delivery when user is over quota on the > latest CentOS 7.4 with the latest Dovecot 2.3.0.1 from Dovecot repo. > > I see the issue has been fixed on January 17, but it doesn't seem to > have made it into 2.3.0.1 (I compared with the source from >

Hi Stephan, Here it is: Program received signal SIGSEGV, Segmentation fault. p_strdup (pool=pool at entry=0x55555579bc20, str=0x6d65642e6c69616d <error: Cannot access memory at address 0x6d65642e6c69616d>) at strfuncs.c:51 51????? strfuncs.c: No such file or directory. (gdb) bt full #0? p_strdup (pool=pool at entry=0x55555579bc20, str=0x6d65642e6c69616d <error: Cannot access memory at

Got a coredump: Mar 5 15:09:42 mail-cbf dovecot: lmtp(backup at backup.invalid)<15425><2B+kCaZPnVpBPAAAplP5LA>: Fatal: master: service(lmtp): child 15425 killed with signal 6 (core dumped) #0 0x00007fea19977428 in __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 resultvar = 0 pid = 15425 selftid = 15425 #1 0x00007fea1997902a in

Hi, In my LMTP config, I have lmtp_hdr_delivery_address = none. Under 2.2, Received headers looked like this: Received: from smtp.example.com by lmtp.example.com with LMTP id +IVdKS81cFwWagAAGhmRSA ; Fri, 22 Feb 2019 17:45:19 +0000 After the update to 2.3, they look like this: Received: from smtp.example.com by lmtp.example.com with LMTP id MJbKAMFEclyKCQAAGhmRSA

That's a good thought. I'm building from the alpine repo and I indeed see pigeonhole is 0.5.5 https://git.alpinelinux.org/aports/tree/main/dovecot/APKBUILD?h=3.8-stable Let me build it with 0.5.7.2 Regards, ? Laszlo On 2019. 10. 07. 10:45, Stephan Bosch via dovecot wrote: > > > On 07/10/2019 10:17, Demonhost via dovecot wrote: >> Hi Stephan, >> >> Here it

I think alpine does not have that https://pkgs.alpinelinux.org/packages?name=dovecot*&branch=v3.8&repo=main&arch=x86_64 https://git.alpinelinux.org/aports/tree/main/dovecot/APKBUILD?h=3.8-stable What else would help? strace? On 2019. 10. 06. 23:05, Stephan Bosch via dovecot wrote: > > > On 06/10/2019 23:03, Demonhost wrote: >> Hi Stephan, >> >> I managed

Hi again, I've not heard anything further regarding this bug, so I've had a look at the code. To restate the bug in a more precise way: LMTP in dovecot treats external RFC822 email addresses in the envelope recipient and internal usernames as almost identical/interchangeable. This is incorrect and leads to issues when attempting to use director as an LMTP proxy to proxy to recipients

Hi, I've read at least one e-mail on this list about making delivered-to in lmtpd optional, but now I need this too, so I made a patch. The default remains as is now (enabled). Rationale: I would like to dsync users and I have catchall POP mailboxes (meaning: a single mailbox gets the mails for a lot of e-mail addresses). If I deliver the e-mails to Dovecot's lmtpd as the original

On 07/10/2019 10:17, Demonhost via dovecot wrote: > Hi Stephan, > > Here it is: > We still can't reproduce it here. First of all, did you update Pigeonhole along with Dovecot? This kind of weirdness can happen when Pigeonhole was compiled against a different version of Dovecot. You could compile Pigeonhole manually as well to make sure, which also gives you the opportunity to

Op 3/5/2018 om 3:14 PM schreef Ralf Hildebrandt: > Got a coredump: > > Mar 5 15:09:42 mail-cbf dovecot: lmtp(backup at backup.invalid)<15425><2B+kCaZPnVpBPAAAplP5LA>: Fatal: master: service(lmtp): child 15425 killed with signal 6 (core dumped) Hmm, yes, I think this an unnecessary RFC5322 -> RFC5321 address translation. Will look at making a fix tomorrow. Regards,

On 03/11/2017 11:48, Stephan Bosch wrote: > Hi, > > Sorry, we're in a bit of a v2.3 merge frenzy. Much of the LMTP code will be > replaced in v2.3, but I'll give the? older code a look as well. > > This can take a while though. Thank you very much for getting back to me, I can appreciate it can get hectic, and I don't wish to appear ungrateful, I wholeheartedly