[quote user="Rolf Lindby"]I sent an email June 25th with the download link, let me know if I should resend. [/quote]

Has been caught in the spam filter [:$] 

4.80 backed up and 4.81 installed (update option). Setup without any problems. Mercury is running as usual so far. I will report in case anything is weird.

Thanks Rolf.

In recent past we experience the following behaviour of Mercury C (SMTP Relay Client): When sending big amounts of e-mails (in number and attachment) the transmitting speed to the ISP becomes more and more slowly over port 587 with SSL/STARTTLS. From time to time I become aware of the issue when someone of my users is expecting an urgent mail which doesn't come. Then I check Mercury for proper working and see that Mercury C is still sending one of a last e-mail since a long time (often about 1 hour). And as long as Mercury C is captured within the sending process, the other processes of the core module are stopped. (I report this Mercury issue already here ). In such case the SMTP queue runs over.

I can only improve the behaviour when switching Mercury C to another user's e-mail account, since all of our users have e-mail accounts with the ISP.  Is it possible that ISPs reduce the SMTP mail speed more and more when receiving a lot of mails by one user to avoid spamming? Since all of our daily e-mails (hundret of mails) will be submitted to ISP over only one e-mail account, the provider could often think about spam.

Is anybody experiencing similar things? What are your SMTP upload speed over port 587? We've got a 50/10 Mbit (down/up) internet connection but the mail submission never reaches this speed. I observe the mercury C mail submission via the increasing of the SMTP log file (TCP-*.MC).  BTW, our german ISP is "1&1". Maybe one of the german guys here are using the same provider.

The ISP might be deliberately throttling mail delivery because of a usage policy. If so, you should identify those user accounts that send a lot of mail and ask your ISP if the account type for the heavy users can be changed to allow for the bulk sending of email.

As written above, only one user credentials could be added to Mercury C. Mercury is collecting the outgoing mails of all users and is sending them via Mercury C to ISP, using always one and the same user account. But I will give my ISP a call to ask for any usage policies.

Thanks Greenman

I think 1&1 has a not so different policy like Telekom: "Versendbare E-Mails" "Freemail: 100/Tag or 1,000/Mon." "Mail-M_Paket: 5,000/Tag"

In older product describtions was an entry like "after passing the amount of email, all further mails will be deleted without any notice to the sender". I do not know if this was changed, because i am below this amount of mails. Perhaps the TOS/AGB contains more information. What i know is, that i have to pay for the smallest paket. I am behind a dsl-line and the entire dsl port range is blacklisted therefore i have to use my ISP as smarthost...

I would call the ISP or with a static ip you could think about a mail-domain something like https://www.domain24.de/hosting.html 

[quote user="Joerg"]

As written above, only one user credentials could be added to Mercury C. Mercury is collecting the outgoing mails of all users and is sending them via Mercury C to ISP, using always one and the same user account. But I will give my ISP a call to ask for any usage policies.

Thanks Greenman

[/quote]

A smart host relays all outgoing mail regardless of sender (user mail account) address via the destination relaying mail server. Do you mean that your ISP provides more than one smart host address?

[quote user="Greenman"]A smart host relays all outgoing mail regardless of sender (user mail account) address via the destination relaying mail server. Do you mean that your ISP provides more than one smart host address?[/quote]

Mercury is not working as a full independent MX server with us. Instead of this every user has an own mail account with the ISP and Mercury is polling these mailboxes regularly und distribute them to local mailboxes.

Mercury C relays all outgoing mail regardless of sender, that's right. But to submit all the mails to our ISP SMTP mailserver, the relay client (Mercury C) needs to be authorized by using of login credentials of one of our users.

Oh, I see. We use Proofpoint Essentials and have a single address/credential set.

It does sound like user accounts are being deliberately throttled.  

Now our ISP has provided me with some details of its E-mail Policy. Clients with contracts older than 30 days [:D] have a limit of 5000 mails per day where single mails must not contain more than 200 recipients. These limits will and were never be exceeded by us. When we've got a day with a high amount, we send about 300 e-mails. Insofar I know as much as before not having a clue why the SMTP transmission is occasionally laming.

Does anybody has an idea how to simply create a SMTP upload speed statistics which logs the speed in kBit/s for each SMTP turn?

