North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Misguided SPAM Filtering techniques

  • From: Nathan Ward
  • Date: Sun Oct 21 01:29:37 2007

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.

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