• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:
    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.

Dr Web sending lot of emails

Hi GOL

Thanks for the tip.
99,9% of the quarantined files are the same, because of the bounce of the same messages.

Reading maillog file, only two messages caused more than 120000 failure notices and an equal number of quarantined files.
That's why in my case it's better to remove all quaratined files than try to release them.
 
UNDO: Dr.Web Upgrade of 15 Dec 2011.

From all my investigations it appears that there is a new version of Dr.Web on the way.

The version, released on 15 Dec 2011, breaks many people's email installation.

The KB article does not provide a viable alternative/workaround.

I posted my solution earlier, but I want to give more detail on the solution.

1. chown root:root -R /opt/drweb/lib
2. Copy the old version of drweb32.dll from backup back to /opt/drweb/lib. (The drweb32.dll prior to 15 December 2011, has a MD5 sum of: 214c4e38db96e5cafa2720f7b46b3a85 and it is dated 18 February 2011.)
3. cd /var/drweb/bases
4. wget 'http://pastebin.com/raw.php?i=UCWcx9cK' -O update.drl
5. dos2unix update.drl
6. chown drweb:drweb update.drl
7. sudo -u drweb /opt/drweb/update.pl
8. cd

Explanation:
Step 1: Change permissions on the /opt/drweb/lib directory so that only root:root can make changes. Since update.pl runs as drweb:drweb, it can no longer update the drweb32.dll.
Step 2: Restore the previous version of the Dr.Web Antivirus Engine.
Step 3: Change to the directory where all the anti-virus signature databases are located.
Step 4: Get the update.drl file from PasteBin that corresponds to the previous version of the engine. The update.drl file is a file containing URLs from where you can update the anti-virus signature databases. The file is the same on all OSes.
Step 5: Convert the file to a Unix(tm) file.
Step 6: Make sure the file has the correct ownership.
Step 7: Update the anti-virus signature databases by executing the update.pl file as the drweb user.
Step 8: Go back home.

A successful run of update.pl in Step 5, should produce the following output:
# ./update.pl
ERROR: Dr.Web (R) Updater: cannot read file drw50000.vdb.lzma !
Dr.Web (R) update details:
Update server: http://update.fr1.drweb.com/unix/500
Update has begun at Mon Dec 19 14:46:37 2011
Update has finished at Mon Dec 19 14:53:10 2011

