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)[]<McRYOFI0jGN1MwAAmC+70w>: 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?
-- Doug
On Dec 3, 2022, at 11:50 PM, Doug Hardie <bc979@lafn.org> 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)[]<McRYOFI0jGN1MwAAmC+70w>: 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)[]<NAfSLTASjWNWTAAAmC+70w>: Panic: file istream-seekable.c: line 238 (read_from_buffer): assertion failed: (*ret_r > 0) Abort
doveadm(doug)[]<C2AvHjASjWN2gQAAZU03Dg>: Error: read(test) failed: EOF (last sent=mail, last recv=mail_request (EOL))
doveadm(doug)[]<C2AvHjASjWN2gQAAZU03Dg>: 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.
-- Doug
On Dec 4, 2022, at 1:42 PM, Doug Hardie <bc979@lafn.org> wrote:
On Dec 3, 2022, at 11:50 PM, Doug Hardie <bc979@lafn.org> 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)[]<McRYOFI0jGN1MwAAmC+70w>: 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)[]<NAfSLTASjWNWTAAAmC+70w>: Panic: file istream-seekable.c: line 238 (read_from_buffer): assertion failed: (*ret_r > 0) Abort
doveadm(doug)[]<C2AvHjASjWN2gQAAZU03Dg>: Error: read(test) failed: EOF (last sent=mail, last recv=mail_request (EOL))
doveadm(doug)[]<C2AvHjASjWN2gQAAZU03Dg>: 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?
On Fri, 2022-12-09 at 20:03 -0800, Doug Hardie wrote:
On Dec 4, 2022, at 1:42 PM, Doug Hardie <bc979@lafn.org> wrote:
On Dec 3, 2022, at 11:50 PM, Doug Hardie <bc979@lafn.org> 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)[]<McRYOFI0jGN1MwAAmC+70w>: 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)[]<NAfSLTASjWNWTAAAmC+70w>: Panic: file istream-seekable.c: line 238 (read_from_buffer): assertion failed: (*ret_r > 0) Abort
doveadm(doug)[]<C2AvHjASjWN2gQAAZU03Dg>: Error: read(test) failed: EOF (last sent=mail, last recv=mail_request (EOL))
doveadm(doug)[]<C2AvHjASjWN2gQAAZU03Dg>: 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
Interesting idea. I am not sure just how to go about that. Just deleting the files from the cur directory still leaves the various indexes unchanged. I don't see any way in doveadm to clean that up. I believe doveadm backup will build a new user that can be used to play around with. I don't want to delete anything from the real user's mailbox. Unfortunately, I have captured all the transmissions between the two systems. It doesn't show anything of value since everything is encrypted. I tried using the tcp transfer, but couldn't get it to work.
-- Doug
On Dec 10, 2022, at 11:09 AM, John Tulp <johntulp@tulpholdings.com> wrote:
On Fri, 2022-12-09 at 20:03 -0800, Doug Hardie wrote:
On Dec 4, 2022, at 1:42 PM, Doug Hardie <bc979@lafn.org> wrote:
On Dec 3, 2022, at 11:50 PM, Doug Hardie <bc979@lafn.org> 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)[]<McRYOFI0jGN1MwAAmC+70w>: 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)[]<NAfSLTASjWNWTAAAmC+70w>: Panic: file istream-seekable.c: line 238 (read_from_buffer): assertion failed: (*ret_r > 0) Abort
doveadm(doug)[]<C2AvHjASjWN2gQAAZU03Dg>: Error: read(test) failed: EOF (last sent=mail, last recv=mail_request (EOL))
doveadm(doug)[]<C2AvHjASjWN2gQAAZU03Dg>: 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
On Dec 10, 2022, at 11:09 AM, John Tulp <johntulp@tulpholdings.com> wrote:
On Fri, 2022-12-09 at 20:03 -0800, Doug Hardie wrote:
On Dec 4, 2022, at 1:42 PM, Doug Hardie <bc979@lafn.org> wrote:
On Dec 3, 2022, at 11:50 PM, Doug Hardie <bc979@lafn.org> 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)[]<McRYOFI0jGN1MwAAmC+70w>: 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)[]<NAfSLTASjWNWTAAAmC+70w>: Panic: file istream-seekable.c: line 238 (read_from_buffer): assertion failed: (*ret_r > 0) Abort
doveadm(doug)[]<C2AvHjASjWN2gQAAZU03Dg>: Error: read(test) failed: EOF (last sent=mail, last recv=mail_request (EOL))
doveadm(doug)[]<C2AvHjASjWN2gQAAZU03Dg>: 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.
I have found the cause for the errors: Somehow I had overlooked the -D argument to doveadm. That is really helpful in diagnosing backup issues. I discovered that there was one email that was 130+ MB. Doveadm cannot handle that. It appears there is a message size limit somewhere. I don't know if that is changeable or not. Anyway, removing that email from the mailbox, deleting it from the Trash, and purging the account enabled backup to work properly. I don't get too many emails that large, but it does happen occasionally. How do I go about telling dovecot to handle those?
-- Doug
-- John Tulp <johntulp@tulpex.com> tulpex
On Sun, 2022-12-11 at 00:05 -0800, Doug Hardie wrote:
On Dec 10, 2022, at 11:09 AM, John Tulp <johntulp@tulpholdings.com> wrote:
On Fri, 2022-12-09 at 20:03 -0800, Doug Hardie wrote:
On Dec 4, 2022, at 1:42 PM, Doug Hardie <bc979@lafn.org> wrote:
On Dec 3, 2022, at 11:50 PM, Doug Hardie <bc979@lafn.org> 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)[]<McRYOFI0jGN1MwAAmC+70w>: 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)[]<NAfSLTASjWNWTAAAmC+70w>: Panic: file istream-seekable.c: line 238 (read_from_buffer): assertion failed: (*ret_r > 0) Abort
doveadm(doug)[]<C2AvHjASjWN2gQAAZU03Dg>: Error: read(test) failed: EOF (last sent=mail, last recv=mail_request (EOL))
doveadm(doug)[]<C2AvHjASjWN2gQAAZU03Dg>: 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.
I have found the cause for the errors: Somehow I had overlooked the -D argument to doveadm. That is really helpful in diagnosing backup issues. I discovered that there was one email that was 130+ MB. Doveadm cannot handle that. It appears there is a message size limit somewhere. I don't know if that is changeable or not. Anyway, removing that email from the mailbox, deleting it from the Trash, and purging the account enabled backup to work properly. I don't get too many emails that large, but it does happen occasionally. How do I go about telling dovecot to handle those?
-- Doug
sorry, no clue. i did find this link quickly...
https://doc.dovecot.org/configuration_manual/quota/
looks like the following section near the bottom of page may apply ?
"Maximum Saved Mail Size"
again, sorry, email is not "my thing" (chuckle inserted here).
On Dec 11, 2022, at 12:42 AM, John Tulp <johntulp@tulpex.com> wrote:
-- John Tulp <johntulp@tulpex.com> tulpex
On Sun, 2022-12-11 at 00:05 -0800, Doug Hardie wrote:
On Dec 10, 2022, at 11:09 AM, John Tulp <johntulp@tulpholdings.com> wrote:
On Fri, 2022-12-09 at 20:03 -0800, Doug Hardie wrote:
On Dec 4, 2022, at 1:42 PM, Doug Hardie <bc979@lafn.org> wrote:
On Dec 3, 2022, at 11:50 PM, Doug Hardie <bc979@lafn.org> 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)[]<McRYOFI0jGN1MwAAmC+70w>: 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)[]<NAfSLTASjWNWTAAAmC+70w>: Panic: file istream-seekable.c: line 238 (read_from_buffer): assertion failed: (*ret_r > 0) Abort
doveadm(doug)[]<C2AvHjASjWN2gQAAZU03Dg>: Error: read(test) failed: EOF (last sent=mail, last recv=mail_request (EOL))
doveadm(doug)[]<C2AvHjASjWN2gQAAZU03Dg>: 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.
I have found the cause for the errors: Somehow I had overlooked the -D argument to doveadm. That is really helpful in diagnosing backup issues. I discovered that there was one email that was 130+ MB. Doveadm cannot handle that. It appears there is a message size limit somewhere. I don't know if that is changeable or not. Anyway, removing that email from the mailbox, deleting it from the Trash, and purging the account enabled backup to work properly. I don't get too many emails that large, but it does happen occasionally. How do I go about telling dovecot to handle those?
-- Doug
sorry, no clue. i did find this link quickly...
https://doc.dovecot.org/configuration_manual/quota/
looks like the following section near the bottom of page may apply ?
"Maximum Saved Mail Size"
again, sorry, email is not "my thing" (chuckle inserted here).
As best as I can tell, that requires quota to be setup as plugin which I do not. Also, it indicates that the default value is 0 which is unlimited.
-- Doug
On 12/11/22 01:42, John Tulp wrote:
sorry, no clue. i did find this link quickly...
https://doc.dovecot.org/configuration_manual/quota/
looks like the following section near the bottom of page may apply ?
"Maximum Saved Mail Size"
I was looking into this on my server. My config has the 100MB value, which came from dovecot defaults as I did not set it. Looks like none of the messages in my install is that big ... "find /var/vmail -size +99M" returns nothing. I have a configured limit in postfix of 50MB, so I am probably never going to exceed the dovecot limit.
Looking over that link, I see the "quota_vsizes" option. I was unable to find anything about this other than "Indicates that the quota plugin should use virtual sizes rather than physical sizes when calculating message sizes." Can anyone tell me what that actually means in simple terms? There is no info that I could find about how it actually calculates the virtual size.
Thanks, Shawn
participants (4)
-
Doug Hardie
-
John Tulp
-
John Tulp
-
Shawn Heisey