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
