MTA on non-standard port

[Jeremy Chadwick]

On Sun, Oct 26, 2008 at 06:55:53PM -0500, Kevin Kinsey wrote:
> Hello,
> 
> Quick thanks to Andrew Clark, Jeremy Chadwick, Tim Kellers,
> Jeff Goldberg, and anyone whose reply I've not seen re:
> this issue.
> 
> Isn't hard, as several pointed out.  Now I've sendmail listening
> on any port I want to.  Problem is, still can't touch it from
> here (and you might have guessed, the base issue is a new provider
> of a lower-class service who I'm guessing only allows certain
> ports by default).

Most consumer ISPs in the United States block two kinds of traffic to
their customers' IP blocks:

1) Incoming SMTP (e.g. someIP:* --> yourIP:25)
2) Outbound SMTP (e.g. yourIP:* --> someIP:25)

#2 has become prominent in the past few years, and is applied by ISPs
because they want to curb their customers sending spam out onto the
Internet (usually as a result of viruses, trojans, etc.), getting their
IPs blocked by DNSBLs and giving them a bad social rep.  Instead, they
force customers to relay outbound mail through their own SMTP servers
(called a "smart host" in sendmail terms).

There's absolutely no way around this; you can beg them all you want,
but the chances of them adding a pass-through for you is very slim.
Story time again...

My setup, just to give you some idea: my home LAN has a FreeBSD box used
for all kinds of purposes.  The box itself does not have direct Internet
access (it sits behind a Linksys WRTSL54GS NAT router, which DOES NOT
have incoming port 25/587 forwarded).  The BSD box listens on
localhost:25,587, and bsdIP:25,587.  This allows other machines on the
LAN to send mail through the BSD box, and of course local utilities on
the BSD box to do the same.

The Linksys router has two outbound firewall rules applied to it: it
only allows bsdIP on my LAN to connect to someIP:25,587 -- thus, only
one machine on my LAN is allowed to speak SMTP to the world.  I do this
purely as a precautionary measure (in case one of my friends comes over
with his/her laptop, which happens to be infected and sends spam, etc.
-- it won't work, period).

All this worked great until Comcast put in place outbound SMTP filters,
which stopped postfix from being able to connect to someIP:25 (where
someIP is some random MX/mail server on the Internet).  I was forced to
set up "smart relaying", causing postfix to siphon all outbound mail
through comcastmailserver:25, which worked fine for a few years.

A couple months ago, Comcast stirred up the ants.  They blocked my
ability to send mail to anyIP:25 (including to their own SMTP servers!),
citing "an incident of spam from my IP address".

I asked them provide timestamps, Reference IDs, or even queue IDs, and
also explained my LAN setup and how what they were claiming happened
simply could not happen without my knowledge of it.  They refused, as in
in literally "We will not provide you any of that".  Abuse and I got
into a very long discussion on the phone about this, and told me a lot
of conflicting things (more or less just inducing me to ask more
questions, because their story didn't make any sense).  They did
eventually tell me what *day* the spam was sent, which allowed me to go
look through my logs -- over and over, and I found absolutely no sign
of any illegitimate mail in my mail logs.

I was told they would lift the block (which was done at the cable modem
level, not at the router level) if I could "permanently guarantee no
more incidents of spam".  I told them that was impossible to guarantee,
because there *was no incident of spam* from my IP in the first place,
and they were refusing to work with me to figure out how/why they were
claiming that.  So we sat there on the phone, silent, basically saying
nothing -- a total standstill.

Eventually they stated that I could send mail through their mail servers
on port 587.  I quickly set this up, and found it failed -- their
servers require SMTP AUTH on port 587, no exceptions (note: this is
NOT mandatory by the RFC; it's OPTIONAL).  This meant I had to go
through the pains of dealing with Cyrus SASL2 (thankfully postfix
makes this easier to deal with than sendmail), and upon configuring it
all, mail once again began to flow.  That's how things remain now.

The reason I do not like siphoning mail through Comcast: their mail
servers are known to act wonky or /dev/null mail for mysterious reasons.
I've had two separate incidents of me sending mail to individuals,
witnessing Comcast's servers say "OK/accepted", but the mail never
reached the destination.  In one case, one recipient ran his own mail
server, and was able to confirm that he saw absolutely no Comcast IP
connect to his server during a 24 hour period.  To this day the mail
has never arrived.

All the anti-spam advocates praise ISPs stepping in and becoming the
"middle man" for spam siphoning/filtering, spanking users like this
when incidents occur -- but when their setup fails or does what I've
described above, they basically turn their cheek and ignore any sort
of mistake or mishap.  The fact that I cannot convince my ISP that I
am a responsible Netizen is disheartening -- I should not need a
business class connection to justify my responsibility.

I hope the experience with your ISP is better than mine.  Good luck.

-- 
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |