Immediately send Postfix messages to HOLD

For a project, I needed to find some way to purposefully and immediately throw sent messages into the Postfix HOLD queue so they could be released programmatically.

On Debian, you’ll need the postfix-pcre package, and then:

In /etc/postfix/main.cf:
header_checks = pcre:/etc/postfix/header_checks

And then in /etc/postfix/header_checks:
/^X-My-Custom-Header: .*YES/ HOLD

In your application, for applicable messages you can set X-My-Custom-Header: YES and the messages will immediately go into HOLD.

An example config: CORS + PHP + NGINX

Using this guide from enable-cors.org I was able to cobble together an example wide-open CORS config for php files. This may not be everything your particular setup needs, and there may be a better way to do it, but it’s a place to start.

    location ~* CORSTest.php {
        root           /webs/exampledoma.in;
        fastcgi_pass   unix:/var/run/php5-fpm-edm.sock;
        include        fastcgi_params;
        #fastcgi_intercept_errors on;
        fastcgi_param  SCRIPT_FILENAME /webs/exampledoma.in$fastcgi_script_name;

     if ($request_method = 'OPTIONS') {
        add_header 'Access-Control-Allow-Origin' '*';
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
        add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range';
        add_header 'Access-Control-Expose-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range';
        add_header 'Content-Type' 'text/plain charset=UTF-8';
        add_header 'Content-Length' 0;
        return 204;
     }
     if ($request_method = 'POST') {
        add_header 'Access-Control-Allow-Origin' '*';
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
        add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range';
        add_header 'Access-Control-Expose-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range';
     }
     if ($request_method = 'GET') {
        add_header 'Access-Control-Allow-Origin' '*';
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
        add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range';
        add_header 'Access-Control-Expose-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range';
     }
   }

Let’s Encrypt and nginx

With the distrust of StartCom by Google and Mozilla, the Let’s Encrypt movement is gaining steam rapidly.

You can use CertBot to get instructions on how to use Let’s Encrypt automatically. Here’s my implementation:

1.) enable jessie-backports and make sure your domain is pointing at your webserver. Then:
2.) # apt-get install certbot -t jessie-backports
3.) # certbot certonly --standalone -d exampledoma.in -d www.exampledoma.in --pre-hook "service nginx stop" --post-hook "service nginx start"
4.) You should now have the necessary files in /etc/letsencrypt/live/ in a folder named after your domain. Add them to the appropriate nginx config thus:

listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/exampledoma.in/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/exampledoma.in/privkey.pem;

(note: I don’t cover dhparams or cipher order in this post.)

Let’s Encrypt certificates are valid for 90 days, so the last step is to automate renewals. In root’s crontab I use the following for quiet monthly renewal attempts, noting that if nothing is due for renewal, no action is taken:

@monthly certbot renew -q --standalone --pre-hook "service nginx stop" --post-hook "service nginx start"

There are other ways to do this; while certbot has a renewal cron in /etc/cron.d/certbot, Certbot’s own advanced setup documentation illustrates how to use the ‘webroot’ plugin which will work with any webserver you like, but since I don’t mind stopping my webserver once a month for this quick check, I simply use the ‘standalone’ plugin instead.