Check if your web site is secure

Analyze your web site with this mozzilla link

  1. put this link in the header of your html template page :

    <meta http-equiv=“Content-Security-Policy” content=“default-src ‘self’; child-src ‘none’; object-src ‘none'”>

  2. in your php.ini file set these rows :

    session.cookie_secure = 1

    session.use_only_cookies = 1

    session.cookie_httponly = 1

  3. Enabling the X-Content-Type-Options Header#

    To enable this security header on your origin server is quite easily and can be done in just a couple steps. Depending upon which web server you’re using will determine which snippet you should add to your server’s configuration file. The following section outlines what needs to be added to both Nginx and Apache web servers.


    For Nginx users, add the following snippet to your .conf file. Once done, save your changes and reload Nginx.

    add_header X-Content-Type-Options "nosniff"

    For Apache users, simply add the following snippet to your .htaccess file. Once done, save your changes.

    Header set X-Content-Type-Options "nosniff"

    Enabling your web server to deliver the X-Content-Type-Options header is quite simple to do.

  4. Implementation Procedure in Apache

    • Ensure you have enabled in Apache HTTP server
    • Add following entry in httpd.conf
    Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
    • Restart Apache HTTP server to test

    Note: Header edit is not compatible with lower than Apache 2.2.4 version.

  5. Configuring Apache

    To configure Apache to send the X-Frame-Options header for all pages, add this to your site’s configuration:

    Header always set X-Frame-Options "sameorigin"

    To configure Apache to set the X-Frame-Options deny , add this to your site’s configuration:

    Header set X-Frame-Options "deny"

    Configuring nginx

    To configure nginx to send the X-Frame-Options header, add this either to your http, server or location configuration:

Install and configure Milter Manager

Install to CentOS 7

Install to CentOS 7 — How to install milter manager to CentOS 7

About this document

This document describes how to install milter manager to CentOS 7. See Install for general install information.

In this document, CentOS 7.6 is used. Sudo is used to run a command with root privilege. If you don’t use sudo, use su instead.

Install packages

Postfix is used as MTA because it’s installed by default.

Spamass-milter, clamav-milter and milter-greylist are used as milters. Milter packages registered in EPEL are used.

Register EPEL like the following:

% sudo yum install -y epel-release

Now, you install milters:

% sudo yum install -y spamass-milter-postfix clamav-scanner-systemd clamav-update clamav-milter clamav-milter-systemd milter-greylist

And you install RRDtool for generating graphs:

% sudo yum install -y rrdtool

Build and Install

milter manager can be installed by yum.

Register milter manager yum repository like the following:

% curl -s | sudo bash

See also: <URL:>

Now, you install milter manager:

% sudo yum install -y milter-manager


Here is a basic configuration policy.

milter-greylist should be applied only if S25R condition is matched to reduce needless delivery delay. But the configuration is automatically done by milter manager. You need to do nothing for it.

It’s difficult that milter manager runs on SELinux. Disable SELinux policy module for Postfix and Milter.

% sudo semodule -d postfix
% sudo semodule -d milter

Configure spamass-milter

At first, you configure spamd.

spamd adds “[SPAM]” to spam mail’s subject by default. If you don’t like the behavior, edit /etc/mail/spamassassin/


rewrite_header Subject [SPAM]


# rewrite_header Subject [SPAM]

Add the following configuration to /etc/mail/spamassassin/ This configuration is for adding headers only if spam detected.

remove_header ham Status
remove_header ham Level

Start spamd on startup:

% sudo systemctl enable spamassassin

Start spamd:

% sudo systemctl start spamassassin

Here are spamass-milter’s configuration items:

  • Disable needless body change feature.
  • Reject if score is larger than or equal to 15.

Change /etc/sysconfig/spamass-milter:


#EXTRA_FLAGS="-m -r 15"


EXTRA_FLAGS="-m -r 15"

Start spamass-milter on startup:

% sudo systemctl enable spamass-milter

Start spamass-milter:

% sudo systemctl start spamass-milter

Configure clamav-milter

Update ClamAV virus database and start clamd.

Edit /etc/freshclam.conf like the following. It comments out “Example”, changes “NotifyClamd” value and uncomments other items.


#LogFacility LOG_MAIL
#NotifyClamd /path/to/clamd.conf


LogFacility LOG_MAIL
NotifyClamd /etc/clamd.d/scan.conf

Run freshclam by hand at the first time:

% sudo freshclam

Configure clamd.

Edit /etc/clamd.d/scan.conf like the following. It comments out “Example” and uncomments other items:


#LogFacility LOG_MAIL
#LocalSocket /run/clamd.scan/clamd.sock


LogFacility LOG_MAIL
LocalSocket /run/clamd.scan/clamd.sock

Start clamd on startup:

% sudo systemctl enable [email protected]

Start clamd:

