Hello again.
I just upgraded to 4.9, and I noticed something strange.
Let's say I have a mailbox on internet, called dummy@mydomain.it
M32 polls the mailbox via pop3, and deliver the mail to the local user called dummy.
User dummy has a forwarding file like this

Forward-To : userME06
Forward-To : userME07
Forward-To : userME08
Forward-To : userME09
Forward-To : userME10
Deliver-Also : N

which forwards the mail to the local users userME06 etc.

Before the upgrade, this was the output in the core windows, when mail was processed

Sat 22, 11:56:23: Job MG000001: from sender@sender.it (non-local)
   To: dummy (local) -OK
Sat 22, 11:56:39: Job MG000002: from dummy@mydomain.it (local)
   To: userME06 (local) -OK
   To: userME07 (local) -OK
   To: userME08 (local) -OK
   To: userME09 (local) -OK
   To: userME10 (local) -OK

So, the first two lines mean that Core delivers the incoming mail to dummy, and the remaining lines mean that the mail was forwarded from dummy to the other users.

After the upgrade to v.4.9, this is the output

Sat 22, 11:56:23: Job MG000001: from sender@sender.it (non-local)
   To: dummy (local) -OK
Sat 22, 11:56:39: Job MG000002: from ErrorHandler-ECA@mydomain.it (local)
   To: userME06 (local) -OK
   To: userME07 (local) -OK
   To: userME08 (local) -OK
   To: userME09 (local) -OK
   To: userME10 (local) -OK

Why "ErrorHandelr-etc..." instead of "dummy"?
The system seems to works flawlessly, but I'd like to know the meaning of "ErrorHandler"...

best regards
Filippo

As mentioned in the release notes the forwarding routines have been updated in Mercury v4.9:

Forwarding fixes Delivery errors during autoforwarding of mail are now handled much better than in previous versions, and there is no longer the possibility of mail loops resulting from the presence of undeliverable addresses in forward files.

The sender in the SMTP envelope is thus replaced by an ErrorHandler address which changes for each message.

Hi Rolf,
May be a little bit off-topic but it also relates to "forward": For a long time we experienced problems in v4.8 when placing the "forward" file into a user mailbox, which should cause the forwarding of all incoming mails (intended for that certain user) to another external mail address, means back to the internet.
It worked so far but the Mercury SMTP Client became slower and slower, especially if mails with big attachments which are just received, should be immediately forwarded to the internet again. Because of that we tried different things for mitigation like changing the mail provider or upgrading our SMTP mail account at ISP to a business mail account to get more mail amount per month and speed. But nothing helped. The outgoing Mercury mail queue became longer and longer since the delivery speed of the SMTP client was so bad.
When restarting Mercury the SMTP Client worked fast but became slower as soon as different big mails have been automatically forwarded back to the internet again.
Finally we removed the forward file from all user mailbox folders and arranged any needed forward rules with the ISP directly. Since then Mercury SMTP client worked fine again and is running stable for weeks until we have to restart the server due to MS updates.

Has something been changed in v4.9 in this direction?

Thank you, Rolf.
Filippo

Once a message has been submitted to the queue for delivery it makes no difference for Mercury if the message was forwarded or not, it's just an SMTP envelope and corresponding message content. The receiving server might check various parts of the message (headers and message text), but if they for some reason found the message unacceptable they would refuse it or simply disconnect. The only thing that would be likely to cause a slowdown is if the receiving server took very long to virus check big attachments before accepting the message.

The forwarding fix in v4.9 should prevent receiving servers to refuse forwarded messages due to the SMTP envelope sender. There is a tiny possibility that the receiving server stopped or delayed handling the incoming queue due to suspicious sender details, but if so your ISP would probably have informed you about that.

If there is some other issue in Mercury that somehow causes queue handling to stall you could perhaps try to test this by setting up a second Mercury instance in your local network and see if delivery to that server behaves the same way. That would eliminate all external factors.

To get the full picture, do you receive incoming mails directly by SMTP or do you collect them from your ISP using the POP3 client?

Beside the Core Process, Mercury S (SMTP Server), Mercury C (SMTP Client), Mercury D (POP3 Client) and Mercury I (IMAP Server) are active with us.
Mercury D is polling our ISP mailboxes permanently (about 30 different mailboxes from german IONOS / 1&1 ISP).
Mercury S is for receiving of local mails, originated from Company LAN, others than Pmail
Mercury I is for receiving of local mails from IMAP clients like Thunderbird or Roundcube
Mercury C is for forwarding all mails, intended for the internet, to the ISP SMTP Server

Rolf, my question was only intended to know whether something has been turned out in the meantime in this regard. We've removed all "forward" files from user mailboxes since months and all is running fine since then.
Unfortunately we don't have the time to setup another machine with another Mercury running. Sorry.

If I should guess, Mercury has (had) a problem when it is retrieving a big mail (about 20 MB) from ISP and should simultaneously forwarding this mail back to the internet to another external address. It seems the overlapping retrieving process by Mercury D and the forward (sending) process of the Core and Mercury C may cause the problem, especially when this happens for different users simultaneously.
As I said, that time we tried different things, up to changing the ISP mail provider. But only the restart of Mercury rought an improvement for some days until the slow-down of Mercury C starts again.

I ran two instances, both on the same machine. Mercury C, D, & I ran in one, and Mercury S & E ran in the other. I started running the two instances early in my Mercury implementation because I was unable to figure out how to prevent all outgoing messages from being run through the general rule set. If you wonder why I had C running in one instance and E in the other it is because I started with C, then once I had E working in the second instance, I never saw a compelling reason to replace C with E in the first. Also worthy of note is that I didn't run either instance as a service. I also ran POPFile. POPFile needed to be running before the first instance of Mercury started, so on machine startup, I triggered a batch file that started POPFile, delayed for 30 seconds, then started the first Mercury instance, delayed for 15 seconds, then started the second Mercury instance.

Our forwarding activity was likely much lower than what Joerg has. We rarely had more than three employees have their Forward file in place at one time. I discouraged it, recommending its use only when someone would be out of the office and resistant to setting up an IMAP connection on a personal device. I made it easy for users to enable/disable their Forward file with a desktop shortcut to a batch file that would rename it.

Part of the long preparations leading up to v4.90 has been testing for and eliminating deadlock situations where multiple simultaneous processes try to acquire access to the same resource at the same time. If there was some issue like that with MercuryD and MercuryC it might well have been fixed, but there is no way to know for sure without testing.

Only for information. Just read the "Ode to Pegasus Mail". Seems I was not alone with the FORWARD experience in past