Mail DNS Records - errorCodex

Miraenda · #1 23 November 2009, 20:02

Spoofing

What is spoofing? Spoofing is the purposeful use of an email address that is not the sender’s actual email address in the FROM field on an email. Spoofing is non-preventable, meaning that a domain owner cannot stop someone from purposely spoofing the domain or email address.

What steps can be taken to address spoofing? Since spoofing cannot be stopped, it is the legitimate sender’s and legitimate receiver’s responsibility to minimize spam. The sender can setup a valid PTR (rDNS), SPF, SenderID, DomainKeys and DKIM records so that outgoing emails verify they are coming from the actual domain or email. The receiver can institute verification checks for incoming emails to look for SPF, Sender ID, DomainKeys and DKIM records as well as using other methods such as sender verify, greylisting and a lame primary MX server.

The following guide will detail how to modify various mail DNS zone records for the sending domain to legitimize email sent from your domain.

PTR (rDNS) records

A PTR record serves to help a receiving server check that the sender server’s response on port 25 matches the DNS record response for the reverse DNS (rDNS) in the zone. You can check the response from any server by doing the following:

Code:

telnet domain.com 25

An example domain could be errorcode.com:

Code:

telnet errorcodex.com 25

Response:

Code:

Trying 64.50.166.3...
Connected to errorcodex.com.
Escape character is '^]'.
220-synthesis.lunaradmin.com ESMTP Exim 4.69 #1 Mon, 23 Nov 2009 18:28:11 -0800 
220-We do not authorize the use of this system to transport unsolicited, 
220 and/or bulk e-mail.

The entry in bold red is the server’s response on port 25 for the hostname. This means the PTR record in the IP zone file should have an entry for 64.50.166.zone that is similar to the following:

Code:

3 IN PTR synthesis.lunaradmin.com.

You can check the PTR entry for the IP at this point:

Code:

host 64.50.166.3

You will get a return such as the following:

Code:

3.166.50.64.in-addr.arpa domain name pointer synthesis.lunaradmin.com.

This shows that the correct entry (synthesis.lunaradmin.com) was indeed setup.

The point of the PTR record is to allow a receiving host to check that a sender server exists and does claim to be the proper sender of the email message. Such a verification check, which is called sender verify, cuts down the likelihood that the sender server is a spam source, since spammers oftentimes do not have legitimate IPs assigned to emails they send, spoofing the IP so that it instead returns to a non-existant or invalid server address.

SPF records

Sender Policy Framework (SPF) is an attempt to control the sending of forged emails by providing a TXT record in the domain’s DNS zone to indicate which mail servers are allowed to send mail for a set domain.

Setting up an SPF record

A wizard is available at http://old.openspf.org/wizard.html on setting up an SPF record. Let’s say we have the domain lunaradmin.com and we indicate yes for the A and MX questions and no for the PTR one, then we would input into the ip4 field the following IPs as the domain and server have both IPs used on it:

Code:

64.50.164.46
64.50.164.47

This will result in the following SPF record:

Code:

"v=spf1 a mx ip4:64.50.164.46 ip4:64.50.164.47 ~all"

You would then go to a server’s DNS zone (typically at /var/named/domain.com.db) and add the following line for the domain in question:

Code:

lunaradmin.com. 14400 IN TXT "v=spf1 a mx ip4:64.50.164.46 ip4:64.50.164.47 ~all"

You would then need to reload the domain for the change to process:

Code:

rndc reload lunaradmin.com

You can check that the SPF record is showing up at that point by doing the following:

Code:

dig txt lunaradmin.com +short

If it is, you should receive something like the following:

Code:

"v=spf1 a mx ip4:64.50.164.46 ip4:64.50.164.47 ~all"

You can then further test by sending an email from the domain to the email address check-auth@verifier.port25.com which has a report similar to the following:

Code:

