Yes we use a CA antivirus product and I find we actually have to turn the real time off completely because even with the drive the email is on exempted from real time checking it still seems to Detect viruses in files on those drives, mainly when our archive Pegasus account which runs on the same server is filtering emails.   I have just changed the settings so that it never starts that way I should not have to remember to turn it off.

 I tried to get ClamAV working a week or so back I really ought to get back onto that.   I noted a thread where someone else was having similar problems the other day so I'd better read it!
 

We have always had a huge volume of mails directed at made up addresses at our domain.   In the past I have set Mercury to refuse mail for invalid local addresses which seemed to work OK for us but recently I think since we changed to Mercury 4.52 our ISP has complained that a huge queue of un delivered email for our domain had built up.   When I tried to turn refuse mail for invalid local addresses off again we built up a huge queue of files in our Mercury Queue directory which seemed to actually stop Mercury from processing any mail in a timely fashion.

 I am told by our ISP that if we send a permanant delivery failure message when refusing mail for invalid local addresses they would delete the mail and not retry it so I have asked them to check the message that we are using to find out.   Does Mercury send a permanent fail message if its refusing mail for local addresses and if we do not refuse such mail what happens to it when it gets on to our server?

Meanwhile I have a backlog of about 8000 QDF and QCF files in my queue directory and I do not know which of them are valid messages.
 

[quote user="chriscw"]

We have always had a huge volume of mails directed at made up addresses at our domain.   In the past I have set Mercury to refuse mail for invalid local addresses which seemed to work OK for us but recently I think since we changed to Mercury 4.52 our ISP has complained that a huge queue of un delivered email for our domain had built up.   When I tried to turn refuse mail for invalid local addresses off again we built up a huge queue of files in our Mercury Queue directory which seemed to actually stop Mercury from processing any mail in a timely fashion.

 I am told by our ISP that if we send a permanent delivery failure message when refusing mail for invalid local addresses they would delete the mail and not retry it so I have asked them to check the message that we are using to find out.   Does Mercury send a permanent fail message if its refusing mail for local addresses and if we do not refuse such mail what happens to it when it gets on to our server?

Meanwhile I have a backlog of about 8000 QDF and QCF files in my queue directory and I do not know which of them are valid messages.
 

[/quote]

Mail rejected by MercuryS  is rejected with a 500 series message.  You can test this yourself by sending a message to your system to an invalid address and read the bounce message. 

I'm slightly confused about how you receive mail. Are incoming SMTP transactions somehow relayed through your ISPs mail server? Or do you pick up mail from their server with the POP3 client module?  The setting to refuse mail  for invalid local addresses should return a 500 series error for SMTP transactions, and should have no effect for POP3.

Greywall on the other hand will refuse SMTP connections with a 400 series error.

/Rolf 

What modules do you use?

MercuryS SMTP Server

MercuryP POP3 Server

MercuryC SMTP Client

MercuryI IMAP Server 

I have been in contact with our ISP since setting refuse email to invalid local addresses to off again and they have admitted that they think the problem was at their end and said that the Queue on their server is clear.

That said this morning Mercury (4.52) had a short unmoving queue our end again, it was also hard for our Thunderbird users to connect via IMAP.   I was also not getting my bounce test messages back to my Yahoo account.   I had to stop and restart Mercury to kick things back into life.   A lot of files were then processed quite quickly and I checked the queue again to find that quite a number of 'orphan' .QCF files had accumulated all had a 0 length and were empty.   I stopped Mercury a second time and deleted these and things seem to have settled down.   Is the occasional creation of empty orphan QCF files a normal and self correcting process or does it indicate that we had another problem of some sort.

My bounce test messages are now working again so all appears to be back to normal.

I did an invalid address test and it certainly came back to me pretty promptly as a delivery failure.   I could not find the error message easily in pegasus but Yahoo reported a 550 error which is what I would expect.

 So it looks as if our ISP have sorted their issue with retrying inavalid addresses ad Nauseam  we shall see.
 

[quote user="chriscw"]

MercuryS SMTP Server

MercuryP POP3 Server

MercuryC SMTP Client

MercuryI IMAP Server 

I have been in contact with our ISP since setting refuse email to invalid local addresses to off again and they have admitted that they think the problem was at their end and said that the Queue on their server is clear.

That said this morning Mercury (4.52) had a short unmoving queue our end again, it was also hard for our Thunderbird users to connect via IMAP.   I was also not getting my bounce test messages back to my Yahoo account.   I had to stop and restart Mercury to kick things back into life.   A lot of files were then processed quite quickly and I checked the queue again to find that quite a number of 'orphan' .QCF files had accumulated all had a 0 length and were empty.   I stopped Mercury a second time and deleted these and things seem to have settled down.   Is the occasional creation of empty orphan QCF files a normal and self correcting process or does it indicate that we had another problem of some sort.

My bounce test messages are now working again so all appears to be back to normal.

[/quote]

It is not normal for there to be these zero byte files and I suspect Mercury/32 is fighting some other  application for access to it's directories for reading/writing files.  The first thng that comes to mind is that you have some on access anti-virus runnung against the Mercury/32 directories.