Mail service deployment and configuration guide

Preparation

Download the image here
After reading the XenU Deployment Guide, configure the virtual machine with the following parameters:
- Volume size: 3GB
- RAM: 512 MB
- Name: mail

  vmcreate --size 3G --file /opt/xen/mail-1.1_2.tgz --mem 512 --ip 192.168.69.24 mail

Create a LVM volume named mail_home in which the mail will reside. The size should be sufficient to contain the data. For example, 30GB in size:

  lvcreate -L30G -n mail_home sys
  mkfs -t ext3 /dev/sys/mail_home

Add the volume to the virtual machine configuration (/etc/xen/auto/mail) as disk hda2

  [ 'phy:/dev/sys/mail,hda1,w','phy:/dev/sys/mail_home,hda2,w','phy:/dev/sys/swap_mail,hdb1,w' ]

Boot the virtual machine

  xm create -c /etc/xen/auto/mail

Machine configuration

There are two configuration options available:

Centralised configuration: if the machine is going to be integrated in a ModularIT management structure
Local configuration: if the machine is not going to be integrated in a ModularIT management structure

Centralized configuration

On the Puppet server

The global parameters of the Mail service are defined in the client group of the machine:

  ## Mail service variables
  # IP of the mail server
  $mail_ip = "192.168.69.24" 
  # Mail domainname
  $maildomain = "modularit.lan"

Create the entry of the ModularIT machine being installed:

  node "devel.mail" inherits "devel" {
        # First installation?
        $bootstrap = yes

        $modularit_name = "devel.mail" 
        $comment = "Development Mail" 
        include modularit 
  }

Client configuration (The machine being installed)

puppetd is restarted in debug mode to ensure that it updates correctly:

  /etc/init.d/puppet stop
  puppetd --debug --no-daemonize --runinterval 60 --fqdn NOMBRE_MODULARIT --server PUPPET_MODULARIT

The parameters NOMBRE_MODULARIT and PUPPET_MODULARIT will be provided by the service manager (register with the mailing list if you have questions regarding this)
The puppet is started as a service after it has completed several cycles without generating errors:

  /etc/init.d/puppet restart

PIFIA should be executed to ensure that notifications to Nagios are functioning correctly

  /var/lib/pica/bin/scheduler Emergency
  /var/lib/pica/bin/scheduler Warning

Ensure that Nagios is not generating alerts that read OK. At this point critical AIDE alerts are expected

Local configuration

The following installation mode is needed when the machine is not integrated in a centralized ModularIT management structure

Go to the /opt directory
Download the ModularIT configuration tree:

  links --source "http://git.modularit.org/?p=modularit.git;a=snapshot;h=HEAD;sf=tgz" | tar xvzf -

This will create the /opt/modularit directory
A directory for the puppet modules is created:

  mkdir /etc/puppet/modules
  ln -s /opt/modularit/Puppet/modularit /etc/puppet/modules/

Edit the file /opt/modularit/Puppet/offline/variables.pp and modify it so that the correct configuration is used. This file will be common to all ModularIT installations
Edit the file /opt/modularit/Puppet/offline/offline.pp to reflect the name and type of the ModularIT machine, in this case: mail. The file will be different for each machine (The name and type of machine are always different)
Once the configuration has been completed, execute puppet in off-line mode

  puppet --debug /opt/modularit/Puppet/offline/offline.pp

The process should finish without errors

Service preparation

Execute the Mail service initialization script. Note: This step may remove data:

  modularit-mail-init.rb

The script does the following
- Configures the system to use LDAP users
- Generates the postfix maps
- Checks the user accounts and LDAP group using getent passwd and getent group
- Creates the machine certificates if they do not exist.

  cd /etc/pki/tls/certs
  make mail.pem
  ln -s mail.pem smtp.pem

Edit the /etc/postfix/main.cf:
- In smtpd_recipient_restrictions configure reject_unauth_destinations depending on whether the machine is a primary or secondary MX (under discussion).
- The option reject_unverified_sender can cause performance issues with machines that handle significant amounts of traffic. Check the relevant service to see if this is the case.
- If there are no networks connected to the mail interfaces, they should be added in mynetworks.
Edit /etc/postfix/helo_checks and enter the name and IP address of the machine being installed. Note: The IP address should be the public address through which the machine is accessed from the internet.
Add the list of local domains to the following file /etc/postfix/localdomains.
Reboot postfix:

  service postfix restart

Configure the alias
- Configure at least one alias with a valid address in root which resides in /etc/aliases
- Add all the necessary aliases, especially if a migration is being performed
- The standard aliases should be added: info, admin, etc
- Load the aliases

  newaliases; postfix reload

Port 25 is connected to ensure that postfix responds
A 220 message should appear containing the full public name of the machine. Disconnect using quit

Initializing AIDE

Once everything is functioning correctly, initialize the AIDE databases as described in the AIDE

Test suite

The following tests should be done from a machine on the internet, not from the server itself or from machines in the same local network

Check that mail is being received for the local domains:

  [root@mail certs]# telnet mail.example.com 25
  Trying XX.XX.XX.XX...
  Connected to mail.example.com (XX.XX.XX.XX).
  Escape character is '^]'.
  220 mail.example.com ESMTP Postfix
  helo gate.dominio.com
  250 mail.example.com
  mail from: test@dominio.com
  250 2.1.0 Ok
  rcpt to: test@example.com
  250 2.1.5 Ok
  data
  354 End data with <CR><LF>.<CR><LF>
  test
  .
  250 2.0.0 Ok: queued as 5A5A418145
  quit
  221 2.0.0 Bye
  Connection closed by foreign host.

Note: Use a technicians address in the from field and a valid local domain in the to field

The following should be checked if errors occur:
- If mail from: is used without helo the response will be: 503 5.5.1 Error: send HELO/EHLO first
- If the name of the machine (mail.example.com in this example) is entered in the helo after the rcpt to: the response will be: Helo command rejected: Don't use my hostname
- If a number is entered that is incomplete or non-existent in the helo then the mail is rejected
- If an IP is entered in the helo after the rcpt to: the response will be: Helo command rejected: Your client is not RFC 2821 compliant
- If an incomplete address is entered (only the user) in the from:/to: the response will be: Sender/Recipient address rejected: need fully-qualified address
- If a non-existent domain is entered in the from:/to: the response will be: Sender/Recipient address rejected: Domain not found
- If a non-local domain is entered in the to: the response will be: Relay access denied
- If a non-existent address is entered in a domain that exists (eg. noexist@dominio.com) the response will be: Sender address rejected: undeliverable address: host mail.dominio.com[XX.XX.XX.XX] said: 550 <noexist@dominio.com>: Recipient address rejected: User unknown in local recipient table (in reply to RCPT TO command)

This restriction will cause the response to be slower because the SPAM verifies that the address of the sender is valid

Check the amavisd filter. These tests should be performed by opening a window and using the server command tail -f /var/log/messages to view the amavis messages
Send a message before the transaction and include the antivirus test string in the data:

  X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

Check that the clamd responds with INFECTED and discards the mail
Send a message before the transaction and include the SPAM test string in the data:

  XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X

Check that it is marked as SPAM.
As a final test configure a mail client and send a test message to echo@rediris.es a reply should be received within a few minutes.

Also available in: HTML TXT

ModularIT

Wiki