Re: [SOGo] user MOVEs message, but SOGo does DELETE instead -> mail lost
Hi Christian,
On 10/21/20 2:39 PM, Christian Mack (christian.m...@uni-konstanz.de) wrote:
Hello
I didn't see that yet.
For us it's also a first, but a very worrying first.
Does the user have privileges to add email to the destination?
If not, it should have been aborted.
It's a folder within her own mailbox. Second time, it succeeded.
Was that a move to an external email account added to SOGo?
Nope, within the same ('internal', localhost) imap dovecot mailbox.
MJ
--
users@sogo.nu
https://inverse.ca/sogo/lists
Re: [SOGo] user MOVEs message, but SOGo does DELETE instead -> mail lost
Hello I didn't see that yet. Does the user have privileges to add email to the destination? If not, it should have been aborted. Was that a move to an external email account added to SOGo? Kind regards, Christian Mack Am 21.10.20 um 11:31 schrieb mj (li...@merit.unu.edu): > Hi, > > Some additional info: > > We have (and already had) dovecot mail-log-plugin enabled > (https://doc.dovecot.org/settings/plugin/mail-log-plugin) and the logs > show NO copy action, only the DELETE. > > I verified our logging, to make sure that a COPY action would be logged, > and here is a sample, to prove that dovecot would log a copy action: > >> Thunderbird copy from INBOX to Drafts: >> Oct 21 11:17:38 mail dovecot: imap(username)<18022>: >> copy from INBOX: box=Drafts, uid=7410, >> msgid=<0.1.4b.2d8.1d6a785a415ff0...@mta-2d567506.ip4.emsmtp.us>, >> from="Newpharma" , subject=... >> Oct 21 11:17:38 mail dovecot: imap(username)<18022>: >> expunge: box=INBOX, uid=72758, >> msgid=<0.1.4b.2d8.1d6a785a415ff0...@mta-2d567506.ip4.emsmtp.us>, >> from="Newpharma" , subject=... > >> SOGo copy back from Drafts to INBOX: >> Oct 21 11:21:24 mail dovecot: imap(username)<10375>: >> copy from Drafts: box=INBOX, uid=72759, >> msgid=<0.1.4b.2d8.1d6a785a415ff0...@mta-2d567506.ip4.emsmtp.us>, >> from="Newpharma" , subject=... >> Oct 21 11:21:24 mail dovecot: imap(username)<10375>: >> delete: box=Drafts, uid=7410, >> msgid=<0.1.4b.2d8.1d6a785a415ff0...@mta-2d567506.ip4.emsmtp.us>, >> from="Newpharma" , subject=... > > So, it really seems that SOGo yesterday actually DELETED a message that > should have been copied, basically causing loss of emails for the end user. > > This looks quite disturbing. > > MJ > > > On 10/20/20 2:51 PM, mj (li...@merit.unu.edu) wrote: >> Hi, >> >> We received a complaint from one of our users, claiming she lost (and >> has lost before in the past) an email, while using the "move to" >> functionality in the SOGo webmail interface. >> >> Below is the timeline, hopfully formatting will survive: >> >>> 12:18:31.554 lda(username)<28404>: save: >>> box=INBOX, uid=9826, >>> msgid=<33gtpcvhtkczk...@ismtpd0029p1iad2.net.sendgrid>, from="zoom" >>> , subject= >>> >>> 12:19:15:000 POST >>> /SOGo/so/username/Mail/0/folderINBOX/moveMessages HTTP/1.1 >>> >>> 12:19:15:229 sogod [13007]: |SOGo| starting method 'POST' on uri >>> '/SOGo/so/tomai/Mail/0/folderINBOX/moveMessages' >>> >>> 12:19:15:380 imap(username)<27062>: delete: >>> box=INBOX, uid=9826, >>> msgid=<33gtpcvhtkczk...@ismtpd0029p1iad2.net.sendgrid>, from="zoom" >>> , subject= >>> >>> 12:19:15.382 sogod [13007]: 84.x.y.z "POST >>> /SOGo/so/username/Mail/0/folderINBOX/moveMessages HTTP/1.1" 204 0/73 >>> 0.173 - - 0 - 20 >>> >>> 12:20:26.569 imap(username)<28783>: expunge: >>> box=INBOX, uid=9826, >>> msgid=<33gtpcvhtkczk...@ismtpd0029p1iad2.net.sendgrid>, from="zoom" >>> , subject= >> >> and after this, the email is gone. >> >> She signed up again for the same zoom thing, received the email again, >> and this time the move to folder succeeded. >> >> She claims this has happened to her before, with a completely >> different (internal) email. >> >> If it actually happened like this, it would of course be very rather >> disturbing... >> >> The logs seem to backup her story: there is a moveMessages from SOGo, >> but nothing move-like is logged at the imap level, only a delete. >> >> We are slightly worried. :-| >> >> I will turn on ImapDebugEnabled = YES tonight, but what else to do? >> How to investigate this further? Has anyone ever seen something similar? >> >> She claims the first time she noticed this, was after we upgraded from >> latest 2.x to 4.x. >> >> Thanks! >> MJ -- Christian Mack Universität Konstanz Kommunikations-, Informations-, Medienzentrum (KIM) Abteilung IT-Dienste Forschung und Lehre 78457 Konstanz +49 7531 88-4416 smime.p7s Description: S/MIME Cryptographic Signature
Re: [SOGo] user MOVEs message, but SOGo does DELETE instead -> mail lost
Hi, Some additional info: We have (and already had) dovecot mail-log-plugin enabled (https://doc.dovecot.org/settings/plugin/mail-log-plugin) and the logs show NO copy action, only the DELETE. I verified our logging, to make sure that a COPY action would be logged, and here is a sample, to prove that dovecot would log a copy action: Thunderbird copy from INBOX to Drafts: Oct 21 11:17:38 mail dovecot: imap(username)<18022>: copy from INBOX: box=Drafts, uid=7410, msgid=<0.1.4b.2d8.1d6a785a415ff0...@mta-2d567506.ip4.emsmtp.us>, from="Newpharma" , subject=... Oct 21 11:17:38 mail dovecot: imap(username)<18022>: expunge: box=INBOX, uid=72758, msgid=<0.1.4b.2d8.1d6a785a415ff0...@mta-2d567506.ip4.emsmtp.us>, from="Newpharma" , subject=... SOGo copy back from Drafts to INBOX: Oct 21 11:21:24 mail dovecot: imap(username)<10375>: copy from Drafts: box=INBOX, uid=72759, msgid=<0.1.4b.2d8.1d6a785a415ff0...@mta-2d567506.ip4.emsmtp.us>, from="Newpharma" , subject=... Oct 21 11:21:24 mail dovecot: imap(username)<10375>: delete: box=Drafts, uid=7410, msgid=<0.1.4b.2d8.1d6a785a415ff0...@mta-2d567506.ip4.emsmtp.us>, from="Newpharma" , subject=... So, it really seems that SOGo yesterday actually DELETED a message that should have been copied, basically causing loss of emails for the end user. This looks quite disturbing. MJ On 10/20/20 2:51 PM, mj (li...@merit.unu.edu) wrote: Hi, We received a complaint from one of our users, claiming she lost (and has lost before in the past) an email, while using the "move to" functionality in the SOGo webmail interface. Below is the timeline, hopfully formatting will survive: 12:18:31.554 lda(username)<28404>: save: box=INBOX, uid=9826, msgid=<33gtpcvhtkczk...@ismtpd0029p1iad2.net.sendgrid>, from="zoom" , subject= 12:19:15:000 POST /SOGo/so/username/Mail/0/folderINBOX/moveMessages HTTP/1.1 12:19:15:229 sogod [13007]: |SOGo| starting method 'POST' on uri '/SOGo/so/tomai/Mail/0/folderINBOX/moveMessages' 12:19:15:380 imap(username)<27062>: delete: box=INBOX, uid=9826, msgid=<33gtpcvhtkczk...@ismtpd0029p1iad2.net.sendgrid>, from="zoom" , subject= 12:19:15.382 sogod [13007]: 84.x.y.z "POST /SOGo/so/username/Mail/0/folderINBOX/moveMessages HTTP/1.1" 204 0/73 0.173 - - 0 - 20 12:20:26.569 imap(username)<28783>: expunge: box=INBOX, uid=9826, msgid=<33gtpcvhtkczk...@ismtpd0029p1iad2.net.sendgrid>, from="zoom" , subject= and after this, the email is gone. She signed up again for the same zoom thing, received the email again, and this time the move to folder succeeded. She claims this has happened to her before, with a completely different (internal) email. If it actually happened like this, it would of course be very rather disturbing... The logs seem to backup her story: there is a moveMessages from SOGo, but nothing move-like is logged at the imap level, only a delete. We are slightly worried. :-| I will turn on ImapDebugEnabled = YES tonight, but what else to do? How to investigate this further? Has anyone ever seen something similar? She claims the first time she noticed this, was after we upgraded from latest 2.x to 4.x. Thanks! MJ -- users@sogo.nu https://inverse.ca/sogo/lists
[SOGo] user MOVEs message, but SOGo does DELETE instead -> mail lost
Hi, We received a complaint from one of our users, claiming she lost (and has lost before in the past) an email, while using the "move to" functionality in the SOGo webmail interface. Below is the timeline, hopfully formatting will survive: 12:18:31.554lda(username)<28404>: save: box=INBOX, uid=9826, msgid=<33gtpcvhtkczk...@ismtpd0029p1iad2.net.sendgrid>, from="zoom" , subject= 12:19:15:000POST /SOGo/so/username/Mail/0/folderINBOX/moveMessages HTTP/1.1 12:19:15:229sogod [13007]: |SOGo| starting method 'POST' on uri '/SOGo/so/tomai/Mail/0/folderINBOX/moveMessages' 12:19:15:380imap(username)<27062>: delete: box=INBOX, uid=9826, msgid=<33gtpcvhtkczk...@ismtpd0029p1iad2.net.sendgrid>, from="zoom" , subject= 12:19:15.382sogod [13007]: 84.x.y.z "POST /SOGo/so/username/Mail/0/folderINBOX/moveMessages HTTP/1.1" 204 0/73 0.173 - - 0 - 20 12:20:26.569 imap(username)<28783>: expunge: box=INBOX, uid=9826, msgid=<33gtpcvhtkczk...@ismtpd0029p1iad2.net.sendgrid>, from="zoom" , subject= and after this, the email is gone. She signed up again for the same zoom thing, received the email again, and this time the move to folder succeeded. She claims this has happened to her before, with a completely different (internal) email. If it actually happened like this, it would of course be very rather disturbing... The logs seem to backup her story: there is a moveMessages from SOGo, but nothing move-like is logged at the imap level, only a delete. We are slightly worried. :-| I will turn on ImapDebugEnabled = YES tonight, but what else to do? How to investigate this further? Has anyone ever seen something similar? She claims the first time she noticed this, was after we upgraded from latest 2.x to 4.x. Thanks! MJ -- users@sogo.nu https://inverse.ca/sogo/lists
