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
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
On Sun, Oct 21, 2007, Nathan Ward wrote:
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.
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
On 21/10/2007, at 7:22 PM, Adrian Chadd wrote:
On Sun, Oct 21, 2007, Nathan Ward wrote:
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.
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.
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. -- Nathan Ward
On Sun, 21 Oct 2007, Nathan Ward wrote:
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. -- f.a.n.finch <dot@dotat.at> http://dotat.at/ SOUTHEAST ICELAND: NORTHERLY 5 AT FIRST IN EAST, OTHERWISE SOUTHEASTERLY 4 OR 5 INCREASING 6 OR 7. MODERATE OR ROUGH. RAIN LATER. GOOD, OCCASIONALLY MODERATE LATER.
On Sat, 20 Oct 2007 13:12:14 -0700 Owen DeLong <owen@delong.com> 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.
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. -- D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
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. :^) -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com
On Sun, 21 Oct 2007 09:37:54 -0500 Dave Pooser <dave.nanog@alfordmedia.com> wrote:
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. :^)
Heh. Never eve thought of that. That sounds like enough fun that I may even turn off the blocker. :-) -- D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
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.)
On Oct 22, 2007, at 11:41 AM, Sean Figgins wrote:
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. :)
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? -- TTFN, patrick
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)
On Mon, 22 Oct 2007 16:13:52 MDT, Sean Figgins said:
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.
That would be all fine and good - if I was being asked to validate mail that I actually sent to you. I've seen very few true positives for this, compared to two *large* classes of false positives: 1) I'm being asked to verify my address because some malware found my address on a hard drive and stuck it in the From: field. I'm sorry, but if you're asking me to verify that, it *is* a burden - you are admittedly *starting off* assuming that it's bad and *needs* some sort of verification. So by definition, you're imposing on people to validate that they're real. 2) The rest of the time, I'm being asked to verify myself because I posted to a mailing list, and some idiot failed to whitelist the list address. Homework question: Does this method scale? What would happen to your inbox if *everybody* on this list did this sort of thing? (Bonus points for figuring out what happens when two people who *both* use this scheme try to exchange email. Hint - my system didn't recognize your C/R format, and concluded it was an e-mail addressed to me. What happens next?)
(Please respond only through the list)
This is NANOG. If you wish to hijack the semantics of my REPLY button, feel free to actually include a Reply-To: field that expresses the semantics that you desire.
Valdis.Kletnieks@vt.edu wrote:
1) I'm being asked to verify my address because some malware found my address on a hard drive and stuck it in the From: field. I'm sorry, but if you're asking me to verify that, it *is* a burden - you are admittedly *starting off* assuming that it's bad and *needs* some sort of verification. So by definition, you're imposing on people to validate that they're real.
Why would you care to validate your email address then? If you didn't send the email, and was not expecting an email from me, then why would you even bother to read, let alone validate?
2) The rest of the time, I'm being asked to verify myself because I posted to a mailing list, and some idiot failed to whitelist the list address.
Yes, except for two things: First YOU should not get a challenge to and email that was sent by you through the list. If you are, then this is just inexcusable on the part of the software developer or admin. Second, you should only get a challenge if you "reply to all" and send a copy of the same email to someone directly.
Homework question: Does this method scale? What would happen to your inbox if *everybody* on this list did this sort of thing?
Absolutely nothing, assuming that the the list members have a clue on how the software works and should be configured. If they don't white list the mailing list, then they are idiots that have no excuse, and quite frankly will be unsubscribed from the list due to excessive bounces. And if people followed good protocol and trimmed their headers, then there really is no good reason why anyone would get a challenge to an email that they sent to the list. And as it is, if everyone had a c/r system, I imagine that everyone would get either white listed or validated here pretty quickly.
(Bonus points for figuring out what happens when two people who *both* use this scheme try to exchange email. Hint - my system didn't recognize your C/R format, and concluded it was an e-mail addressed to me. What happens next?)
Most of this type of software is specifically designed to catch loops, and as thus will stop them. When companies send me an email from an address that has an autoresponder behind it, I usually only get one or two emails before the software stops it.
This is NANOG. If you wish to hijack the semantics of my REPLY button, feel free to actually include a Reply-To: field that expresses the semantics that you desire.
Why should I do such a thing when it is only common (uncommon?) sense to actually do such a thing? How highly that people must think of themselves to send the same email to people multiple times. And I only put that disclaimer in there so people don't whine about the autoresponder. Considering the group here, I'm sure that many of them actually have their mail reader set to ignore the reply-to field. These are the same that will whine about the autoresponder if I didn't let them know ahead of time. -Sean (Please respond only to the list.) Actually it looks like we're being directed to stop, so no response needed, unless you want to take it off line.
On 10/22/07, Sean Figgins <sean@labrats.us> wrote:
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.
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 -- Al Iverson on Spam and Deliverability, see http://www.spamresource.com News, stats, info, and commentary on blacklists: http://www.dnsbl.com My personal website: http://www.aliverson.com -- Chicago, IL, USA Remove "lists" from my email address to reach me faster and directly.
On Mon, 22 Oct 2007 11:30:27 CDT, Al Iverson said:
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.
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. -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com
Dave Pooser wrote:
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.
2-3 spams a day? That's really an amazing low number. You can call BS all you want. I'll stick to my numbers as they are what my reports were telling me. Is it possible that the email address in question was listed somewhere on the list that viruses used to send forged email more than other spammers? That's completely possible. Still, my results are what I observed when I went looking at the statistics over a 6 month period. I was actually looking for other statistics, the reduction in overall spam levels after implementing gray listing, which was the next 6 month's statistics.
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
It's OK, really, as I;m sure that your email address is only used once or twice total, so your validation of the email address really means nothing to the recipient. They get one spam message. If they get more, they just blacklist the address. It's what I do.
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.
You have more information on this? I'd be more than happy to investigate another method myself that does not piss you off so much, as long as it provides the same level of isolating spam. -Sean (Please respond only to the list)
This is another thread that while started as mildly operational ended up as usual discussion on spam filtering, which is not on-topic. I'll make a brief summary: a) statement of original problem by Owen: Is blocking or proxying ports 25/587 appropriate for NSPs? A few responses were pointing out that everything is fair as far as port 25, but port 587 should be unmolested. In the alternative, suggestion made to use port 465 (the ssl equivalent of port 587). Some pointed out that the filtering is a trend that everything except port 80 and 443 are blocked. b) Discussion diverted very quickly to DKIM, SPF, SenderID, Challenge-Response, statistics of mail filtering, blocklists, etc. I'd like to remind everyone what is and what isn't on-topic here: Spam filtering, in general, is *not* on-topic. Spam as a threat to network operations is on-topic. Control of outbound spam our users send is on-topic to a certain point - like, the original post, whether ports 25 or 587 can be blocked or proxied. End-user discussion on spam filtering is *definitely* off-topic. Let me reiterate: If you do not have a perspective of network operator, it is not likely that you can contribute to the discussion in a meaningful way. Note, in this case, 'enterprise' mail filtering is still end user, as far as network operators are concerned. Another example: If you can see your post being a slide of a presentation at NANOG, then it is on-topic. If not, it isn't. While we can all agree that network operations must include certain amount of dealing with spam, same can be said about janitorial services. Just because we have to deal with it, doesn't mean it is on-topic here. If you would like to continue discussing state-of-art for mail filtering, there are better lists to discuss it (like MAAWG and many others). In the light of above, please constrain the discussion to the network operator's view of spam filtering. As usual, if you would like to discuss this post, please do so on nanog-futures. -alex [mlc chair]
On 10/21/07, D'Arcy J.M. Cain <darcy@druid.net> wrote:
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.
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 -- William D. Herrin herrin@dirtside.com bill@herrin.us 3005 Crane Dr. Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On 10/22/07, William Herrin <herrin-nanog@dirtside.com> wrote:
Do you publish SPF records so that remote sites can detect forgeries claiming to be from your domain?
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
On 10/22/07, Suresh Ramasubramanian <ops.lists@gmail.com> wrote:
On 10/22/07, William Herrin <herrin-nanog@dirtside.com> wrote:
Do you publish SPF records so that remote sites can detect forgeries claiming to be from your domain?
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/
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 -- Al Iverson on Spam and Deliverability, see http://www.spamresource.com News, stats, info, and commentary on blacklists: http://www.dnsbl.com My personal website: http://www.aliverson.com -- Chicago, IL, USA Remove "lists" from my email address to reach me faster and directly.
[ "Subject:" line corrected, noting that "SPAM" is a trademark of Hormel and "spam" is the slang term for unsolicited bulk email. ] On Sun, Oct 21, 2007 at 10:27:24AM -0400, D'Arcy J.M. Cain wrote:
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
-----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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHG3jiSo7fU26F3X0RAmNWAKDoxlwaivgeKGPvczL5FpgyOV8eFgCfW2iZ 0d0ZTyWFQA53mdbSNAryYHE= =VZUx -----END PGP SIGNATURE-----
On Sun, 21 Oct 2007, Gaurab Raj Upadhaya wrote:
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.
Welcome to the read-only Internet. If you need anything else, SSL-VPN back to your personal colo <http://www.vix.com/personalcolo/>
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.
Back in the day AT&T dial-up blocked port 25 outgoing (except to their own servers) for the first month; after that, a user could request an unblock. I believe the SBC/AT&T Borg does the same thing with dynamic DSL IPs. It seems to me that blocking port 25 by default and unblocking on request would be an ideal low-maintenance solution that would reduce spam considerably, and has the added benefit of being on-topic for NANOG. -- Dave Pooser, ACSA Manager of Information Services Alford Media http://www.alfordmedia.com
On Tue, Oct 23, 2007, Dave Pooser wrote:
It seems to me that blocking port 25 by default and unblocking on request would be an ideal low-maintenance solution that would reduce spam considerably, and has the added benefit of being on-topic for NANOG.
For those of you who run Cisco kit; you can also use WCCPv2 to redirect 25/TCP -in hardware path without policy routing- to a farm of servers. Its actually documented in the WCCPv2 specification - you can redirect arbitrary TCP/UDP ports. Think of the possibilities. (I don't think the CRS does WCCP :P but it'll be in hardware path on 6500/7600 on anything >= SUP2/PFC2; 3560/3750/4500/4948; It'll also be in CEF path IIRC on software platforms.) I've done this in my lab at home and it works fine. Whats missing is some glue to handle transparently routed connections once they hit your SMTP farm; I'm quite happy to help people out if anyone is interested (and I'll even put the results in the nanog wiki if people care.) 2c, Adrian
On Oct 23, 2007, at 1:28 AM, Adrian Chadd wrote:
On Tue, Oct 23, 2007, Dave Pooser wrote:
It seems to me that blocking port 25 by default and unblocking on request would be an ideal low-maintenance solution that would reduce spam considerably, and has the added benefit of being on-topic for NANOG.
For those of you who run Cisco kit; you can also use WCCPv2 to redirect 25/TCP -in hardware path without policy routing- to a farm of servers. Its actually documented in the WCCPv2 specification - you can redirect arbitrary TCP/UDP ports. Think of the possibilities. (I don't think the CRS does WCCP :P but it'll be in hardware path on 6500/7600 on anything >= SUP2/PFC2; 3560/3750/4500/4948; It'll also be in CEF path IIRC on software platforms.)
This behavior is exactly the kind of irritating misguided action which launched my initial complaint. The problem is that your server farm won't match my expectations for STARTTLS, which then prevents me from engaging SMTPAUTH and sending my mail. My mail severs aren't open relays, but, I am able to send email through them from any non-broken internet connection. The issue is the increasingly high percentage of internet connections which are becoming broken. So far, the only "justification" for this behavior posted is the inability of the folks in Redmond to deliver non-broken software such that a large enough fraction of portable machines are able to "credential hijack" from stored credentials on the machine and impersonate the operator while botted. I really wish we could find a way to punish the folks in Redmond and the people whose hosts are botted instead of punishing everyone else for their errors. Owen
Owen DeLong wrote:
The issue is the increasingly high percentage of internet connections which are becoming broken. So far, the only "justification" for this behavior posted is the inability of the folks in Redmond to deliver non-broken software such that a large enough fraction of portable machines are able to "credential hijack" from stored credentials on the machine and impersonate the operator while botted.
I really don't get it. While I understand with tcp/25 blocking, there is absolutely no reason to block tcp/587. If credential's are being hijacked, it is the responsiblity of the MSA server to close the door. There's nothing to say those credentials weren't blasted to an irc server or a web script somewhere and the actual usage of them will be from some other random location on the net. Jack Bates
participants (17)
-
Adrian Chadd -
Al Iverson -
Alex Pilosov -
D'Arcy J.M. Cain -
Dave Pooser -
Gaurab Raj Upadhaya -
Jack Bates -
Nathan Ward -
Owen DeLong -
Patrick W. Gilmore -
Rich Kulawiec -
Sean Donelan -
Sean Figgins -
Suresh Ramasubramanian -
Tony Finch -
Valdis.Kletnieks＠vt.edu -
William Herrin