[sf-lug] email server problem

[Rick Moen]

Quoting Jim Stockford (jim at well.com):

> 's okay now; fixed. 

Yay!

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
  console.

  $ telnet mail.systemateka.com smtp
  Trying 173.13.130.169...
  telnet: connect to address 173.13.130.169: 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
  Trying 198.144.195.186...
  Connected to linuxmafia.com.
  Escape character is '^]'.
  220 linuxmafia.com ESMTP Exim 4.72 Mon, 29 Oct 2012 12:31:10 -0700
  HELO linuxmafia.com
  250 linuxmafia.com Hello li3-98.members.linode.com [64.62.190.98]
  MAIL FROM: <test at www.svlug.org>
  250 OK
  RCPT TO: <postmaster at linuxmafia.com>
  250 Accepted
  DATA
  354 Enter message, ending with "." on a line by itself
  From: test at www.svlug.org
  To: postmaster at linuxmafia.com
  Subject: Yo, postmaster!
  
  Test.
  .
  250 OK id=1TSv3v-00087n-2k
  quit
  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
  points.

  $ dig -t mx mail.systemateka.com +short
  $ dig -t a mail.systemateka.com +short
  173.13.130.169
  $

  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 173.13.130.169.
  I trust that that IP is bound to a public network interface on the
  'mail.systemateka.com' host.

  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
  itself.

  I cannot help noticing that 'systemateka.com' resolves to a completely
  different IP address.

  $ dig systemateka.com +short
  208.69.42.165
  $



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 173.13.130.169 .
(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.