Community

RemotePOP no new emails

Hello, I am new here and have installed the Axigem MailServer.
I have a problem with the RemotePOP, the server picked up the emails (6553) from the RemoteServer
after the installation. New emails have been on the RemoteServer for two days, according to the
log file the MailServer is establishing the connection without errors.
No new emails arrive at Axigem’s mail server.

What can I do?

Hello,

First of all please confirm if the Remote POP service is reported to be started (WebAdmin > Services > Service Management)

Secondly, please check if the account you are using locally have this service enabled (WebAdmin > Domains & Accounts > Manage Accounts > Edit > Basic settings for this account)

Lastly, please set log level to Communication Protocol for Remote POP service.
Next, please send a new message to “external” account that is configured on your “local” server to be harvest via POP3.
Wait for at least half an hour and in case you still not have the new message locally please provide us the RPOP Axigen logs generated during that period of time (please compress them with ZIP).

Looking forward for your feedback.

Best regards,
Ioan

Hello,

I have now found the problem, Axigen has problems access the POP3 mailbox in which there are approx. 6800 emails.
It lists all emails in the log file under RPOP, but it always loads the emails from the server. In Axigen you either do not arrive at very different times. There are max. approx. 10 emails / days although there are 30 new ones in the mailbox at the provider
If I create an empty mailbox and set the polling to 5 minutes, the new emails always arrive.
Is there a limit for retrieved emails in Axigen the max. can be accessed. Because something is stopping the POP3 poll.

Here is an addendum with an extract from the log file.

Axigen goes through the emails (6800) from the provider, then they are downloaded for 9 hours :open_mouth: :open_mouth: :sob: :sob:
And then it starts polling again and it takes that long again.
That’s why the emails arrive so late :frowning_face:

I had previously used a different email server, so I have never had these problems.
New emails have always arrived on time.

beginning

2020-01-19 10:14:40 +0100 16 mx RPOP:00000003: << +OK 6801 messages, listing follows:
2020-01-19 10:14:40 +0100 16 mx RPOP:00000003: << 1 668660e2e0a010faacf049fa830f537c
2020-01-19 10:14:40 +0100 16 mx RPOP:00000003: << 2 d79d4aa913c47913bbeff0475f346603

some lines deleted

2020-01-19 10:14:40 +0100 16 mx RPOP:00000003: << 6801 1cc2e891ef1c98ed29d736633c0a786b

end

beginning

2020-01-19 10:14:40 +0100 16 mx RPOP:00000003: >> UIDL 1
2020-01-19 10:14:40 +0100 16 mx RPOP:00000003: << +OK 1 668660e2e0a010faacf049fa830f537c
2020-01-19 10:14:40 +0100 16 mx RPOP:00000003: >> UIDL 2

some lines deleted

2020-01-19 19:41:29 +0100 16 mx RPOP:00000003: >> RETR 6799
2020-01-19 19:41:29 +0100 16 mx RPOP:00000003: << +OK Message follows:
2020-01-19 19:41:30 +0100 16 mx RPOP:00000003: >> UIDL 6800
2020-01-19 19:41:30 +0100 16 mx RPOP:00000003: << +OK 6800 44d6fba7f02d7d6cf009ff550408d698
2020-01-19 19:41:30 +0100 16 mx RPOP:00000003: >> RETR 6800
2020-01-19 19:41:30 +0100 16 mx RPOP:00000003: << +OK Message follows:
2020-01-19 19:41:30 +0100 16 mx RPOP:00000003: >> UIDL 6801
2020-01-19 19:41:30 +0100 16 mx RPOP:00000003: << +OK 6801 1cc2e891ef1c98ed29d736633c0a786b
2020-01-19 19:41:30 +0100 16 mx RPOP:00000003: >> RETR 6801
2020-01-19 19:41:30 +0100 16 mx RPOP:00000003: << +OK Message follows:
2020-01-19 19:41:30 +0100 16 mx RPOP:00000003: >> QUIT
2020-01-19 19:41:30 +0100 16 mx RPOP:00000003: << +OK Closing connection

9 hours ? :open_mouth: :open_mouth: :sob: :sob:

beginning

