[SOGo] BTS activities for Wednesday, October 21 2020

2020-10-21 Thread SOGo reporter
Title: BTS activities for Wednesday, October 21 2020





  
BTS Activities

  Home page: https://sogo.nu/bugs
  Project: SOGo
  For the period covering: Wednesday, October 21 2020

  
  
idlast updatestatus (resolution)categorysummary
	
	
	  
	
5187
	2020-10-21 02:21:39
	updated (open)
	Apple iPhone OS
	Calendar invitation does not show up in IOS calendar inbox
	
	  
	
5190
	2020-10-21 10:32:44
	updated (open)
	GUI
	Sogo Api Logon
	
	  
	
  
  


-- users@sogo.nuhttps://inverse.ca/sogo/lists

Re: [SOGo] user MOVEs message, but SOGo does DELETE instead -> mail lost

2020-10-21 Thread mj

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

2020-10-21 Thread Christian Mack
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

2020-10-21 Thread mj

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