1. Home
  2. Support
  3. PMDF
  4. FAQ
  5. Security

PMDF FAQ: Security

 

I want to implement a firewall at my site. Can PMDF work in this environment?

A firewall system generally controls what TCP/IP communications are allowed between internal networks and the external world. Firewalls prevent packets considered to be unsafe from passing through. Most firewalls have a messaging component but few implement many of the messaging components of PMDF. Most utilize only a few features, thereby inhibiting the ability to take advantage of PMDF's full functionality.

Additionally, firewall products generally implement a small subset of the SMTP commands available and do not support ESMTP (Enhanced SMTP) features. Generally, the firewall vendor provides a version of sendmail for the SMTP server. Historically sendmail has had many security problems and as such modifications have substantially reduced the functionality in an attempt to make sendmail more secure.

PMDF, a full function SMTP server that implements ESMTP, can be used either in conjunction with a firewall or on the firewall itself to dramatically improve the functionality and performance of a messaging firewall. PMDF provides configuration tools to assist with either operating with a firewall or acting as a messaging firewall itself.

 

PMDF on a firewall

PMDF can replace the modified version of sendmail providing a secure messaging server and a great deal more features. PMDF has no relationship, history or code base with sendmail. PMDF has been engineered with security in mind, and our customers have a great deal of confidence in PMDF's ability to operate on a firewall.

 

PMDF in conjunction with a firewall

There are several ways to setup the operation of PMDF in conjunction with a firewall. Some of these recommendations may require features more common to a router using packet filtering techniques.

  • Let the firewall operate as an SMTP relay, but have PMDF be the front end on the internal side of the network. This requires all internal mail systems to route mail destined for the external network through PMDF. Then, configure PMDF to route all mail destined for the outside network to the firewall, hence the firewall will handle delivery to the outside network. Also, the firewall will need to be configured to route all mail destined internally through PMDF. The disadvantage of this model is that the firewall is active in the mail delivery process. This means that the nice scaleable performance of PMDF will be hindered by the performance of the firewall. Also, many other features of PMDF will be limited to the internal network, like NOTARY, preventing service denial attacks and implementing some spam blocking techniques.
  • Allow connections from all external systems through the firewall to the PMDF system directly on port 25 only. Implementing this will require packet filtering capability to limit connections only to the PMDF system for port 25 (the SMTP port). All messaging to and from the external network would be routed through the PMDF system. This delivers all of the features of PMDF and consolidates two points of message handling to one, which reduces the determination of overhead problems.
  • Put a PMDF system outside the firewall and allow it access to your internal systems only on port 25. Again, all messaging to and from the external network would be routed through the PMDF system. This provides the same functionality as above, with the notable difference being that the system is not protected from attack by the firewall. Keep in mind that in this case the PMDF system, vulnerable to attack, will necessarily have quite a bit of configuration information about the internal network.
  • Put a PMDF system on both sides of the firewall. The external system will receive mail from the external system and relay messages to the internal PMDF system. This is most preferred for control and security as the access through the firewall is between two well defined systems. In this case, the system outside the firewall will have almost no configuration information about the internal network.

Is there a way to list the individuals who have passwords entered in the PMDF password database (not the passwords themselves) so that system administrators can notify these users of planned changes?

You can list these individual users by issuing the following command: 

# pmdf password -show -user='*'

Note that the command works on UNIX either with or without the quotation marks.

Can I use the chained certificates Verisign now issues with PMDF TLS implementation?

Yes, the new Verisign certificates require a patch to the PMDF library. Once that is applied you should all be concatenate the chained certificates into the same file. The local server certificate should be first, followed by one or more intermediary certificates, and finally the root certificate. Make sure all of the separators (e.g., -----BEGIN CERTIFICATE----) remain intact.

For PMDF, the concatenated chain should be in the server_pub.pem file.

Do we need to create certificates both in PMDF and in PreciseMail, or only in 1 of these products?

You can use the same files for both products. For PreciseMail, just define the configuration variables to point to the .PEM files, wherever you put them (in PMDF_TABLE:, for example). 

ptsmtp_tls_public_cert pmdf_table:server-pub.pem
ptsmtp_tls_private_cert pmdf_table:server-priv.pem

And, typically how should the DISPATCHER.CNF file in PMDF and the PMAS_CONFIG.DAT file in PMAS be configured so they can work together?

A working example of a pair of these files showing the [SERVICE=####] sections in the DISPATCHER.CNF file and the values of the TLS-related parameters in the PMAS_CONFIG.DAT file helps in understanding how to configure files.

For PreciseMail, the PMAS_CONFIG.DAT file has comments for all of the TLS-related variables (and using the admin GUI is even easier).

If you're not using PTSMTP, then there's nothing you have to do for PreciseMail. If you are, then you need to define the following variables: 

ptsmtp_listen_host_tls * 
ptsmtp_listen_port_tls 465 
ptsmtp_mailserver_host_tls 127.0.0.1 
ptsmtp_mailserver_port_tls 465 
ptsmtp_enable_starttls yes 
ptsmtp_tls_public_cert pmas_data:server-pub.pem
ptsmtp_tls_private_cert pmas_data:server-priv.pem

On the PMDF side, the only thing that needs to be added to the PMDF.CNF file is the keyword maytls to the appropriate TCP_* channels.