2020-01-19 19:41:30 +0100 08 mx RPOP:00000003: rpop connection for account XXXX ended, status: 1;SUCCESS, OK
2020-01-19 19:41:30 +0100 08 mx RPOP:00000003: rpop connection for account XXXX rescheduled in 5 minutes
2020-01-19 19:41:32 +0100 16 mx RPOP:00000004: << +OK 6789 b5d6dfff878ef9a1c6b9c9729babd74b
2020-01-19 19:41:32 +0100 16 mx RPOP:00000004: >> UIDL 6790
2020-01-19 19:41:37 +0100 16 mx RPOP:00000004: << +OK 6790 7dca34b6caeedc148560ceec4b3cbc7d
2020-01-19 19:41:37 +0100 16 mx RPOP:00000004: >> RETR 6790
2020-01-19 19:41:38 +0100 16 mx RPOP:00000004: << +OK Message follows:
2020-01-19 19:41:38 +0100 16 mx RPOP:00000004: >> UIDL 6791
2020-01-19 19:41:38 +0100 16 mx RPOP:00000004: << +OK 6791 2bfdf120288abc68073f3764e145ea42
2020-01-19 19:41:38 +0100 16 mx RPOP:00000004: >> RETR 6791
2020-01-19 19:41:38 +0100 16 mx RPOP:00000004: << +OK Message follows:
2020-01-19 19:41:38 +0100 16 mx RPOP:00000004: >> UIDL 6792
2020-01-19 19:41:38 +0100 16 mx RPOP:00000004: << +OK 6792 6e8c73ea9094fcff0db8f57b0160c30a
2020-01-19 19:41:38 +0100 16 mx RPOP:00000004: >> RETR 6792
2020-01-19 19:41:38 +0100 16 mx RPOP:00000004: << +OK Message follows:
2020-01-19 19:41:38 +0100 16 mx RPOP:00000004: >> UIDL 6793
2020-01-19 19:41:38 +0100 16 mx RPOP:00000004: << +OK 6793 03789f341131ee697aeb412d742d4404
2020-01-19 19:41:38 +0100 16 mx RPOP:00000004: >> RETR 6793
2020-01-19 19:41:38 +0100 16 mx RPOP:00000004: << +OK Message follows:
2020-01-19 19:41:39 +0100 16 mx RPOP:00000004: >> UIDL 6794
2020-01-19 19:41:39 +0100 16 mx RPOP:00000004: << +OK 6794 aff52befd0ae88b9855006af43978fc8
2020-01-19 19:41:39 +0100 16 mx RPOP:00000004: >> RETR 6794
2020-01-19 19:41:39 +0100 16 mx RPOP:00000004: << +OK Message follows:
2020-01-19 19:41:39 +0100 16 mx RPOP:00000004: >> UIDL 6795
2020-01-19 19:41:39 +0100 16 mx RPOP:00000004: << +OK 6795 e371038a6cc5595f57f3bc86822ed4d9
2020-01-19 19:41:39 +0100 16 mx RPOP:00000004: >> RETR 6795
2020-01-19 19:41:39 +0100 16 mx RPOP:00000004: << +OK Message follows:
2020-01-19 19:41:39 +0100 16 mx RPOP:00000004: >> UIDL 6796
2020-01-19 19:41:39 +0100 16 mx RPOP:00000004: << +OK 6796 0127b07b21badfa262b9a2426db20b38
2020-01-19 19:41:39 +0100 16 mx RPOP:00000004: >> RETR 6796
2020-01-19 19:41:39 +0100 16 mx RPOP:00000004: << +OK Message follows:
2020-01-19 19:41:39 +0100 16 mx RPOP:00000004: >> UIDL 6797
2020-01-19 19:41:39 +0100 16 mx RPOP:00000004: << +OK 6797 f99103ad4b9d5b5c73adbe0f2f8c0af5
2020-01-19 19:41:39 +0100 16 mx RPOP:00000004: >> RETR 6797
2020-01-19 19:41:39 +0100 16 mx RPOP:00000004: << +OK Message follows:
2020-01-19 19:41:39 +0100 16 mx RPOP:00000004: >> UIDL 6798
2020-01-19 19:41:39 +0100 16 mx RPOP:00000004: << +OK 6798 0e4273d3ccc892f10e8a11c2a38589b2
2020-01-19 19:41:39 +0100 16 mx RPOP:00000004: >> RETR 6798
2020-01-19 19:41:39 +0100 16 mx RPOP:00000004: << +OK Message follows:
2020-01-19 19:41:40 +0100 16 mx RPOP:00000004: >> UIDL 6799
2020-01-19 19:41:40 +0100 16 mx RPOP:00000004: << +OK 6799 24b89f50dbc0bf3225fcb64818f3fd71
2020-01-19 19:41:40 +0100 16 mx RPOP:00000004: >> RETR 6799
2020-01-19 19:41:40 +0100 16 mx RPOP:00000004: << +OK Message follows:
2020-01-19 19:41:40 +0100 16 mx RPOP:00000004: >> UIDL 6800
2020-01-19 19:41:40 +0100 16 mx RPOP:00000004: << +OK 6800 44d6fba7f02d7d6cf009ff550408d698
2020-01-19 19:41:40 +0100 16 mx RPOP:00000004: >> RETR 6800
2020-01-19 19:41:40 +0100 16 mx RPOP:00000004: << +OK Message follows:
2020-01-19 19:41:40 +0100 16 mx RPOP:00000004: >> UIDL 6801
2020-01-19 19:41:40 +0100 16 mx RPOP:00000004: << +OK 6801 1cc2e891ef1c98ed29d736633c0a786b
2020-01-19 19:41:40 +0100 16 mx RPOP:00000004: >> RETR 6801
2020-01-19 19:41:40 +0100 16 mx RPOP:00000004: << +OK Message follows:
2020-01-19 19:41:40 +0100 16 mx RPOP:00000004: >> QUIT
2020-01-19 19:41:40 +0100 16 mx RPOP:00000004: << +OK Closing connection
2020-01-19 19:41:40 +0100 08 mx RPOP:00000004: rpop connection for account XXXX ended, status: 1;SUCCESS, OK
2020-01-19 19:41:40 +0100 08 mx RPOP:00000004: rpop connection for account XXX rescheduled in 5 minutes
2020-01-19 19:46:30 +0100 08 mx RPOP:00000070: rpop connection successfully started for account XXX

