Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Snowshow spammers and "low end" server providers - Page 2
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Snowshow spammers and "low end" server providers

2

Comments

  • Why not use some reliable RBL lists so you avoid these black listed IP

    I'm running an SMTP package called "Post.Office" made by a (now defunct) company that used to be called "Software.com". Post.office was written in 1999/ 2001 and doesn't have the ability to query RBL's. Even if it did, I'm not so sure I'd use an RBL anyways. I find that a lot if the IP's hitting me are not being listed by, say, Spamhaus. There is also many areas of the world (latin and south america, africa, russia) that are covered by /8 A-class ranges that I can block in their entirety with very few entries in my blocking list.

  • @SumGuy - why not use a spam filtering MX service then you don't have to make your MX public; the MX service will filtering all the junk out and then forward it to your mailserver.

    This way you don't have to worry about logs and you can block the whole internet with the exception of the IPs of the MX service

  • given how this is internet most if not all of his claim is more then
    likely hot air unless proven, and we will never get the truth anyways

    The only claim I'm making here is that of the various machines that hit our mail server that I block right-off-the-bat based on IP, the ones that try repeatedly, dozens or hundreds of times a day, for a few days or a week or two, are machines that can be rented from various hosting companies (including, did I mention, Amazon aws?). I'm wondering why they can't be programmed to understand various 5.x.x codes that are well established by convention and essentially are telling the remote machine to "piss off and don't bother to try again".

  • MaouniqueMaounique Host Rep, Veteran
    edited March 2015

    SumGuy said: I'm running an SMTP package called "Post.Office" made by a (now defunct) company that used to be called "Software.com". Post.office was written in 1999/ 2001 and doesn't have the ability to query RBL's.

    Let me guess, it is powered by a Pentium Pro and 16 MB EDO Ram? No wonder writing logs is a very complicated task on an ISA adaptec scsi board connected 500 MB disk.

    OMG, one day you may join us in the 21st century, until then, have fun reading logs one entry at a time.

  • @SumGuy said:
    There is also many areas of the world (latin and south america, africa, russia) that are covered by /8 A-class ranges

    Is there such a thing as an IP racist? Just kidding. This thread is going downhill anyway.

    Thanked by 1k0nsl
  • why not use a spam filtering MX service

    Because I'm blocking such a high percentage of IPv4 IP space, we get less than 10 spams per week. Many of those actually come from gmail and some from hotmail and yahoo servers (which we can't block, at least not by IP, because some of our customers and many new prospects seem to use those corn-ball web-mail services for some reason).

    MX spam filtering is essentially redirecting your domain's mail through an intermediate server that performs spam filtering and forwards non-spam to your own server. The idea of someone else having a store of our mail doesn't sit well with me, for one thing.

    Something that would be of interest, which I don't even know exists, is having a DNS server that rejects MX lookups based on the IP the lookup is coming from. That would be another way to prevent an IP with a "bad reputation" to be able to know how to reach your server because it can't get MX data in the first place.

  • @SumGuy said:
    What makes you think I need to change anything I've been doing for years?

    Your spam mitigation "approach".

    Thanked by 3jar matthewvz Infinity
  • What makes you think I need to change anything I've been doing for years?
    

    Your spam mitigation "approach".

    Please explain.

    Remember, I didn't come here to ask how to mitigate spam. I am not having a spam-problem per say. I am quite happy with how our server operates currently. I'm very happy that the vast, vast majority of direct-to-mx spambot spam killed by agressive IP blocking.

    I just want to know why so many non-spambot commercial spam senders that are rented as hosted servers don't understand certain well known 5.x.x SMTP error codes and react accordingly by not banging away at my server trying to make a connection to deliver to me what will undoubtedly be garbage. As I described in the example that I gave at the start of this thread (Query Foundary / Cloud Shard).

  • SumGuy said: don't understand certain well known 5.x.x SMTP error codes

    Because the majority of people who write these things don't care. If you are spamming then key is to just blast as much mail at as many locations as quickly as possible. Its not a courteous business, if it was they'd have real working unsubscribe links and they wouldn't send you the trash in the first place.

    Thanked by 1switsys
  • @SumGuy said:
    Because I'm blocking such a high percentage of IPv4 IP space, we get less than 10 spams per week. Many of those actually come from gmail and some from hotmail and yahoo servers (which we can't block, at least not by IP, because some of our customers and many new prospects seem to use those corn-ball web-mail services for some reason).

    Yet, you have no problem using gmail on your own contact page?

  • jarjar Patron Provider, Top Host, Veteran

    SumGuy said: Remember, I didn't come here to ask how to mitigate spam

    It seems like you came here to file an abuse report for CloudShards. That kind of confuses all of us, so you'll have to forgive us for being unclear on your reason for being here. In our minds, this is not a reason to post here at all. We would all agree, I'm confident, that such a report should be e-mailed to CloudShards.

  • Yet, you have no problem using gmail on your own contact page?

    As I will explain once more, we set up a gmail account, with automatic forwarding to a local account @ our domain, for new contacts that our server happens to be blocking. That is a different phenomena or "use-case" than receiving spam from other, unrelated gmail accounts (accounts that might have been hacked, or accounts that have been created to perform a spam campaign until the account is shit-canned by google).

    We chose to create this "backup" email contact method using a gmail account because (a) gmail is free, (b) gmail is good at spam-blocking , and (c) the ability to forward email to us and hence we don't have to log in periodically to check.

    And this backup email contact address is listed as such on our web page. We make it clear that we'd rather people use our own email addresses first, and use the gmail address if they get non-delivery or other errors when sending to our regular address.

  • Dude, blocking connections by IP is just not a sustainable practice as many have said before. IPs get reassigned, moved around, cleaned up, etc, and your static blacklist probably never gets updated. I'm sure you have /16 ranges that have been blocked since 2002 that have been reassigned to different companies 5 times since. Regardless of how little spam you get with your currently system, I'm sure you're rejecting far more legit email than you are letting spam through. Your system also seems to require far more work on your part than it should.

    I know this system has been working for you since the 90s, but things change and you need to change with them. Instead you should really reject mail based on content rather than IP alone. Sure, use IP reputation as part of a score using DNSBLs, but don't reject solely on IP.

    I've also been running email servers since 2000 for my company and you can reject email far more accurately by using a score system like spamassassin that uses DNSBLs and other things combined. I used to keep my own blacklist too, it was just a maintenance nightmare. In addition to using spamassassin I use a milter called MimeDefang which gives you programmatic access (in perl) to every step of the SMTP process. So you can reject anyone not conforming to RFC standards for things like bogus HELO names, mismatching reverse DNS, or anything else you want. But you can do things things using a 15 year old software package that isn't being updated anymore.

    Thanked by 1jar
  • @SumGuy said:
    Please explain.

    Jar already did a pretty good job of that. MarkTurner had an excellent suggestion.

    I do get your frustrations, and sorry if this sounds rude, but you've been operating a mail server since 1999 and you don't know why spammers incessantly hammer mail servers? It's rather obvious. I mean . . .

    @SumGuy said: You would not believe the number of rent-a-server operations that ignore spam and abuse reports.

    Yes, we would. Spam is not some new thing the Internet is just waking up to.

    At the end of the day, you're posting about a well known problem that every public SMTP server deals with - which has well known solutions not involving a large hammer.

    Just remember, spammers don't care.

    Thanked by 2jar Infinity
  • SumGuy said: You would not believe the number of rent-a-server operations that ignore spam and abuse reports.

    You wouldn't believe the amount of know-it-all mail admins with their red staplers who fire off angry emails to abuse departments with a bunch of tl;dr mixed in with legal threats

    Thanked by 3jar deadbeef timnboys
  • SumGuy said: Do any of you people read / participate in the usenet newsgroup news.admin.net-abuse.email?

    Not really but I've got this 8 track player I want to sell. Can you help me sell it on there?

    Thanked by 2jar deadbeef
  • edited March 2015

    I bet this guy's mail server is also a open relay and has contributed to someone's spam campaign. But bitching about spam is like complaining that your shit stinks. It always going to stink!

  • Dude, blocking connections by IP is just not a sustainable
    practice as many have said before. IPs get reassigned, moved
    around, cleaned up, etc, and your static blacklist probably
    never gets updated. I'm sure you have /16 ranges that have been
    blocked since 2002 that have been reassigned to different
    companies 5 times since.

    Ok, so more explanation is in order here.

    Prior to, say, 2005 or 2006, if a spam came in from 1.2.3.4, I would automatically add 1.2.3.0/24 to my server's blocking list.

    In 2006 we changed ISP's and I noticed a dramatic reduction in spam immediately. After a few weeks I realized that I hadn't set up a new MX record, so essentially we had no mx record. Thing is - "real" mail servers know to fall back to the A record if MX lookup fails, and that's what was happening because we were still getting incoming mail from legit sources. But back at that time, your typical "zombie" spambot was running a stripped-down version of an SMTP server with minimal functionality - and they didn't know how to deal with mx-lookup failure.

    So after a year or so the spam began to roll in, and I updated our dns records (including mx). But I began to enter larger IP ranges in response to incoming spam. And one thing I did was to get country-specific lists of CIDR's and go through the entire world and assemble a huge list (probably 8000 entries) of IP's located in countries where I had no expectations of legit commercial contact.

    So that list has functioned pretty well, but I wanted zero spam so starting about 2 years ago the smallest new entry to the list was a /16 (so I'm blocking 65,536 addresses with a single entry, based on a single incoming spam). I would first check if we'd ever received a legit mail from that /16 before, at any time going back to 1999.

    Starting about a year ago, not only would I add a single /16 entry, but for good measure I'd add about a dozen /16 entries on either side. Again I'd be checking to make sure I wasn't blocking any good IP's, and I'd carve a hole around them (my server doesn't do white-listing, just black listing).

    About 8 months ago I got really agressive and scanned the log history for various /8 IP ranges - with the intent of blocking whole /8's for which we've never received legit mail.

    For example, the first EVER SMTP contact from 100.0.0.0/8 happened on Feb 25/2014. Maybe 5 other spams (and an open-relay attempt) had come in from that /8 up until January 15 this year - at which point I had a closer look at our history with 100.0.0.0/8 and, seeing how sparse it was - I shit-canned the entire /8. I've seen the same pattern (no contact from entire /8's until very recently) and have shit-canned them (such as 180/8, 106/8, 136/8). At this point I'm blocking about 70 /8's and still have thousands of smaller blocks (CIDR's) that end up blocking over 90% of other /8's.

    Regardless of how little spam you get with your currently system,
    I'm sure you're rejecting far more legit email than you are letting
    spam through.

    I've already explained that (a) we sell a niche product (the only one in the world selling this particular product) and (b) anyone that is a legit prospect for our product will not let a single email rejection get in the way of pursuing a purchase, especially given several alternative contact methods plainly visible on our website.

  • jarjar Patron Provider, Top Host, Veteran
    edited March 2015

    Thing is - "real" mail servers know to fall back to the A record if MX lookup fails

    Are you sure about that?. Which RFC was that? Maybe in 1995, I don't know. Gmail, for example, I would call a "real" mail server and it certainly does no such thing. Neither does any configuration of postfix or exim that I've ever seen. Granted I've not been working with mail as long as you have, so I don't know much about what was true 10 years ago.

    It seems like you really don't want customers. Your market is definitely up for grabs. Sounds profitable too. I wouldn't reveal too much about it. May want to get rid of your website too so no one gets any ideas. You're one alternative solution, from someone who actually wants customers, away from being out of business.

  • joepie91joepie91 Member, Patron Provider

    SumGuy said: Something that would be of interest, which I don't even know exists, is having a DNS server that rejects MX lookups based on the IP the lookup is coming from. That would be another way to prevent an IP with a "bad reputation" to be able to know how to reach your server because it can't get MX data in the first place.

    Friendly tip: you may want to read up on how DNS actually works, because that suggestion you just made is utter nonsense.

  • Jar said: It seems like you really don't want customers.

    Maybe he's the father of the guy with the hosting company who goes out of town / vacation like every 6 weeks and the subject of regular posts about it

    Thanked by 3jar timnboys MSPNick
  • jarjar Patron Provider, Top Host, Veteran
    edited March 2015

    I apologize for coming across harsh @SumGuy. I saw an opportunity to vent about a lot of administrators who make my life more difficult than it needs to be as a mail admin. If you ever decide to use current packages for running your mail server and you want any help fighting spam in the way that best addresses today's climate, you're welcome to any of my configurations. While I run a paid service, nothing I do is secret and I'm happy to share. I don't get a lot of spam, and I certainly don't let spammers run rampant on my network. They meet a quick, harsh fate. That's obviously why it upsets me when I'm blocked because I needed DDOS protection from OVH and I work so hard to maintain a positive mail reputation.

    Despite all my work and not blocking IP addresses, all of my logs take up 20MB. Not that big of a deal. It sounds like you could use logrotate:

    http://linuxcommand.org/man_pages/logrotate8.html

  • perennateperennate Member, Host Rep
    edited March 2015

    Jar said: Are you sure about that?. Which RFC was that? Maybe in 1995, I don't know. Gmail, for example, I would call a "real" mail server and it certainly does no such thing. Neither does any configuration of postfix or exim that I've ever seen. Granted I've not been working with mail as long as you have, so I don't know much about what was true 10 years ago.

    From https://tools.ietf.org/html/rfc974

    It is possible that the list of MXs in the response to the query will
    be empty. This is a special case. If the list is empty, mailers
    should treat it as if it contained one RR, an MX RR with a preference
    value of 0, and a host name of REMOTE. (I.e., REMOTE is its only
    MX). In addition, the mailer should do no further processing on the
    list, but should attempt to deliver the message to REMOTE. The idea
    here is that if a domain fails to advertise any information about a
    particular name we will give it the benefit of the doubt and attempt
    delivery.

    I'll go test it now, but I'm pretty sure Gmail does this just like any other mail server?

    Edit: confirmed, sent an IP to my hostname assigned by ISP (like XYZ.ABC.verizon.com) from Gmail and it went to my computer (despite no MX records for that hostname).

    Edit2: here is corresponding excerpt from the RFC5321 (2008) that Snape mentioned below:

    If an empty list of MXs is returned,
    the address is treated as if it was associated with an implicit MX
    RR, with a preference of 0, pointing to that host. If MX records are
    present, but none of them are usable, or the implicit MX is unusable,
    this situation MUST be reported as an error.

    Thanked by 2jar switsys
  • SnapeSnape Member

    @Jar said:
    Are you sure about that?. Which RFC was that? Maybe in 1995, I don't know.

    RFC5321, actually. :) And it's still current, though support for it is spotty at best. Intending to rely on strict compliance with it is foolish, for a couple of reasons.

    I'd like to point out that the OP's mailserver, "post.office", is now owned by tenon.com, who don't appear to have updated it since 2003. It doesn't appear to support SSL or TLS, but does include a built-in finger server, lol. From its age I'd be surprised if it didn't have issues running on a modern libc, like unpatched qmail. Regardless of its insecurity and antiquity, if the OP had even the slightest clue what he was doing, putting a SMTP proxy in front of it would be a trivial task and provide all kinds of 21st-century antispam filtering.

    Thanked by 1jar
  • Seriously? Are you for real?

  • jarjar Patron Provider, Top Host, Veteran
    edited March 2015

    @perennate said: confirmed, sent an IP to my hostname assigned by ISP (like XYZ.ABC.verizon.com) from Gmail and it went to my computer (despite no MX records for that hostname).

    Learn something new every day I suppose. I swear I've seen gmail refuse delivery due to no MX in the past, so I'm confused, but oh well. I'm clearly wrong. I know I definitely don't do this :)

  • 4n0nx4n0nx Member

    SumGuy said: I don't need to see hundreds and thousands of SMTP connect-reject entries in my log files from IP's belonging to rent-a-server outfits like OHV, Rapidswitch, KVC, Query Foundary, etc.

    And SSH/HTTP connections from bots don't bother you? lel

    If you used software that was not last patched 14 years ago and maybe put a contact form on your website.. tadaa all problems solved.

  • SnapeSnape Member

    Jar, some/many servers (and it may be that Google is/was one) will still refuse to deliver if there's no actual A record for the hostname, like where there's only a CNAME, for instance. (Like someone who tries to redirect domain.tld to www.domain.tld via a CNAME, sigh.)

  • AnthonySmithAnthonySmith Member, Patron Provider

    @SumGuy you are clearly out of your depth, you don't know what your doing you just do a good impression to the people that pay you I suppose.

    The problem with trying to explain to stupid people that they are stupid is that they are often too stupid to realize they are stupid to begin with making continuing this line of conversation.... stupid.

This discussion has been closed.