Teknik Destek

How to test SpamAssassin To test the spam filter, it is necessary to send a Gtube test spam email using the command below (Replacing emailonserver@example.com with a real email account on the server). If the Anti-spam is working correctly you will see it listed in the maillog and in Warden log under Warden -> Logs -> Message Log. While testing, note that Gtube test email gives +1000 scores to spam. So, even if a mailbox is in the whitelist, mail still be detected as spam because whitelisted email gets -100 scores. Disable Greylisting: If greylisting is enabled then you must disable it on the recipient domain before running these tests. /usr/local/psa/bin/grey_listing --update-domain example.com -status off Centos/RHEL/CloudLinux/AlmaLinux: echo "XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X" | mail -S smtp=localhost -r sender@test.com -s "Spam test example" emailonserver@example.com Debian/Ubuntu: apt-get install s-nail echo "XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X" | s-nail -S smtp=localhost -r sender@test.com -s "Spam test example" emailonserver@example.com How to test ClamAV
To test the virus filter, it is necessary to download the eicar test virus email and send it using the command below (Replacing emailonserver@example.com with a real email account on the server). If the Anti-virus is working correctly you will see it get blocked and it will be listed in the maillog and in Warden -> Logs -> Message Log. Disable Greylisting: If greylisting is enabled then you must disable it on the recipient domain before running these tests. /usr/local/psa/bin/grey_listing --update-domain example.com -status off Centos/RHEL/CloudLinux/AlmaLinux: wget http://www.eicar.org/download/eicar.com.txt echo "TEST MESSAGE w/ ATTACHMENT" | mail -S smtp=localhost -r sender@test.com -s "A/V test example" -a eicar.com.txt emailonserver@example.com Debian/Ubuntu: apt-get install s-nail wget http://www.eicar.org/download/eicar.com.txt echo "TEST MESSAGE w/ ATTACHMENT" | s-nail -S smtp=localhost -r sender@test.com -s "A/V test example" -a eicar.com.txt emailonserver@example.com
Tüm Makaleyi Görüntüle...

In order for PHP to log what scripts are sending out from the server you must first set mail.add_x_header = On in all the php.ini files that are being used by the server. 1. Enable the mail.add_x_header in all of your PHP.ini files: // turn on for the OS default php version if you have the base PHP packages installed sed -i -e "s/^mail.add_x_header = Off/mail.add_x_header = On/" /etc/php.ini // turn on for all of the Plesk PHP versions sed -i -e "s/^mail.add_x_header = Off/mail.add_x_header = On/" /opt/plesk/php/*/etc/php.ini // restart any PHP FPM instances systemctl restart plesk-php73-fpm systemctl restart plesk-php74-fpm systemctl restart plesk-php80-fpm 2. Go to Warden -> Settings -> Filter Settings and make sure that the Log template option is set to verbose. 3. Now you should see the X-PHP-Originating-Script header logged when clicking on the plus icon for a message entry that was sent out using PHP in the message log. It will log the UID of the user that ran the script and the script name. Looking up the User from the X-PHP-Originating-Script Header The X-PHP-Originating-Script header consists of the UID of the user and the script name: X-PHP-Originating-Script: 10000:class.phpmailer.php To find the vhost directory from a UID (replace the UID with the user ID that was logged): grep UID /etc/passwd 5. To find the full path to a script (replace the path with the vhost directory from the UID and the php script name with the name of the script that was logged): find /var/www/vhosts/example.com/httpdocs -type f -name "class.phpmailer.php" Viewing the X-PHP-Originating-Script Header from the Queue When viewing a message in the Warden queue, the PHP tab will lookup the local user information based off the X-PHP-Originating-Script header (if it exists) and search the vhost files for any matching script files with the same name.
Tüm Makaleyi Görüntüle...

Amavis will tag the subject line of any email that it can't scan with the tag UNCHECKED. ClamAV Problems First check and see that the ClamAV daemon is running properly. See: How can I check the status of ClamAV and fix any problems? Password Protected Archives Amavis will prepend to Subject (for local recipients only) if mail could not be decoded or checked entirely, e.g. due to password-protected archives. To Disable the UNCHECKED Header (Not recommended)
To disable this on Centos/RHEL edit the file /etc/amavisd/warden.conf or on Debian/Ubuntu edit the file /etc/amavis/conf.d/99-warden and add the line (before the last line 1;): $undecipherable_subject_tag = undef; After making the changes restart Amavis: // Centos/RHEL/CloudLinux/AlmaLinux systemctl restart amavisd // Debian/Ubuntu systemctl restart amavis
Tüm Makaleyi Görüntüle...

