I own "delete.net", I ended up turning the domain's incoming mail into an automatic blacklist for my server. The volume of spam has gone down quite a bit since I started- instead of thousands per hour, it's down to several hundred per day.
My own web site does it... www.jms1.net... or for those not using IE, www.jms1.net/ie.html is what the IE people are seeing. (And before every moron on the planet decides to tell me this at the same time, I already know you can use google's cache to view the site.)
Surely I'm not the only person out there who excludes IE from accessing their web site?
If you get enough trash back because of users, the nicest way is to let the mailserver handle it. A CPU can do the dumping a lot faster than a person can lookup an account, and take the person of the mailinglist
Again you state that your mail server is "dumping" the bounces as they come in. Does your definition of "dumping" mean it's removing the bad email addresses from your list?
If you are removing the bad addresses when bounces come in, whether manually or using an automatic process, then you need to explain what "dumping" means when you describe this process to other people. Most of us think of "dumping" as meaning "throwing away".
However, if your server is ignoring and/or throwing away these bounce messages, then in my book you are a spammer.
We send everybody a welcome message with a login. So they need to be active to get started.
How do they become "active" in the first place? Do they just visit your web site and put in an email address? What would prevent me from visiting your web site and putting in a hundred random email addresses, causing you to send your messages to those people? Is there a second verification step (known as "double verified opt-in") which happens afterwards, or do you just add them to the list and hope that the person will unsubscribe if the signup was bogus?
I'm not trying to sound like a jerk, but in ten years of running ISP's I have seen these same arguments before. Unless you are doing a double verified opt-in, you don't know for sure that the email address you have actually represents a person who wants to receive your messages. Sending a verification request to the email address, and receiving a positive response to that message, is the only way to be sure that the request is genuine.
It sounds like you want people to think you are a "responsible" sender of email, but then you admit the following:
Your mail server throws away bounce messages, rather than routing them to a human being who can remove the bad addresses from your list. Every bounce message you ignore is essentially stolen bandwidth and CPU on somebody else's server- if you were truly a responsible mailer, you would take steps to minimize your impact on others' systems.
You have to "craft the messages" to get around spamassassin. This tells me that YOU KNOW whatever you're sending is likely to be considered spam, and yet you send it anyway- ESPECIALLY where you know that your list has "hundreds of wrong/fake" email addresses. How fscking rude.
The fact that you even HAVE wrong or fake email addresses on your list is an indicator that your signup method is flawed. You should be using a double opt-in mechanism, if for no other reason than when somebody calls one of your messages spam, you can forward them back a copy of the message you received which agreed to receive it.
All of these are common traits of the spammer's trade. Do us all a favor- post the IP address of the machine which sends this list, so that we can blacklist you now.
The way iTunes is designed, in order to play a music track on a PC, you have to install Quicktime on the PC as well - not everyone wants Quicktime on their PC to be honest. And so on.
Quicktime is required for two reasons: (1) iTunes uses the quicktime libraries to do the actual sound output, and (2) the DRM functions which do the decryption (and the encryption, when you make a purchase from ITMS) are part of the quicktime libraries.
Here's what Apple's FairPlay DRM means for users: any iPod can play any iTMS-purchased AAC, which implies there is a master key for decoding the FairPlay file.
There is no "master key" for FairPlay- every song is encrypted as it's purchased, and the encryption key is tied to the account which purchased the song. In fact, the encryption is done on the computer which downloads the file- the actual transmission of the song from ITMS to the computer is not DRM-protected. The only thing preventing a packet sniffer from grabbing the raw file is the fact that the transfer happens inside of an SSL connection.
When the computer copies the encrypted song to an iPod, the key is copied as well (if it's not already there- I have about 200 songs from ITMS, and most of them are encrypted with the same key. The program seems to generate new keys every few months.) Programs like jhymn simply read the key from the iPod's key repository and use it to decrypt the audio chunks in the.m4p file, writing the result out as an.m4a file.
... is who the US report quotes as having problems with Canada's rejection of the DMCA. Like this quote...
The U.S. copyright industry is concerned about proposed copyright legislation...
... or this one...
The U.S. pharmaceutical industry is concerned about certain aspects of the proposed regulations...
I didn't see anything in the report about "the American PEOPLE" having a problem with Canada's internal policies.
Speaking as one of the PEOPLE that the US government is supposed to be representing, I'd like to know why they give a flying fsck what "the U.S. {anything} industry" thinks? Isn't it their job to represent the PEOPLE of the United States?
I have a friend who works for a large US company (no names, but it sounds a bit like "moo-sent") which makes the cell tower equipment used by several of the large american carriers, especially Verizon with their new high-speed data service. The last time I visited his office, he showed me the CALEA (Communication Assistance for Law Enforcement Act of 1994) box from their in-house system mock-up (used for training Verizon's techs.)
In a normal market area, all of a carrier's towers are linked back to a single facility for the entire market, and that facility contains the links to the wireline carriers. Inside this data center, the sound channels of all of the calls on all of the towers are sorted out and routed to the appropriate wireline ports. The equipment which does this knows how to do a "wiretap"- as a call starts, if either the caller's number or the number being called are listed in a certain database, the call is set up with a copy of the audio being routed to what is essentially a WAV file. When the call is done, that WAV file is immediately emailed to whatever law enforcement person is interested.
IN THEORY, the law enforcement types are supposed to show a court order before being able to add numbers to the database. IN REALITY, the carrier (at least Verizon) provides an SSL-secured web interface where law enforcement can just go and enter the number and an email address. The carrier does not perform any verification of whether or not there is a valid court order, they stay as close to hands-off as they can.
I wonder if my bank would be gracious enough to issue me a defunct credit card that I could use specifically for this purpose.
If you call your bank and report your current card as stolen, they will cancel the current number and send you a new card with a different number. As long as you don't mind being without a card for the week it takes them to get the new one to you, and you don't have any automated charges assigned to the old card number, that old card number becomes an instant fraud flag. You can feed that number to the phishers, then tell the bank to back-track the authorization attempts to find the scumbags.
Actually, the phones which are capable of being infected by this virus are NOT the ones they give away free. These are all running SymbianOS, which means for the most part they are high-end phones which have PDA and/or computer capabilities.
My own telephone is one which could be infected. I have already contacted T-Mobile to find out if they plan on filtering this as it passes through their servers. In the meantime, I just won't accept MMS messages from people I know without verifying that the sender actually meant to send them... and of course I wouldn't accept an MMS message from somebody I don't know in the first place, so unless the virus writers find a way around the "user must accept the message" requirement, I don't feel myself to be in any danger.
The one in Altamonte Springs on 434 just south of 436 (two doors down from the wal-mart) also has the stickers on the door. I haven't used it but I have seen several people sitting around in there with laptops.
That's what I'm doing with delete.net, one big honeypot. Anything sent to it is automatically forwarded to spamcop, and the sending IP is added to the "rbl.delete.net" blacklist, which I use for my own server, but do not recommend anybody else use because there is no automated removal process- it's all manual and it's all whenever I feel like getting around to it.
I'm also serving an SPF record for delete.net which tells any interested server that there are no valid IP addresses which are allowed to send mail claiming to be from that domain. Anybody whose server checks SPF for incoming mail will automatically know that any messages claiming to be "From: slashdot@delete.net " are forged. (And yes, I put what looks like a real email address just to bait any harvesters which may be reading this.)
To me, ASK looks just like TMDA. I already use TMDA as a challenge-response mechanism for my own inbox, however I am (usually) careful about manually whitelisting strangers before emailing them. I also watch TMDA's logs to make sure it's not stopping anybody I know, and I have customized the challenge message to fully explain what's going on. It even apologizes to the sender in advance for the trouble. I have never had a problem with it, and over the last year I've only had one spam message actually get through it.
I have seen several web pages written by people who don't like these challenge-response mechanisms, including one earlier today which went so far as to say that if he receives such a challenge, he will delete it- even if it's from one of his customers asking for help. This seems a bit extreme to me, but I can understand his frustration- it is an extra step which shouldn't really be necessary. It's a pain to have to deal with it, both for the sender (who has to respond to the challenges) and the recipient (who sends out the challenges, and has to deal with people calling on the phone to complain about them.)
It's a very touchy situation, having to ask your clients to prove that they are human beings instead of spam-sending robot programs... but if you keep a close eye on the mechanism, manually whitelist as many legitimate people as you can, and watch the log file to catch anybody you know, it can be a workable solution (as it has been for me.)
However, having spent ten years building and running ISPs, I can say that there is no way I would ever force something like this on my clients. I might try to find a way to ALLOW my clients to use it on their mailboxes if they want to, but I certainly wouldn't just turn it on for every single email address- trying to explain it to somebody who receives a challenge is hard enough without having to try and explain the whole mechanism to some old lady who knows nothing about computers and just wants to receive email from her grandkids and her sewing circle. I remember the pain of trying to explain blacklists to these people...
Seems like an awful lot of trouble for a would-be spammer to find your ISP and sign up for service with them, just so they could joe-job YOUR company. I think it would be easier for the spammer to choose a different domain name which doesn't already have an SPF record and joe-job them instead. However, you do have a point when you talk about a deliberate attacker- but I think if somebody is determined enough to attack your company, they're probably going to do more than just a joe-job.
Another point... the reverse-dns name for your ISP's mail server makes no difference to the SPF mechanism. When a mail server checks an SPF record as part of receiving an incoming message, and that SPF record contains an "a" tag, the mail server does a forward dns query on the domain name and compares the answer with the IP address at the other end of the socket.
The only time reverse-dns becomes part of the process is with the "ptr" tag- and even then it's only a part of the process. The description of the ptr mechanism says that a server should take the PTR result and verify that it forward-resolves back to the same IP address. This prevents a spammer who has control over their IP's reverse DNS from forging a PTR record with your domain's name and "allowing" themselves to send mail claiming to be from your domain.
once you figure out how to get past their flash demo you can use the "help" button at the top right and eventually find http://help.emusic.com/emsub/3859.asp, which has the run-down on the pricing.
it's priced as a subscription plan. you pay a monthly fee and are able to download "up to" a certain number of MP3 files during the month... it's $9.99/mo for 40, $14.99 for 65, or $19.99 for 90 songs per month. if you want to go over your limit they sell "booster tracks" (the help pages don't give any pricing info on these) and if you don't use your entire limit for a month they don't carry over to the next month.
I actually was in the same situation a few years back- I was originally offered a "management" job at an ISP, which would have been all paperwork and dealing with vendors- I told them no, but if they had a high-level system/network admin job I would take it in a heartbeat... so they created one for me, and then wanted me to help interview people for the original management job.
The one question that I always made sure to ask when interviewing somebody, usually late in the interview, was "Why is the sky blue?"
Not so much because I wanted to know if they knew the answer (if they said the word "nitrogen" anywhere in their answer I gave them credit for it) but because I wanted to watch their face and see how they reacted to a totally unexpected question which is probably the furthest thing from their mind at the time.
This is important in the ISP industry, because you'll get into a rut of constantly being bombarded with the same things over and over, and then out of nowhere comes a totally unexpected situation and you have to know how to handle it without going "huh?" in front of a customer.
Following links from links from the article, I came across http://www.ti.com/tiris/ which is the list of the RFID equipment that TI is already selling to companies. In fact, their item RI-TRP-RFOB looks exactly like the Mobil SpeedPass that I stopped using a few months ago, although I wonder which version it is- they have a 64-bit read-only, an 80-bit read-write, and an 88-bit read-only with a challenge-response mechanism, all working at 134.2kHz.
Even better (or worse for consumers,) their RI-I01-110A looks a lot like the square "anti-theft" stickers that I've seen on different items at Wal-Mart for years... which leads me to believe that pretty much every Wal-Mart in the country already has RFID readers at the doors, and they just need to install more 13.56MHz tags on/in their merchandise in order to attain their dream of "total retail visibility".
I wonder if the "de-activate" device they have at the cash registers is actually turning off the tag, or if it's just registering the tag as "sold" in a separate computer system which is (as far as you and I know) only being used for loss prevention purposes, and the reader looks up the serial number and recognizes it as sold and therefore doesn't squeal at you when you walk out the door.
I also have an idea for a device I'd like to see on the market, which would read an RFID tag, show you what data is contained in it, and which could "toast" a tag after you get it home- so you could verify that it is indeed shut off. It would have to work with several frequency bands, and would probably have the same low power limits that the in-store readers are limited to (in order to get FCC type-acceptance.) Free idea for a business venture if somebody knows how to build such a beast, and I'll be one of your first customers...
Quicktime gets installed with iTunes because, at least under OSX, the functions which handle the encryption and decryption are in the file/System/Library/Frameworks/QuickTime.framework/Ver sions/Current/QuickTime (which is a shared library.) Try "nm QuickTime | grep DRM" and you'll see the functions there.
This allows not only iTunes, but the Quicktime player and any other application which uses the Quicktime API (like Toast, with their "Save as AIFF" button, hint hint) to decrypt these protected files, in order to play them or to burn them to a CD.
Any bets on how long it will be before script kiddies (and other unsavory characters) start recording, disconnecting, cutting into, and otherwise interfering with telephone calls for fun?
I've spent the last nine years building and running ISP's in the Orlando area, and have done more than my share of tracking down the owners of IP blocks to make sure that when I block an IP block, I don't block too many people close to the spammer.
One problem I have always run into is the lack of information about the owners of these netblocks. The spam situation is one of the reasons ARIN maintains a SWIP database, showing who owns each particular block of IP addresses. Whenever SWIP information is out there, I use it as the basis of how big a block to add to my list, especially if the owner of the smallest block is "ABC Internet Marketing" or something similar.However in many cases the information just plain isn't there.
For example, I have received 257 spam messages from 204.127.131.(111-133) over the past three weeks. The SWIP database shows this as part of a/16 block belonging to AT&T, but there is no further information available.
I had to GUESS and block 204.127.131.0/24, but I may have blocked others in the same class c by mistake. If AT&T would make specific netblock information available through SWIP or an RWHOIS server, I wouldn't have to guess and I wouldn't be running the risk of accidentally blocking people who don't deserve it.
Maybe if the ISP's would actually publish their SWIPS like they were supposed to, this type of collateral damage wouldn't have to happen. (Are you listening, AT&T?)
Slashdot Mirror
I own "delete.net", I ended up turning the domain's incoming mail into an automatic blacklist for my server. The volume of spam has gone down quite a bit since I started- instead of thousands per hour, it's down to several hundred per day.
My own web site does it... www.jms1.net... or for those not using IE, www.jms1.net/ie.html is what the IE people are seeing. (And before every moron on the planet decides to tell me this at the same time, I already know you can use google's cache to view the site.)
Surely I'm not the only person out there who excludes IE from accessing their web site?
(Self-slashdotting... is that like suicide?)
If you are removing the bad addresses when bounces come in, whether manually or using an automatic process, then you need to explain what "dumping" means when you describe this process to other people. Most of us think of "dumping" as meaning "throwing away".
However, if your server is ignoring and/or throwing away these bounce messages, then in my book you are a spammer.
How do they become "active" in the first place? Do they just visit your web site and put in an email address? What would prevent me from visiting your web site and putting in a hundred random email addresses, causing you to send your messages to those people? Is there a second verification step (known as "double verified opt-in") which happens afterwards, or do you just add them to the list and hope that the person will unsubscribe if the signup was bogus?I'm not trying to sound like a jerk, but in ten years of running ISP's I have seen these same arguments before. Unless you are doing a double verified opt-in, you don't know for sure that the email address you have actually represents a person who wants to receive your messages. Sending a verification request to the email address, and receiving a positive response to that message, is the only way to be sure that the request is genuine.
- Your mail server throws away bounce messages, rather than routing them to a human being who can remove the bad addresses from your list. Every bounce message you ignore is essentially stolen bandwidth and CPU on somebody else's server- if you were truly a responsible mailer, you would take steps to minimize your impact on others' systems.
- You have to "craft the messages" to get around spamassassin. This tells me that YOU KNOW whatever you're sending is likely to be considered spam, and yet you send it anyway- ESPECIALLY where you know that your list has "hundreds of wrong/fake" email addresses. How fscking rude.
- The fact that you even HAVE wrong or fake email addresses on your list is an indicator that your signup method is flawed. You should be using a double opt-in mechanism, if for no other reason than when somebody calls one of your messages spam, you can forward them back a copy of the message you received which agreed to receive it.
All of these are common traits of the spammer's trade. Do us all a favor- post the IP address of the machine which sends this list, so that we can blacklist you now.According to DVD Jon's web site, it is AES.
I wasn't aware that MacOS iTunes had trapped ptrace() but it doesn't surprise me...
I find it rather telling that CNN and Fox News didn't mention this until AFTER the vote was done...
Quicktime is required for two reasons: (1) iTunes uses the quicktime libraries to do the actual sound output, and (2) the DRM functions which do the decryption (and the encryption, when you make a purchase from ITMS) are part of the quicktime libraries.
When the computer copies the encrypted song to an iPod, the key is copied as well (if it's not already there- I have about 200 songs from ITMS, and most of them are encrypted with the same key. The program seems to generate new keys every few months.) Programs like jhymn simply read the key from the iPod's key repository and use it to decrypt the audio chunks in the .m4p file, writing the result out as an .m4a file.
I didn't see anything in the report about "the American PEOPLE" having a problem with Canada's internal policies.
Speaking as one of the PEOPLE that the US government is supposed to be representing, I'd like to know why they give a flying fsck what "the U.S. {anything} industry" thinks? Isn't it their job to represent the PEOPLE of the United States?
I have a friend who works for a large US company (no names, but it sounds a bit like "moo-sent") which makes the cell tower equipment used by several of the large american carriers, especially Verizon with their new high-speed data service. The last time I visited his office, he showed me the CALEA (Communication Assistance for Law Enforcement Act of 1994) box from their in-house system mock-up (used for training Verizon's techs.)
In a normal market area, all of a carrier's towers are linked back to a single facility for the entire market, and that facility contains the links to the wireline carriers. Inside this data center, the sound channels of all of the calls on all of the towers are sorted out and routed to the appropriate wireline ports. The equipment which does this knows how to do a "wiretap"- as a call starts, if either the caller's number or the number being called are listed in a certain database, the call is set up with a copy of the audio being routed to what is essentially a WAV file. When the call is done, that WAV file is immediately emailed to whatever law enforcement person is interested.
IN THEORY, the law enforcement types are supposed to show a court order before being able to add numbers to the database. IN REALITY, the carrier (at least Verizon) provides an SSL-secured web interface where law enforcement can just go and enter the number and an email address. The carrier does not perform any verification of whether or not there is a valid court order, they stay as close to hands-off as they can.
http://www.jms1.net/ie.html
- or -
http://www.jms1.net/{anything else} if you're running IE.
mushroom, mushroom...
If you call your bank and report your current card as stolen, they will cancel the current number and send you a new card with a different number. As long as you don't mind being without a card for the week it takes them to get the new one to you, and you don't have any automated charges assigned to the old card number, that old card number becomes an instant fraud flag. You can feed that number to the phishers, then tell the bank to back-track the authorization attempts to find the scumbags.
Actually, the phones which are capable of being infected by this virus are NOT the ones they give away free. These are all running SymbianOS, which means for the most part they are high-end phones which have PDA and/or computer capabilities.
My own telephone is one which could be infected. I have already contacted T-Mobile to find out if they plan on filtering this as it passes through their servers. In the meantime, I just won't accept MMS messages from people I know without verifying that the sender actually meant to send them... and of course I wouldn't accept an MMS message from somebody I don't know in the first place, so unless the virus writers find a way around the "user must accept the message" requirement, I don't feel myself to be in any danger.
The one in Altamonte Springs on 434 just south of 436 (two doors down from the wal-mart) also has the stickers on the door. I haven't used it but I have seen several people sitting around in there with laptops.
Actually, the amateur radio bands are licensed- which is why amateurs are required to get licenses.
-John KG4ZOW
That's what I'm doing with delete.net, one big honeypot. Anything sent to it is automatically forwarded to spamcop, and the sending IP is added to the "rbl.delete.net" blacklist, which I use for my own server, but do not recommend anybody else use because there is no automated removal process- it's all manual and it's all whenever I feel like getting around to it.
I'm also serving an SPF record for delete.net which tells any interested server that there are no valid IP addresses which are allowed to send mail claiming to be from that domain. Anybody whose server checks SPF for incoming mail will automatically know that any messages claiming to be "From: slashdot@delete.net " are forged. (And yes, I put what looks like a real email address just to bait any harvesters which may be reading this.)
I have seen several web pages written by people who don't like these challenge-response mechanisms, including one earlier today which went so far as to say that if he receives such a challenge, he will delete it- even if it's from one of his customers asking for help. This seems a bit extreme to me, but I can understand his frustration- it is an extra step which shouldn't really be necessary. It's a pain to have to deal with it, both for the sender (who has to respond to the challenges) and the recipient (who sends out the challenges, and has to deal with people calling on the phone to complain about them.) It's a very touchy situation, having to ask your clients to prove that they are human beings instead of spam-sending robot programs... but if you keep a close eye on the mechanism, manually whitelist as many legitimate people as you can, and watch the log file to catch anybody you know, it can be a workable solution (as it has been for me.)
However, having spent ten years building and running ISPs, I can say that there is no way I would ever force something like this on my clients. I might try to find a way to ALLOW my clients to use it on their mailboxes if they want to, but I certainly wouldn't just turn it on for every single email address- trying to explain it to somebody who receives a challenge is hard enough without having to try and explain the whole mechanism to some old lady who knows nothing about computers and just wants to receive email from her grandkids and her sewing circle. I remember the pain of trying to explain blacklists to these people...
Another point... the reverse-dns name for your ISP's mail server makes no difference to the SPF mechanism. When a mail server checks an SPF record as part of receiving an incoming message, and that SPF record contains an "a" tag, the mail server does a forward dns query on the domain name and compares the answer with the IP address at the other end of the socket.
The only time reverse-dns becomes part of the process is with the "ptr" tag- and even then it's only a part of the process. The description of the ptr mechanism says that a server should take the PTR result and verify that it forward-resolves back to the same IP address. This prevents a spammer who has control over their IP's reverse DNS from forging a PTR record with your domain's name and "allowing" themselves to send mail claiming to be from your domain.
it's priced as a subscription plan. you pay a monthly fee and are able to download "up to" a certain number of MP3 files during the month... it's $9.99/mo for 40, $14.99 for 65, or $19.99 for 90 songs per month. if you want to go over your limit they sell "booster tracks" (the help pages don't give any pricing info on these) and if you don't use your entire limit for a month they don't carry over to the next month.
I actually was in the same situation a few years back- I was originally offered a "management" job at an ISP, which would have been all paperwork and dealing with vendors- I told them no, but if they had a high-level system/network admin job I would take it in a heartbeat... so they created one for me, and then wanted me to help interview people for the original management job.
The one question that I always made sure to ask when interviewing somebody, usually late in the interview, was "Why is the sky blue?"
Not so much because I wanted to know if they knew the answer (if they said the word "nitrogen" anywhere in their answer I gave them credit for it) but because I wanted to watch their face and see how they reacted to a totally unexpected question which is probably the furthest thing from their mind at the time.
This is important in the ISP industry, because you'll get into a rut of constantly being bombarded with the same things over and over, and then out of nowhere comes a totally unexpected situation and you have to know how to handle it without going "huh?" in front of a customer.
Following links from links from the article, I came across http://www.ti.com/tiris/ which is the list of the RFID equipment that TI is already selling to companies. In fact, their item RI-TRP-RFOB looks exactly like the Mobil SpeedPass that I stopped using a few months ago, although I wonder which version it is- they have a 64-bit read-only, an 80-bit read-write, and an 88-bit read-only with a challenge-response mechanism, all working at 134.2kHz.
Even better (or worse for consumers,) their RI-I01-110A looks a lot like the square "anti-theft" stickers that I've seen on different items at Wal-Mart for years... which leads me to believe that pretty much every Wal-Mart in the country already has RFID readers at the doors, and they just need to install more 13.56MHz tags on/in their merchandise in order to attain their dream of "total retail visibility".
I wonder if the "de-activate" device they have at the cash registers is actually turning off the tag, or if it's just registering the tag as "sold" in a separate computer system which is (as far as you and I know) only being used for loss prevention purposes, and the reader looks up the serial number and recognizes it as sold and therefore doesn't squeal at you when you walk out the door.
I also have an idea for a device I'd like to see on the market, which would read an RFID tag, show you what data is contained in it, and which could "toast" a tag after you get it home- so you could verify that it is indeed shut off. It would have to work with several frequency bands, and would probably have the same low power limits that the in-store readers are limited to (in order to get FCC type-acceptance.) Free idea for a business venture if somebody knows how to build such a beast, and I'll be one of your first customers...
Quicktime gets installed with iTunes because, at least under OSX, the functions which handle the encryption and decryption are in the file /System/Library/Frameworks/QuickTime.framework/Ver sions/Current/QuickTime (which is a shared library.) Try "nm QuickTime | grep DRM" and you'll see the functions there.
This allows not only iTunes, but the Quicktime player and any other application which uses the Quicktime API (like Toast, with their "Save as AIFF" button, hint hint) to decrypt these protected files, in order to play them or to burn them to a CD.
Any bets on how long it will be before script kiddies (and other unsavory characters) start recording, disconnecting, cutting into, and otherwise interfering with telephone calls for fun?
I've spent the last nine years building and running ISP's in the Orlando area, and have done more than my share of tracking down the owners of IP blocks to make sure that when I block an IP block, I don't block too many people close to the spammer.
/16 block belonging to AT&T, but there is no further information available.
One problem I have always run into is the lack of information about the owners of these netblocks. The spam situation is one of the reasons ARIN maintains a SWIP database, showing who owns each particular block of IP addresses. Whenever SWIP information is out there, I use it as the basis of how big a block to add to my list, especially if the owner of the smallest block is "ABC Internet Marketing" or something similar.However in many cases the information just plain isn't there.
For example, I have received 257 spam messages from 204.127.131.(111-133) over the past three weeks. The SWIP database shows this as part of a
I had to GUESS and block 204.127.131.0/24, but I may have blocked others in the same class c by mistake. If AT&T would make specific netblock information available through SWIP or an RWHOIS server, I wouldn't have to guess and I wouldn't be running the risk of accidentally blocking people who don't deserve it.
Maybe if the ISP's would actually publish their SWIPS like they were supposed to, this type of collateral damage wouldn't have to happen. (Are you listening, AT&T?)