Configure Postfix as an Inbound and Outbound SMTP Mail Only Relay

Posted on by rgesteland Posted in Linux, Postfix — No Comments ↓

How Postfix Relays Incoming and Outgoing SMTP Mail

For this article, we will show you how to configure a Postfix server as an SMTP mail relay for incoming and outgoing mail. You can use any third party email service provider as a smarthost. Companies like Comodo, Proofpoint, Mailgun are all great examples of such companies.

How Outbound SMTP Mail is Handled using Postfix as a Mail Relay
• Internal Mail servers sends outbound mail to Postfix server
• Postfix server hands off mail to external smarthost for delivery
• Smarthost delivers mail or rejects it
How Inbound SMTP Mail is Handled using Postfix as a Mail Relay
• Inbound SMTP mail is received by Postfix 
• Postfix checks the mail domain the email is addressed to 
• If the mail domain matches an internal mail domain then the mail is handed off to the internal mail server 
• If there is no match then Postfix will reject it and will not process it any further

The solution to set up Postfix as a mail relay only server for inbound and outbound SMTP mail is actually quite simple. When we tried to find documentation that clearly explains how to do this it was no easy task. There are so many configurable options for Postfix that it sometimes can be difficult to find the correct options for your particular scenario.

Linux Platforms Supported and the Flexibility When Using this Configuration

For the purposes of this article we installed Postfix on Ubuntu 20.04. However, the configuration should work on any Linux flavor including Debian, SUSE, CentOS, RHEL, Fedora, etc….

With this configuration you can support multiple internal mail domains. You can also use it to relay the mail to a different internal mail server depending on the mail domain. The below configuration supports any number of internal mail domains. You can also specify an SMTP Authenticated service such as a Google Mail server as your outgoing smarthost.

For simplicity sake and to make this article Linux flavor agnostic, we are not going to go into the details on how you install and setup Postfix itself. There are thousands of articles and videos that will help you do that. So, let’s jump right into how to modify a working Postfix server configuration to support this new environment. Use your favorite editor to edit and save your files.

Create the Transport, Relay Files and Modify the Main.cf file for Postfix

You only need to create or modify 3 files for this scenario to work. Please note that you should first backup your Postfix folder before making any changes. Also, our recommended changes are to be followed at your own risk. We are not responsible for changes adversely affecting your mail environment. If you modify files that already exist then please do so with caution. You might cause your current Postfix configuration to stop working. Finally, you need root or sudo rights to modify/create any of the files below.

We are assuming that Postfix is installed in the /etc/postfix folder.

Configure the /etc/postfix/transport File to Specify which Relay each Domain is Using
your-mail-domain.com   relay:[X.X.X.X]:port
*                      relay:[Y.Y.Y.Y]:port
Configure the /etc/postfix/relay File to Specify which Domains are being Relayed
your-mail-domain.com   OK
*                      OK
Run Postmap on the Transport and Relay Files to Prepare them to be used by Postfix
postmap /etc/postfix/transport
postmap /etc/postfix/relay
Edit the Main.cf File to Add Transport and Relay Settings to the Postfix Configuration
transport_maps = hash:/etc/postfix/transport
relay_domains = $mydestination, hash:/etc/postfix/relay
Remove All References to your Internal Mail Domains from mydestination in the Main.cf file

You must remove any references to your-mail-domain.com in the mydestination entry in the main.cf file. It is possible that your mydestination may just have localhost defined as shown below:

mydestination = localhost

If you don’t remove those references then the inbound relay will not work. Entries in mydestination tell Postfix that the your-mail-domain.com addressed mail is to be processed by Postfix. You just want Postfix to relay it and not reject it. You may also get an error that Postfix is not authorized to relay mail for your-mail-domain.com.

After you’ve made the above changes, makes sure to reload or restart your Postfix service. If it reloads/restarts successfully then test it out by to ensure it is working as expected.

Some Other Useful Sample Configurations for Postfix

Here are some other sample configurations that you may find useful. The below are slight modifications of what we described above. We are only going to show you the differences between the transport and relay files since the changes made to the main.cf will be the same.

Multiple mail domains relaying inbound mail to the same internal mail server
/etc/postfix/transport
your-1st-mail-domain.com    relay:[X.X.X.X]:port
your-2nd-mail-domain.com    relay:[X.X.X.X]:port
your-3rd-mail-domain.com    relay:[X.X.X.X]:port
*                           relay:[Y.Y.Y.Y]:port

