Adding a PTR Record for an Elastic IP on AWS

To add or update a PTR record for an AWS IP, you will need to contact Amazon through the: Request to remove email sending limitations form. Read more in this article.

111 views

Edited: 2021-05-13 12:57

I recently learned that the DNS pointer record (PTR) for Beamtic's SMTP server was inaccurate; one of the e-mails I sent bounced back as Undelivered Mail Returned to Sender, and when I investigated the error message from the receiving server it read as follows:

450 4.7.25 Client host rejected: cannot find your hostname

So, apparently some servers will try to do a reverse-DNS lookup to see if the sending IP resolves to the given host name; if you are on a Linux system, you can easily test this yourself with the host command from a terminal:

host 52.71.13.209

Result

209.13.71.52.in-addr.arpa domain name pointer smtp.beamtic.com

Now, the above example accurately resolves to smtp.beamtic.com, which is the subdomain where Beamtic's SMTP server is hosted; if your result is inaccurate, then you need to update the PTR record for the IP address hosting your server for outgoing e-mail.

What a PTR record is

Just as a domain name or subdomain can have a DNS record that points to a specific IP, an IP address can also have a record that points to a hostname.

This is not normally necessary if you are just hosting websites (handling HTTP traffic), but when you have an e-mail server, this is actually something that can help prevent spam.

The problem is that you can not update PTR records on your own; if you are hosting with Amazon Web Services, then you must contact them through the Request to remove email sending limitations form. Although it says that this is for removal of sending limits, it is also used for updating PTR records.

Reverse-IP lookup

As it seems, far from every server on the internet will actually do a reverse-IP lookup — which is also why I did not notice the problem until now — but some servers will do it, and for those, it can be an extra layer of security to prevent spam.

I do not see what the purpose is when you already got an SPF record, and I am not even sure all hosting services will offer the option to update PTR records, so maybe you would expect servers to prioritize SPF. Welcome to the nightmare of configuring e-mail servers :-D

Note. It is theoretically possible for you to send e-mail on behalf of any domain or e-mail address from your laptop — on a home IP address — but, the receiving e-mail server will usually reject the e-mail if the IP is not approved via DNS records.

In the good old days, it was possible to send spoofed e-mail very easily, simply because receiving e-mail servers would uncritically trust the sending servers. I remember, as a teenager, there was even a program for Windows 9x where you could enter in any sender-address, although I never actually got it to work — maybe I was too late — it would have been a fun prank though :-P

Doing a reverse-IP lookup before accepting an incoming e-mail can help ensure that the e-mail originated from the real user.

Request to remove email sending limitations

Amazon has a form you need to use to update PTR records, and in case you have not done so already, to lift the sending limitations on your Elastic IP.

When you submit the form, you may need to provide them with a statement about what measures you have taken to limit and prevent spam. The statement can, for example, include a list of security measures.

Securing your e-mail server is not straight forward, but here is some things you can do:

1. Remember to add password authentication for the root user, and others — root might not have a password on default Ubuntu installations in AWS.

Even if you have restricted SSH access to your own IP, SMTP will still be open, potentially making your server an open relay! For example, a bot could try to login with root (without password) and start sending e-mail. Other measures below could help prevent e-mail sending, or at least, slow down the attacker.

2. Require users to login before they can send e-mail (Postfix with SASL).

3. Configure your server so that the FROM address must match the e-mail address of the logged in user, the setting name is reject_sender_login_mismatch in the /etc/postfix/main.cf file. E.g.:

smtpd_sender_restrictions = reject_sender_login_mismatch

Surprisingly this is not so with a default Postfix installation, and therefor users will be able to supply any e-mail address as the "FROM" address.

This is probably the hardest part. But, you will also need to maintain a list of logins and e-mail addresses. E.g.:

smtpd_sender_login_maps = hash:/etc/postfix/smtpd_sender_login_maps

The /etc/postfix/smtpd_sender_login_maps file contains a list of users, one per line, along with e-mails that they are allowed to use as the FROM address. E.g.:

jacob@beamtic.com jacobsUserName
kim@beamtic.com kimsUserName
someSecretAddress@beamtic.com root

The last entry should prevent hackers that have success logging in as root from sending e-mail. An easier way is to configure Postfix to use pcre, that way you do not have to update the file every time you add a new user.

4. Limit the amount of e-mail individual users can send per minute in the /etc/postfix/main.cf file. E.g:

smtpd_client_message_rate_limit = 2
anvil_rate_time_unit = 60s

This will allow users to send a maximum of 2 e-mails every 60 seconds.

5. Install and configure fail2ban to prevent brute-force attacks and ban offending IPs.

6. Make sure any e-mail newsletter sign-up forms do not allow submitting the same e-mail address twice.

7. Implement an IP-blacklist of known spammers to prevent spam sign-ups on newsletter subscription forms and create user forms.

It is totally moronic, but spam-bots will attempt to sign up on your newsletter-forms. Preventing this can be difficult, and showing a CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) is not necessarily the best approach.

8. If you are the only user, restrict access to your own IP address.

Note. Even though a lot of receiving e-mail servers (most?) have their own security to prevent spam, it is also important that you try to prevent spam e-mail from getting sent through your server. This can be difficult, but it can also be lots of fun. Running your own e-mail server is also a way to support a free internet.

Links

  1. Request to remove email sending limitations form - amazon.com

Tell us what you think:

  1. How to configure a SMTP server with letsencrypt on an amazon EC2 instance.
  2. Rate limiting your postfix server to limit the amount of e-mail a single user can send.
  3. How to use SPF records to increase the likelihood that your e-mails will be received and not go to spam.
  4. How to configure Postfix to use Lets Encrypt certificates.

More in: Mail Servers