=========Summary of Results=========
SPF check:          pass
DomainKeys check:   neutral
DKIM check:         neutral
Sender-ID check:    pass
SpamAssassin check: ham

=========Details:=========
HELO hostname:  synthesis.lunaradmin.com
Source IP:      64.50.164.46
mail-from:      admin@lunaradmin.com

SPF check details:
Result:         pass
ID(s) verified: smtp.mail=admin@lunaradmin.com
DNS record(s):
lunaradmin.com. 14400 IN TXT "v=spf1 a mx ip4:64.50.164.46 ip4:64.50.164.47 ~all"
lunaradmin.com. 14400 IN A 64.50.164.47
lunaradmin.com. 14400 IN MX 0 lunaradmin.com.
lunaradmin.com. 14400 IN A 64.50.164.47

SenderID

This system of verifying senders by the DNS zones is very similar to SPF records and was developed by Microsoft. Using almost the same syntax as the SPF record, this allows a domain to have an SPF record on a domain to pass the SenderID check. The main difference between the two systems is that SPF checks the MAIL FROM envelope value, while SenderID checks the From address header value. Normally, both of these values are the same.

If you’ve setup an SPF record already and performed the test to check-auth@verifier.port25.com then you will notice the pass for SenderID as well:

Code:

========Summary of Results=========
SPF check:          pass
DomainKeys check:   neutral
DKIM check:         neutral
Sender-ID check:    pass
SpamAssassin check: ham

The specific results would appear as follows for it:

Code:

Sender-ID check details:
Result:         pass
ID(s) verified: header.From=admin@lunaradmin.com
DNS record(s):
lunaradmin.com. 14400 IN TXT "v=spf1 a mx ip4:64.50.164.46 ip4:64.50.164.47 ~all"
lunaradmin.com. 14400 IN A 64.50.164.47
lunaradmin.com. 14400 IN MX 0 lunaradmin.com.
lunaradmin.com. 14400 IN A 64.50.164.47

With Microsoft’s SenderID framework, however, you will need to actually add a few more pieces of information to your SPF record to get it to pass their own check.

Now that you have a working SPF record, simply go to http://www.microsoft.com/mscorp/safe...d/default.aspx and follow the prompts to get the rest of the SenderID setup.

When I did it, I received the following changed record by Microsoft:

Code:

"v=spf1 a mx ip4:64.50.164.46 ip4:64.50.164.47 mx:lunaradmin.com -all"

I then had to revise the existing TXT record for the SPF in my zone and reaload it. After doing that, then I registered the SenderID with Microsoft at the following:
https://support.msn.com/eform.aspx?p...eformts&scrx=1

It might take 1-2 days after filling out the form for Microsoft to add your domain to their program. You will receive an email from Microsoft after it has been successfully added.

A few parts to note. First of all, if you only have 1 IP on the server, you would not need the ip4:IP ip4:IP portions of the record, so simply having this would normally work:

Code:

“v=spf1 a mx ~all”

I was required to have the ip4:64.50.164.46 ip4:64.50.164.47 entries in the record as my lunaradmin.com domain uses a dedicated IP of 64.50.164.47, while my dedicated server has the main IP of 64.50.164.46. The A record for the lunaradmin.com domain does not match the server’s mail IP of 64.50.164.46 due to this reason.

Next, the original SPF record site uses a soft fail (~all) rather than a hard fail (-all) for it. The Microsoft SenderID site switched it to a hard fail (-all). I have no idea why the Microsoft site required mx:lunaradmin.com for the record, but it did in order to get approved into the program without errors.

DomainKeys and DKIM

DomainKeys was developed by Yahoo as an encryption system to verify the domain sender and message integrity. The system uses public and private keys in a similar fashion to SSL encryption. The protocol was further developed into DKIM (DomainKeys Identified Mail), which is the replacement for DomainKeys. Unfortunately, some servers use the older DomainKeys verification system and some use the newer DKIM system, and the two systems aren’t interchangeable for the most part. You cannot have both DomainKeys and DKIM records either in your DNS.

