MTA on non-standard port

[Jerry]

On Sun, 26 Oct 2008 17:23:59 -0700
Jeremy Chadwick <koitsu at FreeBSD.org> wrote:

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

I had a similar experience with Comcast. After speaking with their
representatives and getting nowhere, I got the representatives to give
me their ID #'s, something they have to do by law anyway, and then
filed a protest with the 'Public Service Commission' in New York State.
Within five days I had both the Comcast and PS Commission reps talking
to me. Long story, Comcast backed down. The PS commission said that
Comcast could issue a system wide regulation if they wanted, and in
fact they are in the process of doing that right now; however, they
could not just single me out without supplying me with the requested
information.

Further more, they are now requiring SMTP AUTH on 587. While that may
not be RFC required, I really see no reason to complain about it.
Actually, it is probably a good idea if it helps contain the spread of
SPAM. However, at least in my case, both inbound and outbound port 25
traffic is open.

-- 
Jerry
gesbbb at yahoo.com

It's kind of fun to do the impossible.
		-- Walt Disney
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20081027/003c491c/signature-0001.pgp