End

Hello Martin,

Are you asking us why it took so more times for retrieving 6800 messages via RPOP?

We could try to have an answer only after you are giving us the entire RPOP service log file (or at least the lines that contains RPOP:00000003). If them log file(s) are big, please consider using ZIP for compression.

BR,
Ioan

Hello loan,

Here is the log file as ZIP


Martin

rpop.zip (1021.7 KB)

Hi there,
unfortunately I have not yet received an answer to my problem.

Martin

Hello Martin,

Thank you for providing the requested RPOP logs.

Let’s try to understand what is happening after succesfully login to the remote server:

… so there are 6812 messages, using ~875 MB

2020-01-20 17:46:08 +0100 16 mx RPOP:00000001: >> STAT
2020-01-20 17:46:08 +0100 16 mx RPOP:00000001: << +OK 6812 875332586

… and Axigen will ask to receive the unique ID for all messages

2020-01-20 17:46:08 +0100 16 mx RPOP:00000001: >> UIDL
2020-01-20 17:46:08 +0100 16 mx RPOP:00000001: << +OK 6812 messages, listing follows:
2020-01-20 17:46:08 +0100 16 mx RPOP:00000001: << 1 668660e2e0a010faacf049fa830f537c
...
2020-01-20 17:46:08 +0100 16 mx RPOP:00000001: << 6812 89f5ade97dbb2ba152d5690df48acc77
2020-01-20 17:46:08 +0100 16 mx RPOP:00000001: << .

… now starts the interesting part - Axigen is rechecking, for all messages, the received IDs
… but the remote server starts to answer with 5 sec delay
… examples for ~3 sec delay

2020-01-20 17:46:31 +0100 16 mx RPOP:00000001: >> UIDL 28
2020-01-20 17:46:34 +0100 16 mx RPOP:00000001: << +OK 28 3685b5c55de078fc72c27eafbd73abf5
2020-01-20 17:46:44 +0100 16 mx RPOP:00000001: >> UIDL 33
2020-01-20 17:46:47 +0100 16 mx RPOP:00000001: << +OK 33 c299b04a33d9a8b015f91d9a07a9b555

… examples of ~5 sec delay