% sudo systemctl start [email protected]

Configure clamav-milter.

Edit /etc/mail/clamav-milter.conf like the following. It comments out “Example”, change “ClamdSocket” value and uncomments other items:


#MilterSocket /run/clamav-milter/clamav-milter.socket
#MilterSocketMode 660
#ClamdSocket tcp:scanner.mydomain:7357
#LogFacility LOG_MAIL


MilterSocket /run/clamav-milter/clamav-milter.socket
MilterSocketMode 660
ClamdSocket unix:/run/clamd.scan/clamd.sock
LogFacility LOG_MAIL

Add “clamilt” user to “clamscan” group to access clamd’s socket:

% sudo usermod -G clamscan -a clamilt

Start clamav-milter on startup:

% sudo systemctl enable clamav-milter

Start clamav-milter:

% sudo systemctl start clamav-milter

Configure milter-greylist

Change /etc/mail/greylist.conf for the following configurations:

  • use the leading 24bits for IP address match to avoid Greylist adverse effect for sender uses some MTA case.
  • decrease retransmit check time to 10 minutes from 30 minutes (default value) to avoid Greylist adverse effect.
  • increase auto whitelist period to a week from 1 day (default value) to avoid Greylist adverse effect.
  • don’t use Greylist when trusted domain passes SPF. (Trusted domains are configured in milter manager)
  • use Greylist by default.

The configuration relaxes Greylist check to avoid Greylist adverse effect. It increases received spam mails but you should give priority to avoid false positive rather than false negative. You should not consider that you blocks all spam mails by Greylist. You can blocks spam mails that isn’t blocked by Greylist by other anti-spam technique such as SpamAssassin. milter manager helps constructing mail system that combines some anti-spam techniques.


socket "/run/milter-greylist/milter-greylist.sock"
# ...
racl whitelist default


socket "/run/milter-greylist/milter-greylist.sock" 660
# ...
subnetmatch /24
greylist 10m
autowhite 1w
sm_macro "trusted_domain" "{trusted_domain}" "yes"
racl whitelist sm_macro "trusted_domain" spf pass
racl greylist sm_macro "trusted_domain" not spf pass
racl greylist default

Start milter-greylist on startup:

% sudo systemctl enable milter-greylist

Start milter-greylist:

% sudo systemctl start milter-greylist

Configure milter manager

Add “milter-manager” user to “clamilt” group to access clamav-milter’s socket:

% sudo usermod -G clamilt -a milter-manager

Add “milter-manager” user to “mail” group and “grmilter” group to access milter-greylist’s socket:

% sudo usermod -G mail -a milter-manager
% sudo usermod -G grmilter -a milter-manager

Add “milter-manager” user to “postfix”” group to access spamass-milter’s socket:

% sudo usermod -G postfix -a milter-manager

milter manager detects milters that installed in system. You can confirm spamass-milter, clamav-milter and milter-greylist are detected:

% sudo /usr/sbin/milter-manager -u milter-manager -g milter-manager --show-config

The following output shows milters are detected:

define_milter("milter-greylist") do |milter|
  milter.connection_spec = "unix:/run/milter-greylist/milter-greylist.sock"
  milter.enabled = true
define_milter("clamav-milter") do |milter|
  milter.connection_spec = "unix:/var/run/clamav-milter/clamav-milter.socket"
  milter.enabled = true
define_milter("spamass-milter") do |milter|
  milter.connection_spec = "unix:/run/spamass-milter/postfix/sock"
  milter.enabled = true

You should confirm that milter’s name, socket path and “enabled = true”. If the values are unexpected, you need to change /etc/milter-manager/milter-manager.local.conf. See Configuration for details of milter-manager.local.conf.

But if we can, we want to use milter manager without editing miter-manager.local.conf. If you report your environment to the milter manager project, the milter manager project may improve detect method.

milter manager’s configuration is finished.

Start to milter manager on startup:

% sudo systemctl enable milter-manager

Start to milter manager:

% sudo systemctl start milter-manager

milter-test-server is usuful to confirm milter manager was ran:

% sudo -u milter-manager milter-test-server -s unix:/var/run/milter-manager/milter-manager.sock

Here is a sample success output:

status: accept
elapsed-time: 0.128 seconds

If milter manager fails to run, the following message will be shown:

Failed to connect to unix:/var/run/milter-manager/milter-manager.sock

In this case, you can use log to solve the problem. milter manager is verbosily if –verbose option is specified. milter manager outputs logs to standard output if milter manager isn’t daemon process.

You can add the following configuration to /etc/sysconfig/milter-manager to output verbose log to standard output:

OPTION_ARGS="--verbose --no-daemon"

Restart milter manager:

% sudo systemctl restart milter-manager

Some logs are output if there is a problem. Running milter manager can be exitted by Ctrl+c.

