Slashdot Mirror
Kelihos Botnet Comes Back To Life
angry tapir writes "A botnet that was crippled by Microsoft and Kaspersky Lab last September is spamming once again and experts have no recourse to stop it. The Kelihos botnet only infected 45,000 or so computers but managed to send out nearly 4 billion spam messages a day, promoting, among other things, pornography, illegal pharmaceuticals and stock scams. But it was temporarily corralled last September after researchers used various technical means to get the 45,000 or so infected computers to communicate with a "sinkhole," or a computer they controlled."
Researchers knew that it would only be a matter of time before its controller used the botnet's complex infrastructure of proxy servers and communication nodes to regain control.
The linked story says they fully expected this, and that the method they used (sink-holing) was never expected to be a permanent solution. One has only to hope that stating they have no "recourse" is merely baffle-gab to embolden the controllers. It might also mean "lets make believe we haven't compromised some of the bots and planted a few or our own".
They also suggest that the suspected Russian controller couldn't be extradited, but conveniently neglect to mention that Kaspersky Lab is a Russian company that could influence internal Russian enforcement actions.
Kaspersky Lab Expert Maria Garnaeva Posts in her Blog some of the difference between the new and old control mechanisms: http://www.securelist.com/en/blog/655/Kelihos_Hlux_botnet_returns_with_new_techniques
She also mentions it is not as bleak as the original article, because:
It is still possible to neutralize the botnet with sinkholing but using slightly different techniques as was used before, and it is still possible to push an update tool on infected machines to neutralize the botnet. In this case the botmasters need to infect machines again to build another botnet.
Sig Battery depleted. Reverting to safe mode.
The common answer is no. When they roll up a botnet they usually pick up the suspects which have been using this botnet, but all the peers are usally (if not most often) left alone.
Not surprising considering the kind of peers, but doesn't that aspect alone make scenario's like these plain out obvous? Its only a matter of time before another "botmaster" picks up where the previous owner was cut off.
so clearly, all we need to do is find the head and shoot it.
I assume that the zombie-workstations send out e-mail via SMTP. Why not require real mail servers to comply with DNS to have an MX record for the domain or IP, and to then have SMTP servers for a given network or internet service provider throttle the number of e-mail per unit of time and to limit the number of recipients to human real-world numbers?
That would prevent a non-MX mail server from being able to send mail since other mail servers would reject it based on DNS, and would prevent zombie botnets from using the SMTP servers of the service provider that the computer is connected to in order to spam through.
It wouldn't eliminate spam, but it might serve well to reduce it significantly. Yes, it would require some more programming in the SMTP daemon, but it shouldn't jack with the protocol.
Do not look into laser with remaining eye.
What I don't get in the whole spam saga - and I've been following it for 15 years now - is why it is possible for law enforcement to cooperate internationally and do joint raids in several countries when it comes to fake products, unauthorized DVD presses or computer games piracy groups - but not when it comes to spam.
Ask Spamhaus - we know most of the top offenders. We know who they are and in many cases we know where they live. And law enforcement is sitting on their hands.
Because it is a small damage on many people - an attack on the commons, not on one particular company or individual. We as humans assess damages instinctively, not mathematically. And that leads to crazy results. We consider someone stealing $50k from a bank a serious criminal, but someone stealing $0.01 from 50 mio. people is a nuissance - even though the actual damage is 10 times higher.
Sadly, that's a trend not only with spam. When Mommy Jane illegally downloads a Disney movie, she is fined ridiculous amounts of money. When Disney corrupts the law to steal from the public domain by retroactively taking content back under copyright, or extending it so it enters it later (if ever), it is hard to even explain to people why that's bad.
We have lost the concept of the commons, and that is the real tragedy of the commons, not the bullshit neo-liberal bedtime story by the same name.
Assorted stuff I do sometimes: Lemuria.org
because MX implies location for reception, not necessarily for sending. get any kind of serious mail volume and you'll very quickly decide to separate your outbound SMTP from your inbound SMTP.
The problem is eMail and its technical basis are seriously flawed from the very beginning. Invented in the 70s, spam and other malevolent uses of eMail were not considered as it was invented for use in a scientific setting and intended for proper scientists at universities to exchange messages. SMTP = SIMPLE mail transport protocol.
What we would need is eMail 2.0.
A seriously beefed up system, redesigned from the ground up.
Problem is : eMail 1.0 and its infrastructure of POP3/SMTP servers is so deeply embedded, you would need to update and change ALL operating systems, ALL eMail clients, ALL script engines (PHP, PERL, etc) used to send eMail from webpages, ALL eMail servers, etc. That's one heck of a challenge. Good luck.
"We could have issued an update to those machines to clean them up, but in several countries that would be illegal," said Ram Herkanaidu, security researcher and education manager for Kaspersky Lab.
Don't be a sissy! If you have the means to clean up machines infected with a botnet client without screwing it up, do it! If some pedantic rule-thumper complains about good-faith efforts to make clueless people's spamming machines stop doing that, rat them out by name to The Internet and sit back and watch a million people demand video evidence of their head being placed on a spike.
The reason these assholes can run all over us is that too few of those involved care. I am very happy that MS has started to care, and it's probably the only good thing they've done all century, but it really is a powerful signal.
The next people who need to start caring are the ISPs. Just recently I complained to my own ISP that they are hosting the actual website that the spam I get is advertising. They told me to use the "unsubscribe" link. Yeah, right. Living under a nice rock there, customer service idiot?
I'm all for making ISPs responsible if they knowingly host spammers. I'm for vigilante action at this point, as nothing else seems to work. Get Anonymous on the subject. Blast the ISPs who say "fuck off" when you point out that they have a spammer in their hosting center off the 'net.
We all know that there is no single, simple solution to the issue. So instead of looking for it, why not combine all the imperfect, partial solutions we have? Let MS & Co. take down the botnets. Put pressure on the CC companies to stop dealing with them. Make the banks liable and cut off the money flow. Make the ISPs care and make it harder (thus more expensive) for the spammers to find a home. Shoot some spammers. Shoot some idiots who keep them in business by buying from them. Sacrifice a goat, stick needles in a puppet and pray to your god(s). Do it all at once.
Assorted stuff I do sometimes: Lemuria.org
Then maintain separate MX records for inbound and outbound SMTP. Any legitimate business should have no trouble getting a second record. And this is not preventing unregistered SMTP from sending mail. Just throttling.
Other problem is: How to do that without essentially eliminating all illusions of privacy.
It's easier to be a result of the past, but more fun to be a cause of the future! http://www.spacefinancegroup.com/
"It is impossible to neutralize a botnet by taking control over the controller machines .. It is still possible to push an update tool on infected machines to neutralize the botnet" Securelist.com
...
How to neutralize the botnet, use Ubuntu on the desktop
AccountKiller
There are plenty of rules that could be set up to prevent rogue systems from sending spam, but the problem is with getting network operators and individual server administrators on board. Trying to get all network operators (or ISPs) around the world doing something is like herding cats. Trying to get all individual server administrators to do something is like herding millions of catnip-infused cats.
Your thought about MX records is not quite right. There is a difference between servers that recieve mail (which should be pointed to by MX records) and servers that send mail (which should have valid PTR records in reverse DNS for their IP). While a single server may perform both duties, that is not by any means guaranteed. One action that would block a large number of infected systems from delivering their spam would be receiving mail servers blocking all mail from senders that do not have a valid RDNS record. This is the correct version of your proposal, and some major providers already do this. An even greater benefit could be achieved if all ISPs were to block outbound traffic headed for TCP port 25 by default, requiring subscribers to "opt-in" to initiate port 25 traffic. Some ISPs already do this, but far too many do not. Yet another good measure would be for recipients to block mail from servers that fail to identify themselves with a valid fully-qualified domain name in their HELO message and require that domain to resolve by DNS. Like the RDNS solution, this would require all legitimate mail server operators to set their sending servers up properly. As more receiving operators start blocking non-compliant mail servers, we may slowly push more sending server operators to do things right, but it is a long, slow process when users demand that every legitimate message get through.
Why not require real mail servers to comply with DNS to have an MX record for the domain or IP,
Because there is no rule that says any destination must have an MX record associated with it. RFC 5321 lists how to determine the host a server connects to, and "no MX" is an allowed case.
and to then have SMTP servers for a given network or internet service provider throttle the number of e-mail per unit of time and to limit the number of recipients to human real-world numbers?
What is a "human real-world number"? How do you deal with mailing lists that have hundreds of recipients? One email to the list results in hundreds of emails all at the same time.
That would prevent a non-MX mail server from being able to send mail since other mail servers would reject it based on DNS,
I'm sorry, but I don't think you understand the purpose of an MX record. The MX record isn't for the SENDING server, it is so the sending server can find a defined host to which email FOR a domain is sent. In fact, if an MUA uses SMTP to send mail, then it is highly unlikely that the sending host (the user's computer) will be the address pointed to by the MX record for any domain.
Yes, it would require some more programming in the SMTP daemon, but it shouldn't jack with the protocol.
As long as you don't consider "not being able to send email at all" a problem, no, your idea won't "jack with the protocol".
The more correct means of dealing with the problem is two-fold. SPF (sender permitted|policy framework) is how a recipient server looks up the authorized hosts that might be sending it email from a domain. Greylisting is how a server typically dispatches botnet senders, since the botnet is usually not going to try resending an email after getting a 500-level error.
Why don't you recommend a bulletwound victim just shoot up heroin? Same thing. Android alone, a Linux variant, shows that once Linux obtains a large marketshare on a platform (smartphones, essentially pc's themselves) it too will be as victimized as Windows has been, and largely only due to being the most used on a given platform (because malware makers do not target 'crowds of 1' and are like pickpocket thieves - they go to where the most people are in crowded thoroughfares, to maximize the victim potential of their efforts)). There is NO Linux that is anymore immune to concentrated specific attacks anymore than Windows is on PC's, or ANDROID (a Linux variant with the lion's share of the market on smartphones). You're only recommending a temporary fix, because Linux can be attacked just as easily as any other computing platform there is and ANDROID proves it.
and servers that send mail (which should have valid PTR records in reverse DNS for their IP).
Since MUA can use SMTP to send email, it is not required that there be a PTR for every sending host. It is true that there MAY be one, but it isn't a requirement. Large sites that may not publish DNS records for every internal system can likely get around any requirement from the recipient MTA by using a central mail server through which outgoing mail is sent. That server would have a PTR (and SPF) record.
That, however, seems to be an undesirable solution when it comes to an ISP serving many customers, however.
1. Track the botnet operators to their "C&C bunker" (LOL)
2. Storm in, guns blazing.
3. What problem?
Jeez where do I start? You must not be that familiar with email or how it is actually run today.
First off, email is an archaic platform that gets a bunch of glue and duct tape every so often.
Why not require real mail servers to comply with DNS to have an MX record for the domain or IP, and to then have SMTP servers for a given network or internet service provider throttle the number of e-mail per unit of time and to limit the number of recipients to human real-world numbers?
You can already do this with most mail servers. You have two problems here:
1) Requirement.
2) ISP involvement.
You cannot legally compel any person operating a mail server to do anything as part of configuration. The only legal liability I am aware of is sending SPAM itself, and even then the claim that you are merely a victim usually works.
ISPs don't want to be involved on a general basis. On business connections they don't do a damn thing, because businesses would go ape shit. I would. On residential connections some have at some points in time restricted port 25 destination traffic and the TOS usually prevent operating services off the IP address anyways. That being said, it has been awhile since I have actually seen a US based ISP actually block port 25 traffic anymore.
What is done on a day-to-day basis now:
1) Inspection of the IP address communicating with the mail server. Policy based lists, which are contributed to by the ISPs, tell us if it is a residential connection (Dynamic IP address ranges). There are also other lists that allow us to see if that specific IP address is flagged for SPAM. Look at Spamhaus or Cisco's Senderbase products. If the IP address is on a list it the session can be terminated immediately or the SPAM score increased sufficiently.
2) Headers. Who is it being sent to? Who is it being sent from? You have to ignore who the email is claiming to be from in most cases since that is easily forged. Every part of the email address can be forged except the remote IP address. Sent to addresses can be on white list to get it into the Inbox regardless of SPAM heuristics. Part of what you seemed to be alluding to is the EHLO statement. You check the reverse DNS for the remote IP address and see if it matches, or even exists in the first place. You're right that most real mail servers run by professionals, and not on home networks, will have a proper reverse DNS. Shutting down the connection solely based on that is questionable though.
3) URI inspection. Parse out all the links in the email and compare them against lists of known malware host sites. Fairly effective, and I personally don't allow the email to even reach the junk mail folder when one is found. New URIs pop up very fast so this is only effective for older campaigns.
4) Certifications, DKIM, SPF. These are methods outside of the mail server communication that involve 3rd parties, certificates, and DNS records that can validate a mail server as authentic and provide policies on how to treat remote IP addresses.
5) Anti-virus and Anti-malware. Inspection of attachments.
6) Heuristics. Evaluating all of the above plus content inspection to arrive at an overall SPAM score. If it exceeds the threshold throw it in the junk mail folder.
Now that is just off the top of my head for the mail servers I run. You also alluded to gray listing which is temporarily denying an email and asking that it be resent later. This is controversial because a lot of people are waiting for an email ASAP and can't wait 15 minutes. Throttling is also not very useful because on an IP address basis the SPAM load is distributed.
There are already quite a number of tools to reduce SPAM. The biggest problem I face is backlash from executives. Requiring proper reverse DNS left out half the vendors we were communicating with right off the bat. I have had to tone down the security a number of times because the remote part has no clue what they are
Any machine being used for purposes outside of the intent of the owner should be shut down. Owners should be notified and given time to respond, but if they are unaware of the additional traffic their computer is spewing then they should be shut down until corrected.
Unfortunatly service providers probably don't care, they would probably rather have the $29.99/mo customer rather then shutting them down until it's fixed.
End-users should not be using SMTP to communicate directly with recipient servers, and almost none do. Nearly all ISPs provide authenticating SMTP relays for their subscribers, and end-users should be using those ISP-provided SMTP servers or some other mail provider's SMTP servers to relay their mail. If they have some legitimate reason to send mail directly (such as operating their own server), then requiring them to ask their ISP for a port 25 blocking exemption is perfectly reasonable.
Legitimate large-volume senders have already dealt with this. I haven't encountered any legitimate large-volume senders in recent history that do not have valid PTR records for all of their outbound relays.
Blocking servers without a valid RDNS record may not be part of any proper standard, but it is slowly becoming a de facto standard.
MX record is inbound only. period.
However, ISP's could block outbound port 25 unless using their servers (such as my cable company) and/or make arrangements for a particular IP range to be outgoing mail servers. That starts to make sending servers a little more accountable.
If you need to send mail direct to a server outside this network, use ssl and submission port, not port 25.
Let them take it down national security is at risk.
It could do a lot more than send spam.
They hit me today (or someone did) by authenticating to my mail server using a password stolen from one of my remote users. If I didn't have any remote users, it wouldn't have been possible. But at least I caught it quickly when the user reported getting lots of bounce messages.
Pornography - What's the problem with that? It's not like we don't want that, now is it?
"Illegal" pharmaceuticals - Well, the pharma industry certainly doesn't want that. After all, it could harm the sales of their harmful pharmaceuticals.
Stock scam - Huh? There's stock options that are not a scam? The whole stock marked is a scam by definition.
I have no problem with calling it spam and scams. I have a problem with there being spam and scams that somehow are "excluded" and OK, like that of Eli Lilly, Monsanto, Goldman Sachs, Apple/MS, Vivendi, and their competitors.
Your post advocates a
(X) technical ( ) legislative ( ) market-based ( ) vigilante
approach to fighting spam. Your idea will not work. Here is why it won't work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses
(X) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
( ) It will stop spam for two weeks and then we'll be stuck with it
( ) Users of email will not put up with it
( ) Microsoft will not put up with it
( ) The police will not put up with it
( ) Requires too much cooperation from spammers
( ) Requires immediate total cooperation from everybody at once
( ) Many email users cannot afford to lose business or alienate potential employers
( ) Spammers don't care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else's career or business
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it
(X) Lack of centrally controlling authority for email
(X) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
(X) Asshats
( ) Jurisdictional problems
( ) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
( ) Huge existing software investment in SMTP
( ) Susceptibility of protocols other than SMTP to attack
(X) Willingness of users to install OS patches received by email
(X) Armies of worm riddled broadband-connected Windows boxes
(X) Eternal arms race involved in all filtering approaches
(X) Extreme profitability of spam
( ) Joe jobs and/or identity theft
( ) Technically illiterate politicians
(X) Extreme stupidity on the part of people who do business with spammers
( ) Dishonesty on the part of spammers themselves
( ) Bandwidth costs that are unaffected by client filtering
( ) Outlook
and the following philosophical objections may also apply:
( ) Ideas similar to yours are easy to come up with, yet none have ever
been shown practical
( ) Any scheme based on opt-out is unacceptable
( ) SMTP headers should not be the subject of legislation
( ) Blacklists suck
( ) Whitelists suck
( ) We should be able to talk about Viagra without being censored
( ) Countermeasures should not involve wire fraud or credit card fraud
(X) Countermeasures should not involve sabotage of public networks
( ) Countermeasures must work if phased in gradually
( ) Sending email should be free
( ) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don't want the government reading my email
( ) Killing them that way is not slow and painful enough
Furthermore, this is what I think about you:
(X) Sorry dude, but I don't think it would work.
( ) This is a stupid idea, and you're a stupid person for suggesting it.
( ) Nice try, assh0le! I'm going to find out where you live and burn your
house down!
Security researchers really are the unsung heroes.
If there are anyone reading Slashdot who works in that area: I would like to express my deepest gratitude for all the efforts you go through in combatting this global problem. Thank you so much for making the web a less shit place to be.
I wish I could say that you made that up, but alas. Other pathetic replies are
The latter ISP didn't like my bugging them too much, and in the end they firewalled my IP address in their firewall, so their customer couldn't spam me anymore.
Some ISPs just don't care. For example, I have been receiving spam for 19 9.10 2.22 8.21 9/~lightfoo/tracking&campaign=t-a-x&subid=main&var=jonxqo (ip address mangled) several times earlier this week, and last week. Reported it to ServInt via SpamCop.net (several times), direct email (several times), in their live chat, and in the end on their Facebook page. My comments on the latter they deleted, and of course I am now blocked...
Reporting spam is becoming more and more a pain in the ass. A lot of ISPs have non-working abuse@, or they seem to have an abuse@ only it's internally routed to /dev/null. When complaining with the ISP you are told to email to abuse@ (did that, 5 times already), or use their online form (with a CAPTCHA and/or other forms of major PITA). And maybe, maybe, if you're really lucky, the ISP resolves the issue within 48 hours of your tenth complaint (8 days later...)
Really, if you want spam to stop, make ISPs and hosting providers pay for mess coming out of their network. Right now it's a tough choice: dropping the spammer, or hosting it for another month. The latter makes another 20 USD and maybe people bitching about spam have given up by then...
Perl Programmer for hire
An interesting thought occurred to me. Spam earns a pittance for the pirates -- so instead of dishing out viagra e-mails, suppose they were to turn that huge bot-net cloud into some kind of distributed Megaupload (which I understand was quite profitable). Files would be spread out across the cloud, with extensive use of duplication and parity to cope with the constant ebb-and-flux of zombie hosts.
You wouldn't be able to earn legitimate advertising dollars, but the viagra spammers would probably still pay you (plus super-users who wanted bonus bandwidth).
That actually doesn't sound quite that hard. Changing PHP and Perl would be easy; the maintainers of those languages would simply change their implementations to use email 2.0. As soon as web hosts upgrade, they'd be using the new version, and web hosts usually stay fairly current on scripting languages because customers demand it (newer versions, particularly with PHP, mean more built-in functions and easier coding).
With email servers, again there's not that many pieces of software out there that are really popular, maybe a dozen or so. In the Linux world at least, they just need to get sendmail and postfix to switch to email2.0, then get the distros to push it out to everyone as a "security update" (instead of making them wait for the next distro upgrade, as many times people don't upgrade their distros for a long time if ever), and it's done.
Same for email clients; there's just not that many in widespread use. Changing Outlook would get most desktop users right away, then after that probably Thunderbird. Surely Gmail, Hotmail, and Yahoo could change fairly quickly, affecting the bulk of email users.
The big problem I see is all the people using their crappy ISP's crappy webmail client. But even these are largely a limited group of applications, such as SquirrelMail, so once those get changed, the ISPs would just need to change.
If it was all done with a 1-year transition period, it'd be feasible to get most people and companies switched over I think, and the leftovers would be forced to switch at the end of the transition period or just not use email any more.
End-users should not be using SMTP to communicate directly with recipient servers, and almost none do.
"Almost none"? I believe that Outlook does. Evolution does. Pine does. The mail program on my smart phone uses SMTP to send email. I would hardly call that "almost none".
Nearly all ISPs provide authenticating SMTP relays for their subscribers,
Yes, which talk SMTP to the "end user".
Legitimate large-volume senders have already dealt with this.
They haven't already dealt with some new proposal that requires MX records for sending hosts and "human" limits on sending email.
What about email based attacks? What about maliciously scripted site attacks??
Fact is, You're overlooking a hell of a lot of possible other sources that are a LOT MORE PREVALENT FOR ATTACKING OTHERS, MOSTLY, other than app repositories even beginning to "keep end users safe".
Here's some proofs of that based on research:
http://betanews.com/2012/01/25/the-top-10-web-security-threats-you-should-avoid/
Pertinent quote/excerpt:
"The compromised website is still the most effective attack vector for hackers to install malware on your computer with 47.6 percent of all malware installs occurring in that manner, says security firm AVG. Another 10.6 percent are tricked into downloading exploit code -- many times, without their knowledge -- by clicking on links on pages to sites hosting malware... It also found that faked pharmacy sites are a popular attack method, seen in about 10.4 percent of all attacks. Fake antivirus scanners remain a popular malware injection method at 8.4 percent. "
---
* Fact is, what I noted, compromised sites, comprises 77% of malware installations - not what users download & install themselves (ala shareware/freeware sites like download.com etc./et al)...
APK
SMTP consists of both a message submission part and a message transfer part. They both use the same protocol and appear extremely similar.
The way it works is, Sender connects to SMTP Server S and transfers message. SMTP Server S connects to SMTP Server R and transfers message. Recipient connects to Server R (via POP3 for example) and retrieves the message.
Nearly all ISPs provide authenticating SMTP relays (Server S in the explanation) so that the Sender never needs to communicate directly to Server R.
Half the business world seems to believe that it is acceptable to mail my ISP, and have me disconnected from the internet if I download a couple of songs, movies, or whatever. Three strikes, and you're out.
So - why isn't anyone clamoring to have these machines disconnected by the ISP's? If they had all those machines communicating with a sinkhole for months, then surely they have identified real IP addresses for most, if not all of them.
We have the ability to unplug people and computers from the internet. Why do we only want to use that ability to punish small time downloaders?
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
You hit the nail on the head there, Lotana.
Thanks for the link. I knew user ignorance is the primary vector for malware spreads, but I did not know what to call it.
Corporations/Governments seem to love to keep underlings ignorant so they can be controlled - Knowledge is Power.
Ignorance of digital hygiene on the internet is just as risky as ignorance of bacterial hygiene in the kitchen.
A big problem is a few people profit immensely from privileged information. They will lobby like hell to keep it that way.
There was once a time I knew exactly how my machine worked, but with the advent of all sorts of proprietary protocols and formats, I have no idea of what is and is not legitimate traffic on my machine.
Can I trust even an antivirus company?
The Kelihos botnet that sent up to 3.8 billion spam e-mails per day before being taken offline by Microsoft and Kaspersky Lab four months ago was created and controlled by a software developer who formerly worked for an antivirus firm, Microsoft said in a civil lawsuit updated yesterday.
I can't tell you how many times I have had rogue scripts pop up on my system, warning me I was infected and needed to "click here" to fix it - for free.
I absolutely hate this circus certain "businessmen" have foisted on us by "working with" other trusted businesses to use proprietary technologies which I cannot verify whether or not they have other motives. The simplest apps now require megabytes of code and use tunneling protocols. Its now illegal to even discuss who is using what and how to see into what it is doing. How do I know if they are honest?
As far as I am concerned, these botnets are the internet equivalent of typhoid Mary .
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
End-users should not be using SMTP to communicate directly with recipient servers, and almost none do. (Emphasis added.)
"Almost none"? I believe that Outlook does. Evolution does. Pine does. The mail program on my smart phone uses SMTP to send email. I would hardly call that "almost none".
I very much doubt your mail client is configured to send mail directly. It almost certainly has an SMTP relay configured for sending mail. Nearly all MUAs lack the option to send directly -- they require that a relay be configured.
Nearly all ISPs provide authenticating SMTP relays for their subscribers,
Yes, which talk SMTP to the "end user".
Legitimate large-volume senders have already dealt with this.
They haven't already dealt with some new proposal that requires MX records for sending hosts and "human" limits on sending email.
"This" in my statement above specifically referring to having the appropriate PTR records set up, as the context in the following (unquoted) sentence indicates. No part of my post supports any funky use of MX records or sending volume limits.
Context -- it changes things.
How hard can it be? - The legendary DDoS'ing screen saver did the right thing IMHO.
It's just a question of DDoS'ing all the members of the botnet, kicking them off the net. We're almost exclusively talking regular PC's with limited bandwidth so it should be trivial to choke them off the net. Should get the attention of the owners that might wake up and do something about it... or just turn off his/hers now worthless computer... both would stop the zombie cold.
Yes, it's the right thing to do because anybody who allows his/her machine to do evil is evil by definition and it's always right to fight evil. Keeping a machine patched and protected is so simple it hurts. If you don't you're intentionally causing the evil to happen. You should know better. Windows has a fairly well-functioning auto update feature, and there's lots of anti-virus and firewall software out there (newer Windows includes one as well), including decent free stuff, so there's no excuse. Failing to stay vigilant is evil.
Yes, I've had various Windows boxes for decades and I've never had an infection, despite being actively online for 12+ hours each day. But I've always been careful to keep things updated, and of course to use a browser that helps protect the system.
I know! I know!
Let's make email that supports Javascript!
Typo or mistake, you mean to say 400-level. If it's 500, no one's coming back.