/etc/postfix/relay
your-1st-mail-domain.com     OK
your-2nd-mail-domain.com     OK
your-1st-mail-domain.com     OK
*                            OK
Relay Inbound Mail for Multiple mail domains to Different Internal Mail Servers
/etc/postfix/transport
your-1st-mail-domain.com   relay:[W.W.W.W]:port
your-2nd-mail-domain.com   relay:[X.X.X.X]:port
your-3rd-mail-domain.com   relay:[Y.Y.Y.Y]:port
*                          relay:[Z.Z.Z.Z]:port

/etc/postfix/relay
your-1st-mail-domain.com    OK
your-2nd-mail-domain.com    OK
your-1st-mail-domain.com    OK
*                           OK
Support outbound mail relay through a secure SMTP Authenticated service such as Gmail

If you want to relay through a secure email provider such as Gmail using SMTP Authentication then keep on reading. Please note that we not going to explain how to configure your Gmail account and Postfix to use SMTP Authentication. If you want to authenticate securely connect Gmail to Postfix there are many resources available elsewhere to give you that information. Here’s how you can configure Postfix to use Gmail as an outbound relay:

/etc/postfix/transport
your-mail-domain.com    relay:[X.X.X.X]:port
*                       relay:[smtp.gmail.com]:587

/etc/postfix/relay
your-mail-domain.com     OK
*                        OK

Hopefully you find the above information useful and you are ready to configure Postfix to function as a mail relay only server for inbound and outbound SMTP mail. If you need assistance by experienced professionals to install, configure and deploy secure mail for your environment please do not hesitate to contact us.

Adding Security (HTTP Response) Headers to IBM (Lotus) Domino Server to get an “A” Rating

Posted on by rgesteland Posted in IBM XWork Server, Lotus Domino server, Lotus Domino Support, Lotus Domino Website — No Comments ↓

IBM is doing its best to keep its Domino HTTP Server updated to accommodate all of the security patches and enhancements that are more readily available in competing web servers such as Apache and NGinx. One of these security enhancements is adding Security Headers or HTTP Response Headers to Domino’s HTTP server.

The main headers needed currently are:
Strict-Transport-Security
Referrer-Policy
X-Frame-Options
X-Content-Type-Options
X-XSS-Protection
Content-Security-Policy

Starting with Domino 9.0.1 Feature Pack 6 (or FP6) you can now add the majority of the above headers directly to Domino using both Notes.ini settings and an Internet Site Document. The IBM stated limitation is that a maximum of 4 Headers can be accommodated by Domino since you can add only one header using the Notes.ini and 3 to the Internet Site document. However, we’ve found that the limit is actually 5 since the “Strict Transport Security” header can be added as a separate Notes.ini setting.

For the Internet Site document you’ll have to pick and choose which headers you want to add since you do have that 3 header limit. Based on our testing and experience, we’ve found that the one header that causes the most problems to your site after applying it is the “Content Security Policy”. For sites with complex applications running X-Pages and other scripting technologies, this latter header can cause certain functions to break, so we decided to leave that one out of the 5 that we added. Your experience may be different and you may decide that you want that one added instead of another header.

You can add the following entries to the Notes.ini to support Strict-Transport-Security and X-Frame-Options (after saving your Notes.ini you will need to restart your Domino server for these to take effect):
HTTPDisableServerHeader=1
HTTP_HSTS_MAX_AGE=17280000
HTTP_HSTS_INCLUDE_SUBDOMAINS=1
HTTPAdditionalRespHeader=X-Frame-Options: SAMEORIGIN

To add the following 3 headers you can do so using the Internet Site Document and creating an Website HTTP Response Header Rule:
Referrer-Policy
X-Content-Type-Options
X-XSS-Protection

