[sf-lug] email server problem

[Rick Moen]

Quoting Jim Stockford (jim at systemateka.com):

>     I recently discovered a problem with the email 
> server system for Systemateka (mail.systemateka.com). 
> I've got details gleaned from various log files, but 
> so far I have not been able to find anything that 
> looks like a clue as to why the Postfix-Dovecot 
> system seems to refuse connections from other 
> internet email servers trying to pass email to 
> jim at systemateka.com 

Jim said offlist that, after the above query, friends helped him isolate
the problem to a _firewall_ (an IP/port filter) built into his Comcast
cable modem, that was unexpectedly blocking incoming SMTP connections.

That sort of thing's a real puzzler when it happens, so I'm sympathetic.
In retrospect, it's understandable that Comcast wants its overwhelmingly
residential customers' computers to be unable by default to accept
outbound SMTP sessions from arbitrary outside locations:  It's one of
their antimalware things, and also Comcast typically tries to discourage
customers generally from running Internet services.

Anyway, it's useful to know how to manually simulate an SMTP delivery
attempt.  On Saturday, when Jim said that he'd been unable to receive
SMTP mail at mail.systemateka.com, I thought 'Well, what exactly happens 
when one tries?'  And there's no better way than observing an attempt in
real time.

  $ 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
  $

The telnet utility is capable of opening an outbound connection on any
service port, not just the telnet one.  By saying 'smtp' after the
target hostname, I instructed the telnet client to connect to TCP port
25, the SMTP port.  (These numbers and names are associated in lookup
file /etc/services.)

The answer to 'what exactly happens' is... no connection whatsoever.  
I didn't reach the Postfix SMTP daemon that Jim said was running on the
target host.  So, I advised Jim that he should check to see if either 
Postfix was failing to run as a daemon or firewalling was preventing
connections.