[sf-lug] email server problem
rick at linuxmafia.com
Mon Oct 29 15:51:36 PDT 2012
Quoting Jim Stockford (jim at well.com):
> 's okay now; fixed.
At Jim's invitation, here are some of my offlist comments about
diagnosing such problems:
It's really useful to know how to do manual SMTP sessions at the
$ telnet mail.systemateka.com smtp
telnet: connect to address 126.96.36.199: Operation timed out
telnet: Unable to connect to remote host
Well, that's a really fundamental problem: Postfix isn't even answering
at all, when someone comes knocking.
You need to make sure the Postfix daemon is running on the
mail.systemateka.com host, and you need to make sure you are not
firewalling off incoming connections to it on tcp port 25 (SMTP).
Again, compare to a _successful_ manual SMTP session, and notice the
difference between failing on 'connect... timeout' and getting an
answering 220 success response from the remote SMTP host:
$ telnet linuxmafia.com smtp
Connected to linuxmafia.com.
Escape character is '^]'.
220 linuxmafia.com ESMTP Exim 4.72 Mon, 29 Oct 2012 12:31:10 -0700
250 linuxmafia.com Hello li3-98.members.linode.com [188.8.131.52]
MAIL FROM: <test at www.svlug.org>
RCPT TO: <postmaster at linuxmafia.com>
354 Enter message, ending with "." on a line by itself
From: test at www.svlug.org
To: postmaster at linuxmafia.com
Subject: Yo, postmaster!
250 OK id=1TSv3v-00087n-2k
221 linuxmafia.com closing connection
Connection closed by foreign host.
I had also noticed that Jim's problem description talked both about
mail.systemataka.com and systemataka.com, which raised the possibility
of DNS issues and of the SMTP host possibly not recognising itself as
the destination, so I talked about that, too:
The first thing I'd look at -- given that I'm flying blind because
you didn't bother specifying what you tried in order to test -- is
checking DNS correctness.
You say you're talking about receiving system 'mail.systemateka.com'.
Let's see where the public DNS declares that inbound SMTP to
'mail.systemateka.com' should be delivered. The RFCs say that inbound
mail should get delivered to whichever one or more destination hosts are
specified in the MX records. If there are no MX records, then as a
fallback, inbound mail should get delivered to where the A record
$ dig -t mx mail.systemateka.com +short
$ dig -t a mail.systemateka.com +short
You have not (yet) created MX records for FQDN 'mail.systemateka.com'.
It would be a good idea for you to do so.
Anyway, the A record, used here as the fallback, says IP 184.108.40.206.
I trust that that IP is bound to a public network interface on the
You say you 'cannot receive e-mail' (a phrase whose meaning is just a
bit vague, but never mind) if it's addressed to jim at systemateka.com . Is
'systemateka.com' one of the lines in the mydestination line in
Postfix's /etc/postfix/main.cf ? If not, that would explain what you
observed. By default, the line is like this:
mydestination = $myhostname,localhost.$mydomain, localhost, $mydomain
Since you said the host is mail.systemateka.com, not systemateka.com,
Postfix by default would not recognise the latter as an alias for
I cannot help noticing that 'systemateka.com' resolves to a completely
different IP address.
$ dig systemateka.com +short
When seeking help with a technical problem, it's wise to go because
'cannot receive e-mail' and specify what your attempt consisted of, and
what you checked to conclude that the mail didn't arrive. Otherwise,
your helper is left speculating about what you did, and that's an
unpromising place to start.
So, Jim might have said this:
1. I made sure a local 'jim' account exists on mail.systemateka.com
2. I sent local test mail from 'jim' to 'jim' on mail.systemateka.com,
and received and read that mail, delivered locally by Postfix.
3. On separate system systemateka.com, I verified ability to ping
mail.systemateka.com, which FYI resolves to IP 220.127.116.11 .
(Provide ping session inline.)
4. On separate system systemateka.com, I sent test mail to destination
user 'jim at mail.systemateka.com'. I got no delivery status notification
at my sender address. Examining /var/log/maillog on destination system
mail.systemateka.com, I found no log entries showing attempted delivery.
(I'm omitting the complication of Jim reportedly attempting to get
mail.systemateka.com to accept mail addressed to jim at systemateka.com,
which currently would be a mailbox on a completely different system on
a different IP address.)
By the way, Bobbie mentioned having a 'bunch of bounces'. People should
be aware that the _contents_ of the bounce advisories -- the Delivery
Status Notification -- are crucial for diagnosis, and people should read
the reasons cited in those advisories for permanent or temporary
delivery failure, and not just ignore tham as 'bounces' as if they were
all the same.
More information about the sf-lug