Following files has been updated:
/var/drweb/bases/drw50000.vdb
/var/drweb/bases/drw50001.vdb
/var/drweb/bases/drw50002.vdb
/var/drweb/bases/drw50003.vdb
/var/drweb/bases/drw50004.vdb
/var/drweb/bases/drw50005.vdb
/var/drweb/bases/drw50006.vdb
/var/drweb/bases/drw50007.vdb
/var/drweb/bases/drw50008.vdb
/var/drweb/bases/drw50009.vdb
/var/drweb/bases/drw50010.vdb
/var/drweb/bases/drw50011.vdb
/var/drweb/bases/drw50012.vdb
/var/drweb/bases/drw50013.vdb
/var/drweb/bases/drw50014.vdb
/var/drweb/bases/drw50015.vdb
/var/drweb/bases/drw50016.vdb
/var/drweb/bases/drw50017.vdb
/var/drweb/bases/drw50018.vdb
/var/drweb/bases/drw50019.vdb
/var/drweb/bases/drw50020.vdb
/var/drweb/bases/drw50021.vdb
/var/drweb/bases/drw50022.vdb
/var/drweb/bases/drw50023.vdb
/var/drweb/bases/drw50024.vdb
/var/drweb/bases/drw50025.vdb
/var/drweb/bases/drw50026.vdb
/var/drweb/bases/drw50027.vdb
/var/drweb/bases/drw50028.vdb
/var/drweb/bases/drw50029.vdb
/var/drweb/bases/drw50030.vdb
/var/drweb/bases/drw50031.vdb
/var/drweb/bases/drw50032.vdb
/var/drweb/bases/drw50033.vdb
/var/drweb/bases/drw50034.vdb
/var/drweb/bases/drw50035.vdb
/var/drweb/bases/drw50036.vdb
/var/drweb/bases/drw50037.vdb
/var/drweb/bases/drw50038.vdb
/var/drweb/bases/drw50039.vdb
/var/drweb/bases/drw50040.vdb
/var/drweb/bases/drw50041.vdb
/var/drweb/bases/drw50042.vdb
/var/drweb/bases/drw50043.vdb
/var/drweb/bases/drw50044.vdb
/var/drweb/bases/drw50045.vdb
/var/drweb/bases/drw50046.vdb
/var/drweb/bases/drw50047.vdb
/var/drweb/bases/drw50048.vdb
/var/drweb/bases/drw50049.vdb
/var/drweb/bases/drw50050.vdb
/var/drweb/bases/drw50051.vdb
/var/drweb/bases/drw50052.vdb
/var/drweb/bases/drw50053.vdb
/var/drweb/bases/drw50054.vdb
/var/drweb/bases/drw50055.vdb
/var/drweb/bases/drw50056.vdb
/var/drweb/bases/drw50057.vdb
/var/drweb/bases/drw50058.vdb
/var/drweb/bases/drw50059.vdb
/var/drweb/bases/drw50060.vdb
/var/drweb/bases/drw50061.vdb
/var/drweb/bases/drw50062.vdb
/var/drweb/bases/drw50063.vdb
/var/drweb/bases/drw50064.vdb
/var/drweb/bases/drw50065.vdb
/var/drweb/bases/drw50066.vdb
/var/drweb/bases/drw50067.vdb
/var/drweb/bases/drw50068.vdb
/var/drweb/bases/drw50069.vdb
/var/drweb/bases/drw50070.vdb
/var/drweb/bases/drw50071.vdb
/var/drweb/bases/drw50072.vdb
/var/drweb/bases/drw50073.vdb
/var/drweb/bases/drw50074.vdb
/var/drweb/bases/drw50075.vdb
/var/drweb/bases/drw50076.vdb
/var/drweb/bases/drw50077.vdb
/var/drweb/bases/drw50078.vdb
/var/drweb/bases/drw50079.vdb
/var/drweb/bases/drw50080.vdb
/var/drweb/bases/drw50081.vdb
/var/drweb/bases/drw50082.vdb
/var/drweb/bases/drw50083.vdb
/var/drweb/bases/drw50084.vdb
/var/drweb/bases/drw50085.vdb
/var/drweb/bases/drw50086.vdb
/var/drweb/bases/drw50087.vdb
/var/drweb/bases/drw50088.vdb
/var/drweb/bases/drw50089.vdb
/var/drweb/bases/drw50090.vdb
/var/drweb/bases/drw50091.vdb
/var/drweb/bases/drw50092.vdb
/var/drweb/bases/drw50093.vdb
/var/drweb/bases/drw50094.vdb
/var/drweb/bases/drw50095.vdb
/var/drweb/bases/drw50096.vdb
/var/drweb/bases/drw50097.vdb
/var/drweb/bases/drw50098.vdb
/var/drweb/bases/drw50099.vdb
/var/drweb/bases/drw5009a.vdb
/var/drweb/bases/drw5009b.vdb
/var/drweb/bases/drw5009c.vdb
/var/drweb/bases/drw5009d.vdb
/var/drweb/bases/drw5009e.vdb
/var/drweb/bases/drw5009f.vdb
/var/drweb/bases/drw5009g.vdb
/var/drweb/bases/drw5009h.vdb
/var/drweb/bases/drw5009i.vdb
/var/drweb/bases/drwdaily.vdb
/var/drweb/bases/drwebase.vdb
/var/drweb/bases/drwnasty.vdb
/var/drweb/bases/drwrisky.vdb
/var/drweb/bases/drwtoday.vdb
/var/drweb/bases/dwn50000.vdb
/var/drweb/bases/dwn50001.vdb
/var/drweb/bases/dwn50002.vdb
/var/drweb/bases/dwn50003.vdb
/var/drweb/bases/dwn50004.vdb
/var/drweb/bases/dwn50005.vdb
/var/drweb/bases/dwn50006.vdb
/var/drweb/bases/dwn50007.vdb
/var/drweb/bases/dwn50008.vdb
/var/drweb/bases/dwn50009.vdb
/var/drweb/bases/dwn50010.vdb
/var/drweb/bases/dwn50011.vdb
/var/drweb/bases/dwn50012.vdb
/var/drweb/bases/dwn50013.vdb
/var/drweb/bases/dwn50014.vdb
/var/drweb/bases/dwn50015.vdb
/var/drweb/bases/dwn50016.vdb
/var/drweb/bases/dwn50017.vdb
/var/drweb/bases/dwn50018.vdb
/var/drweb/bases/dwn50019.vdb
/var/drweb/bases/dwn50020.vdb
/var/drweb/bases/dwn50021.vdb
/var/drweb/bases/dwn50022.vdb
/var/drweb/bases/dwn50023.vdb
/var/drweb/bases/dwn50024.vdb
/var/drweb/bases/dwn50025.vdb
/var/drweb/bases/dwn50026.vdb
/var/drweb/bases/dwn50027.vdb
/var/drweb/bases/dwn50028.vdb
/var/drweb/bases/dwn50029.vdb
/var/drweb/bases/dwn50030.vdb
/var/drweb/bases/dwntoday.vdb
/var/drweb/bases/dwr50001.vdb
/var/drweb/bases/dwr50002.vdb
/var/drweb/bases/dwr50003.vdb
/var/drweb/bases/dwr50004.vdb
/var/drweb/bases/dwr50005.vdb
/var/drweb/bases/dwr50006.vdb
/var/drweb/bases/dwr50007.vdb
/var/drweb/bases/dwr50008.vdb
/var/drweb/bases/dwr50009.vdb
/var/drweb/bases/dwr50010.vdb
/var/drweb/bases/dwr50011.vdb
/var/drweb/bases/dwr50012.vdb
/var/drweb/bases/dwr50013.vdb
/var/drweb/bases/dwrtoday.vdb
/var/drweb/updates/timestamp
Following files has been removed:
/var/drweb/bases/drw70000.vdb
/var/drweb/bases/drw70001.vdb
/var/drweb/bases/drw70002.vdb
/var/drweb/bases/drw70003.vdb
/var/drweb/bases/drw70004.vdb
/var/drweb/bases/drw70005.vdb
/var/drweb/bases/drw70006.vdb
/var/drweb/bases/drw70007.vdb
/var/drweb/bases/drw70008.vdb
/var/drweb/bases/drw70009.vdb
/var/drweb/bases/dwf70000.vdb
/var/drweb/bases/dwn70000.vdb
/var/drweb/bases/dwp70000.vdb
Click to expand...