To overcome this hurdle, you can utilize the DKIMProxy program to handle the setup. Download this package at http://downloads.sourceforge.net/dki...oxy-1.2.tar.gz

To see the instructions for installing DKIMProxy on a cPanel-based exim server, please review this tutorial.

Synopsis

Spoofing of a domain and email address is unpreventable, since anyone can use a script or program to pretend to be using any domain or email address. In order to limit the impact such spoofing causes for a domain, the domain owner can add several components to the domain and server.

First, a PTR record can be setup that matches the port 25 telnet response for a domain to pass the sender verify check sent by the receiving server. Usually, the zone file for an IP is only editable at the webhost or ISP level, so if you do not have access to the IP zone file itself, please contact the IP provider to get the PTR record edited to the proper entry.

Next, an SPF and SenderID TXT record can be created. Microsoft prefers these type of records, since they were involved in the SenderID framework. An SPF or SenderID record basically is a record in the domain’s zone file indicating what domains and IPs are allowed to send through the server for email. Services like msn and hotmail and live.com email recipients are less likely to reject or tag as spam domains with the SPF and SenderID records.

For DomainKeys and DKIM records, you can only have one such record on your domain. This record adds a public key in the DNS zone that maps to a private key on the server. The TXT record is checked by a receiving server and the private key is then requested to see if it matches the encryption. If it passes, then emails will be accepted by the receiving server. This method of authentication is preferred by Yahoo, since the original DomainKeys method was developed by them. Gmail also uses DKIM and DomainKeys to pass email senders to the inbox rather than spam box.

Setting Up a Receiving Server to Check for SPF and DomainKeys/DKIM

As a note, you can also setup a server as a receiving server to check for SPF, DomainKeys and DKIM to minimize spam on your own server. DKIMProxy actually has an inbound check for DomainKeys and DKIM signed emails. A better idea would probably be to simply add the Perl Modules for SpamAssassin and enable those plugins. This is not as straightforward as it might sound since, even on cPanel, you don’t simply use a GUI to enable them.

First, you’d need to install the Perl Modules required for the SpamAssassin plugins to work:

Code:

/scripts/perlinstaller Mail::SPF
/scripts/perlinstaller Mail::SpamAssassin::Plugin::SPF
/scripts/perlinstaller Mail::DomainKeys
/scripts/perlinstaller Mail::SpamAssassin::Plugin::DomainKeys
/scripts/perlinstaller Mail::DKIM
/scripts/perlinstaller Mail::SpamAssassin::Plugin::DKIM

Then you would change to the spamassassin directory:

Code:

cd /etc/mail/spamassassin

Of note, the SPF plugin is already installed and allowed. If you look at init.pre file, you will see that this line is uncommented already:

Code:

loadplugin Mail::SpamAssassin::Plugin::SPF

For DomainKeys, the plugin is found in the v310.pre file in /etc/mail/spamassassin, but there is no reason to enable DomainKeys plugin as enabling the DKIM plugin will support both, so instead just enable the DKIM one:

Code:

vi v312.pre

Uncomment the following line:

Code:

loadplugin Mail::SpamAssassin::Plugin::DKIM

Save the file with :wq and restart exim:

Code:

/etc/init.d/exim restart

Test it is working by sending an email to one of the accounts on your server then check /var/log/maillog to see if you find the following type of examples:

Code:

Sep 13 14:46:47 synthesis spamd[11790]: spamd: result: . 0 - 
DKIM_SIGNED,DKIM_VERIFIED,HTML_MESSAGE,SPF_PASS scantime=4.0,
size=2486,user=admin,uid=510,required_score=5.0,rhost=localhost,raddr=127.0.0.1,
rport=58185,mid=<4f1bee20909131446r24f747b9y3ceac9ec453cecfb@mail.gmail.com>,
autolearn=ham,shortcircuit=no

