[Techtalk] mail records, bind9

[R. Daneel Olivaw]

Hi there,

> I have become confused about mail and dns, because various places
> that I have looked refer to DNS entries for sending and receiving
> mail as if they are separate things, but without being explicit about
> it. I know that I need an MX entry for my mail server (receiving
> mail), and am also suppose to have a SPF record. Do I also need an
> entry (other than an A record) for machines that only send mail? Also
> is there any advantage/disadvantage to using ips vs. hostnames in the
> SPF records?

SPF records are an "addon" for email sending, but if you're
already confused with standard A & MX records, let's start it "simple"
 
First, 'A' records do only one thing : refer a host name to an ip
address. I ask for 'blah.example.com', and it returns x.y.z.t an IP
address.
You may set an 'A' record for any host you're using, maybe even
more than one per host (we're simplifying here : one host = one IP).

For this to work with e-mail sending, an e-mail address should look
like this : 'user at blah.example.com'. This looks obvious, but having one
e-mail server for every user is not a solution, and people wanted to
group the e-mail receiving/storing function, grouping things around the
domain name part of a host ('example.com' here).
This means, when an e-mail server wants to send an e-mail to
'user at example.com', there shall be a way to 'ask' what host
specifically will collect e-mails for that domain.
Here it is where MX records are needed. Instead of asking the DNS
system (I'll skip the recursive searching stuff) for a host-to-ip
conversion, the e-mail server will ask for the 'MX' record (there
usually is more than one record, but let's admit there is just one).
The DNS system will answer "the host that handles mail for my domain,
is called 'blah.example.com'".
Now, the e-mail server still needs to know the ip address of the mail
server, and therefore will ask for a simple host-to-ip resolution,
getting x.y.z.t as a response (same as above).
At last we know the ip address, we will connect to port 25 (smtp),
talk to the remote mailserver and try to deliver the e-mails.

Diggin' into the Simple Mail Transfer Protocol.
Setting up things: We are a mailserver, our domain is ALPHA.COM.
Some user (USER1) sends and email to USER2 at BETA.COM.
We (the mailserver) will try to send it:
1/ get the MX record(s) for domaine BETA.COM
=> MX for BETA.COM is MAIL.BETA.COM
2/ get the ip address for MAIL.BETA.COM
=> MAIL.BETA.COM has ip address 1.2.3.4
3/ connect to MAIL.BETA.COM on port 25
first thing we do is : say hello !
HELO ALPHA.COM
(here we tell the server what our domain is)
the server answers something like
250 Hello ALPHA.COM
(very nice to meet you, waddaya want ?)
and so on we discuss things, like sender address, target address,
e-mail body, ...

This, used to be heaven on earth, every e-mail server agreed to receive
e-mails and to transfer them to whoever was concerned. Eventually, the
mailserver of BETA.COM found the target address to be one of his users,
and dropped that e-mail into the appropriate mailbox.

This had some issues: everyone could set up a mailserver pretending to
be ALPHA.COM's legitimate mailserver and forge e-mails for BETA.COM's
users. The time of spam had come.

To protect users from spam, mailservers used some tricks to prevent
spammers to fool them : when someone connects to send an e-mail,
mailservers knew the incoming ip address, could do a "reverse
resolution" (means doing the opposite of the 'A' record lookup :
getting the hostname from the ip address) and tryied to check if it
matched with the names given by the incoming connection.
This doesn't work well, as many servers handle multiple domains, and
cannot show up "clean" for each domain. Moreover, companies tend to use
multiple inbound and outbound mail gateways, and there is no way to
"know" if an incoming connection is legitimate or not.

Hey, but BETA.COM's mailserver could ask for the MX records of
ALPHA.COM, and then know what ip address should connect, but again,
there is no rule that forces someone to send out mail from the inbound
mailserver.
Here is where SPF should help : as an admin of ALPHA.COM's dns system,
you may set up SPF records (now this is getting complicated, SPF
records may be TXT records on older dns systems, and 'true' SPF records
on newer dns systems, therefore, ... let's skip it).
SPF records may tell BETA.COM's mailserver what hosts (ip addresses)
are legitimate outbound mail servers for ALPHA.COM.

Your 'outgoing only' mailserver should be referenced in an SPF record.
As the whole dns system is built upon host-to-ip resolution, it should
be logical to use a hostname in the SPF record, instead of an ip
address. Again, there is no rule, you may be sure that your mailserver
will sit on a static neverchanging ip address, and may want to reduce
the dns load (as using a hostname will force the other mailserver to
poll the dns system once again to fetch the ip address).

> I was having problems with mail we were sending being sent through
> our spam filter on its way out, so I created a new hostname and ip on
> the same machine to be used for sending mail only, and I want to make
> sure that we aren't receiving mail at this ip/hostname.

If you set up your e-mail server with multiple ip's and don't want
people to connect to none but one ip for incoming mail, you should tell
your mta (say, postfix ;p) to bind on only one ip interface (this
shouldn't be complicated to find : man postfix).
You may also use your firewall to allow incoming connections on port 25
only for one ip of your server.
However, IMHO, I am really unsure about the logic of the setup you are
telling us about.
A bit more investigation on the 'real' problem may be needed.

Anyway, I hope I didn't misunderstand your questions, writing, once
again, too much things ... (apologies to those who think I
oversimplified things too much ;p)

Don't hesitate to ask for details,

read you soon,

R. Daneel Olivaw,
The Human Robot Inside.