OPTION_ARGS configuration in /etc/sysconfig/milter-manager should be commented out after the problem is solved to run milter manager as daemon process. And you should restart milter manager.

Configure Postfix

Enables Postfix:

% sudo systemctl enable postfix
% sudo systemctl start postfix

Configure Postfix for milters. Append following lines to /etc/postfix/

milter_protocol = 6
milter_default_action = accept
milter_mail_macros = {auth_author} {auth_type} {auth_authen}

For details for each lines.

milter_protocol = 6Use milter protocol version 6.
milter_default_action = acceptMTA receives mails when MTA cannot access milter. Although there are problems between MTA and milter, MTA can deliver mails to clients. But until you recover milter, perhaps MTA receives spam mails and virus mails.

If you can recover the system quickly, you can specify ‘tempfail’ instead of ‘accept’. Default value is ‘tempfail’.

milter_mail_macros = {auth_author} {auth_type} {auth_authen}MTA gives information related SMTP Auth to milters. milter-greylist etc. uses it.

Register milter manager to Postfix. It’s important that spamass-milter, clamav-milter and milter-greylist aren’t needed to be registered because they are used via milter manager.

Append following lines to /etc/postfix/

smtpd_milters = unix:/var/run/milter-manager/milter-manager.sock

Reload Postfix’s configuration.

% sudo systemctl reload postfix

milter manager logs to syslog. If milter manager works well, some logs can be shown in /var/log/maillog. You need to send a test mail for confirming.


There are many configurations to work milter and Postfix together. They can be reduced by introducing milter manager.

Without milter manager, you need to specify sockets of spamass-milter, clamav-milter and milter-greylist to /etc/postfix/ With milter manager, you don’t need to specify sockets of them, just specify a socket of milter manager. They are detected automatically. You don’t need to take care some small mistakes like typo.

milter manager also detects which ‘/sbin/chkconfig -add’ is done or not. If you disable a milter, you use the following steps:

% sudo systemctl stop milter-greylist
% sudo systemctl disable milter-greylist

You need to reload milter manager after you disable a milter.

% sudo systemctl reload milter-manager

milter manager detects a milter is disabled and doesn’t use it. You don’t need to change /etc/postfix/

You can reduce maintainance cost by introducing milter manager if you use some milters on CentOS.

milter manager also provides tools to help operation. Installing them is optional but you can reduce operation cost too. If you also install them, you will go to Install to CentOS (optional) .

Postfix Authenticated SMTP Relay configuration

This is my configuration in addition to an existing ispconfig setup:
smtpd_sasl_auth_enable = yes
#smtpd_client_message_rate_limit = 5
#smtp_sasl_auth_enable = yes
#smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
#smtp_sasl_security_options =
broken_sasl_auth_clients = yes
smtpd_sasl_local_domain = $myhostname
smtpd_reject_unlisted_recipient = no
smtpd_reject_unlisted_sender = no

