Do you have any way to try a different MTA for your mail? setup a test account on another mail provider and set it in yaf and restart and see if the queue clears and duplicates stop?

That was one thing that changed in our configuration that sticks out where we're not getting 'duplicate emails anymore' since we moved our site --

Which leads indirectly to if there is an email stuck in the queue and the queue doesn't complete, successful mails inside that same queue should be removed. I have to look at the source code and just how the queue is processed and cleared. It's an area I have no knowledge but would be nice to know how it works at this point.

The exceptions and errors responses I see in the source code show usage of the "DEBUG" flag. If I compile in debug mode and load it up, where will I find the 'debug' error messages? Do they go to the event log of YAF or are they on screen or what?

In the source code, it looks like all messages in the table are loaded into a dictionary object, spooled to the mailsender, then deleted on a second 'trip' through the dictionary. I am most likely wrong but that's how I read the code. If this is the case, is there any way to get some 'output' from the sendmail task as to if it's having issues somewhere? Would I get that from debug mode? My theory is taking my 'live data' and getting it onto a dev server of mine, load up the debug compiled code, then testing things out with the sendmail task (such as bad emails, high number of messages, and so on) to try to figure out what's keeping successful messages from being removed if they're sent...

No this shouldn't be a problem there is a check if the user is a guest or not before the messages are collected

Yes but currently the code seems wrong normally it should also log email exceptions when not in debug mode but thats not the case. Thats the reason why the event log will be always empty when the send mail threading isnt working.

To finally solve the Problem with the Multiple Mails or Mails not send at all, we need to turn on the logger for this, to hopefully shed some light in to this Problem.

I have setup the mail server to receive non delivery reports and found that a very active user had a non-existant mail address. After changing this with an updated working one all is fine.

Agreed, would be easily to add. I add it later.

I enabled the Logger for the Threaded Send Mail Function

So are you saying you fixed a bad email address also that was clogging the queue and now it's behaving normally?

Exactly.

My forum has 830 users and it is quite easy to keep under control bad email addresses.

But thinking better about it this can hardly be the issue. The mail server should take the message from the client (YAF Forum application) and LATER try to send it to the recipient, so the queue should not clog for this reason.

I am sure there are no connection issues with my previous mail server (it was the one from my provider, on my same subnet, fiber connectivity, no problems at all connecting from another site via Exchange on a quite busy environment) but there could be some about the way YAF connects to it, for example for too frequent sessions opened.

Just my guess, since there is actually no log to examine.

See I don't know how the mail task in YAF accounts for communications with the mail server over 'network' - and how it records 'communication' errors. The issue seems to be occurring during communication with SMTP via "network" if there is some form of error transmitting a particular message, the whole queue is left intact in the table instead of the 'successfully' communicated messages being cleared as success is received.

"It used to work but it is now broken" - How many times have I not said that during my 27 years in the computer business... 😄

I myself use a Merak mail server on the same machine as the forum as the SMTP relay, and have had this issue after 1.9.4, so I don't really believe in the "bad email address" theory. I get all bounces from bad addresses and do not see any connection between a bounce on eg a watched topic and a sudden barrage of 10 new registrations mails for a single user with the same timestamp...

Could it be that the mail process spawns a new thread for every new sendmail in the queue, and if there is some delay in sending there are several threads sending the same mail, due to small delays in the SMTP contact? Ie reading the same first in queue item from the database? Resulting in parallel work instead of strictly sequential?

Just a crazy idea, since I don't know how it works but love speculating in wild theories based on earlier experiences ... 😄

This behaviour is inconsistent: sometimes mailing works fine, sometimes two emails arrive, sometimes five, or six, or seven...

I have changed four mail servers with no apparent effects.

Hopefully developers should investigate on this issue, it is quite annoying for users.

Yes! I think it needs to be done as a priority, it's so annoying now that I'm looking for alternatives to YAF.