Postfix Configuration File Plesk Web

Posted on by admin

Configuring postfix to block all emails except the specified email accounts. If you need allow a emailing only from a particular from the postfix email server you can follow the below steps. Use Transport Mapping. Here we can tell the postfix mail server to sent or disregard the emails. For this we need to edit the postfix configuration file.

  1. Postfix Configuration File Plesk Webmail
  2. Postfix Configuration File Plesk Website

Point Postfix to a Smart Host for a Specific Domain (Linux)

Problem
When sending mail to a specific domain, tell Postfix to send to a smart host (i.e. gateway or spam filter) rather than directly to the mail server.

tl;dr
Add a line to /etc/postfix/transport:

recipientdomain.com smtp:filter1.recipientdomain.com
Create a postmap file:

Point Postfix to use the created postmap file by adding a line to /etc/postfix/main.cf:

Postfix configuration file plesk webmail

transport_maps = hash:/etc/postfix/transport
Restart postfix:

Solution

Some large organizations often employ mail gateways, such as Proofpoint to filter incoming email for spam. If you are using a large web email provider, such as Hotmail, Yahoo, or Gmail, their mail servers will often be white-listed. But what if you are trying to send an email to a bank from your office's tiny Postfix mail server? In this case, you will need to point your mail server to the bank's mail gateway.

To do this, you need to create (or edit) your mail lookup table to include the bank's domain, and point any email to their mail gateway, rather than directly to the mail server. This is accomplished via a postmap.

First, you need to create an entry in /etc/postfix/transport file. You can use any file of your choosing as long as you point to it, but by convention, the transport file is used. So, open it:

Add a line in the format domain.com smtp:smarthost.fqdn.com:port. Unless you are specifying a port (i.e. 587 for SSL connection), you can omit the :port section.

recipientdomain.com smtp:filter1.recipientdomain.com

Save and exit the transport file (Ctrl-O then Ctrl-X if you are using nano). Then, generate a postmap file from your transport configuration:

And finally, point Postfix to use the previously generated map any time it restarts:

transport_maps = hash:/etc/postfix/transport

Save and exit the main configuration file, and finally, restart Postfix:

Author

Vlad Dzhabarov.

Views: 4387

Understanding Postfix

Postfix is like a router in a network, just for email traffic. It receives emails from a sender and tries to send them on to their recipient, where the recipient can be the local postfix server or some other server.

As such, postfix has different interfaces to handle different protocols. The architecture is modular and contains different daemons each specifically handling only a few tasks. The most important daemons are the following:

  • master is the main daemon that starts all the other daemons.
  • smtpd is the SMTP server daemon handling incoming connections to receive emails from another mail server or client.
  • smtp is the SMTP client handling outgoing connections to send email out to another mail server.
  • local is the local delivery agent responsible for delivering email to the local server.
  • qmgr processes and controls all messages in the mail queue.

Maps are used in postfix to control email routing. Such maps are used to accept or reject email, inform postfix about local recipients and more.

The main configuration files are main.cf which is the global configuration for all daemons and the master.cf which defines the runtime environment for the daemons. The master.cf configuration thereby overrides the configuration options from the main.cf.

SMTP Security

What do you need to secure? SMTP is by default a trusting protocol. Without any additional security configuration it will accept any emails from anybody and send it on to the recipient. This behaviour is called “open-relay” which means that the email server accepts an email from a spammer, for example, and just delivers it to the recipient. As this would cause your email server to nearly instantaneously appear on most of the block lists, this is something you want to avoid.

SMTP authentication is the best fitting solution for preventing your server acting as an open relay. But to secure the user-name and password combination while transferring it to the server, even the RFC4616 proposes to use an “adequate external data security protection, such as TLS”.

Installing Postfix and Cyrus

We need to install the postfix and cyrus (for SMTP authentication) packages on the server. Usually at this point I block incoming traffic to the postfix daemon (port 25) via iptable rules. This is to avoid someone sending through postfix as long as it is not configured. In my experience, open-relays are found very quickly once the server is online, so my advice would be to only open the port to postfix after you have configured postfix and are ready to test your configuration.

Now sendmail is not needed anymore as it is replaced by postfix, we can remove it from the system.

Once postfix and the required packages for SMTP authentication are installed, configuration needs to be done. The postfix configuration is mainly in the /etc/postfix/master.cf and /etc/postfix/main.cf file.

Open the /etc/postfix/main.cf with you favourite editor and edit the following lines. Those configuration options should already be in the configuration file. Some might be commented out and others have different default values.

The configuration options above mainly configure the basics for postfix like the domain and hostname this mail system is running on, the trusted networks and the network interfaces postfix is listening on.