To get your free Maxmind license key Signup for the free license key here: https://www.maxmind.com/en/geolite2/signup Generate a license key here (When asked - Will this key be used for geoipupdate? Choose: no) Navigate to your Extension -> Settings -> Panel Application -> Geolocation Settings and enter the license key under MaxMind license key. (It might take 30 minutes before MaxMind will recognize a newly created key). Press the Update button to save your settings.
Tüm Makaleyi Görüntüle...

Bad Header Destiny The default setting under Warden -> Settings -> Content Filter-> Content Filter Settings -> Bad header destiny is set to reject. The server wide policy option under Warden -> Settings -> Content Filter -> Policy Settings -> Receive bad header emails is set to Yes to allow bad header emails to pass to the mailbox. This means that Amavis will store a copy of the bad header emails for review but will still allow the emails to pass to the users mailbox. Warden will delete the quarantined copies of the messages automatically after 30 days.
If you would like to reject mail with bad headers you can change the server wide policy option under Warden -> Settings -> Content Filter -> Policy Settings -> Receive bad header emails is set to No. Then bad header emails will not be passed though to the users mailbox.

To disable all bad header tests To disable all bad header tests on Centos/RHEL/CloudLinux/AlmaLinux edit the file /etc/amavisd/warden.conf or on Debian/Ubuntu edit the file /etc/amavis/conf.d/99-warden and search for the @bypass_header_checks_maps option. Change from: @bypass_header_checks_maps = (\%bypass_header_checks, \@bypass_header_checks_acl, \$bypass_header_checks_re); Change to: @bypass_header_checks_maps = [1]; After making these changes restart Amavis: // Centos/RHEL/CloudLinux/AlmaLinux systemctl restart amavisd // Debian/Ubuntu systemctl restart amavis To disable all bad header tests for a specific policy bank (outgoing email only) Go to Warden -> Settings -> Policy Banks and set the Disable bad header filter to Yes for the policy you want to disable it on. To disable specific bad header tests There is an $allowed_header_tests option by which you can define what should be looked up during the bad-header checks, and the list is as follows: other catchall for everything else - normally not used mime Bad MIME (sub)headers or bad MIME structure 8bit Invalid non-encoded 8-bit characters in header control Invalid control characters in header (CR or NUL) empty Folded header field made up entirely of whitespace long Header line longer than RFC 2822 limit of 998 characters syntax Header field syntax error missing Missing required header field multiple Duplicate or multiple occurrence of a header field To disable certain tests on Centos/RHEL/CloudLinux/AlmaLinux edit the file /etc/amavisd/warden.conf or on Debian/Ubuntu edit the file /etc/amavis/conf.d/99-warden and search for the $allowed_header_tests option. Setting a test to 0 will disable that test: $allowed_header_tests{'multiple'} = 0; $allowed_header_tests{'missing'} = 0; After making these changes restart Amavis // Centos/RHEL/CloudLinux/AlmaLinux systemctl restart amavisd // Debian/Ubuntu systemctl restart amavis  
Tüm Makaleyi Görüntüle...

From the Extension Interface Admins can remove a reported IP address by clicking on the IP address from any of the grid pages then click on the reputation tab then select the clear operation. From the AbuseIPDB Website Registered users have the option to remove their own reports via the Reports section of the AbuseIPDB user control panel. Additionally there is a take down request feature on the each reported IP addresses page, usable by all registered users. 
Tüm Makaleyi Görüntüle...