Sep 13 14:46:47 synthesis dkimproxy.out[21329]: DKIM signing - signed; 
message-id=<4f1bee20909131446r24f747b9y3ceac9ec453cecfb@mail.gmail.com>, 
signer=<@lunaradmin.com>, sender=<domain@gmail.com>

This was an email sent from my gmail account to an email address on lunardmin.com. Since gmail uses SPF records and DKIM on it, it passes the validation checks by SpamAssassin.

Miraenda · #2 19 April 2010, 07:08

I actually wanted to update this topic to mention something that I'd recently found out. While it isn't possible to prevent spoofing from another server for the email address in the "From:" field, it is possible to prevent this on your own machine.

The following ACL can be added to exim.conf

Code:

acl_check_data:
deny
 authenticated     = *
 condition = ${if or {{ !eqi{$authenticated_id} {$sender_address} }\
 { !eqi{$authenticated_id} {${address:$header_From:}} }\
 }\
 }
message = Your FROM must be as the account you have authenticated with to deliver

For cPanel, this would be done in WHM > Exim Configuration Editor > Advanced Editor area by placing the lines above in the box immediately below this section:

Code:

#!!#######################################################!!#
#!!# This new section of the configuration contains ACLs #!!#
#!!# (Access Control Lists) derived from the Exim 3      #!!#
#!!# policy control options.                             #!!#
#!!#######################################################!!#

#!!# These ACLs are crudely constructed from Exim 3 options.
#!!# They are almost certainly not optimal. You should study
#!!# them and rewrite as necessary.

begin acl

The ACL code will force the email user on your machine to use the same FROM address as they authenticated with on the server.

Please note that the above differs from this option in cPanel > Exim Configuration Editor area:

Set the Sender: Header when the mail sender changes the sender (-f flag passed to sendmail). [?]

The cPanel option only sets the Sender: Header for an email, which isn't the same as the From: address. Many email clients look at the From: address rather than the Sender: Header for an email, although the full header will show the Sender: Header in it. Basically, the cPanel option only adds additional details to track down who sent the message, but it does not stop someone from changing the From: address. The ACL mentioned initially does prevent this from happening, preventing spoofing being used on your machine.

Thanks.

shaycorl · #3 3 May 2010, 14:31

Trying on SMPT server and while sending out emails ... emails aren't being sent by system so i just setup a error log while which is showing me only info about emails sent or not but not what exactly is wrong i am using PHP 5+

Miraenda · #4 3 May 2010, 14:56

You haven't provided enough details for me to know what might be wrong. Try to send an email using:

exim -odf -d mail@domain.com (replace mail@domain.com with the email you are trying to send out to)
Test.
.

Then see what it shows when it tries to send. Provide the output from "exigrep mail@domain.com /var/log/exim_mainlog" command with mail@domain.com as the actual email you sent out to for us to see the error. Also, I'm not certain what PHP 5 would have to do with mail, since the PHP version doesn't impact exim.

jorj · #5 7 May 2010, 13:32

For the sake of more helpful information for the public please allow me to add a few comments on this post.

Quote:

You cannot have both DomainKeys and DKIM records either in your DNS.

To overcome this hurdle, you can utilize the DKIMProxy program to handle the setup.

Actually one can have both of these in the DNS and it is recommended to do so. Moreover, DKIMProxy is only suitable for basic configurations where one wants to use the server for one domain only and manage the emails with through desktop email clients (Outlook, etc).

All the other details are correct and very useful for interested users. Find more information about setting up, references and testing in this article: "Postfix with DKIM, Domainkeys, SPf and Sender-ID" at http://www.tai.ro/2010/04/03/postfix...and-sender-id/

Cheers
Alex

Miraenda · #6 8 May 2010, 22:03

I would presume you haven't setup dkimproxy properly in the past as it can be used for multiple domains.

Powered by vBulletin® Version 3.8.1 Copyright ©2000 - 2010, Jelsoft Enterprises Ltd.