Did you use mercury for sending directly to your smarthost or do you use my longer way with stunnel in the middle between mercury and smarthost?

Either wireshark or stunnel with debug-log would be your friends. I don't know, if session logging from mercury would be helpful in your case.

[quote user="Sellerie"]

Did you use mercury for sending directly to your smarthost or do you use my longer way with stunnel in the middle between mercury and smarthost?

Either wireshark or stunnel with debug-log would be your friends. I don't know, if session logging from mercury would be helpful in your case.

Hi guys,

Recently we experienced the above mentioned issue again. My users complain either about missing expected mails or get the Mercury "Send Delivery Status Notification" that their mails weren't sent since 1 h. This is the trigger to me to check Mercury at the server. And again, MercuryC (SMTP Client) is sending with reduced speed over port 587 and the mail queue is overcrowded. The TCP connection is still enabled and is sending, but with about 1 kB/s only. This could be checked by visiting the log folder of the SMTP client. Therein I can see a slowly increasing TCP-[date]-[time]-XX.MC log file.

Now the same procedure as every time: Quit Mercury, start Mercury, change to offline mode, change the user credentials for authentication purposes of MercuryC to another of our ISP mail user, leve the offline mode. Then Mercury resumes or restart the sending of all unsend mails within the queue with usual high speed again and the queue is done after a few minutes.

After that I went in contact with our ISP again (unfortunately the more or less success of such an support request depends on the skills of the current support guy which you get on the line). But what I discover again: With our booked standard hosting package (including our e-mail accounts) we could send up to 5000 mails per month, where one single mail must not contain more than 200 recipients (e.g. in cc). And we are far from it. Last month we've sent about 3600 mails to the internet. Nevertheless I asked him about the consequences when exceeding the lines. In that case they would completely refuse the receipt of further mails. They would never throttle down the receiving speed of their SMTP server.

Now I'm as smart as before. Could the issue be on Mercury side? Mostly these losts of SMTP transmission speed happend when Mercury is trying to directly forward an received mail. Many of my users have the FORWARD file in place and active. Due to this also a lot of mails with big attachments will be received, moved to local user mailboxes and simultaneously directly forwarded into the internet again to another address.

Further I experienced a frozen Mercury Core Process when MercuryC is catched in a slow SMTP sending process, means any internal local mails will also not being processed as long as MercuryC is not working properly.

Has anybody another clue for me what I could do or test to enclose the problem?

Did you speak with a normal support guy or with someone from the tech department of your ISP? If you have had only the normal support in the line, then ask for forwarding to the tech department. My last problem was false answered by the support department, the tech department has a much better/plausibly answer, where my problems comes from and in the end the techs was right. 

Can you use port 25 for testing purposes? Perhaps the port 587 is really throttled somewhere.

On the other side you can send "Rolf Lindby" a message for the beta version. Maybe this solves your problem faster...

Hi Joerg,

Are you configured such that someone reviews copies of failed delivery notices?  I ask because I occasionally see a notice where an auto-forwarded (FORWARD file) message was rejected by the destination server and that rejection notice creates an infinite loop of forward>reject>forward>reject until I create a filter that deletes the next rejection notice.  I don't know whether such a loop would seriously bog down MercuryC but it's something that occurs here occasionally so thought it worth mentioning.

@Sellerie

I spoke with so many different support guys in past, sometimes via phone, sometimes via chat. Don't exactly know what kind of support they were. But in any case they didn't escalate the ticket since 1&1 IONOS  doesn't throttle any connections when a limit is reached.

I believe them more and more since sometimes it takes about 1 month until the next slow down cycle, and sometimes the issue appears after a few days after switching the SMTP authentication to another user. After one month our mail limitation could be reached, but never after a few days. Additionally I'm a little bit confused about the simultaneous freeze of the Core Process as long as the MercuryC is working so slowly.

Changing the port is not possible since 1&1 doesn't longer support any unencrypted SMTP connections over port 25. They only offer port 465 for SSL or port or 587 for TLS with STARTTLS.

@Brian

 All failed delivery notices will be additionally send to me as postmaster. This works fine since years. I receive different of such notices per day when my users type wrong e-mail addresses, or in case a destination mailbox is unreachable. But I never experienced such infinite loops as you describe.

