Well, killing connectivity to an IP customer generating spam is a good strategy, and should put single-homed spammers out of business.
Assuming of course, they are not an innocent victim. But in any case, your IP network is your IP network.
But as mentioned above, the more insidious spammers might make that impossible, by leasing rack space and power from provider A, transport from provider B, and IP from providers C, D, E, and F..
Relying on the notion that IP providers C,D,E, and F, have no control over the rack, and can't "turn off" the spammers servers.
The only thing they can do with remote safety is to kill their own link to the suspected spammer, and send them a disconnect notice (following the terms of their agreements).
If IP provider C tried to break into your rack, and turn off the connection to provider D or E, or to unplug power cables, the facilities providers, their security staff, and possibly the police might have some choice words for provider C...
If provider C kills their IP handoff (which is legal), the spam continues with the other providers D-E-F, if just D kills their IP handoff, the spam continues with C-E-F, etc...
C,D,E,and F, all need to shutdown the spammer.
I suppose the feasability depends on how profitable the spam... rack space in places where many ISPs are available is not the cheapest thing in the world, let-alone large amounts of IP transit without providers asking questions, or performing at least a credit check.
I remain skeptical that spammers can really pull this off, unless it's extremely profitable..
Blacklisting tends to be quick, and if their campaign gets shutdown before they can make up for installation fees, then the spammer should lose money..
I wonder now if you could legally bypass the termination fee by claiming Verizon made a material change the conditions of service that was experienced during the 30-day trial/cool-down period, before the early termination fee could be active.
When you gave customers a choice between A and B, and most picked A.
Letting the manufacturer of B pay you $500 million to remove the choice of A and force all your customers to use B is going to hurt you in the long run.
They will now switch to the company that lets you pick A.
And hopefully, you and the manufacturer of B will soon be under investigation for abuse of a monopoly.
I look forward to sending my complaints into the FCC, and providing as input as possible in the FCC investigation of this matter that is sure to come.
In most cases it would be. Most spammers and non-spammers, don't make an agreement with provisions for their landlord to turn off the lights.
The contract specifies services to be provided, and turning off those services is a failure to perform under the agreement, in the most common scenario.
Even if the terms don't explicitly prohibit the landlord to do so, it may still be unlawful for them to turn off the power without meeting certain advance notification requirements.
Whether the actual crime is breach of contract, unlawful eviction, or tortious interference, is immaterial.
Well, you probably broke quite a few laws by using coersion to gain access to a customer's servers. But I for one would overlook it, given the benefits to the world at large (still it could be risky).
Fortunately, given the use of GRE tunnels, the spammer probably broke more laws, and would probably be a bit hesitant to sue.
The scenario is atypical. From the sounds of it, most spammers are not buying the cabinet space from the same company that is providing the internet access.
Of course it's a breach of contract and likely a violation of SLA for a cabinet provider to power down anyone's equipment or start cutting wires, because they think they might be spamming.
The spammer might sue claiming loss of valuable data (due to an unclean shutdown of their server).
Industry standard terms are power can be disconnected at request of customer (for a fee of course), emergency, planned maintenance, and violation of wiring standards (e.g. many major colocation facilities will have many rules on how equipment can be plugged in). But I don't think there are many Enterprise rack residents that accept "We may disconnect you if we feel your servers are doing something suspicious"
Of course network connections are a bit different.
Well, if you buy TRANSPORT from point A to point B, such as a connection from your rack to an ISP, in a major datacenter, you can expect by contract the transport provider cannot examine any data crossing the wire. In fact, they cannot cut the cable, just because they suspect you might be sending spam over it.
Your OC-3 or Ethernet transport from "Point A" to "Point B" is not an internet service. It's extremely unlikely for an Enterprise to negotiate a contract that allows their transport provider to disconnect them.
Following industry standard terms, a transport provider cannot kill the link, even if you are spamming, in fact, even if an internet attack happens to be crossing the link, a transport provider has no right to kill your connection or detect the nature of the traffic that is being transported.
To do so would be breach of contract/SLA on their part, and subject them to unnecessary liabilities (they lose their common carrier status for links that they 'watch').
In most cases, the one and only party that can legally cut off such a professional spammer at the source is the upstream ISPs, transit providers, or peering exchange of the misbehaving party.
Naturally, this is assuming the ISP isn't the same company that provides the rack space. In other situations matters might be different.
And in a major datacenter, there might be a lot of different ISPs to choose from...
I guess, my point is just... the standard arrangements for such facilities can actually serve to protect spammers.
Just like they protect Enterprises (who wouldn't inhabit them otherwise -- if someone could just arbitrarily decide to power off their servers, because they didn't like a file on their website).
Well, you could send complaints to the provider they peer with.
Normally that means the provider you send the messages to forwards them to the administrator of the network the spam complained about originates from.
Blacklisting is still your best bet, if you want to stop spam.
Spamhaus has a list called DROP, the Don't Route or Peer list, for listing hijacked blocks and professional spammers.
Trend Micro has InterCloud, ICSS/BASE..
which can provide tl. a BGP feed of providers/IP addresses to blacklist/null-route (botnet command and control points and infected hosts).
No.. it's worse than that. IP addresses aren't bought or sold.
Once they are no longer using the IPs, once they cancel the connection, the IP delegation goes away.
If the IPs came from the ISP, that ISP has to re-use such IPs: they count against the ISP's ability to justify need for more IP addresses.
If the IPs came from a RIR, once the justification goes away, the IP addresses are supposed to be returned, or they get revoked when the recipient of the IPs stops paying their annual maintenance fees.
In any case, the IPs eventually go back to the free pool, and get allocated to someone else.
The registries aren't going to try and "clean" blacklists, neither will ISPs. The recipient of IPs inherits the problem, to deal with any connectivity issues caused by blacklisting.
For IPs received from an ISP though... you should be able to convince your ISP to get you new IPs and allow you to move, if you're willing to take the time and energy to renumber, and (for some ISPs), there may be fees involved in you making the change requests, for the time it takes the ISP to make changes.
In many ways, poorly-maintained blacklists are just as harmful to the internet and end-to-end universal connectivity, as the spammers and malware peddlers are.
There is a strong movement on the public internet registries such as ARIN, RIR, etc, supporting privacy of IP address allocation data.
In the future, it is very likely that registry policy may shift in favor of these supporters of internet privacy.
The result will be you cannot do so much as a WHOIS lookup to find out who these spammers might be if the privacy advocates/spammer have their way, only with a court order...
Good luck getting that when the spammer lives in a different country, where spam isn't illegal.
No, because once every/24 in those f****ers block gets on enough blacklists, they get a few more hosts to justify a bigger block, fill out a form to RETURN the IP addresses they got. Their old IPs will be assigned to someone else,
and after the exchange their old IPs for a fresh new block of IPs they have even more/24s than before, and none of them blocked.
Now only the new guy (that happens to be so unlucky as to get their old IPs) is blocked.
Of course the f'ers will pretend to be legitimate extremely well, and make it as hard as possible for people to see reason to ban their whole block.. (E.g. The "shell" ISP will create "fake" separation from spammers who "received space" from their block)
They may do all kinds of weird s**** to make it look like it's not just one spammer.
Alternatively, they just apply for more space, using more shell companies, lather, rinse, and repeat. Until IPv4 is exhausted, that is.
If they have no problem lying once... it's not the least bit difficult to create 30 more fake companies (or even, make them real companies -- if the spam effort is profitable enough).
This is all assuming they are getting the IPs from the RIRs in the first place, which I doubt is the most common.. that could be too easy to track, since these allocations generally get published very visibly.
LIR ips are just fine for them, and much easier to get.
Also, the RIRs are basically powerless to stop this.
Contrary to the article, it's not necessarily about "LIRs being lax".
Once a block of IP addresses is assigned, it is not as if the LIR or RIR can revoke it and force its use to cease.
Revoking IP addresses doesn't magically make them unreachable on the internet -- once the spammer convinced their ISP to announce the address space, they don't need (any longer) to prove they got the IPs legitimately, until/unless they get more ISPs.
The article's terminology is wrong. An LIR is just another name for an ISP.
Verizon is an LIR, Level3 is an LIR, Cogent is an LIR, AT&T, Sprint, etc, are all LIRs, any ISP that receives ISP allocations of addresses which are issued to them for the sole purpose of sub-delegating for use with their services, is called an LIR.
Maybe the article means the spammers are getting IP delegations from an ISP LIR, that would make sense. It is very easy to believe, they could do this en masse with very little effort, in fact.
If you buy internet services from an ISP like Verizon, and claim to have X hosts, they will have a very hard time rejecting a request from their customer for those IPs.
For a simple/24 or two, most won't ask for much documentation, as long as the price is right, it's not customer-friendly to try that.
The tough questions don't start getting asked, until a request for a larger number of IPs is made, which is sensible.
Level of justification and documentation commensurate with the expected usage.
The LIR/ISP will SWIP the listing or list the claimed owner on their RWHOIS Servers, but it won't appear as public knowledge in the RSS feeds, that such and such/24 has been allocated.
ISP RWHOIS servers are commonly broken and poorly maintained -- the spammer's new subdelegation may not even become public knowledge.
No.. I think some players in the industry just want to create confusion, and make you think a thin-client is a specially-packaged "diskless workstation" for their own benefit.
First of all, the term thin-client came way before there were any products named thinclient.
It's true that many packaged thinclient products today will be diskless, or will utilize compact flash for local storage (Just like that PC in a keyboard product, by the way, with the SD/SDHC card option), and include curious features like smartcard readers.
Anyways: companies that sell products for implementing thin-clients want to convince you that their product is somehow different (or better) than using an old ordinary PC, so they can differentiate their product in the marketplace.
IOW: They want you to believe their product is different (even in ways that it is not).
In the case of thin clients: they want you to believe their product has a lower TCO; they would have you think it will (A) last longer, not be likely to fail, (B) use less electricity, (C) be more secure, than using generic thin-client hardware.
They will try to convince you that using no local disks or using CF instead, somehow makes the product better, or make it last longer, while costing less to maintain, than anything using something capable of being a PC. Even though these claims have not really been shown to be true.
Otherwise you would just use uber-cheap PC hardware, instead of paying the extra premium for a brand-name "packaged thin client".
Unplug the power cable to the HDD if you want, slap an internal USB stick, or PXE boot mod, and call it a day.
In other words, the motive of companies that speicalize in thin-clients is inherently self-serving, they want to warp the industry's perception of what a thin client is.
The truth is... when you aren't talking about solutions packaged by major vendors:
Not all thin clients have to be diskless.
Not all thin clients have to be off-the-shelf products "designed originally to be thin clients"
All ultra light-weight PCs are good candidates, especially units that don't need fans for cooling or mechanical storage (e.g. systems that use SD/SDHC, CF, or SSDs, are great candidates for quiet low-power thinclients).
Sometimes a local HDD may be used to boot a thin client, or you may use PXE boot or a simple $5 USB thumb drive to startup the thin-client (despite any existence of local disk).
In some cases it could be simply read-only storage to load a ramdisk from.
In other cases, there could be local caching of various things.
HDDs don't drop dead that often -- if you execute power management well, and use HDDs only to boot the thin-clients, they will be spun down most of the time, anyways, extremely low mechanical wear, and you can expect 10+ years on average, easily.
Ok. 20,000 machines on a Class B subnet is ludicrous.
With so many, you should divide the LAN and subnet with routers, or if for some ludicrous reason you must keep a class B subnet, then use a LAN divided transparently with routers acting as Proxy ARP servers.
I think it's fair to say that FB servers generate a large amount of database I/O.
And their PHP code is likely running a lot of graph flow, pattern matching, and other data mining algorithms.
Including plaintext indexing and search algorithms
Remember, the whole point of the social network from an advertiser perspective is to select people on the network who are most likely to be interested in certain ads.
This suggests a lot of elaborate DM on FB's part.
Just because the intensive computations aren't obvious to the end-user, doesn't necessarily mean there is no heavy numerical computation being done behind the scenes.
The PC-in-a-keyboard is not a thin client--it's a full, although lightweight, computer in a keyboard.
No. It's a fricckin thin-client.
This argument is something like saying a computer monitor that has an HDMI input in addition to DVI is not a monitor, because computer monitors only have DVI/VGA inputs.
OMG: being a computer doesn't disqualify something from being a thin client. All thin clients are computers.
It's the lightweight part and low-cost that by definition makes the system a thin-client.
Having a hard drive or other storage media doesn't mean it's not a thin client either.
The actual qualification to being a thin client refers to how the machine is used, not the actual specs of the machine.
For a machine to be used as a thin client, it indicates the bulk of the data processing and long-term storage will be handled by the server.
Most other device makers are more interested in getting you to buy the newest toy. Which is why they aren't too keen on keeping them updated, or even working after you've paid for it.
In fact... this has advantages for the consumer.
A lower cost product.
Sure you don't get lowe-cost software updates -- but it's expensive to support your product with updates in the long run.
And that price basically has to be built into the cost of the product.
So it could be that the iPhone is the high-end $600+ product that includes updates.
Whereas the Android-based devices are the low-end units that cost maybe $100. But one of the things you lose out on in buying low-end is the ability to update after purchase.
The price is so low partly because updatability hasn't been included.
If there's demand for updates to the Android OS,
on such an inexpensive device you should expect to have to buy a new one to get the update, or to have to pay $50+ for a downloadable update.
In fact, even the iPhone is pretty low price (much of the "price" goes into cost of the hardware components and payment to the carrier), and one could expect, that eventually, major version updates be for-pay, just as they are for computer OSes.
It works fine, and I use it..
And no, you don't need to stop the master on a regular basis for any reason.
Clients that perform updates have to connect to master.
For select queries, use a load balancer that connects to the slaves.
When you are creating a new slave, you replicate it first, then add it to the load balanced cluster AFTER replication is proceeding.
The asynchronous nature has some drawbacks though, since your app can never really be 100% sure that what you see is the latest version of the database.
It helps if you record in-flight transactions and "hot" data using memcached, and consult the database for cold data.
MySQL already has perfect asynchronous master-slave replication through binary logging.
What's hard is synchronous replication it would be a very useful enhancement if 5.5 had a reliable synchronous replication option, and supported clustering, failover/hot-standby, and failed-node recovery/resynch.
Oh really.. No. I think it's more of a case of RFC2821 being revisions to the standard proposed to make it more accurately reflect current implementations / current common practice.
If it were generally accepted and widely seen to have no issues, it had plenty of time to cross from PROPOSED STANDARD to Full standard.
Obviously someone (or some people) objected to rfc2821 and hold that further revisions are necessary, before a new standard is arrived at.
Meanwhile, implementors who see advantages
of some of the changes in 2821 begin to incorporate some of what they see as the best improvements into their implementations.
Of course Internet Standards can't force anyone to do (or not do) anything.
MTA developers can and should play around with experimental features.
It's how new standards get developed, in the first place.
RFC1123 is a standard, STD 3 is currently RFC1123. RFC2821 is currently not a standard of any kind.
Check the listing in the RFC Index next time.
1123 Requirements for Internet Hosts - Application and Support. R.
Braden, Ed.. October 1989. (Format: TXT=245503 bytes) (Updates
RFC0822) (Updated by RFC1349, RFC2181, RFC5321) (Also STD0003)
(Status: STANDARD)
2821 Simple Mail Transfer Protocol. J. Klensin, Ed.. April 2001.
(Format: TXT=192504 bytes) (Obsoletes RFC0821, RFC0974, RFC1869,
STD0010) (Obsoleted by RFC5321) (Updated by RFC5336) (Status:
PROPOSED STANDARD)
0821 Simple Mail Transfer Protocol. J. Postel. August 1982. (Format:
TXT=124482 bytes) (Obsoletes RFC0788) (Obsoleted by RFC2821) (Also
STD0010) (Status: STANDARD)
rfc1123 removed the relay function whereby your mail server may list other server's names in the return path.
The replacement is that only your mailserver is listed in the MAIL FROM entry.
The RFC never said anything about adding some other server's address to a MAIL FROM line, that was never allowed by the standard. Your mail server can only add its own address as it is known to the mail server it is sending to period (for a new mail from: line).
To list the address in MAIL FROM: means that you (the sending mail server) are claiming you can take responsibility for being able to return mail to the address you list.
That is: by listing an address in mail from, you PROMISE you can immediately return mail to the host you received it from, if there is an error.
There are traditionally only two ways a mail server can take that responsibility:
either (1) the item you list in MAIL FROM is you, and you list a local user, then of course you can return the message to your local user, OR:
(2) You are relaying the item, and you received that address in MAIL FROM.
You can live up to the promise by delivering the error message to the server that relayed you the message with that address in MAIL FROM, and that server can live up to their promise, and so on.
Well, without source routing (2) is actually a stretch.
The elimination of option (2) as a way to satisfy the promise you make means that you are left with option (1) only.
Well, the section of interest is 5.2.6 of RFC1123, which killed section 3.6 of RFC 822 with the stated goal of abolishing source-routing of the destination or of the return path.
Basically, the baby was accidentally thrown out with the bathwater, and it is unfortunately way too late to do anything about it..
5.2.6 Mail Relay: RFC-821 Section 3.6
.... the relay function defined in section 3.6 of RFC-821 should
not be used.
... The mailbox is an absolute address, and the route is
information about how to get there. The two concepts should not
be confused.
Conceptually the elements of the forward-path are moved to the
reverse-path as the message is relayed from one server-SMTP to
another. The reverse-path is a reverse source route
When a server-SMTP deletes its
identifier from the forward-path and inserts it into the
reverse-path, it must use the name it is known by in the environment it is sending into, not the environment the mail came
from...
If when the message arrives at an SMTP the first element of the forward-path is not the identifier of that SMTP the element is not deleted from the forward-path and is used to determine the next
SMTP to send the message to. In any case, the SMTP adds its own identifier to the reverse-path....
Of course this breaks forwarders ahem, "legitimate" forgers who want to stuff an address they have on someone else's mail server in the "MAIL FROM" line as well...
Referencing someone else's mailserver in 'MAIL FROM' is always forgery, due to the very nature of RETURN PATH. When you place your server name in the Return path, you are claiming that server said they were responsible for the message
Again, prior to rfc1123, this was a lot clearer; every relay in the path the message had passed through would appear in the MAIL FROM line.
SPF and 'MAIL FROM' / Return-Path have nothing to do with 'From' line in the e-mail message itself.
The From: line is user data, not subject to SPF checks, and doesn't have to match the return path.
Using whatever e-mail address you own in the From: line is fine.
Placing someone else's mail server's hostname in the 'MAIL FROM' or Return-Path headers is forgery, and blocking this is one of SPF's best features.
So they have an account elsewhere, at a vanity domain or on another computer, and they forward mail from that address to whichever is their current ISP, or their employer.
The keyword is elsewhere.
RFC 1123 deprecated the concept of a proper return path. If it hadn't happened, there would be no issue.
But due to RFC 1123, if you place another mail server's hostname in the "MAIL FROM" line, you are committing forgery, regardless of any ad-hoc justification you may come up with for "permitting" it.
The abuse doesn't make a technology that stops it evil.
Particularly when there is a good workaround called SRS.
Senders that don't publish SPF records are dodgy sources, and they get an automatic penalty, unless the source IP matches the MX record and listens on port 25.
Automatic +5.0 to spam score.
Basically assures the sender will be hit by graylisting, and the message may ultimately be classified spam.
Fail to publish proper SPF records at you and your users' peril.
Slashdot Mirror
Well, killing connectivity to an IP customer generating spam is a good strategy, and should put single-homed spammers out of business.
Assuming of course, they are not an innocent victim. But in any case, your IP network is your IP network.
But as mentioned above, the more insidious spammers might make that impossible, by leasing rack space and power from provider A, transport from provider B, and IP from providers C, D, E, and F..
Relying on the notion that IP providers C,D,E, and F, have no control over the rack, and can't "turn off" the spammers servers. The only thing they can do with remote safety is to kill their own link to the suspected spammer, and send them a disconnect notice (following the terms of their agreements).
If IP provider C tried to break into your rack, and turn off the connection to provider D or E, or to unplug power cables, the facilities providers, their security staff, and possibly the police might have some choice words for provider C...
If provider C kills their IP handoff (which is legal), the spam continues with the other providers D-E-F, if just D kills their IP handoff, the spam continues with C-E-F, etc...
C,D,E,and F, all need to shutdown the spammer.
I suppose the feasability depends on how profitable the spam... rack space in places where many ISPs are available is not the cheapest thing in the world, let-alone large amounts of IP transit without providers asking questions, or performing at least a credit check.
I remain skeptical that spammers can really pull this off, unless it's extremely profitable.. Blacklisting tends to be quick, and if their campaign gets shutdown before they can make up for installation fees, then the spammer should lose money..
I wonder now if you could legally bypass the termination fee by claiming Verizon made a material change the conditions of service that was experienced during the 30-day trial/cool-down period, before the early termination fee could be active.
Customer choice matters.
When you gave customers a choice between A and B, and most picked A.
Letting the manufacturer of B pay you $500 million to remove the choice of A and force all your customers to use B is going to hurt you in the long run.
They will now switch to the company that lets you pick A.
And hopefully, you and the manufacturer of B will soon be under investigation for abuse of a monopoly.
I look forward to sending my complaints into the FCC, and providing as input as possible in the FCC investigation of this matter that is sure to come.
In most cases it would be. Most spammers and non-spammers, don't make an agreement with provisions for their landlord to turn off the lights.
The contract specifies services to be provided, and turning off those services is a failure to perform under the agreement, in the most common scenario.
Even if the terms don't explicitly prohibit the landlord to do so, it may still be unlawful for them to turn off the power without meeting certain advance notification requirements.
Whether the actual crime is breach of contract, unlawful eviction, or tortious interference, is immaterial.
Well, you probably broke quite a few laws by using coersion to gain access to a customer's servers. But I for one would overlook it, given the benefits to the world at large (still it could be risky).
Fortunately, given the use of GRE tunnels, the spammer probably broke more laws, and would probably be a bit hesitant to sue.
The scenario is atypical. From the sounds of it, most spammers are not buying the cabinet space from the same company that is providing the internet access.
Of course it's a breach of contract and likely a violation of SLA for a cabinet provider to power down anyone's equipment or start cutting wires, because they think they might be spamming.
The spammer might sue claiming loss of valuable data (due to an unclean shutdown of their server).
Industry standard terms are power can be disconnected at request of customer (for a fee of course), emergency, planned maintenance, and violation of wiring standards (e.g. many major colocation facilities will have many rules on how equipment can be plugged in). But I don't think there are many Enterprise rack residents that accept "We may disconnect you if we feel your servers are doing something suspicious"
Of course network connections are a bit different.
Well, if you buy TRANSPORT from point A to point B, such as a connection from your rack to an ISP, in a major datacenter, you can expect by contract the transport provider cannot examine any data crossing the wire. In fact, they cannot cut the cable, just because they suspect you might be sending spam over it.
Your OC-3 or Ethernet transport from "Point A" to "Point B" is not an internet service. It's extremely unlikely for an Enterprise to negotiate a contract that allows their transport provider to disconnect them.
Following industry standard terms, a transport provider cannot kill the link, even if you are spamming, in fact, even if an internet attack happens to be crossing the link, a transport provider has no right to kill your connection or detect the nature of the traffic that is being transported.
To do so would be breach of contract/SLA on their part, and subject them to unnecessary liabilities (they lose their common carrier status for links that they 'watch').
In most cases, the one and only party that can legally cut off such a professional spammer at the source is the upstream ISPs, transit providers, or peering exchange of the misbehaving party.
Naturally, this is assuming the ISP isn't the same company that provides the rack space. In other situations matters might be different.
And in a major datacenter, there might be a lot of different ISPs to choose from...
I guess, my point is just... the standard arrangements for such facilities can actually serve to protect spammers.
Just like they protect Enterprises (who wouldn't inhabit them otherwise -- if someone could just arbitrarily decide to power off their servers, because they didn't like a file on their website).
If there were... nobody would bother cleaning old blacklist entries, since the IPs only get recycled every 100 years or so.... no reason to bother.
Then 100 years later, an IP that was spamming 100 years ago gets re-used... and can't connect to anyone......
Well, you could send complaints to the provider they peer with.
Normally that means the provider you send the messages to forwards them to the administrator of the network the spam complained about originates from.
Blacklisting is still your best bet, if you want to stop spam.
Spamhaus has a list called DROP, the Don't Route or Peer list, for listing hijacked blocks and professional spammers.
Trend Micro has InterCloud, ICSS/BASE.. which can provide tl. a BGP feed of providers/IP addresses to blacklist/null-route (botnet command and control points and infected hosts).
No.. it's worse than that. IP addresses aren't bought or sold.
Once they are no longer using the IPs, once they cancel the connection, the IP delegation goes away.
If the IPs came from the ISP, that ISP has to re-use such IPs: they count against the ISP's ability to justify need for more IP addresses.
If the IPs came from a RIR, once the justification goes away, the IP addresses are supposed to be returned, or they get revoked when the recipient of the IPs stops paying their annual maintenance fees.
In any case, the IPs eventually go back to the free pool, and get allocated to someone else.
The registries aren't going to try and "clean" blacklists, neither will ISPs. The recipient of IPs inherits the problem, to deal with any connectivity issues caused by blacklisting.
For IPs received from an ISP though... you should be able to convince your ISP to get you new IPs and allow you to move, if you're willing to take the time and energy to renumber, and (for some ISPs), there may be fees involved in you making the change requests, for the time it takes the ISP to make changes.
In many ways, poorly-maintained blacklists are just as harmful to the internet and end-to-end universal connectivity, as the spammers and malware peddlers are.
There is a strong movement on the public internet registries such as ARIN, RIR, etc, supporting privacy of IP address allocation data. In the future, it is very likely that registry policy may shift in favor of these supporters of internet privacy.
The result will be you cannot do so much as a WHOIS lookup to find out who these spammers might be if the privacy advocates/spammer have their way, only with a court order...
Good luck getting that when the spammer lives in a different country, where spam isn't illegal.
No, because once every /24 in those f****ers block gets on enough blacklists, they get a few more hosts to justify a bigger block, fill out a form to RETURN the IP addresses they got. Their old IPs will be assigned to someone else,
and after the exchange their old IPs for a fresh new block of IPs they have even more /24s than before, and none of them blocked.
Now only the new guy (that happens to be so unlucky as to get their old IPs) is blocked.
Of course the f'ers will pretend to be legitimate extremely well, and make it as hard as possible for people to see reason to ban their whole block.. (E.g. The "shell" ISP will create "fake" separation from spammers who "received space" from their block)
They may do all kinds of weird s**** to make it look like it's not just one spammer.
Alternatively, they just apply for more space, using more shell companies, lather, rinse, and repeat. Until IPv4 is exhausted, that is.
If they have no problem lying once... it's not the least bit difficult to create 30 more fake companies (or even, make them real companies -- if the spam effort is profitable enough).
This is all assuming they are getting the IPs from the RIRs in the first place, which I doubt is the most common.. that could be too easy to track, since these allocations generally get published very visibly.
LIR ips are just fine for them, and much easier to get.
Also, the RIRs are basically powerless to stop this. Contrary to the article, it's not necessarily about "LIRs being lax".
Once a block of IP addresses is assigned, it is not as if the LIR or RIR can revoke it and force its use to cease.
Revoking IP addresses doesn't magically make them unreachable on the internet -- once the spammer convinced their ISP to announce the address space, they don't need (any longer) to prove they got the IPs legitimately, until/unless they get more ISPs.
The article's terminology is wrong. An LIR is just another name for an ISP. Verizon is an LIR, Level3 is an LIR, Cogent is an LIR, AT&T, Sprint, etc, are all LIRs, any ISP that receives ISP allocations of addresses which are issued to them for the sole purpose of sub-delegating for use with their services, is called an LIR.
Maybe the article means the spammers are getting IP delegations from an ISP LIR, that would make sense. It is very easy to believe, they could do this en masse with very little effort, in fact.
If you buy internet services from an ISP like Verizon, and claim to have X hosts, they will have a very hard time rejecting a request from their customer for those IPs.
For a simple /24 or two, most won't ask for much documentation, as long as the price is right, it's not customer-friendly to try that.
The tough questions don't start getting asked, until a request for a larger number of IPs is made, which is sensible. Level of justification and documentation commensurate with the expected usage.
The LIR/ISP will SWIP the listing or list the claimed owner on their RWHOIS Servers, but it won't appear as public knowledge in the RSS feeds, that such and such /24 has been allocated.
ISP RWHOIS servers are commonly broken and poorly maintained -- the spammer's new subdelegation may not even become public knowledge.
No.. I think some players in the industry just want to create confusion, and make you think a thin-client is a specially-packaged "diskless workstation" for their own benefit.
First of all, the term thin-client came way before there were any products named thinclient.
It's true that many packaged thinclient products today will be diskless, or will utilize compact flash for local storage (Just like that PC in a keyboard product, by the way, with the SD/SDHC card option), and include curious features like smartcard readers.
Anyways: companies that sell products for implementing thin-clients want to convince you that their product is somehow different (or better) than using an old ordinary PC, so they can differentiate their product in the marketplace.
IOW: They want you to believe their product is different (even in ways that it is not). In the case of thin clients: they want you to believe their product has a lower TCO; they would have you think it will (A) last longer, not be likely to fail, (B) use less electricity, (C) be more secure, than using generic thin-client hardware.
They will try to convince you that using no local disks or using CF instead, somehow makes the product better, or make it last longer, while costing less to maintain, than anything using something capable of being a PC. Even though these claims have not really been shown to be true.
Otherwise you would just use uber-cheap PC hardware, instead of paying the extra premium for a brand-name "packaged thin client".
Unplug the power cable to the HDD if you want, slap an internal USB stick, or PXE boot mod, and call it a day.
In other words, the motive of companies that speicalize in thin-clients is inherently self-serving, they want to warp the industry's perception of what a thin client is.
The truth is... when you aren't talking about solutions packaged by major vendors:
Not all thin clients have to be diskless.
Not all thin clients have to be off-the-shelf products "designed originally to be thin clients"
All ultra light-weight PCs are good candidates, especially units that don't need fans for cooling or mechanical storage (e.g. systems that use SD/SDHC, CF, or SSDs, are great candidates for quiet low-power thinclients).
Sometimes a local HDD may be used to boot a thin client, or you may use PXE boot or a simple $5 USB thumb drive to startup the thin-client (despite any existence of local disk).
In some cases it could be simply read-only storage to load a ramdisk from. In other cases, there could be local caching of various things.
HDDs don't drop dead that often -- if you execute power management well, and use HDDs only to boot the thin-clients, they will be spun down most of the time, anyways, extremely low mechanical wear, and you can expect 10+ years on average, easily.
Not if your LAN is correctly configured.
Ok. 20,000 machines on a Class B subnet is ludicrous.
With so many, you should divide the LAN and subnet with routers, or if for some ludicrous reason you must keep a class B subnet, then use a LAN divided transparently with routers acting as Proxy ARP servers.
No excuses.
I think it's fair to say that FB servers generate a large amount of database I/O.
And their PHP code is likely running a lot of graph flow, pattern matching, and other data mining algorithms.
Including plaintext indexing and search algorithms
Remember, the whole point of the social network from an advertiser perspective is to select people on the network who are most likely to be interested in certain ads.
This suggests a lot of elaborate DM on FB's part.
Just because the intensive computations aren't obvious to the end-user, doesn't necessarily mean there is no heavy numerical computation being done behind the scenes.
The PC-in-a-keyboard is not a thin client--it's a full, although lightweight, computer in a keyboard.
No. It's a fricckin thin-client. This argument is something like saying a computer monitor that has an HDMI input in addition to DVI is not a monitor, because computer monitors only have DVI/VGA inputs.
OMG: being a computer doesn't disqualify something from being a thin client. All thin clients are computers.
It's the lightweight part and low-cost that by definition makes the system a thin-client.
Having a hard drive or other storage media doesn't mean it's not a thin client either.
The actual qualification to being a thin client refers to how the machine is used, not the actual specs of the machine.
For a machine to be used as a thin client, it indicates the bulk of the data processing and long-term storage will be handled by the server.
They already tried that. Apparently it did not work out too well.
Most other device makers are more interested in getting you to buy the newest toy. Which is why they aren't too keen on keeping them updated, or even working after you've paid for it.
In fact... this has advantages for the consumer.
A lower cost product.
Sure you don't get lowe-cost software updates -- but it's expensive to support your product with updates in the long run.
And that price basically has to be built into the cost of the product.
So it could be that the iPhone is the high-end $600+ product that includes updates.
Whereas the Android-based devices are the low-end units that cost maybe $100. But one of the things you lose out on in buying low-end is the ability to update after purchase.
The price is so low partly because updatability hasn't been included.
If there's demand for updates to the Android OS, on such an inexpensive device you should expect to have to buy a new one to get the update, or to have to pay $50+ for a downloadable update.
In fact, even the iPhone is pretty low price (much of the "price" goes into cost of the hardware components and payment to the carrier), and one could expect, that eventually, major version updates be for-pay, just as they are for computer OSes.
It works fine, and I use it.. And no, you don't need to stop the master on a regular basis for any reason.
Clients that perform updates have to connect to master.
For select queries, use a load balancer that connects to the slaves.
When you are creating a new slave, you replicate it first, then add it to the load balanced cluster AFTER replication is proceeding.
The asynchronous nature has some drawbacks though, since your app can never really be 100% sure that what you see is the latest version of the database.
It helps if you record in-flight transactions and "hot" data using memcached, and consult the database for cold data.
MySQL already has perfect asynchronous master-slave replication through binary logging.
What's hard is synchronous replication it would be a very useful enhancement if 5.5 had a reliable synchronous replication option, and supported clustering, failover/hot-standby, and failed-node recovery/resynch.
With Mandatory Closed Standards policy.
That is: ban on the use of open standards (due to their lack of obscurity / good security protected by the secrecy of the standard)
Oh really.. No. I think it's more of a case of RFC2821 being revisions to the standard proposed to make it more accurately reflect current implementations / current common practice.
If it were generally accepted and widely seen to have no issues, it had plenty of time to cross from PROPOSED STANDARD to Full standard.
Obviously someone (or some people) objected to rfc2821 and hold that further revisions are necessary, before a new standard is arrived at.
Meanwhile, implementors who see advantages of some of the changes in 2821 begin to incorporate some of what they see as the best improvements into their implementations.
Of course Internet Standards can't force anyone to do (or not do) anything.
MTA developers can and should play around with experimental features. It's how new standards get developed, in the first place.
RFC1123 is a standard, STD 3 is currently RFC1123. RFC2821 is currently not a standard of any kind. Check the listing in the RFC Index next time.
rfc1123 removed the relay function whereby your mail server may list other server's names in the return path.
The replacement is that only your mailserver is listed in the MAIL FROM entry. The RFC never said anything about adding some other server's address to a MAIL FROM line, that was never allowed by the standard. Your mail server can only add its own address as it is known to the mail server it is sending to period (for a new mail from: line).
To list the address in MAIL FROM: means that you (the sending mail server) are claiming you can take responsibility for being able to return mail to the address you list.
That is: by listing an address in mail from, you PROMISE you can immediately return mail to the host you received it from, if there is an error.
There are traditionally only two ways a mail server can take that responsibility: either (1) the item you list in MAIL FROM is you, and you list a local user, then of course you can return the message to your local user, OR:
(2) You are relaying the item, and you received that address in MAIL FROM. You can live up to the promise by delivering the error message to the server that relayed you the message with that address in MAIL FROM, and that server can live up to their promise, and so on.
Well, without source routing (2) is actually a stretch.
The elimination of option (2) as a way to satisfy the promise you make means that you are left with option (1) only.
Well, the section of interest is 5.2.6 of RFC1123, which killed section 3.6 of RFC 822 with the stated goal of abolishing source-routing of the destination or of the return path.
Basically, the baby was accidentally thrown out with the bathwater, and it is unfortunately way too late to do anything about it..
Now, if you go lookup that section you will find:
Of course this breaks forwarders ahem, "legitimate" forgers who want to stuff an address they have on someone else's mail server in the "MAIL FROM" line as well...
Referencing someone else's mailserver in 'MAIL FROM' is always forgery, due to the very nature of RETURN PATH. When you place your server name in the Return path, you are claiming that server said they were responsible for the message
Again, prior to rfc1123, this was a lot clearer; every relay in the path the message had passed through would appear in the MAIL FROM line.
SPF and 'MAIL FROM' / Return-Path have nothing to do with 'From' line in the e-mail message itself.
The From: line is user data, not subject to SPF checks, and doesn't have to match the return path.
Using whatever e-mail address you own in the From: line is fine.
Placing someone else's mail server's hostname in the 'MAIL FROM' or Return-Path headers is forgery, and blocking this is one of SPF's best features.
It's not harmful. That post is based on a lie.
So they have an account elsewhere, at a vanity domain or on another computer, and they forward mail from that address to whichever is their current ISP, or their employer.
The keyword is elsewhere.
RFC 1123 deprecated the concept of a proper return path. If it hadn't happened, there would be no issue.
But due to RFC 1123, if you place another mail server's hostname in the "MAIL FROM" line, you are committing forgery, regardless of any ad-hoc justification you may come up with for "permitting" it.
The abuse doesn't make a technology that stops it evil.
Particularly when there is a good workaround called SRS.
I publish SPF records.
I administer SurgeMail mail software.
Senders that don't publish SPF records are dodgy sources, and they get an automatic penalty, unless the source IP matches the MX record and listens on port 25.
Automatic +5.0 to spam score. Basically assures the sender will be hit by graylisting, and the message may ultimately be classified spam.
Fail to publish proper SPF records at you and your users' peril.