SIS and tracing the origin of an attachment
Hi All, I'm trying to trace an attachment within an SIS subdirectory to the email message(s) that link to it. I say messages because I'm also using dovecot dedup. My understanding is the linked file name is the hash value of the attachments contents concatenated with the GUID of the email message. I have had marginal success with a message I created myself. Example: I generated an email with two attachments. Here are the links in my attachment directory. ./26/c5/26c5c540d41779d83d2f5388041d05c67d720d9a-73eca8051acd27627231f2bc99a3 ./65/cd/65cd73112a489ef07f17ed5740aa60358e2dd3fb-74eca8051acd27627231f2bc99a3 In my sent folder the actual GUID of the message is 75eca8051acd27627231f2bc99a3. So the GUID of the attachment is based on the GUID of the message, but not exact. The second hex byte seems to be decremented as an offset of the attachment index from the GUID of the message. At least in my one example. # doveadm dump /mailstore/doug/mail/mailboxes/Sent/dbox-Mails/dovecot.index | grep guid | tail -1 - guid: 75eca8051acd27627231f2bc99a3 With that actual GUID I can find the message with a search: # doveadm search -u doug mailbox Sent guid 75eca8051acd27627231f2bc99a3 doug e5711f1cf2c9294f7109059b96e4 53526 Now let's try to track down another email when only the HASH-GUID value is known. Here is one randomly picked. ./00/a2/00a2d5de3e41053d59bd10084826bbe094aa1c59-57857b09d1a327627e26f2bc99a3 # doveadm search -A mailbox '*' guid 57857b09d1a327627e26f2bc99a3 # doveadm search -A mailbox '*' guid 58857b09d1a327627e26f2bc99a3 # doveadm search -A mailbox '*' guid 59857b09d1a327627e26f2bc99a3 I repeated this incrementing and decrementing from 5085... through 5f85... and never located the message. This seems like it should be trivial but I've been struggling with it for days. The GUID isn't random, there must be a way to track the attachment back. What am I missing? And for those wondering why, our virus scanner flagged a number of attachments, some with several links, and I want ask the users to delete the offending messages so I can purge them from the server. If I can find the emails I can give them the mail folder, date/time, and subject of the message. -- Doug
Re: XOAUTH2 submission - "500 5.5.2 Line too long"
On 8.3.2022 18.33, Patrick Nagel wrote: Hi, On Tuesday, 8 March 2022 16:12:48 CET Rosario Esposito wrote: I setup a dovecot submission server, using xoauth2 authentication. My roundcube webmail points to dovecot submission. In roundcube smtp logs, I see: [...] [08-Mar-2022 15:47:16 +0100]: Send: AUTH XOAUTH2 dXNlcj1yZXNwb3NpdAFhdXRoPWJlYXJlci<<<...*very long base64 string*>>> [08-Mar-2022 15:47:16 +0100]: Recv: 500 5.5.2 Line too long Apparently, the problem came out after upgrading from dovecot 2.3.17 to 2.3.18 Interesting, the changelog (https://github.com/dovecot/core/releases/tag/2.3.18) says: - submission-login: Authentication does not accept OAUTH2 token (or other very long credentials) because it considers the line to be too long. But sorry, not much else I can contribute, I'm just a random passerby. Unfortunately there were some issues with the initial fix to this. There were fixups after the release of 2.3.18 to community. https://github.com/dovecot/core/commit/667e206a017a48cf623f95f9837e79760be6309b (and commits right before)
Re: XOAUTH2 submission - "500 5.5.2 Line too long"
Hi, On Tuesday, 8 March 2022 16:12:48 CET Rosario Esposito wrote: > I setup a dovecot submission server, using xoauth2 authentication. > My roundcube webmail points to dovecot submission. > In roundcube smtp logs, I see: > [...] > [08-Mar-2022 15:47:16 +0100]: Send: AUTH XOAUTH2 > dXNlcj1yZXNwb3NpdAFhdXRoPWJlYXJlci<<<...*very long base64 string*>>> > [08-Mar-2022 15:47:16 +0100]: Recv: 500 5.5.2 Line too long > > Apparently, the problem came out after upgrading from dovecot 2.3.17 to > 2.3.18 Interesting, the changelog (https://github.com/dovecot/core/releases/tag/2.3.18) says: - submission-login: Authentication does not accept OAUTH2 token (or other very long credentials) because it considers the line to be too long. But sorry, not much else I can contribute, I'm just a random passerby. Patrick.
XOAUTH2 submission - "500 5.5.2 Line too long"
Hello, I setup a dovecot submission server, using xoauth2 authentication. My roundcube webmail points to dovecot submission. In roundcube smtp logs, I see: [08-Mar-2022 15:47:16 +0100]: Recv: 250-PIPELINING [08-Mar-2022 15:47:16 +0100]: Recv: 250 XCLIENT ADDR PORT PROTO HELO LOGIN SESSION TTL TIMEOUT FORWARD [08-Mar-2022 15:47:16 +0100]: Send: AUTH XOAUTH2 dXNlcj1yZXNwb3NpdAFhdXRoPWJlYXJlci<<<...*very long base64 string*>>> [08-Mar-2022 15:47:16 +0100]: Recv: 500 5.5.2 Line too long [08-Mar-2022 15:47:16 +0100]: Send: ** [4] [08-Mar-2022 15:47:16 +0100]: Recv: 221 2.0.0 Bye And, in dovecot logs I found: Mar 8 15:47:17 ### dovecot[97376]: submission-login: Debug: smtp-server: conn 172.18.6.100:38658 [1]: command EHLO: 250 reply: Sent: 250-###.<#> 8BITMIME AUTH PLAIN OAUTHBEARER XOAUTH2 BURL imap CHUNKING ENHANCEDSTATUSCODES SIZE PIPELINING XCLIENT ADDR PORT PROTO HELO LOGIN SESSION TTL TIMEOUT FORWARD Mar 8 15:47:17 ### dovecot[97376]: submission-login: Debug: smtp-server: conn 172.18.6.100:38658 [1]: command EHLO: Finished Mar 8 15:47:17 ### dovecot[97376]: submission-login: Debug: smtp-server: conn 172.18.6.100:38658 [1]: command EHLO: Destroy Mar 8 15:47:17 ### dovecot[97376]: submission-login: Debug: smtp-server: conn 172.18.6.100:38658 [1]: command EHLO: 250 reply: Destroy Mar 8 15:47:17 ### dovecot[97376]: submission-login: Debug: smtp-server: conn 172.18.6.100:38658 [1]: Trigger output Mar 8 15:47:17 ### dovecot[97376]: submission-login: Debug: smtp-server: conn 172.18.6.100:38658 [1]: No more commands pending Mar 8 15:47:17 ### dovecot[97376]: submission-login: Debug: smtp-server: conn 172.18.6.100:38658 [1]: Sending replies Mar 8 15:47:17 ### dovecot[97376]: submission-login: Debug: smtp-server: conn 172.18.6.100:38658 [1]: No more commands pending Mar 8 15:47:17 ### dovecot[97376]: submission-login: Debug: smtp-server: conn 172.18.6.100:38658 [1]: Client sent invalid command: Command line is too long Apparently, the problem came out after upgrading from dovecot 2.3.17 to 2.3.18 Any ideas ?
Re: Replicator Issues on Large Mail Boxes
Hi, > simply put replication works fine on smaller email boxes without issues. > > dsync also works when run manually, longest sync is 60 secords or so > when using dsync so need replicator bumped up ? You can configure dsync parameters for the replicator to adjust the time limit, e.g.: replication_dsync_parameters = -d -N -l 120 -U best regards, Carsten
