Voytek Eymont writes:
I've enabled logging as per your suggestion:
-rw------- 1 vmail vmail 127 Oct 16 21:38 20221016-213738.25640.1.in -rw------- 1 vmail vmail 8546603 Oct 16 21:38 20221016-213738.25640.1.out -rw------- 1 vmail vmail 96 Oct 16 21:58 20221016-215757.26075.1.in -rw------- 1 vmail vmail 8343463 Oct 16 21:58 20221016-215757.26075.1.out
# cat 20221016-213738.25640.1.in 1665916659.491025 STAT 1665916659.550829 LIST 1665916676.430794 UIDL 1665916693.761281 RETR 114437 1665916694.440965 QUIT # cat 20221016-215757.26075.1.in 1665917878.786953 STAT 1665917878.863136 LIST 1665917905.610805 UIDL 1665917924.491198 QUIT #
what should I look in the .out file ?
some of the file is like: .... 1665916661.234807 114436 70097 1665916661.234814 114437 154498 1665916661.234821 . 1665916676.430870 +OK 1665916676.981415 1 000024b95283283a 1665916676.981459 2 000024ba5283283a ....
1665916679.434297 114436 00033fcf5283283a 1665916679.434327 114437 00033fd05283283a 1665916679.434349 . 1665916694.048139 +OK 154498 octets 1665916694.048199 Return-Path: <buyer-notice14.g@mail.aliexpress.com> ....
I haven't seen anyone else replying, but there doesn't seem anything anomalous with the output. The session commands-repliesd is is more or less what I expect, although to make sense of this, you'll have to splice the input and output files together using timestamps to see the sequential flow of data.
I forget what the symptoms you originally reported, but theoretically, you could simulate either client or server by feeding in the above data and see how the other end behaves.
If dovecot is serving out the correct data, then TB is somehow misinterpreting it.
on an uneducated guess, the mailbox is just 'too large' ? POP has difficulty handling so many files ?
Typically, if some resource limit is hit, one side or the other will create a log or notification. Your INBOX is large, but not outrageous. You can test it directly by creating smaller subsets of the INBOX messages and see if the problem goes away.
Joseph Tam <jtam.home@gmail.com>
On Sat, October 22, 2022 11:29 am, Joseph Tam wrote:
I haven't seen anyone else replying, but there doesn't seem anything anomalous with the output. The session commands-repliesd is is more or less what I expect, although to make sense of this, you'll have to splice the input and output files together using timestamps to see the sequential flow of data. ... Typically, if some resource limit is hit, one side or the other will create a log or notification. Your INBOX is large, but not outrageous. You can test it directly by creating smaller subsets of the INBOX messages and see if the problem goes away.
Joseph,
thank you very much for the follow up! you won't believe it, literally minutes before your email I got this email from the 'problem user' (below)
thank you to all who responded!
I guess if TB debug log was enabled (as was suggested)- maybe the issue would become apparent from TB debug log ?
I guess i should encourage POP users to switch to IMAP anyhow ?
got this from problem user:
Mozilla Thunderbird released an update which I just installed.
Problem solved.
I guess Tbird had a problem that the new release addressed.
I'm sorry for the inconvenience.
I'm mystified why my issue was only with one account. Perhaps it was something to do with the size of the database.
yesterday it was
I'm still experiencing a 40 second delay to retrieve emails for xxx
I have changed the pop port to 110 for the server but that did not work at all.
I have reinstalled my email client TBird but no change, anyway all the other accounts on TBird are working ok but they are MAPI not POP.
Voytek
Over the last several months we have seen what seems like large delays in email delivery as well, we get emails at 11AM that are time stamped at 9:10. I thought it was a networking issue, but I can’t be sure. I wish I knew more about coding, to look under the hood to examine things further.
Sent from my iPhone
On Oct 23, 2022, at 7:17 AM, Voytek Eymont <voytek@sbt.net.au> wrote:
On Sat, October 22, 2022 11:29 am, Joseph Tam wrote:
I haven't seen anyone else replying, but there doesn't seem anything anomalous with the output. The session commands-repliesd is is more or less what I expect, although to make sense of this, you'll have to splice the input and output files together using timestamps to see the sequential flow of data. ... Typically, if some resource limit is hit, one side or the other will create a log or notification. Your INBOX is large, but not outrageous. You can test it directly by creating smaller subsets of the INBOX messages and see if the problem goes away.
Joseph,
thank you very much for the follow up! you won't believe it, literally minutes before your email I got this email from the 'problem user' (below)
thank you to all who responded!
I guess if TB debug log was enabled (as was suggested)- maybe the issue would become apparent from TB debug log ?
I guess i should encourage POP users to switch to IMAP anyhow ?
got this from problem user:
Mozilla Thunderbird released an update which I just installed.
Problem solved.
I guess Tbird had a problem that the new release addressed.
I'm sorry for the inconvenience.
I'm mystified why my issue was only with one account. Perhaps it was something to do with the size of the database.
yesterday it was
I'm still experiencing a 40 second delay to retrieve emails for xxx
I have changed the pop port to 110 for the server but that did not work at all.
I have reinstalled my email client TBird but no change, anyway all the other accounts on TBird are working ok but they are MAPI not POP.
Voytek
Hi!
This is very unlikely to be a dovecot issue itself. There is nothing inside dovecot that would horde your emails for 2 hours before "delivering" them.
You should
- Enable mail_log plugin. This will tell you when mails are delivered, when deleted etc, see https://doc.dovecot.org/configuration_manual/plugins/mail_event_logging/
- Examine your logs
- Check
doveadm fetch 'date.received date.sent date.saved' mailbox INBOX '*'( this will print you the last email in INBOX, note the quotes)
Aki
On 23/10/2022 16:49 EEST Chris Wensink <cwensink@five-star-plastics.com> wrote:
Over the last several months we have seen what seems like large delays in email delivery as well, we get emails at 11AM that are time stamped at 9:10. I thought it was a networking issue, but I can’t be sure. I wish I knew more about coding, to look under the hood to examine things further.
Sent from my iPhone
On Oct 23, 2022, at 7:17 AM, Voytek Eymont <voytek@sbt.net.au> wrote:
On Sat, October 22, 2022 11:29 am, Joseph Tam wrote:
I haven't seen anyone else replying, but there doesn't seem anything anomalous with the output. The session commands-repliesd is is more or less what I expect, although to make sense of this, you'll have to splice the input and output files together using timestamps to see the sequential flow of data. ... Typically, if some resource limit is hit, one side or the other will create a log or notification. Your INBOX is large, but not outrageous. You can test it directly by creating smaller subsets of the INBOX messages and see if the problem goes away.
Joseph,
thank you very much for the follow up! you won't believe it, literally minutes before your email I got this email from the 'problem user' (below)
thank you to all who responded!
I guess if TB debug log was enabled (as was suggested)- maybe the issue would become apparent from TB debug log ?
I guess i should encourage POP users to switch to IMAP anyhow ?
got this from problem user:
Mozilla Thunderbird released an update which I just installed.
Problem solved.
I guess Tbird had a problem that the new release addressed.
I'm sorry for the inconvenience.
I'm mystified why my issue was only with one account. Perhaps it was something to do with the size of the database.
yesterday it was
I'm still experiencing a 40 second delay to retrieve emails for xxx
I have changed the pop port to 110 for the server but that did not work at all.
I have reinstalled my email client TBird but no change, anyway all the other accounts on TBird are working ok but they are MAPI not POP.
Voytek
Even more easy, start by examining the mail headers to see where the mail was blocked.
Jhp
On October 23, 2022 4:05:51 PM GMT+02:00, Aki Tuomi <aki.tuomi@open-xchange.com> wrote:
Hi!
This is very unlikely to be a dovecot issue itself. There is nothing inside dovecot that would horde your emails for 2 hours before "delivering" them.
You should
- Enable mail_log plugin. This will tell you when mails are delivered, when deleted etc, see https://doc.dovecot.org/configuration_manual/plugins/mail_event_logging
- Examine your logs
- Check
doveadm fetch 'date.received date.sent date.saved' mailbox INBOX '*'( this will print you the last email in INBOX, note the quotes)Aki
On 23/10/2022 16:49 EEST Chris Wensink <cwensink@five-star-plastics.com> wrote:
Over the last several months we have seen what seems like large delays in email delivery as well, we get emails at 11AM that are time stamped at 9:10. I thought it was a networking issue, but I can’t be sure. I wish I knew more about coding, to look under the hood to examine things further.
Sent from my iPhone
On Oct 23, 2022, at 7:17 AM, Voytek Eymont <voytek@sbt.net.au> wrote:
On Sat, October 22, 2022 11:29 am, Joseph Tam wrote:
I haven't seen anyone else replying, but there doesn't seem anything anomalous with the output. The session commands-repliesd is is more or less what I expect, although to make sense of this, you'll have to splice the input and output files together using timestamps to see the sequential flow of data. ... Typically, if some resource limit is hit, one side or the other will create a log or notification. Your INBOX is large, but not outrageous. You can test it directly by creating smaller subsets of the INBOX messages and see if the problem goes away.
Joseph,
thank you very much for the follow up! you won't believe it, literally minutes before your email I got this email from the 'problem user' (below)
thank you to all who responded!
I guess if TB debug log was enabled (as was suggested)- maybe the issue would become apparent from TB debug log ?
I guess i should encourage POP users to switch to IMAP anyhow ?
got this from problem user:
Mozilla Thunderbird released an update which I just installed.
Problem solved.
I guess Tbird had a problem that the new release addressed.
I'm sorry for the inconvenience.
I'm mystified why my issue was only with one account. Perhaps it was something to do with the size of the database.
yesterday it was
I'm still experiencing a 40 second delay to retrieve emails for xxx
I have changed the pop port to 110 for the server but that did not work at all.
I have reinstalled my email client TBird but no change, anyway all the other accounts on TBird are working ok but they are MAPI not POP.
Voytek
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
participants (5)
-
Aki Tuomi
-
Chris Wensink
-
Jan Hugo Prins
-
Joseph Tam
-
Voytek Eymont