Additionally, the following configuration items should be added to the /etc/postfix/main.cf configuration file. These settings are not absolutely necessary but will reduce the amount of spam you will receive. For a detailed description, see the Spamassassin Long delay (high latency) Trick.

Configure SMTP-Authentication for smptd daemon

The following configuration items are not in the postfix configuration and need to be added to the /etc/postfix/main.cf configuration file. They configure the SMTP authentication settings for the smtpd daemon.

With this configured, every Linux account is allowed to login to postfix which uses Cyrus sasl. The sasl module then uses PAM to authenticate with the operating system.

If you don’t want to allow all shell accounts to send emails, read on. The idea is to allow only users that are member of a specific group to send mail.

The PAM module has a configuration file related to the Cyrus sasl authentication. The following line needs to be added at the top of the /etc/pam.d/smtp file.

By adding this one line of configuration to the /etc/pam.d/smtp file, PAM will load the file /etc/pam.d/mail_auth_group.allow. This file will contain a list of group names that should be allowed to login. Create the file as it is named in the PAM configuration with your favourite editor and add all the group names you want to allow to authenticate. You can choose to use already existing groups like “user” or to create a new group specifically for this purpose.

Here is an example how the file with the group names could look:

Postfix configuration file plesk webmail

If you decided to use a group that does not yet exist, this group needs to be created:

With the group created, this group needs to be added to the user you want to allow to authenticate with postfix. The following command adds the group as a supplementary group to the account:

Configure TLS for smptd daemon

The following configuration items in /etc/postfix/main.cf are used to configure TLS support for the smtpd daemon. It also contains an SSL certificate. Such an SSL certificate can be requested by any CA. Some of them provide certificates for a very small price or even free. If you need a certificate consider CACert and StartSSL as they provide free certificates that can be used for this purpose.

You can alternatively provide the certificate and key combined in one file if you prefer it like that. To do that, use this configuration:

Configure alias addresses

As the setup is up to now, postfix would receive emails to recipients that have the linux user name as the username part in the email and the domain you configured. It would be possible to receive emails for root@example.com where root is the username on the system and example.com the domain configured in “mydomain”. Most likely you have the need to provide different email addresses. These are called aliases and can be configured using a mapping file.

In the /etc/postfix/main.cf add the following part to define the mapping file:

This file can now be filled with the aliases. These aliases can then be forwarded to another external email or to a local user. The format of the mapping file is the following:

You can assign any number of alias addresses to a user. All the email listed as an alias will be delivered to the user1 mailbox. Keep in mind that local delivery will only work if the destination user is available in the system.

Every time you change this mapping file, the postmap command needs to be executed. Without executing this command the db file will remain unchanged and your changed configuration will not have any effect.

After the mapping file is created execute the following command to create the lookup table database out of this file:

Additionally there is another mapping file available outside of the postfix configuration directories. The aliases(5) provides a system-wide mechanism to redirect mail for local recipients.

Most likely you want to receive all the emails from different daemons and system components not to the user ‘root’ but in another user that has access to emails. To do this, open /etc/aliases with your favourite editor and navigate to the end of the file. You will find something like this:

Uncomment the line by removing the leading ‘#’ from it and replace the “marc” with the user who should receive all the messages addressed to root.

Apply the configuration

After the configuration changes we need to restart postfix to load the changed configuration. Additionally the Cyrus authentication daemon needs to be started.

Check the startup configuration as you might want those services to start at boot time. This can be done via the following command:

Test the SMTP authentication

To test the SMTP authentication connect with telnet to postfix as in the example below. Follow the example and type in the lines marked with “C: “. You should see a similar output (marked as “S: “) from the server as in the example.

If you don’t want to type all these commands, you can also use Mailserver-Test script which is a simple script that does all this for you:

What’s important here is that the “RCPT TO” line is answered from the server with a “Relay access denied”. This means that postfix did not accept the email as we have not authenticated.

Postfix Configuration File Plesk Webmail

To actually test the authentication, we need to prepare the username and password hash to be able to authenticate in the second run. This is done by the following command that expects the “MIME::Base64” module to be installed:

0username0password')' AHVzZXJuYW1lAHBhc3N3b3Jk

This generated base64 encoded string is used in the authentication mechanism.

Base64 is a reversible string encoding which does not provide any security. This string contains the user-name and password in plain text. This is the reason why you want to enable TLS on the mail client to make sure the password is securely transferred from your client to the server.

With this encoded authentication string you can authenticate in the telnet session.

Test the TLS connection

Testing the TLS connection is not as simple as connecting via telnet. The connection needs to be encrypted and the TLS handshake has to be done. To do this, use the following openssl command.

As you can see in the last part, the connection is established and the SMTP server responds to the “EHLO” greeting in the normal way.

Postfix Configuration File Plesk Website

Read more of my posts on my blog at http://blog.tinned-software.net/.

Related posts: