[sf-lug] email server problem

[Rick Moen]

Just as one follow-up:  Beware of DNS confusion.

Jim mentioned both 'mail.systemateka.com' and 'systemateka.com' in his 
problem description:  He said new mail host mail.systemateka.com was 
(at the time) unable to receive SMTP e-mail addressed to
jim at systemateka.com.


Looking in the public DNS, one immediately noticed that DNS names
'mail.systemateka.com' and 'systemateka.com' map to very different IPs,
making it seem highly likely they were/are distinct server boxes:

$ dig mail.systemateka.com +short
173.13.130.169
$ 

$ dig systemateka.com +short
208.69.42.165
$

I'm hoping most readers are seeing one big problem up-front:  If you're
out somewhere on the Internet addressing mail to mailbox
jim at systemateka.com, is it going to even reach 'mail.systemateka.com' at
all, given that the latter's an entirely different mail-server system
from 'systemateka.com'?

One can put hints into the public DNS saying 'Hey, whenever you wish to
deliver mail to systemateka.com, please drop them off at mail system
mail.systemateka.com.  This is called an MX (mail exchanger) record in
the public DNS.  For example:

$ dig -t mx unixmercenary.net +short
10 linuxmafia.COM.
$

The 'dig' command asked 'What MX entries exist in the public DNS for
unixmercenary.net (and please give me the short version of your answer).
The authoritative servers answered 'Mail intended for that DNS entity
should be dropped off at host linuxmafia.com .  That particular mail
exchanger is assigned relative priority level 10 where a lower number is 
higher priority (which would matter if there were multiple MX entries,
but there aren't).'

So, getting back to 'jim at systemateka.com', there _could_ be MX entries
in the public DNS saying where mail for DNS entity 'systemateka.com'
should be dropped off.  Checking the current DNS:

$ dig -t mx systemateka.com +short
20 mail.systemateka.com.
$

There is such an entry _now_.  There was not one on Saturday when Jim
first posted about his problem:  That was one of the several obstacles
he faced, and he's been very capably working through them.

(According to the RFCs, if a DNS entity lacks an MX entry for it,
delivering mail systems should, as a fallback, drop off mail at the
place where the regular-forward-lookup 'A' record points.  Thus,
although it's always a good idea to publish an MX record for any system
intended to receive SMTP mail, it's not strictly necessary unless you
want to say that mail for DNS entity X should be delivered to separate
DNS entity Y.)


Anyway, backing off to overview again:

You can't just wave a magic wand and say 'deliver mail addressed to
jim at systemateka.com to mail.systemateka.com'.  The effort starts with
understanding how mail gets delivered, step by step:

1.  The sending mail program drops off outbound mail at a delivering
SMTP host.

2.  The delivering SMTP host looks up the destination system's MX
record(s) in the DNS.  If that/those are non-existent, it falls back on
using the 'A' record contents.  Either way, it thus determines the
remote destination IP address.

3.  The delivering system opens a TCP socket to the remote destination's
SMTP port (tcp port 25), if one can be reached.  It describes the
results of that effort in logfiles kept by the Mail Transport Agent
(MTA = SMTP daemon) process.

4.  If delivery to a remote destination MTA is successful, then the
remote MTA examines and classifies the received mail, maybe throws away
or rejects it if the mail seems too spammy, or otherwise hands it off to
some local delivery agent (LDA) if it's deemed acceptable.  The results
of that activity gets described in logfiles kept by the receiving MTA.

If something goes wrong, following that chain of events will find it.
(Note that there are potentially two logfile entries to help tell you
the story.)  

Note also that steps #1-3 get rolled into a single step if you compose a
test e-mail, live, by simulating a delivering MTA and typing SMTP
commands into a telnet session you open to the receiving system's SMTP 
port (tcp port 25).


And, again, the result response codes that a receiving MTA issues (and
then get conveyed to sender in Deliver Status Notifications) are highly
meaningful, and tell you a _lot_ more than just 'bounce'.  Here's some
basic information about the three-digit response codes:
http://www.greenend.org.uk/rjk/tech/smtpreplies.html

They are divided into categories:
2xx responses are success results.
4xx responses are transient (temporary) failure results.
5xx responses are permanent failure results.