RE: Strange problem with sieve
That looks like base64 encoding to me. Possibly your sieve script is parsing the output and truncating the data before handing it off to base64. Doug > -Original Message- > From: Peter via dovecot > Sent: Tuesday, April 9, 2024 2:03 PM > To: dovecot@dovecot.org > Subject: Re: Strange problem with sieve > > Thanks for the advise. > > Yes, the mails are automatically created. Unfortunately, the software > that generates them are out of our control. > > I supposed that it is a base64 code, but if I try to manually pass the > text into 'base64 -d' - nothing usable goes out (you can try yourself > with the first part of the mail I've posted). Maybe it is salted, but I > don't see how to decode it... > > Peter > > > On 09/04/2024 16:15, Doug via dovecot wrote: > > > >> -Original Message- > >> From: Peter via dovecot > >> Sent: Tuesday, April 9, 2024 5:18 AM > >> To: dovecot@dovecot.org > >> Subject: Strange problem with sieve > >> > >> Hello, > >> > >> I use Dovecot 2.3.20 on FreeBSD 13.2 (in jail) as a part of iRedMail > >> installation. > >> > >> Some mailboxes are configured for automatic mails processing using sieve > >> (execute :pipe) and a custom binary (started by script). The system was > >> configured and was working correctly during several weeks. > >> > >> Since ~10 days the system starts to work strangely. _*/Some/*_ mails > >> cannot be decoded anymore. No changes at our side, no updates etc. > >> > >> I dumped the content received by my binary, and it looks really strange: > >> > >> pOUc9Z33O0GbfzbW5Mrmi > >> > 3L4tTlvKfsD8wP+hc6vN1v1bv+Vx827kW+YX5n/Zxtl240erH4t+nNyeuL1zh92 > >> O0p24nYKd > >> > vbtcd1UVyBdkFwztDtrdsIexJ2/Pu71L914vnFdYto+0T7JvoCiwqGm/7v6d+78 > U > >> Jxf3lHiU > >> > 1B9QO7D1wIeD3IO3S91K68rUy/LLPv/E/6m/3Le8oUK/ovAQ7lDWoaeHow6 > >> 3/8z8ubpStTK/ > >> > >> This is a start of one mail. No headers, no readable data. > >> > >> I removed "discard;" from sieve script to put such mails in the mailbox, > >> and the mails look normally: > >> > >> Mime-Version:1.0 > >> Content-Type:multipart/mixed; boundary="=- > /3n/zeVGlN5thgeL28RKiw==" > >> > >> --=-/3n/zeVGlN5thgeL28RKiw== > >> Content-Type: multipart/alternative; boundary="=- > >> sE/MdvfJZlakBmrKkcdzCg==" > >> > >> --=-sE/MdvfJZlakBmrKkcdzCg== > >> Content-Type: multipart/related; boundary="=- > cgJVnLNlzX5YuD6yaI5USQ==" > >> > >> --=-cgJVnLNlzX5YuD6yaI5USQ== > >> Content-Transfer-Encoding: base64 > >> Content-Type: text/html; charset=utf-8 > >> > >> etc. > >> > >> Really, I have no idea about any direction to explore. The server is > >> totally under my control, I can do anything, but I have no idea how to > >> debug this situation. > >> > >> I tried to redirect such mails to another mailbox and process them > >> there, but I get the same strange data. If I connect Thunderbird to the > >> mailbox - I can read the mails correctly. So, the problem arrives at the > >> moment when the sieve system is invoked - the mail data is corrupted > >> somehow. > >> > >> Any advise will be really appreciated. > >> > >> Peter > > RE: > > --=-cgJVnLNlzX5YuD6yaI5USQ== > > Content-Transfer-Encoding: base64 > > > > What has changed is the body content of incoming emails is now base64 > encoded. Because you are trying to process these messages with a script, I'm > going to guess that the emails in question are automatically generated > somewhere. Go back to the process that is creating these emails and disable > base64 encoding. Or, add a base64 decode step to the sieve execute script. > > > > Doug > > > > ___ > > dovecot mailing list -- dovecot@dovecot.org > > To unsubscribe send an email to dovecot-le...@dovecot.org > ___ > dovecot mailing list -- dovecot@dovecot.org > To unsubscribe send an email to dovecot-le...@dovecot.org ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Users with enough rope to hang themselves
This is ... bug like. The user moves a folder inside another, the resulting path exceeds the maximum length, the folder's content is no longer accessible, the user complains. Double trouble. The user proceeded to move the parent folder. Most subfolders moved as requested. Those whose path exceeded maxlength are stuck in the origin, and the full tree is no longer accessible: it is still there, you can see it, but the mail client says it was deleted. I lost count of the number of times I had to rescue users out of this mess, by going in manually into dovecot's storage. So... +4. dovecot refuses to move folders if the resulting path exceeds the maximum length. Original Message On Apr 3, 2024, 22:37, Rupert Gallagher < r...@protonmail.com> wrote: I forgot... 3. dovecot writes folders like any other program, that is, instead of writing /.../folder.subfolder.subsubfolder/ it just writes /.../folder/subfolder/subsubfolder/ Original Message On Apr 3, 2024, 22:15, Rupert Gallagher < r...@protonmail.com> wrote: Hello, I keep finding myself in a corner with a user. He uses mail extensively, which is fine, he has a huge archive of own professional correspondence, which is fine, but he uses mail folders as if they were regular system folders, with very long paths, and keeps renaming them and moving them around, daily, breaking the mail index and ultimately wasting his own time looking around for lost mail. His Inbox holds a gargantuan of subfolders, causing both the client and the server to overwork each time he opens the mail. His Archive is a maze of subfolders with repeating names. I advised him almost daily across 20 year on how to stay organised, but he keeps abusing the service. I want to help him by limiting what he can do with folders. This is the agenda: 1. the Archive is the only place where he can create folders; 2. folder names have a maximum length of 20 characters. Can I do that with Dovecot? ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Strange problem with sieve
Thanks for the advise. Yes, the mails are automatically created. Unfortunately, the software that generates them are out of our control. I supposed that it is a base64 code, but if I try to manually pass the text into 'base64 -d' - nothing usable goes out (you can try yourself with the first part of the mail I've posted). Maybe it is salted, but I don't see how to decode it... Peter On 09/04/2024 16:15, Doug via dovecot wrote: -Original Message- From: Peter via dovecot Sent: Tuesday, April 9, 2024 5:18 AM To: dovecot@dovecot.org Subject: Strange problem with sieve Hello, I use Dovecot 2.3.20 on FreeBSD 13.2 (in jail) as a part of iRedMail installation. Some mailboxes are configured for automatic mails processing using sieve (execute :pipe) and a custom binary (started by script). The system was configured and was working correctly during several weeks. Since ~10 days the system starts to work strangely. _*/Some/*_ mails cannot be decoded anymore. No changes at our side, no updates etc. I dumped the content received by my binary, and it looks really strange: pOUc9Z33O0GbfzbW5Mrmi 3L4tTlvKfsD8wP+hc6vN1v1bv+Vx827kW+YX5n/Zxtl240erH4t+nNyeuL1zh92 O0p24nYKd vbtcd1UVyBdkFwztDtrdsIexJ2/Pu71L914vnFdYto+0T7JvoCiwqGm/7v6d+78U Jxf3lHiU 1B9QO7D1wIeD3IO3S91K68rUy/LLPv/E/6m/3Le8oUK/ovAQ7lDWoaeHow6 3/8z8ubpStTK/ This is a start of one mail. No headers, no readable data. I removed "discard;" from sieve script to put such mails in the mailbox, and the mails look normally: Mime-Version:1.0 Content-Type:multipart/mixed; boundary="=-/3n/zeVGlN5thgeL28RKiw==" --=-/3n/zeVGlN5thgeL28RKiw== Content-Type: multipart/alternative; boundary="=- sE/MdvfJZlakBmrKkcdzCg==" --=-sE/MdvfJZlakBmrKkcdzCg== Content-Type: multipart/related; boundary="=-cgJVnLNlzX5YuD6yaI5USQ==" --=-cgJVnLNlzX5YuD6yaI5USQ== Content-Transfer-Encoding: base64 Content-Type: text/html; charset=utf-8 etc. Really, I have no idea about any direction to explore. The server is totally under my control, I can do anything, but I have no idea how to debug this situation. I tried to redirect such mails to another mailbox and process them there, but I get the same strange data. If I connect Thunderbird to the mailbox - I can read the mails correctly. So, the problem arrives at the moment when the sieve system is invoked - the mail data is corrupted somehow. Any advise will be really appreciated. Peter RE: --=-cgJVnLNlzX5YuD6yaI5USQ== Content-Transfer-Encoding: base64 What has changed is the body content of incoming emails is now base64 encoded. Because you are trying to process these messages with a script, I'm going to guess that the emails in question are automatically generated somewhere. Go back to the process that is creating these emails and disable base64 encoding. Or, add a base64 decode step to the sieve execute script. Doug ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
RE: Strange problem with sieve
> -Original Message- > From: Peter via dovecot > Sent: Tuesday, April 9, 2024 5:18 AM > To: dovecot@dovecot.org > Subject: Strange problem with sieve > > Hello, > > I use Dovecot 2.3.20 on FreeBSD 13.2 (in jail) as a part of iRedMail > installation. > > Some mailboxes are configured for automatic mails processing using sieve > (execute :pipe) and a custom binary (started by script). The system was > configured and was working correctly during several weeks. > > Since ~10 days the system starts to work strangely. _*/Some/*_ mails > cannot be decoded anymore. No changes at our side, no updates etc. > > I dumped the content received by my binary, and it looks really strange: > > pOUc9Z33O0GbfzbW5Mrmi > 3L4tTlvKfsD8wP+hc6vN1v1bv+Vx827kW+YX5n/Zxtl240erH4t+nNyeuL1zh92 > O0p24nYKd > vbtcd1UVyBdkFwztDtrdsIexJ2/Pu71L914vnFdYto+0T7JvoCiwqGm/7v6d+78U > Jxf3lHiU > 1B9QO7D1wIeD3IO3S91K68rUy/LLPv/E/6m/3Le8oUK/ovAQ7lDWoaeHow6 > 3/8z8ubpStTK/ > > This is a start of one mail. No headers, no readable data. > > I removed "discard;" from sieve script to put such mails in the mailbox, > and the mails look normally: > > Mime-Version:1.0 > Content-Type:multipart/mixed; boundary="=-/3n/zeVGlN5thgeL28RKiw==" > > --=-/3n/zeVGlN5thgeL28RKiw== > Content-Type: multipart/alternative; boundary="=- > sE/MdvfJZlakBmrKkcdzCg==" > > --=-sE/MdvfJZlakBmrKkcdzCg== > Content-Type: multipart/related; boundary="=-cgJVnLNlzX5YuD6yaI5USQ==" > > --=-cgJVnLNlzX5YuD6yaI5USQ== > Content-Transfer-Encoding: base64 > Content-Type: text/html; charset=utf-8 > > etc. > > Really, I have no idea about any direction to explore. The server is > totally under my control, I can do anything, but I have no idea how to > debug this situation. > > I tried to redirect such mails to another mailbox and process them > there, but I get the same strange data. If I connect Thunderbird to the > mailbox - I can read the mails correctly. So, the problem arrives at the > moment when the sieve system is invoked - the mail data is corrupted > somehow. > > Any advise will be really appreciated. > > Peter RE: --=-cgJVnLNlzX5YuD6yaI5USQ== Content-Transfer-Encoding: base64 What has changed is the body content of incoming emails is now base64 encoded. Because you are trying to process these messages with a script, I'm going to guess that the emails in question are automatically generated somewhere. Go back to the process that is creating these emails and disable base64 encoding. Or, add a base64 decode step to the sieve execute script. Doug ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
error: no member named 'st_ctim' in 'struct stat'
Hello James, I get the exact same error when trying to compile Dovecot 2.3.21 on both Mac OS Monterey 12.7.3 and Mac OS Ventura 13.6.4. dbox-storage.c:296:32:error:no member named 'st_atim' in 'struct stat' last_temp_file_scan = stats.st_atim.tv_sec; ~ ^ dbox-storage.c:297:24:error:no member named 'st_ctim' in 'struct stat' change_time = stats.st_ctim.tv_sec; Dovecot 2.3.20 compiles without any issue. Did you ever understand how to solve the problem? Best regards Lasse Törngren ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Strange problem with sieve
Hello, I use Dovecot 2.3.20 on FreeBSD 13.2 (in jail) as a part of iRedMail installation. Some mailboxes are configured for automatic mails processing using sieve (execute :pipe) and a custom binary (started by script). The system was configured and was working correctly during several weeks. Since ~10 days the system starts to work strangely. Some mails cannot be decoded anymore. No changes at our side, no updates etc. I dumped the content received by my binary, and it looks really strange: pOUc9Z33O0GbfzbW5Mrmi 3L4tTlvKfsD8wP+hc6vN1v1bv+Vx827kW+YX5n/Zxtl240erH4t+nNyeuL1zh92O0p24nYKd vbtcd1UVyBdkFwztDtrdsIexJ2/Pu71L914vnFdYto+0T7JvoCiwqGm/7v6d+78UJxf3lHiU 1B9QO7D1wIeD3IO3S91K68rUy/LLPv/E/6m/3Le8oUK/ovAQ7lDWoaeHow63/8z8ubpStTK/ This is a start of one mail. No headers, no readable data. I removed "discard;" from sieve script to put such mails in the mailbox, and the mails look normally: Mime-Version:1.0 Content-Type:multipart/mixed; boundary="=-/3n/zeVGlN5thgeL28RKiw==" --=-/3n/zeVGlN5thgeL28RKiw== Content-Type: multipart/alternative; boundary="=-sE/MdvfJZlakBmrKkcdzCg==" --=-sE/MdvfJZlakBmrKkcdzCg== Content-Type: multipart/related; boundary="=-cgJVnLNlzX5YuD6yaI5USQ==" --=-cgJVnLNlzX5YuD6yaI5USQ== Content-Transfer-Encoding: base64 Content-Type: text/html; charset=utf-8 etc. Really, I have no idea about any direction to explore. The server is totally under my control, I can do anything, but I have no idea how to debug this situation. I tried to redirect such mails to another mailbox and process them there, but I get the same strange data. If I connect Thunderbird to the mailbox - I can read the mails correctly. So, the problem arrives at the moment when the sieve system is invoked - the mail data is corrupted somehow. Any advise will be really appreciated. Peter ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
Re: doveadm sync - I/O has stalled
We haven't found any specific bugs with lib-ssl-iostream so far, but we did find istream-multiplex bug that could cause hangs with doveadm-doveadm connections. Could be worth testing if it helps: https://github.com/dovecot/core/commit/bbe546bc637a6ac5c9e91fc8abefce62e4950d07 > On 30. Dec 2022, at 14.37, songliny wrote: > > Hi All, > We are using dovecot 2.3.19.1 > We created a account with more than 1000 mail folders in Maildir format to > reproduce the issue. > After weeks of testing, we have found a logic that may cause dsync to > encounter the error - no activity for 900 seconds > The function, dsync_ibc_stream_input, is the callback function after some > data are ready for be read. > This is part of what it does. > o_stream_cork(ibc->output); > ibc->ibc.io_callback(ibc->ibc.io_context); > o_stream_uncork(ibc->output); > Normally, ibc->ibc.io_callback(ibc->ibc.io_context) reads some data and > then processes it. > But when dsync connects over tcps, > it uses function implementations in lib-ssl-iostream to send and receive data. > And this simplified call stack would result in some data are read when > calling o_stream_uncork > > o_stream_uncork => o_stream_flush => o_stream_ssl_flush_buffer => > openssl_iostream_bio_sync => openssl_iostream_bio_input > > If some data arrive after ibc->ibc.io_callback(ibc->ibc.io_context) and > before o_stream_uncork, > o_stream_uncork would read the data and then return. > After o_stream_uncork returns, dsync then waits for new data to be read or > written. > But because the data had been read in o_stream_uncork, and there may be no > new data to be read, > dsync may then wait until timeout is met. > It may happen, but it is hard to reproduce. > If you also encounter this situation, you may try to use dsync over tcp > connection. > It does not read data when calling o_stream_uncork. > As a result, it may not stuck. > Back to the error itself, > Maybe openssl-stream should not read data when doing uncork(flush)? > Song-Lin Yang ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