I'm with  Sellerie on this - you need to speak to someone who knows how their mail servers work. Are some of their mail servers reaching capacity? Switching credentials may also force a switch of mail server (to one that is not over-burdened).

Or - are there any traffic throttling policies in place on your servers?

[quote user="Greenman"]I'm with  Sellerie on this - you need to speak to someone who knows how their mail servers work. Are some of their mail servers reaching capacity? Switching credentials may also force a switch of mail server (to one that is not over-burdened).

Or - are there any traffic throttling policies in place on your servers?[/quote]

How should I do this? If I call (or mail / or chat) the ISP support and they tell me that their SMTP servers reject any mail delivery after reaching the monthly limit - should I tell them that I don't believe it? They don't escalate the ticket and don't forward me to any special support team.

I've got one option left. We could book an additional option "mail marketing" for about 5 €/m where the limit (5000 mails/month / max number of addresees of 200 per mail) will be increased. But with our about 4000 mails per month this would be not really necessary.

What about my other thought, that Mercury Core Process freezes when MercuryC is caught in the "reduced speed sending process". Does anybody experienced such things? Any local mails between our local Pmail users, which will be nevertheless routed via Mercury, will be queued and not processed until MercuryC has finished its sending jobs. Maybe anybody could try to send an email with a real big attachment which takes different minutes to transmit and check whether during MercuryC is sending, the Core Process is still processing local mail or not?

I've never seen the behaviour you describe. Any slow-downs are usually because our Internet usage is being hammered - staff uploading large data sets etc. Mercury usually hums along quite nicely.

Hi,

I can confirm this issue to some extent.
Yesterday I had a problem with MercuryC not sending mails at all.
I am using Stunnel for the SSL connection to my ISP, and it appeared to be caused by Stunnel being broken (version 5.54 win-x64 appeared to have a bug).
It took me some time to understand and fix this (skipping Stunnel, and directly letting MercuryC contact my ISPs SMTP server), so I had some mails in the queue.
This were only a few messages, like 6 or so.
But after the connection came up again, the sending of these messages was very slow, with one or two per minute or so. Note that these were just small messages (no attachments).
Only after the queue was empty, normal behaviour re-initiated (when I now send several messages at once, they are all send immediately).
Does this sound familiar?
Could it be that it is caused by the internet connection temporary being lost?

Hi Guys,

Maybe somebody could assess this:

Today we experience such a slow-down of MercuryC again. I did quit Mercury (Menu > File > Exit) during the ongoing slow SMTP sending process, followed by a restart of Mercury. The SMTP client log (TCP-190611-1325-487.MC) shows now the following last lines:

15:34:19.385: << tvEXIAUVIAM1BqMLT2TonXr+VNO71JWrKcd7JciTygvyAscnmp7G5a6j+dcHOKwIZWtmZgcNggir<cr><lf>
15:34:19.495: << em3ZEygg7eScVcoqxvKKsa83pWfefu4Hb0FaD/M2azNVO2xf3qIbmUdzMMR+yrOh5GMmtZbphZ2l<cr><lf>
15:34:19.588: << 0OsbbH+lQWEXmaQRjqDUGlymW1urVu65H1FazVzuw8nexT1+08i+85RhJhvFNs3DxFexGMVfvP8A<cr><lf>
15:34:19.698: << TtF5OZLc/pWPZsVcD0relK8bGtRalSVfLmYDsa3NEujHMj5+6ayr1R9oYjvzT7GQpKK0nG8TGauj<cr><lf>
15:34:19.807: << 1RG3IGB4PNSA1maTN52nxsTyBg1fBryZqzscjJiNwNZOqwMbYnHGa1lNEsImt3WktAOKZccHmp9O<cr><lf>
15:34:19.916: << mktLoSIDz1FWrmycPgL+NT2djtcMwrVzTQM345jMitjGR0qrqrYgXOOvcZqxHwMVS1Y4RATjnsxH<cr><lf>
15:34:20.745: [!] OpenSSL reported a write error (5) - error queue follows:
15:34:21.151: [!] -------------------------------------------------------------------------

Is the Open SSL write error caused by my manually released Mercury exit? Or could the OpenSSL libriary the source of the problem?