[sf-lug] email server problem
rick at linuxmafia.com
Mon Oct 29 10:27:28 PDT 2012
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
$ telnet mail.systemateka.com smtp
telnet: connect to address 18.104.22.168: 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
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
More information about the sf-lug