Misguided SPAM Filtering techniques

Nathan Ward nanog at daork.net
Sun Oct 21 05:11:49 UTC 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.

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



More information about the NANOG mailing list