2020-01-20 17:47:27 +0100 16 mx RPOP:00000001: >> UIDL 50
2020-01-20 17:47:32 +0100 16 mx RPOP:00000001: << +OK 50 429f68a0101f801924f047632724dac2
2020-01-20 17:47:32 +0100 16 mx RPOP:00000001: >> UIDL 51
2020-01-20 17:47:37 +0100 16 mx RPOP:00000001: << +OK 51 0804c24da239654b4f1a2be5f9f8d647
2020-01-20 17:47:37 +0100 16 mx RPOP:00000001: >> UIDL 52
2020-01-20 17:47:42 +0100 16 mx RPOP:00000001: << +OK 52 16bb60ed6c50d8a61cee4fc5182678fd
2020-01-20 17:47:42 +0100 16 mx RPOP:00000001: >> UIDL 53
2020-01-20 17:47:47 +0100 16 mx RPOP:00000001: << +OK 53 f56fac9fcb0dfc99c89f0a7a390205d9
2020-01-20 17:47:47 +0100 16 mx RPOP:00000001: >> UIDL 54
...
2020-01-21 03:14:04 +0100 16 mx RPOP:00000001: >> UIDL 6807
2020-01-21 03:14:09 +0100 16 mx RPOP:00000001: << +OK 6807 1a01a7c8df53c8fb00db237bf5ac12a6

…so here you have:
6087 POP3 UIDL commands requested by Axigen and answered by remote sever in ~9.5 hours

…and finally is retrieving 4 messages that were not already downloaded

2020-01-21 03:14:09 +0100 16 mx RPOP:00000001: >> UIDL 6808
2020-01-21 03:14:14 +0100 16 mx RPOP:00000001: << +OK 6808 959d1e1c5104d49c8b448058a38b0a0d
2020-01-21 03:14:14 +0100 16 mx RPOP:00000001: >> RETR 6808
2020-01-21 03:14:14 +0100 16 mx RPOP:00000001: << +OK Message follows:
...
2020-01-21 03:14:15 +0100 16 mx RPOP:00000001: >> UIDL 6812
2020-01-21 03:14:15 +0100 16 mx RPOP:00000001: << +OK 6812 89f5ade97dbb2ba152d5690df48acc77
2020-01-21 03:14:15 +0100 16 mx RPOP:00000001: >> RETR 6812
2020-01-21 03:14:15 +0100 16 mx RPOP:00000001: << +OK Message follows:
2020-01-21 03:14:15 +0100 16 mx RPOP:00000001: >> QUIT

Now I let you conclude - is Axigen to blame, the remote server or the owner of the mailbox?

  • maybe in Axigen we could make some improvements (to be checked internally)
  • but why the remote is delaying the answer to POP3 UIDL messages is something that you will have to check

My suggestions are:
1/ ask the owner of the remote mailbox to archive old messages in a subfolder so there will not be so many messages to be checked

2/ test RemotePOP with 6800 messages when the remote server is Axigen (very easy to configure, just use another mailbox on the same Axigen server) - is the same delay observed?

3/ bring this topic in attention of the remote server support team so they could provide an explanation for POP3 UIDL responses delayed by 5 sec

HTH,
Ioan

PS: please remember that here you are receiving answers from a public community, depending on the availability of each one. I’m strongly advise you to use the dedicated support channel in case you are interested in a better response time.

Hello Ioan,

I don’t think it’s because of the remote server or the amount
of the many messages in the mailbox. A server should be able to cope with that.

Here is a comparison of my log file from my previous mail server.
As you can see, it works here and he also calls up regularly.

Ok, I contact support with the problem.
If support cannot solve this problem either, I will probably have to continue using my previous mail server.
For the test, I tested an alternative mail server, which had no problems with the amount of these emails.
So unfortunately I see the problem with Axigen mail servers.

Martin
pop3-log.zip (1.5 MB)

Hello Martin,

I’ve look over the log you have provided and there are no UIDL messageID commands.

Now, I’ve mention that maybe the RPOP client that is built in Axigen could be optimized in order to cope with remote servers that are responding with 3 - 5 sec delays (BTW - could you share what is the remote server you are downloading from?) and presented you 2 workaround options.

Also I have asked you to check if downloading from another source (the easiest source should be the same Axigen server - but from another account) you are observing the same behavior.

In response I get your statement that “I see the problem with Axigen” and “I will probably have to continue using my previous mail server”. This is fine with me and I could only say that I like your determination.

BR,
Ioan

Hello Ioan,

I can not say why there is no UIDL messageID in the pop3 protocol?

My remote server is pop3.strato.de

The download with Axigen works, with a mailbox where there are fewer emails, I have already checked this.

I wanted to send my request to support today, this service is chargeable and I still use the free version in the test environment.

Martin