Notice how the *700*.vdb files are replaced by the older *500*.vdb files.

To monitor update.pl's progress do an ls -la /var/drweb/spool and monitor how the *500*.vdb.xxxxxxxx files are downloaded.

Once update.pl is complete it will move the *500*.vdb.xxxxxxxx files to the /var/drweb/bases/*500*.vdb files.

This will roll back your Dr.Web installation to the version prior to 15 December 2011.

HTH

--
Regards,
-Carl

EDIT: 19 December 2011 15:18 SAST - Changed the URL for update.drl and added a few additional steps.
 
Last edited:
That's odd - I haven't seen that behaviour!

For each error logged in maillog/messages I have one message in the /infected directory, there were many more messages in the /infected directory but that was because there is nothing that cleans up or prunes that directory so there were quarantined messages from when the server was first setup to the present.

Rob
 
MU #8 didn't resolve this issue, still receiving some notifications when a message with an attached file is received by an account with drweb enabled.

One positive thing is that messages are no more bouncing. So no more tsunamis of messages and quarantined file.

Dear Postmaster,

A message with the following attributes was not delivered because it contains an object which cannot be checked by antivirus.

-------------------

Sender = [email protected]
Recipients = [email protected]
Subject = = some subject
Message-ID = <[email protected]>

--- Antivirus report ---
Detailed report:
127.0.0.1 [9721] drweb.tmp.TeWQaS - archive MAIL
127.0.0.1 [9721] drweb.tmp.TeWQaS/[text:plain] - Ok
127.0.0.1 [9721] drweb.tmp.TeWQaS/[text:html] - archive JS-HTML
127.0.0.1 [9721] >drweb.tmp.TeWQaS/[text:html]/JSClick_1[59] - Ok
127.0.0.1 [9721] >drweb.tmp.TeWQaS/[text:html]/ - read error!

--- Antivirus report ---

The original message was stored in archive record named:
file was not created
 
AdelM,

Once you have applied MU#8, you have to either manually run update.pl (sudo -u drweb /opt/drweb/update.pl) OR you must wait for the cron daemon to do it for you.

To verify that the MU#8 patch has been completely applied, do a ls -la /var/drweb/bases. The output should only contain *500*.vdb files and an update.drl file.

If not, something is not properly updated.

I can confirm that the MU#8/(Plesk 9 = MU#14) patches fixes the problem by rolling back the version of Dr.Web. Personally, I think this should have been done on 15 December 2011 already.

Anyway, there is at least a functional fix available now.

-Carl
 
Thanks Carl for the advice

Updated manually, run a few tests, everything seems to work correctly so far.

Wait and see, hope that this issue is definitly fixed.
 
Rob,

You can apply the solution as per: http://kb.parallels.com/en/113018

In case of Plesk 8.6.0 or if the micro-update installation is not possible, you can follow these steps to update DrWeb bases manually:

Download: http://update.drweb.com/unix/500/update.drl
Put it to: /var/drweb/bases
Update DrWeb databases:
# sudo –u drweb /opt/drweb/update.pl

Note: Plesk prior to v8.6.0 ships Dr.Web 4.33, which is EOL now and is no longer being updated. Please update to at least Plesk v8.6.0, where Dr.Web 5.x support is provided.

The above solution works on Plesk 8, 9 and 10.

-Carl
 
Thanks for that Carl - will apply it manually.

Kind of annoying that the documentation to this issue points to MU#14 for 9.5 which doesn't seem to exist! <sigh>

Will be interesting to see what happens when the next MU is released! :)
 
How to restore the mails from the "infected" directory

I have the same problem and applied the above solution. I also updated drweb manually.
Seems to work now, but not definitely sure.

But I have still some files - some definitely false positives - in the infected directory.

Has anyone an idea how to restore those mails using the CLI?
I don't want to install the GUI version, which requires webadmin, which most probably will conflict with PLESK.
 
Restore?

Does anyone know how I can restore the quarantined emails?

Version: drweb 5.0.1-0plesk
Control-Panel: Plesk 9.5.4
 
Bump:

"Does anyone know how I can restore the quarantined emails?"

Is there any easy way to re queue these emails from /var/drweb/infected ?

I have a feeling I can manually inject them using qmail-inject but i am not an expert at this so if anyone has any insight it would be greatly appreciated!

Thanks so much!
 
AdamS. said:
Is there any easy way to re queue these emails from /var/drweb/infected ?
Click to expand...

You may try to resend rejected emails by the following way:

==========

# grep -iA1 quarantine /etc/drweb/drweb32.ini
# Path to quarantine directory.
MoveFilesTo = /var/drweb/infected

# cd /var/drweb/infected/
# for i in `ls -1`; do sendmail -t < $i ; done

==========
 
Hello,

- I have updated from 8.6.x to 9.0 just 3 days ago.
- I have updated the latest microupdates with
# $PRODUCT_ROOT_D/admin/sbin/autoinstaller --select-product-id plesk --select-release-current --reinstall-patch --install-component base
then as well as just now.

Also I have the latest Dr Web Updates.

The strange thing is:
I don't even _use_ Dr. Web!
No mailbox on this server has Dr Web and the systemwide Antivirus settings are set to "no antivirus filter".

Still every single mail sent to the Plesk Server gets:

> Von: "DrWeb-DAEMON"@XXXXXXX
[...]
> the message with following attributes has not been delivered, because
> contains an object which cannot be checked by antivirus filter.


But wait - there's more: The best is: The mails are all being delivered! Even though Plesk issues an error! No mail has yet got lost, all get delivered but still Plesk sends out this notifications for each and every mail.


Can someone please help? Shall I continue to update from 9.0 to 9.5 or 10 or how do I get this thing handeled?

Should I perhaps just kill the Dr Web Deamon as I don't use it anyway?

Any comments might help... Thanks.
 
Requeuing Mail from Quarantine

Igor, can you please explain to me in some more detail how to initate the resending of emails that I believe have incorrectly being quarantined.

Our servers are CentOS 6.x

Kind Regards,
 
You must log in or register to reply here.

Similar threads

D
Issue Spoofed Emails Appearing as Sent from My Own Server Despite Correct SPF/DKIM/DMARC Configuration?
Replies
2
Views
828
drdna
D
M
Question Hackers are sending tons of mails
Replies
4
Views
639
MrPleskLearner
M
carlsson
Resolved Outgoing administrator mail not authorized [missing SPF record in sender domain]
Replies
11
Views
3K
rkbonatto
rkbonatto
K
Question Mail not sended.
Replies
2
Views
1K
klamort
K
A
Issue DKIM and DMARC issue, emails not sending
Replies
4
Views
2K
danami
danami
Back
Top