AbuseIPDB is the gold standard for abuse reporting and is used by some of the largest hosting companies worldwide. To enable AbuseIPDB support within the extension: Sign up for a free API key here. The free API key is good for up to 1000 checks per day. Generate an API key here. Enter your API key at Settings -> Network Tools Settings -> Reputation Settings -> AbuseIPDB API key. Check the "Block Reporting" checkbox to have the login failure daemon report failed trigger blocks back to AbuseIPDB automatically (Juggernaut Firewall extension only). Press the update button to save your settings. Check an IP Address To check an IP address click on an IP address then select "Reputation". Report an IP Address To report an IP address select "Report" from the operation select list. Then select the abuse categories you want it. Remove a Reported IP Address To remove a reported a IP address select "Clear" from the operation select list (You are limited to 10 clear operations per day). See here for how to remove a reported IP address from the AbuseIPDB website. Block Reporting If "Block Reporting" is enabled the login failure daemon will report failed triggers back to AbuseIPDB automatically. (Juggernaut Firewall extension only) AbuseIPDB Blocklist
Navigate to Juggernaut Firewall -> Settings -> Login Failure Daemon -> IP Block Lists Click the edit icon next to the AbuseIPDB block list. Replace YOUR_API_KEY with your API key in the source URL. Check the enabled checkbox. Then press the submit button to save the entry then press the restart button to restart the firewall and login failure daemon. Check the Enabled checkbox and press the submit button. Press the Restart button on the grid so that the login failure daemon will download the new blocklist. // Default Source URL https://api.abuseipdb.com/api/v2/blacklist?plaintext&limit=65000&confidenceMinimum=100&key=YOUR_API_KEY // Replace YOUR_API_KEY with the API key that you generate https://api.abuseipdb.com/api/v2/blacklist?plaintext&limit=65000&confidenceMinimum=100&key=db413d60408bd4cba20840285402385sdjfasjdpu09374934gsdfg99de1f You can see the view the login failure daemon download the block list under Logs -> LDF log 2022-01-19 01:28:53 PM 5105 IPSET: switching set new_6_ABUSEIPDB to bl_6_ABUSEIPDB 2022-01-19 01:28:53 PM 5105 IPSET: loading set new_6_ABUSEIPDB with 99 entries 2022-01-19 01:28:52 PM 5105 IPSET: switching set new_ABUSEIPDB to bl_ABUSEIPDB 2022-01-19 01:28:52 PM 5105 IPSET: loading set new_ABUSEIPDB with 46914 entries Block list entries are stored in the /var/lib/csf/ directory. Note: CSF will optimize downloaded blocklists so if another blocklist already has the same IP address then it will not be included. To view the number of entries for a blocklist on the command line: # wc -l /var/lib/csf/csf.block.ABUSEIPDB 74140 /var/lib/csf/csf.block.ABUSEIPDB AbuseIPDB Free vs Paid Plans The free plan blocklist is limited to a maximum of 10,000 IP addresses. Paid users can include more IP addresses by raising the limit option and lowering the confidenceMinimum option in the source URL. Admins should first raise the Juggernaut Firewall -> Settings -> General Settings -> Ipset maxelem option larger than your limit (e.g. 100,000 - so that you don't get ipset errors loading a large blocklist of that size). // Paid source URL example with limit set to 100,000 IP addresses and a confidenceMinimum set to 75 https://api.abuseipdb.com/api/v2/blacklist?plaintext&limit=100000&confidenceMinimum=75&key=db413d60408bd4cba20840285402385sdjfasjdpu09374934gsdfg99de1f AbuseIPDB has a nice graph with how many IP addresses will be included at different confidence minimums here.
Tüm Makaleyi Görüntüle...

