[Techtalk] mail records, bind9

Thu Nov 8 23:55:50 UTC 2007

R. Daneel Olivaw wrote:
> 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.
> _______________________________________________

Thanks for the overview, it is helpful. Maybe I can explain what we have 
set up a bit better. We have a spam filter on our smtp port, which meant 
that not only was all incoming mail being filtered through spamassassin, 
but all outgoing mail from local mail users was as well. So, we set up a 
second smtp port on a different ip address. The first one was still 
advertised to the world on our mx record as being our mail server, and 
received and filtered mail. The second one is what users for sending 
mail, and it is not filtered. So, these are the relevant entries in 
master.cf

smtp      inet  n       -       n       -       -       smtpd
   -o content_filter=sfilter:
smtp.shadlen.org:587       inet  n       -       n       -       - 
   smtpd

So, users are welcome to use another port for sending mail, but their 
outgoing mail is then sent through the spam filter. What I don't want is 
people sending email to our domain to send it to smtp.shadlen.org:587, 
and thus bypassing the spam filter for incoming mail. It seems the first 
way to do this is to make sure I am not advertising smtp.shadlen.org as 
a host that is receiving mail, so there is no mx record for it. I'm 
wondering if there is anything else I should/should not do regarding dns 
so people don't get the idea to send email there. Then, I will look at 
postfix to see about actually blocking incoming mail to this port, or at 
least monitoring it. It seems like all of our incoming mail at this 
point is going through the filter, so I think I am ok, but I am moving 
my mail server to a new machine, and just want to make sure I have stuff 
set up properly from the get-go. Looking through my postfix config, I 
think I may see something wrong. I have myhostname set to 
smtp.shadlen.org, and I think it should be mail.shadlen.org (which is 
what the mx record is under).

Sorry for the lengthy post, and thanks for the help.

Maria