Misguided SPAM Filtering techniques

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

Primarily, I have run up against this in the following networks:

  SPRINT Cellular network (can no longer send email from my phone)
  Public wireless networks
  Hotel networks
  Other WiFi hotspots
  Some DSL providers networks

I can't imagine that these tactics actually do anything to significantly reduce
the amount of spam delivered to the internet, so, I'm curious as to:

  1. Why are they used?
  2. How do we convince operators to abandon them?
  3. How prevalent is this problem, and, is it growing as I perceive?

Owen

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.

Or peoples' machines are now being infected by malware which
checks for login credentials or uses the existing mail client
via various inter-process communication techniques; re-using said
login credentials to talk to authenticated SMTP servers.

Gotta get a clue; its not enough to just authenticate who sent
the email anymore..

Adrian

If you force people to use your MSAs, the malware will get those details, too.

With that in mind, the only semi-reasonable solution I can see is limiting the number of new connections/min heading out to these ports. If your hardware can DNAT and/or filter based on L4 info (port), then it can probably limit the number of packets to a certain port with the SYN flag set.

Here's one that recenly annoyed me. I actually got into an argument
over it which was a secondary annoyance - that I lost my temper.

There is a service out there, spamarrest.com but there is probably more
than one, that you can sign up for and have all your email filtered
through. If something comes that is not whitelisted then email is sent
back asking you to confirm that it is not spam. I received one of these
confirmation requests for a piece of spam that I did not send out. I
complained to them that this was not being a good neighbour. While I
sympathize with their spam problem I did not appreciate that they
turned it into my problem. I deal with my own spam without resorting to
making the rest of the net act as my personal filter.

This person actually got abusive. He couldn't understand why I would
complain about his attempts to reduce spam. I could not make him see
that he was just adding to the overall problem.

Of course, I fixed the issue for myself by simply blocking
spamarrest.com. I have no need to correspond with anyone who thinks
that their spam problem needs to be my spam problem.

If something comes that is not whitelisted then email is sent
back asking you to confirm that it is not spam. I received one of these
confirmation requests for a piece of spam that I did not send out.

Whenever I get one of those, I go ahead and confirm the message so the spam
gets through to the end user. I figure if they think I'm gonna filter their
mail for free, well, they get what they pay for. :^)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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?

It's not just mail. These days the mantra seems to be "only allow port
80 and 443 through, the users don't need anything else." specially in
situations you cite (public wifi, hotel nets etc.). In these cases, i
believe even ssh won't go through. Default settings in some devices
don't help either.

I remember that until a few years ago, port 443 traffic was getting
blocked, but enough stuffs stopped working, that 443 is now allowed
everywhere. Personally, have been lucky using smtp+ssl on port 465.
Doesn't work 100%, but works most of the time.

thanks
- gaurab

Welcome to the read-only Internet. If you need anything else, SSL-VPN
back to your personal colo <http://www.vix.com/personalcolo/>

Heh. Never eve thought of that. That sounds like enough fun that I
may even turn off the blocker. :slight_smile:

D'Arcy,

Do you publish SPF records so that remote sites can detect forgeries
claiming to be from your domain?

If so, shame on them. Enough is known about the forgery problem at
this point that there's little excuse for autoresponse to a detectably
forged message.

If not, shame on you. You do realize that section 3.7 of RFC 2821
requires their server to notify the sender if they can't deliver the
message, right? Find the paragraph that starts, "If an SMTP server
has..." Just because a lot of spam filters break the RFC and just drop
the message on the floor doesn't mean its the proper thing to do.

Like the fence around your backyard swimming pool, you should have an
SPF record for your domain. Otherwise it may become an attractive
nuisance. That would be your fault.

Regards,
Bill Herrin

In other words "Do you play russian roulette with your email"?

John Levine's got something really good on this at
http://www.circleid.com/posts/spf_loses_mindshare/

-srs

My take on it matches that of some of the commenters there...until
DKIM is used far and wide, and everybody catches up to using it, SPF
and Sender ID serve a useful purpose, and I would personally recommend
implementation for anyone sending email for any purpose.

Yes, it breaks forwarding.

Regards,
Al Iverson

[ "Subject:" line corrected, noting that "SPAM" is a trademark
of Hormel and "spam" is the slang term for unsolicited bulk email. ]

Of course, I fixed the issue for myself by simply blocking
spamarrest.com. I have no need to correspond with anyone who thinks
that their spam problem needs to be my spam problem.

Unfortunately, they're not alone. Any number of carpetbagging
"anti-spam" companies have materialized, eager to exploit the
Internet's collective misery for profit, and willing to engage
in wholesale abuse in order to do so. The most common form of
observed abuse is C/R, but I've also noted outscatter-by-design,
callbacks, and outright spamming. The local blacklist of such
entities follows below.

