nanog mailing list archives

Re: Misguided SPAM Filtering techniques


From: Nathan Ward <nanog () daork net>
Date: Sun, 21 Oct 2007 18:11:49 +1300



On 21/10/2007, at 9:12 AM, Owen DeLong wrote:


I'm seeing an increasing variety of misguided SPAM blocking techniques such that they are starting to become more and more annoying, and, I'm curious as to what solutions/work-arounds others have deployed, and, if anyone has any
ideas on how to get these tactics reduced/stopped?

Here's the primary hinderance.

I use an authenticated TLS-protected mailhost at home for submitting my
email for delivery.  Unfortunately, networks have taken to:

        outright blocking 25 and 587 except to their own servers.
        proxying all 25/587 connections in a manner incompatible with TLS
proxying all 25/587 connections in a manner incompatible with SMTPAUTH
        blocking TLS startup on 25/587 connections

Blocking 25/TCP is acceptable, blocking 587/TCP is not - it is designed for mail submission to an MSA, so serves little use for spam, save when a spammer has detected an open mail relay listening on 587/TCP, or someone has (mis)configured port 587 to allow submission to locally hosted domains from remote hosts without authentication. I'd be /very/ surprised if the networks in question received sufficient complaints from (clueless) mail admins, who were being spammed via one of these techniques.

http://www.ietf.org/rfc/rfc2476.txt

I find blocking this sort of thing pretty despicable and surprising. You should test that port 587 actually is blocked (and not appear that way as a function of some other anomaly), and then provide their technical people with a swift kick to the backside.
In the short term, your alternative may be to use 465/TCP. (smtp+ssl)

Blocking 25/TCP prevents people running their own mail MSAs on their connection, and that's fine, many T&C's don't allow that.
Blocking 587/TCP prevents people using someone elses mail service.
I view the latter as no different to preventing you viewing someone elses website.

--
Nathan Ward


Current thread: