Postfix: local mail only for some users

If you want to allow some users to send "local" mail only, the following postfix configuration will do the trick. With local I mean within the organisation, for which your postfix is configured to receive mail.

In your smtpd_recipient_restrictions, rather at the top of the restriction list, add

        check_sender_access hash:/etc/postfix/access-sender-local_mail_only,

where the file /etc/postfix/access-sender-local_mail_only contains a list of senders which are restricted:

usera@example.com       localmailonly
userb@example.com       localmailonly
userc@example.com       localmailonly

So here we have defined that these users are subject to the restriction class "localmailonly", which we will have to define:

smtpd_restriction_classes = localmailonly
localmailonly = permit_auth_destination,reject

Here we have defined a new restriction class, and have assinged rules to this class. Namely, we only permit authorized destinations (thats the destinations we accept mail for), and otherwise reject the message. In order for this configuration to take effect, we need to convert /etc/postfix/access-sender-local_mail_only to a .db file, and reload postfix (to read the changes to main.cf):

postmap /etc/postfix/access-sender-local_mail_only
service postfix reload

Check ssl certificates with a shell oneliner

If you want to check the details of a ssl certificate, you can do it with something like this:

for a local certificate file. If you want to check the certificate that specific services servers, use servicename should be a service which translates into a portnumer via /etc/services.

Faster ssh on virtual machines

A problem with virtual machines is that they have trouble finding entropy. Because they have no real hardware to get entropy from, the tend to have rather low entropy availabe. You can check with

 cat /proc/sys/kernel/random/entropy_avail

A typical virtual machine will be in the low hundreds. If this is the case, you will probably frequently experience unusual long waiting times when loggin in with ssh, or even hangs .... This is because the system uses entropy to for the encryption. So because there is not much, it might wait for it to be generated.

Fortunatly, there is a tweek, which will speed up things: rng-tools (props to my fellow Stephan Seitz who explained this to me). It really is meant for gathering entropy from special hardware devices, but can be tweeked to use /dev/urandom. Please note that this will increase the available entropy, but not probably decrease the strength of the encryption. If you are more knowledgeble about this, I would be happy to hear from you.

Here is my setup on a ubuntu 12.04 server: Edit /etc/default/rng-tools, so that it contains

RNGDOPTIONS="--rng-device=/dev/urandom --fill-watermark=90% --feed-interval=1"

 (only that, the rest should be comments). This will tell rng-tools to use /dev/urandom. Now the problem with this is, that the init script will check if the device is a real hardware device. So we need to edit /etc/init.d/rng-tools as well. Find the following line

START="${START} -- -r ${HRNGDEVICE} ${RNGDOPTIONS}"

and replace it with

START="${START} -- ${RNGDOPTIONS}"

Now restart rng-tools, and you should have much more entropy available:

cat /proc/sys/kernel/random/entropy_avail
3968