As to the snake-oil known as SPF (mentioned elsewhere in this thread),
it, like DomainKeys and SenderID, reflects confusion vis a vis the spam
problem vs. the forgery problem. Yes, they're related, but solving one
is not the same as solving the other -- and at present, the forgery
problem is completely unsolvable. (...because any of the 10e8 or so
fully-0wned systems out there that can emit apparently-unforged email
using any credentials that happen to be present on them...) Efforts
should instead be focused on solving the outscatter problem, because
doing so helps minimize the impact of the forgery problem.

---Rsk

19948courses.org
barracudanetworks.com
bluesecurity.com
bongosoft.com
boxbe.com
c-programmer.com
collactive.com
cruelmail.com
ctyme.com
emailaccount.com
emailaccount.net
emailaccounts.com
emailsanitizer.com
emailservice.com
gennux.ca
gennux.com
hendricom.com
hydra.net
ihatespam.net
junkemailfilter.com
junkemailfilter.net
junkemailfilter.org
limitspam.com
mail-block.com
mailblocks.com
mailfrontier.com
mailfrontier.net
mindtechuniversity.org
netwinsite.com
onlymyemail.com
rhinosoft.com
spamarrest.com
spamfighter.com
spamsnag.com
spamstrike.net
ssdcorp.net
sunbelt-software.com
sunbelt-university.com
sunbeltsoftware.com
totalblock.net
vanquish.com
w2knews.com
winxpnews.com
wservernews.com
wxpnews.com
zaep.com

Dave Pooser wrote:

Whenever I get one of those, I go ahead and confirm the message so the spam
gets through to the end user. I figure if they think I'm gonna filter their
mail for free, well, they get what they pay for. :^)

And that is probably just fine, as 99% of the true spam comes from email addresses (and often doamins) that either do not exist, or often are not configured to receive email. The result is that 99% of the spam filtered by spamarrest (or other challenge-response techniques) is never actually seen by any human. If you didn't send the the email, why bother confirming it? Aren't you also adding back to the problem?

Even if you confirm your email address, that's all that spamarrest is asking for. If the email address is valid, then it's done it's job. If the email address is not valid, then the spam gets stopped.

I use a challenge-response system in conjunction with other techniques, and have reduced the amount of spam I have to deal with by a couple orders of magnitude.

I also advise the list membership here that if they DON'T want to get the challenge from my agent, they should send responses through the list.

As fas as the original poster... When I was working for a particular MSO the topic came up for filtering port 25. It took me about a minute to convince them that it was a bad idea, as a lot of people with broadband are the work-fro-home type, and not all of them VPN into their work, but instead use their corporate SMTP/POP/IMAP server to do their business. Since handling these valid servers on a ticket basis would prove to be too much work, the plan was scrapped.

  -Sean

(Please respond only to the list.)

Dave Pooser wrote:

Whenever I get one of those, I go ahead and confirm the message so the spam
gets through to the end user. I figure if they think I'm gonna filter their
mail for free, well, they get what they pay for. :^)

And that is probably just fine, as 99% of the true spam comes from email addresses (and often doamins) that either do not exist, or often are not configured to receive email. The result is that 99% of the spam filtered by spamarrest (or other challenge-response techniques) is never actually seen by any human. If you didn't send the the email, why bother confirming it? Aren't you also adding back to the problem?

Where did you get that 99% #?

Even if you confirm your email address, that's all that spamarrest is asking for. If the email address is valid, then it's done it's job. If the email address is not valid, then the spam gets stopped.

That is neither the statement that most CR systems make in their challenge, nor what most people who use the system think it means.

I use a challenge-response system in conjunction with other techniques, and have reduced the amount of spam I have to deal with by a couple orders of magnitude.

I'm sure you have. I'm also certain you have put a burden on other people, which is the reason we all hate spam

I also advise the list membership here that if they DON'T want to get the challenge from my agent, they should send responses through the list.

That would be me. :slight_smile:

As fas as the original poster... When I was working for a particular MSO the topic came up for filtering port 25. It took me about a minute to convince them that it was a bad idea, as a lot of people with broadband are the work-fro-home type, and not all of them VPN into their work, but instead use their corporate SMTP/POP/IMAP server to do their business. Since handling these valid servers on a ticket basis would prove to be too much work, the plan was scrapped.

I'm not at all certain I agree with your reasoning. If someone wants to send e-mail from home, they can use 587, or your server, or VPN, or .....

I am assuming you also do not list your IP addresses in the PBL? So the "99%" of your users who do _not_ need to work from home, but are infected, are allowed to spew spam at me?

Cite?