If you don’t already use an Internet Site document created for your web server then you will need to create one and change the settings on the server document in the Basics tab to point to the newly created Internet Site document (instructions on how to create an Internet Site document are beyond the scope of this post).  If you’ve created a new Internet Site document or already have an existing one then the next step is to create an HTTP Response Header Rule (HTTP responses headers is a “type of rule” for a Web Site Rule document) which is under that same document. When creating an HTTP Response Header Rule you set the following values:
Description: Whatever description you want here
Type of Rule: HTTP response headers
Incoming URL Pattern: /*
HTTP response codes: 200, 206
Expires header:
Always add header (override applcation’s header) 
Specify as number of days (selected)
Custom Headers (see table below and attached image):
[su_table]

Name Value Override
Referrer-Policy same-origin Checked
X-Content-Type-Options nosniff Checked
X-XSS-Protection 1; mode=block Checked

[/su_table]

Once you have filled in the Web Site Rule correctly, save and close it. 

After it is saved you can restart the Domino HTTP task to activate the new rules (you don’t need to restart the whole Domino server).  Once the HTTP task is restarted you can go to the following website to scan and check the status of your domain and all 5 headers except Content-Security-Policy should now be recognized and you should have an “A” rating assigned (please see attached image for similar results):
https://securityheaders.io


Here are all five of the settings and their corresponding values:
Strict-Transport-Security: max-age=31536000; includeSubDomains
Referrer-Policy: same-origin
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options:nosniff
X-XSS-Protection: 1; mode=block

Another way to add security headers is to add a reverse proxy in front of your Domino server.  The reverse proxy can reside on the same server as the Domino server or separately in the DMZ to provide additional security.  Setting up a reverse proxy to add the http response readers is for a future topic.

DIIOP over SSL and SHA-2 on IBM Domino (XWork) Server 9 don’t mesh

Posted on by rgesteland Posted in DIIOP, IBM XWork Server, Lotus Collaboration Express, Lotus Domino Collaboration Express, Lotus Domino Consulting, Lotus Domino Development, Lotus Domino Enterprise Server, Lotus Domino server, Lotus Domino Support — No Comments ↓

IBM has been working hard recently to shore up the SSL vulnerabilities with Domino and XWork server. They have been applying fixes to both Domino 8.5 and 9.0 requiring multiple interim fixes over the past few months. Most recently IBM has made support for SHA-2 SSL certificates available as well so users with Domino websites can finally upgrade their SHA-1 SSL certificates to SHA-2 for better security. However, the new security updates have also had some unsuspecting side effects with other IBM Domino tasks running on the server. In particular we came across a problem accessing the Domino server via DIIOP over SSL.

Normally it is fairly easy to use a Java application to access Domino via DIIOP with or without SSL. With SSL it is necessary to use the TrustedCert.class file generated by the DIIOP task on Domino located in the /domino/java folder located in the Domino data folder. However, most recently accessing DIIOP over SSL was not working on our Domino 9.0.1 Fixpack 3 Interim Fix 2 server using a SHA-2 SSL certificate. Even with the proper TrustedCert.class file access was failing.

Looking at the Domino server console we noticed the following error when the DIIOP task was started:
DIIOP Server: Agent error: keyrng: Could not read certificate

We also noticed the following errors at different intervals when trying to access DIIOP over SSL:
TLS/SSL connection X.X.X.X(63149)-X.X.X.X(64023) failed with rejected protocol version

Also from the Java application trying to connect to DIIOP over SSL we saw the following error:
NotesException: Session closed due to communications failure

To fix: TLS/SSL connection X.X.X.X(63149)-X.X.X.X(64023) failed with rejected protocol version enable SSLv3 on the server.
To do so set “DISABLE_SSLv3=0” in the notes.ini

The same Java code was working fine against a Domino 9.0.1 FP3 IF3 server with a SHA-1 certificate, so, after enabling SSLv3 we switched out the SHA-2 certificate with a SHA-1 SelfCert created by Domino and all was good in the DIIOP world again.

Note that making DIIOP over SSL work opens up your HTTP server to SSL vulnerabilities, so it would be best to either disable HTTP altogether or put the server behind a reverse proxy such as Apache or IHS to protect the HTTP task while allowing access to DIIOP.

We checked the above with IBM and, as of this writing, IBM acknowledges that DIIOP over SSL with a SHA-2 certificate with SSLv3 disabled is not currently supported. They are working on the issue, but this may not be resolved in the near future.

Other Errors you might have seen on the Domino Server Console when investigating:
TLS/SSL connection X.X.X.X(443)-X.X.X.X(11951) failed with server certificate chain signature alogrithms NOT supported by client
TLS/SSL connection X.X.X.X(443)-X.X.X.X(11951) failed with server certificate chain requiring support for SHA384
HTTP Server: SSL handshake failure, IP address [X.X.X.X], Keyring [cert.kyr], [SSL Error: Invalid SSL message], code [4166]
HTTP Server: SSL handshake failure, IP address [X.X.X.X], Keyring [cert.kyr], [SSL Error: Invalid peer], code [4171]

Tagged with:
Top
MENU