About Greylisting Important: Greylisting is recommended for advanced users only. Make sure to read though this article thoroughly so that you don't accidentally get extended delays in legitimate email after enabling greylisting.
Greylisting is a method of defending against spam. Greylisting will tell the mail server to temporarily reject any email from a sender it does not recognize. If the mail is legitimate, the originating server will try again after a delay, and if sufficient time has elapsed, the email will be accepted. Warden uses Plesk's built in greylisting tool. Server-wide and domain level greylisting management is supported by Warden. Personal level (mailbox level) grey listing management is not supported and should not be enabled.
Server-wide greylisting can be enabled/disabled in Warden ->Settings -> Greylisting Settings -> Greylisting . Unchecking and disabling the server wide setting will disable all greylisting and hide the greylisting tab in Warden for all domains. Domain level greylisting can be enabled/disabled under Warden -> Policies -> click the edit icon next to the domain on the grid -> Greylisting -> Disable greylisting option (yes or no). Greylisting defers emails from senders that use multiple IP addresses so it is important to whitelist those providers otherwise you will get extended delays in email. Look at the "Senders that use multiple IP addresses" section below for how to whitelist those mail servers. Greylisting will be applied to any non-authenticated email (both incoming and outgoing email). There will be longer delays in email delivery after first enabling greylisting as it might take a few days for entries to be populated in the greylisting database. Enabling Greylisting To enable greylisting server wide go to Warden -> Settings -> Greylisting Settings -> Check the greylisting option to enable it. Note that unchecking and disabling the server wide setting will disable all greylisting and hide the greylisting tab in Warden for all domains. After greylising is enabled server wide you have the option of disabling greylisting per domain under Warden -> Policies -> click the edit icon next to the domain on the grid -> Greylisting -> Disable greylisting (yes or no). Viewing Greylisted Emails Emails that are greylisted will be listed under Warden -> Logs -> Reject Log. Greylisted entries will have the a 451 4.7.1 status with the message Service unavailable - try again later (postfix is telling the other mail server to try again later). You can use the message select list on the reject page to filter by Service unavailable - try again later to view all greylisted entries. Normally greylisted emails will have at least 3 rejected entries before delivery is accepted. The Client rDNS column in the reject log is important as that is what you will use to whitelist a mail server from greylisting. If you see many entries for the same message coming from different IP addresses then you might need to create a wildcard whitelist for that provider. See: "Sender mail servers that use multiple IP addresses" below for more information. Sender mail servers that use multiple IP addresses After enabling greylisting it is important to review your Warden -> Logs -> Reject log over the next week in order to whitelist those mail service providers that send using multiple IP addresses otherwise you will get extended delays in email. It could take 1 or 2 days for delivery with greylisting enabled unless you whitelist those mail servers. You can whitelist the mail servers using a matching wildcard on the Client rDNS (PTR record) of the connecting mail server. Example: You might see the same email in the reject log coming from different mail servers from one provider: a15-177.smtp-out.amazonses.com a14-30.smtp-out.amazonses.com a15-229.smtp-out.amazonses.com e252-50.smtp-out.amazonses.com To whitelist emails from Amazon matching all of the mail servers you can whitelist it using a wildcard entry (Remember that you are whitelisting the client RDNS record of the email server not an email address): plesk bin grey_listing --update-server -domains-whitelist add:"*.amazonses.com" Known providers that send out using multiple IP addresses: // Adobe plesk bin grey_listing --update-server -domains-whitelist add:"*.adobe.com" // Amazon plesk bin grey_listing --update-server -domains-whitelist add:"*.amazonses.com" // Ebay plesk bin grey_listing --update-server -domains-whitelist add:"*.ebay.com" // Google plesk bin grey_listing --update-server -domains-whitelist add:"*.google.com" // Github plesk bin grey_listing --update-server -domains-whitelist add:"*.github.com" // Linkedin plesk bin grey_listing --update-server -domains-whitelist add:"*.linkedin.com" // Paypal plesk bin grey_listing --update-server -domains-whitelist add:"*.paypal.com" // Shopify plesk bin grey_listing --update-server -domains-whitelist add:"*.shopify.com" // Telus plesk bin grey_listing --update-server -domains-whitelist add:"*.telus.com" Configuring Greylisting Parameters like expire-interval, grey-interval, penalty-interval, and others can be configured under Warden -> Settings -> Greylisting Settings or using the Plesk CLI utility "grey_listing". Note: The personal command line option --update-mailname is not supported as it's tied to Plesk's legacy spam filter. To view the current greylisting settings: plesk bin grey_listing --info-server To enable greylisting for a specific domain: plesk bin grey_listing --update-domain example.com -status on To disable greylisting for a specific domain: plesk bin grey_listing --update-domain example.com -status off Whitelisting To whitelist a mail server from greylisting (Remember that you are whitelisting the client RDNS record of the email server not an email address): plesk bin grey_listing --update-server -domains-whitelist add:"mail.example.com" To remove a whitelisted mail server from greylisting: plesk bin grey_listing --update-server -domains-whitelist del:"mail.example.com" Blacklisting By default greylisting will block any client rDNS that matches the following patterns (The default patterns match dynamic hosts that should not be sending any emails). Mail servers that are blacklisted will be listed under Warden -> Logs -> Reject Log. Blacklisted entries will have the a 451 4.7.1 status with the message Command rejected. *[0-9][0-9]-[0-9][0-9]-[0-9][0-9]* *[0-9][0-9].[0-9][0-9].[0-9][0-9]* *[0-9][0-9][0-9]-[0-9][0-9][0-9]-[0-9][0-9][0-9]* *[0-9][0-9][0-9].[0-9][0-9][0-9].[0-9[0-9]][0-9]* dsl|broadband|hsd dynamic|static|ppp|dyn-ip|dial-up To add blacklist patterns: plesk bin grey_listing --update-server -domains-blacklist add:"mail.badserver.com" To remove blacklist patterns: plesk bin grey_listing --update-server -domains-blacklist del:"mail.badserver.com" Adjusting the Default Blacklist Patterns
Some of the default blacklist patterns will likely block email from legitimate providers so it is recommended that you remove them: // matches mta-70-12-15.sparkpostmail.com plesk bin grey_listing --update-server -domains-blacklist del:"*[0-9][0-9]-[0-9][0-9]-[0-9][0-9]*" // matches outbound-147-160-155-33.pinterestmail.com plesk bin grey_listing --update-server -domains-blacklist del:"*[0-9][0-9][0-9]-[0-9][0-9][0-9]-[0-9][0-9][0-9]*" // matches mail25.static.mailgun.info so we remove the "static" pattern then re-add the rest plesk bin grey_listing --update-server -domains-blacklist del:"dynamic|static|ppp|dyn-ip|dial-up" plesk bin grey_listing --update-server -domains-blacklist add:"dynamic|ppp|dyn-ip|dial-up" Disabling Greylisting For Newly Created Domains Some users may want to have greylisting enabled server wide but have greylisting disabled by default for newly created domains. This can be done using a Plesk event handler. In Plesk go to Tools & Settings -> Event Manager -> Add Event Handler: Event: Default domain (the first domain added to a subscription) created Priorty: lowest(0) User: root Command: /usr/local/psa/bin/grey_listing --update-domain <NEW_DOMAIN_NAME> -status off  
Tüm Makaleyi Görüntüle...