We use imapsync to sync account.
The imap APPEND command on Axigen can’t update internal timestamp of messages and retrivieng message from IMAP is sorted in a bad way.
For example:
Stat Connected.
Recv 20/04/2022 14:49:49: * OK AXIGEN IMAP4rev1 service is ready<EOL>
Sent 20/04/2022 14:49:49: C1 CAPABILITY<EOL>
Recv 20/04/2022 14:49:49: * CAPABILITY IMAP4rev1 CHILDREN IDLE LITERAL+ MULTIAPPEND SPECIAL-USE NAMESPACE UIDPLUS QUOTA XLIST ... leted<EOL>
Sent 20/04/2022 14:49:49: C1 LOGIN monitoring@PostMaster ****<EOL>
Recv 20/04/2022 14:49:49: C1 OK LOGIN completed<EOL>
Sent 20/04/2022 14:49:49: C2 CAPABILITY<EOL>
Recv 20/04/2022 14:49:49: * CAPABILITY IMAP4rev1 CHILDREN IDLE LITERAL+ MULTIAPPEND SPECIAL-USE NAMESPACE UIDPLUS QUOTA XLIST ... leted<EOL>
Sent 20/04/2022 14:49:49: C3 SELECT "INBOX/REPORTS"<EOL>
Recv 20/04/2022 14:49:49: * FLAGS (\Seen \Answered \Flagged \Deleted \Draft $MDNSent $Forwarded $Completed)<EOL>
* 8669 EXISTS< ... leted<EOL>
Mails in mailbox: 8669
---
Processing Mail: 8669
Sent 20/04/2022 14:49:49: C4 FETCH 8669 (BODY.PEEK[])<EOL>
Recv 20/04/2022 14:49:49: * 8669 FETCH (BODY[] {7560}<EOL>
Delivered-To: reports@init-s.it<EOL>
Received: by 2002:ab4:a110:0:0:0 ... 8.2022.04.
Recv 20/04/2022 14:49:49: 17.19.01.01<EOL>
for <reports@init-s.it><EOL>
(version=TLS1_3 cipher=TLS_AES_256_GCM_S ... <reports@
Recv 20/04/2022 14:49:49: init-s.it>;<EOL>
Mon, 18 Apr 2022 04:01:00 +0200 (CEST)<EOL>
Received: from zimbra.metaprogettazione. ... <EOL>
<EOL>
Recv 20/04/2022 14:49:49: )<EOL>
C4 OK FETCH completed<EOL>
Sender: MAILER-DAEMON@zimbra.metaprogettazione.com
Subject: Undelivered Mail Returned to Sender
Timestamp: 18/04/2022 04:01:00
Message age: 58 hours
Message too old. Stopping search.
Sent 20/04/2022 14:49:49: C5 LOGOUT<EOL>
Recv 20/04/2022 14:49:49: * BYE AXIGEN IMAP4rev1 service is logging out<EOL>
C5 OK Done LOGOUT<EOL>
Stat Disconnected.
Stat Disconnected.
This sort is different from what is visible on webmail (there are infact many newer messages).
I’m sorry but could not understand exactly what are you saying.
Could you please provide more details?
For example, I’ve not seen any IMAP APPEND command into the logs you have shared above.
This is why I have to ask for step by step procedure to reproduce what are you considering a bad IMAP implementation so we could check it on our side as well.
sorry I wasn’t clear.
Situation: we have an account on Axigen synced with imapsync from GMAIL.
Of course headers are ok.
The log I’ve provided is to show IMAP command to get messages sorted by the server: the log shows that the first message sorted by the server is a message more than 2 days old (Timestamp: 18/04/2022 04:01:00) - of course there are newer messages, and the sort is ok in the webmail.
From my understanding the job of imapsync is to keep in sync 2 accounts (but one-way-synchronization from source to destination and avoiding duplicates on destination via “Message-Id:” and “Received:” headers ).
I do not see the relevance between how “messages are sorted by the server” and the imapsync main job to identify the missing messages from destination and transferring them from source.
Should we have to understand that the source is Axigen?
If yes, how are the messages you are reffering beeing populated into the accont from Axigen?
If by SMTP: than their internal date will be based on the time the server received them.
If by IMAPAPPEND: than please reffer to RFC-9051 details where it is mentioned that if an IMAP client (and I’m not reffering here to imapsync) needs to set the internal date for the new message it likes to append than the information should be present into the APPEND command via OPTIONAL date/time string
As you see I’m still not on the same page with you so any additional information, or, better, step-by-step instructions to replicate your problem will be appreciated.
Hello, and thank you again for your message.
The source is a Google Workspace Account.
The destination is an Axigen Account.
This is the command we use with imapsync:
We’ve tried both “idatefromheader” and “syncinternaldates” (the last one is the default one).
So I think we can assume that imapsync is always using “APPEND” command with setting internal date.
We sync every 10 minutes.
After the sync, the AXIGEN account is checked with a PRTG script (the one who produced the log you saw earlier - ref IMAP Sensor | PRTG Manual) with a time limit check: for example, search a message not older than 1 day.
This tool connects to AXIGEN and retrieve messages from the last one:
After the retrive of one message, it checks for filter rules (not shown in the log) and the age of the message.
So: if we keep in sync every ten minutes the two accounts, we cannot encounter any problem.
But if we sync the 2 accounts once a day we encounter problem that sensor cannot work because the message order in IMAP is not respecting a last-arrival-date sort.
Now, I think there can be 2 kinds of problems:
imapsync is not successfully setting the internal date and the imapserver is serving messages sorted by the internaldate (that is different from the headers one, due the sync)
Axigen is not sorting messages in imap with last-arrival order, but this is weird because it appears to be correct if we sync every 10 minutes
I hope I was more clear, don’t hesitate to let me any info you may need.
Thank you
2/ What happens if you choose to sync at a different interval, let’s say at 2 hours?
3/ How many new messages are usually expected to be found in the source server? Like 1 per day, x per hour, etc.
I’m trying here to understand why the PRTG is missing the messages from the rule mentioned above : “search for message not older than 1 day”
4/ If you are syncing at 1 day could you please modify the --maxage value used for imapsync from 1 to 2 and see if anything changed? What I’m trying to say is maybe imapsync is missing the message that it have to be transferred to Axigen so the PRTG script will miss it as well.
5/ Please increase the log level on IMAP service from Axigen server to Protocol Communication and share the logs for:
imapsync reletad session
PRTG script related session
pointing out the wrong order of messages that the Axigen server is presenting to PRTG script.
Other than that I have no furhter ideas on how to advance on this report, especially that we are talking about 2 separate 3rd party mail clients for which we do not have extensive knowledge on how they works internally.
But let’s look on the requested Axigen IMAP logs (important to be in Protocol Communication) as maybe we’ll get some hints from there.
because we need to be updated nearly realtime, as the AXYGEN server is a collector for email service account (backup results, alarms, etc)
most probably we will encounter errors due the sort problem - we’ve found the problem after the sync stopped for one day
we are using 2 accounts in the same way: one has about 250/300 messages per day, the other one 200/250. We keep messages in AXIGEN for 7 days. Please note the PRTG is missing the message, but the message exist.
we are sure the message exist because it’s available in webmail (and the sort of messages is different between imap and webmail)
can I message you in some way to send you logfiles?
Hello Jay,
sorting in Webmail is ok.
IMAP sorting is different.
I’m using PRTG to check for emails: I sync 2 external accounts to Axigen to let PRTG search for message in there.
Unfortunaltey, I cannot select any sort type in IMAP - PRTG is keeping the default.
Is there any setting to change this behaviour - to let webmail and IMAP using same sorting?
Thank you