I log only valid domains used as the PRA or MFROM in the spam I
receive, about 10k/day. Counting valid domains only, each domain is
only seen on about three different spams, when averaged out. That's a
hell of a lot of domains that actually exist, and I think a more
accurate assumption is that a significant nonzero amount of that
backscatter does actually reach a recipient mailbox on the other end.

Regards,
Al Iverson

It would be interesting to know how your numbers get changed if you look
for stuff sent with "domain tasting" domains. Sure, it was a valid domain -
for all of 48 hours before it got returned because it was starting to
"taste bad"....

And that is probably just fine, as 99% of the true spam comes from email
addresses (and often doamins) that either do not exist, or often are not
configured to receive email.

I call BS. I ran sender-callout verification on my primary email server for
a while (before I became convinced it was mildly abusive, and stopped) and
typically blocked 2-3 spams per day. In fact, I had more FPs than legit spam
blocked by that method.

If you didn't send the the email, why bother confirming it?
Aren't you also adding back to the problem?

Absolutely I am. If you're going to try to offload your spam filtering to
me, I want the process to cause you as much pain as possible (within ethical
limits, which is why I won't forward your email

Even if you confirm your email address, that's all that spamarrest is asking
for. If the email address is valid, then it's done its job.

Sender callouts will verify addresses without requiring any action from the
end user. If you must [ab]use my resources to do your job, please have the
common decency to use my (abundant) hardware and software resources rather
than my (much more limited) wetware resources.

Note that this has been superseded by RFC 4409. More recommendations about
the operational and policy issues are laid out in
http://www.ietf.org/internet-drafts/draft-hutzler-spamops-08.txt which
will soon be published as RFC 5068. Sadly it doesn't say much about the
rationale for its recommendations, especially why it's not OK to block 587
even when it might be OK to block 25, because talk of port blocks rapidly
descends into flame wars. However it's fairly clear if you think about who
suffers from spam sent via port 587.

The key point is that the operators of an MSA has a strong incentive to
keep their users clean, or at least their mail flows clean, because any
spam sent via their MSA will (typically) go out of the same relays whether
the client is on site or roaming or using the webmail service. Therefore
reputation problems (AOL spam complaints, blacklistings, etc.) will accrue
where it hurts. The situation is very different for port 25 email, becase
the target MTA has no control over the senders. Access providers don't
care about their access networks having bad spam reputations because the
pain doesn't affect them directly enough.

Tony.

Patrick W. Gilmore wrote:

Where did you get that 99% #?

Statistics from my own mail server. Yours may vary. In the course of 6 months, on one honey-pot email address, I received about 10,000 spam messages that were classified as from forged addresses by spam assassin. I'm sure you are familiar with these, they are like aslkuews@hotmail.com, lkjjyes@yahoo.com, etc. I also received about 200 other messages that spam assassin classified as spam for overall score. My statistic is a little off. 98% of them were forged addresses. Not all of that remaining 2% had a valid address, most of them were either from domains that did not receive email, or addresses that did not exist.

I have my c/r system setup on this account to discard the forged hotmail accounts, as well as the email that was otherwise classified as spam. The rest I handle manually until I find a conclusive pattern.

That is neither the statement that most CR systems make in their challenge, nor what most people who use the system think it means.

The problem is that C/R systems is not the only means to stop spam or viruses, or other junk. As you said, it only validates email addresses. If they are valid, and confirmed as such, the email gets through. Anyone that sees it as otherwise is mislead.

I'm sure you have. I'm also certain you have put a burden on other people, which is the reason we all hate spam

So, I burden a VERY small number of people over the course of 6 months, since 99% of the forged addresses are dropped at the server, and a challenge is never sent. I understand that my setup is unique, and that commercial c/r systems likely don't discard anything.

And, is it really a burden if you SEND me an email to validate yourself? If it IS such a burden, then I invite you not to send email to start with, especially not to me.

I'm not at all certain I agree with your reasoning. If someone wants to send e-mail from home, they can use 587, or your server, or VPN, or .....

Yeah, and since the ISP only accepts email from their customers with a valid login from their IP addresses, when their customer takes their laptop elsewhere they can't send email. Most are not going to know to change their SMTP server, and many more aren't going to have a valid SMTP server which to send email through when they are traveling.

And your your comment of VPN or port 587... Those are not always options either.

I am assuming you also do not list your IP addresses in the PBL? So the "99%" of your users who do _not_ need to work from home, but are infected, are allowed to spew spam at me?

If the user is infected, they are infected. Not much that can be done about that. Fortunately, most infected PCs do not bother to send email through the user's SMTP server. As long as the user connects to the SMTP server, starts TLS and authenticates themselves, that's all that I require. This is on my personal email server, which serves only a handful of trusted users. I can't speak to my current company's external email server. The Internal one requires a VPN, but also runs Microsoft software, so it's highly suspect.

  -Sean

(Please respond only through the list)