Information on BugID

Yes,

yesterday I looked for the explanation on this topic.

I need to tell my customers also what was going on.

Thanks Astaro

Alex

Known Issue List of v6 says:
---------------------------


Closed Issues
=============


ID3966 6.203 Duplicate emails sent from SMTP Proxy
--------------------------------------------------
Description: Also there has been some improvements to avoid duplicate
             emails being sent from SMTP Proxy, an issue in the server
             backend may have caused some emails to be duplicated again.
             In order to avoid this kind of problems another software
             change is necessary.
Workaround:  ---
Fix:         Fixed in 6.300

Hmmmm that didn't tell me much :-) I'm still as blank as before I read it ;-)

Me too... what was the problem. Why did it occur only the last days. Other members reported the same !! 

Alex

As far I remember, think it only happened once and only at one system of our 70 installations, the Firewall made a "double post".

Firewall sends the mail to the backend smtp server, then gets some strange error, and sends again, also the smtp server recieved the mail at first try. (doubled the mail)

We've got lots of not only double, but up to 20 copies of the same email, over a period of approx. 1 week. It all disappeared after installing 6.203. But I don't think 6.203 solved the problem, but that the reboot of the system cleared all tables relates to exim. Now we've installed 6.300 to hopefully have solved the problem from coming back.
But I need a desription of the problem, not just information that there was a problem, Customers demand to know what the problem was, so I need to know what it was so I can explain it to our customers.

Can't tell you where the bug was, either the exim or the av engines. But I never seen this bug in any exim configuration so I guess it was the av engines.

It is similar to the behavior of outlook in connection with the pop3av transparent proxy and an exchange server, when the outlook timeout is to low, and the line is very slow.

Hi,

had weird problems 2 days ago with VERY slow email delivery at a customers astaro's.
I found out  that in 6.202 i had a problem with sending mail via telnet worked BUT the ". QUIT" took sometimes several minutes...
I was able to reproduce it on the other Machine (HA-Switch)
A reboot or SMTP Proxy stop/start didnt helped.
After installing 6.203 it worked greatfast and also no probs with 6.300 now.

Regards,
Bernd

Hi there all, 

dublicate emails occure if for whatever reason, the scanning of an email message takes longer as the client timeout of the sending SMTP client.

The client timeout is normally between 30-60 seconds.

Now if the the processing of the email takes longer than those 60 seconds, the SMTP client thinks the server is dead and the message has not been delivered, as he has not received the QUIT command.
Therefore the client schedules anotherdelivery n minutes later.

After scanning of an email the SMTP Proxy immidiatly tries to deliver the message and if that was successfull, he sents the QUIT back, but the client has already disconnected.

There were two main reasons why scannig took to long, which triggered dublicate emails:
The old AV scanner got slower and slower over time, as the amount of pattern increased.
We had an innefficient way to detect which is the fastest URL database server to query, which sometimes took up to 10 seconds, and if one of the server resoponded slow, it was even worse.
For every email we find URLs in, we ask our database if this is a known spam URL. This will than increase the spam score.

In ASG V6.300 we added a much faster AV engine and a more efficient way to select the database servers which also removes slow database servers from the list. On top of that we setup addition database server to handle the load better.

I hope that explains it better.

Unfortunatly this will not fix the theoretical possibility of dublicate emails, but will minimize the effect dramatically.

Sidenote: we have found another possibility which increases the possibilty of dublicate emails, if you are using the HTTP parent proxy. This will be fixed in the next up2date package.

Best regards
Gert

Hi there all, 

dublicate emails occure if for whatever reason, the scanning of an email message takes longer as the client timeout of the sending SMTP client.

The client timeout is normally between 30-60 seconds.

Now if the the processing of the email takes longer than those 60 seconds, the SMTP client thinks the server is dead and the message has not been delivered, as he has not received the QUIT command.
Therefore the client schedules anotherdelivery n minutes later.

After scanning of an email the SMTP Proxy immidiatly tries to deliver the message and if that was successfull, he sents the QUIT back, but the client has already disconnected.

There were two main reasons why scannig took to long, which triggered dublicate emails:
The old AV scanner got slower and slower over time, as the amount of pattern increased.
We had an innefficient way to detect which is the fastest URL database server to query, which sometimes took up to 10 seconds, and if one of the server resoponded slow, it was even worse.
For every email we find URLs in, we ask our database if this is a known spam URL. This will than increase the spam score.

In ASG V6.300 we added a much faster AV engine and a more efficient way to select the database servers which also removes slow database servers from the list. On top of that we setup addition database server to handle the load better.

I hope that explains it better.

Unfortunatly this will not fix the theoretical possibility of dublicate emails, but will minimize the effect dramatically.

Sidenote: we have found another possibility which increases the possibilty of dublicate emails, if you are using the HTTP parent proxy. This will be fixed in the next up2date package.

Best regards
Gert

Hello Gert,

This is just the information I needed. Thank you very much. [:D]