eg. rerouting all emails of destination domain via a relay server (

(Email ==> Email Accounts / Email Routing)
Select ‘Add new Transport’
Fill in the fields:
Server: (Select the server)
Type: (select smtp)
No MX lookup: (leave unchecked)
Sort by: 1
Active: (Checked)

(Email ==> Global Filters / Relay Recipients)
Select: ‘Add new relay reciepient’

Fill in the fields:
Server: (Chose the server)
Relay recipient:
Active: (Checked)

What is a DMARC record and how do I create it on DNS server?

Command to verify the DNS record : dig any


Email Security: What is DMARC record and how to create it on DNS server.


Before creating DMARC records it’s a good idea to test DKIM and SPF. Testing can be found here:


Creating a DMARC record

Create the record
DMARC is designed to give receivers of email better judgment control  based on sending domain reputations.  It provides a platform where the sending side can publish policies to improve effectiveness against spam and phishing, in effect building domain reputations. This helps to provide guidelines on how to address messages that do not align according to those policies published by the sending domains.
DMARC was aimed at:
Reducing false negatives
Provide authentication reporting
Apply sender policies at the receiving end
Reduce phishing
Be scalable
In order to get started with DMARC, the sending domain needs to have an SPF and DKIM record published. Once the SPF and DKIM records are in place, you can configure DMARC by adding policies to your domain’s TXT records (the same way in which you published your SPF and DKIM records).  Your TXT record name should read something similar to “”  Please replace the “” with your own domain.
As DMARC policies are published as TXT records, it defines what an email receiver should do with non-aligned mail it receives.

A DMARC record’s name when creating a TXT record is “_dmarc” which forms a TXT record such as or etc

An external guide/wizard on creating DMARC records:

“v=DMARC1;p=reject;pct=100;rua=mailto:[email protected]”  
 In this scenario, the sender defines the policy as such that the receiver outright rejects all non-aligned messages and sends a report about the rejections to a specific email address. If the sender were to use the “quarantine” setting in the policy, it would look like:
“v=DMARC1;p=quarantine;pct=100;rua=mailto:[email protected]” 

and would request the action to quarantine on the receiving end of the message. In the next example, if a message claims to be from your and fails DMARC, no action is taken. Instead, these messages will then show up in your daily aggregate report sent to
 “v=DMARC1; p=none; rua=mailto:[email protected]” 

Here is a sample where the message fails DMARC, then quarantines it 5% of the time.
 “v=DMARC1; p=quarantine; pct=5; rua=mailto:[email protected]” 

In this sample, the policy is set to reject the message 100% of the time and send the daily report to the specified address of [email protected]
“v=DMARC1; p=reject; rua=mailto:[email protected], mailto:[email protected]”
 DMARC records follow the extensible “tag-value” syntax for DNS-based key records defined in DKIM. The following chart illustrates some of the available tags:
Common tags used in DMARC TXT records:

TagName   RequiredPurposeSample
v             requiredProtocol Versionv=DMARC1
prequiredProtocol for Domainp=quarantine
pctoptional% of message subjected to filteringpct=20
ruaoptionalReporting UTIof aggregate reportrua=mailto:[email protected]
spoptionalPolicy for subdomains of the domainsp=r
aspfoptionalAlignment mode for spfaspf=r 

Only the v (version) and p (policy) tags are required. Three possible policy settings are available:

  • none – Take no action. Only log the affected messages in the daily report.
  • quarantine – Mark affected messages as spam.
  • reject – Cancel the message at the SMTP layer.  

Alignment mode refers to the analysis which sender records are compared to SPF and DKIM signatures. There are two possible values being presented, relaxed “r” or strict “s”. Relaxed allows for partial matches such as subdomains while strict requires an exact match.
Be sure to include an email address with the optional rua tag to have the daily reports sent to that address.
Example report
The daily reports are sent in XML format. They provide feedback informing you of the sending source IP addresses that have been sending out on your domain’s behalf.  This helps in determining which sources are valid or not. As a result, this assists in more effective deployment of your SPF and DKIM records.
Here is an example of a daily aggregate report. The judgement result is shown along with the source IP addresses and the action taken.
Here is an example of how to specify the optional size limit argument and set it to 10 MB.
“v=DMARC1; p=none; rua=mailto:[email protected]!10m”
Deploy slowly 
As the DMARC specification takes into consideration that scaling out the deployment may be challenging for some organizations to do at once, there are a number of built-in methods for “throttling” the DMARC processing so full deployment can be done in increments over time.

  • First thing to do is monitor your traffic and reports. Assess where your vulnerabilities are (where messages are being delivered without being digitally signed or are coming from invalid source IP addresses) and address them through SPF and DKIM records.
  • As you monitor your daily aggregate reports and get to a place where you are comfortable with the results, you can change the action on your policies to start to quarantine. You do this by changing your TXT record using DMARC to use the “quarantine” action. Continue to monitor your daily reports
  • Once you have been monitoring your traffic and daily reports for some time and feel comfortable with the sources seen sending traffic on behalf of your domain and they are all being digitally signed, you can move forward with the next step in changing the policy to use the “reject” tag to fully deploy DMARC in its entirety. Monitoring your reports and your spamfeed is an essential part of maintenance for DMARC accuracy.

Also worth noting, the optional pct tag can be used to sample your DMARC deployment in increments as well. Since 100% is the default, passing “pct=20” in your DMARC TXT record results in one-fifth of all messages affected by the policy actually receiving the disposition instead of all of them. This setting is especially useful once you elect to quarantine and reject mail. Start with a lower percent to begin with and increase it every few days.
So a conservative deployment cycle would resemble:

  1. Monitor all.
  2. Quarantine 1%.
  3. Quarantine 5%.
  4. Quarantine 10%.
  5. Quarantine 25%.
  6. Quarantine 50%.
  7. Quarantine all.
  8. Reject 1%.
  9. Reject 5%.
  10. Reject 10%.
  11. Reject 25%.
  12. Reject 50%.
  13. Reject all.

When you are ready to complete the DMARC deployment, remove the percentages from your policies so that the full action of “quarantine” and “reject” is now functioning at 100%. As always, monitor your daily reports.
Recap DMARC deployment.

  1. Deploy SPF and DKIM records for your domain.
  2. Confirm that all sending MTA’s on behalf of the specified domain are aligning the appropriate identifiers appropriately.
  3. Publish DMARC record using the “monitor” flag and specify rua value to receive daily aggregate reports.
  4. Assess vulnerabilities from the daily reports and adjust SPF and DKIM accordingly. Make changes to your mailstreams as needed.
  5. Change DMARC policy flags to “quarantine” and then eventually to “reject” as you see fit.

For further reference, you can go to: