Sending mail from EC2 Servers

Sending mail from EC2 servers, is for the most part the same as sending email from any other dedicated server. Setup Postfix and then use the "sendmail" provided by postfix. In your web applications just use "localhost" as your smtp server. This works, except that Amazon EC2 IPs are now blacklisted by Spamhaus, so corporations that fight spam based on Spamhaus info will block all your messages.

That's exactly what happened to us. I'm not the only one having email sending issues with EC2, there are several articles about the Spamhaus, EC2 issue.

Solution
Use an SMTP server external to EC2 for handling mail sending. I first tried to use gmail, but gmail alters the sender address, so that all messages appear to come from gmail, not quite what I needed.

1. Add a relayhost entry to postfix (for me this was in /etc/postfix/main.cf)
   relayhost = mail.otherserver.com
2. On the host that will be acting as a relay (in this example mail.otherserver.com also in the /etc/postfix/main.cf file), I added the reserved ip address for my EC2 instance to the mynetworks list
   mynetworks = 127.0.0.1/8 11.20.30.40 #where this represents the ip of my ec2 server

That's it.
After running /etc/init.d/postfix restart on both servers, no more blacklisting issues.

The problem with this is that I end up needing to have a server outside of the cloud, which brings a single point of failure and works against the scalability of cloud based solutions.

Hmmm, wonder if I could run my smtp server in Google App Engine, somehow.

NGINX entity too large, no more

Sometimes a simple sentence can make a world of difference. It did that for my nginx configuration this morning. Since setting nginx in front of Plone, I've had an "413 entity too large" error for files bigger than 1 MB.

My configuration uses a special conf/proxy.conf file which looks like this::

# proxy.conf
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size 30m;
client_body_buffer_size 2m;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffer_size 2m;
proxy_buffers 4 1m;
proxy_busy_buffers_size 2m;
proxy_temp_file_write_size 2m;

The wrong way
Previously my 'server' section in my nginx.conf used to look like this:

server {
listen 1.2.3.4;
server_name example.com www.example.com;
location / {
rewrite ^/(.*)$ /VirtualHostBase/http/www.example.com:80/example/plone/VirtualHostRoot/$1;
}
location /VirtualHostBase/ {
proxy_pass http://sharedhosting;
include conf/proxy.conf; #this is apparently a bad place to put this
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}

}


The right way
So I read the following comment at the slicehost forums:

"Try moving the directive from inside the location block to just inside the server block."


So now I've moved it to "just inside the server block" so my 'server' section in my nginx.conf now looks like this:

server {
listen 1.2.3.4;
server_name example.com www.example.com;
include conf/proxy.conf; #now it works, phew!
location / {
rewrite ^/(.*)$ /VirtualHostBase/http/www.example.com:80/example/plone/VirtualHostRoot/$1;
}
location /VirtualHostBase/ {
proxy_pass http://sharedhosting;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root html;
}

}