What is eMPF?
eMPF follows a set of administrator-defined rules describing who can message whom. With this, administrators can segregate various parts of their organizations email activities, as well as provide a variety of security-enhancing services. Because of this, eMPF can help to support HIPAA and Sarbanes-Oxley compliance.
- The homepage is located at http://www.inter7.com/?page=empf
- You can subscribe to the eMPF mailing list by sending an email to email@example.com
How it does it
During an SMTP session, when a sender identifies themselves, either via SMTP_AUTH, or via the message envelope, as well as a recipient, eMPF loads applicable message policies to determine if the sender is allowed to message the sender, and if the recipient is allowed to receive mail from the sender.
What it can't do
Because mail from outside your mail server cannot be authenticated, the policy framework cannot be entirely sure about the identities of senders messaging local users. However, if SMTP authentication is required by local users, eMPF can prevent remote users from masquerading as local users to bypass policies.
Policies define how eMPF restricts messaging. Policies can be created to keep mail internal, or to prevent various other types of messaging from occuring. These types of configurations are very useful for financial companies especially.
Format of a policy
A large, complicated policy may be rather intimidating at first, however, if the rules are documented well, and a basic knowledge of the format of a policy is known, they are rather simple to set up. By default, all policies should be in /var/qmail/control/policy. You can modify this by editting conf-policy.
comment: # text ; text policy: <domain>:<delivery policy>,[<user policy>,][<etc>,] user policy: <username>:<delivery policy>[<delivery policy>] delivery policy: <delivery type>[(<address>[,<address>])]
Delivery types fall into one of four categories:
- L - Local (Sender only) When sending a message to a user on the same domain
- R - Remote (Sender only) When sending a message to a user on another domain
- I - Internal (Recipient only) When receiving a message from a user on the same domain
- E - External (Recipient only) When receiving a message from a user on another domain
Delivery types specify what types of messaging can take place. An uppercase delivery type allows a type of delivery, and a lowercase delivery type, disallows a type of delivery. Delivery types may take a list of addresses. When a list of addresses is provided after a delivery type, those addresses are the only addresses covered by that delivery type.
In this example, example.com allows all messaging. In this case, simply not defining a policy would be more efficient.
Now, example.com wishes all mail to stay internal. As stated above, there are particular cases in which eMPF cannot authenticate a sender. This only occurs when a remote mail server is transmitting mail to a local user on your system. In this case, a remote user could pretend to be a local user, and succesfully deliver mail to another local user. However, the recipient would be unable to message back.
As in the above example, example.com wants all mail to stay internal, however, a few of their users are allowed to communicate with the outside world. Sales can communicate with everybody, and Tasks can send messages only to their sister-site, example.org.
Something to keep in mind in this scenario, is that if example.org is hosted on the same system, and has similar policies to example.com, a policy must be established for example.org which allows messages from example.com.
Note that there are comas after all local user policies. This is required.
A policy story
bank.com is a small-town bank. They have around 20 employees. Nancy (firstname.lastname@example.org) has been working at bank.com for 3 years. In the past, she has been repremanded for spending lots of time emailing friends and family. Finally, her boss decided that she should only be able to email bobs-shirts.com since they are her primary business contact. Other than this, bank.com isn't too worried about messaging security, as they haven't had any prior incidents, and their employee base is small.
bobs-shirts.com prints and sells their own t-shirt designs on the internet. They use bank.com as their primary banking and payment processing center. Everything is great for bobs-shirts.com, except that, Alice (email@example.com) has been sending abusive email to her ex-boyfriend Joe (firstname.lastname@example.org). Joe's ISP quickly contacted bobs-shirts.com, and Bob decided that Alice should not be able to email her ex-boyfriend anymore.
isp.com is a large, nationwide dialup and broadband provider. Joe (email@example.com) is Alice's ex-boyfriend, and he expects not to receive email from her in the future. isp.com, at Joe's request, has decided to reject all mail from firstname.lastname@example.org going to email@example.com
large-bank.com is a nationwide chain of banks. They also provide all sorts of financial advise for their customers. Because of the nature of the information that is passed around between employees, email security is very tight. Only managers may send mail to other domains. All other mail must remain local, between employees.