All there is is an image containing no picture, but rather rendered text that tells me I have to click on some pop-up to "authorize" a player. Yet the pop-up doesn't show up, of course, as it's probably dependent upon my letting the site run code on my computer -- not going to happen.
What I've learned from this: The studio's marketing group quite sucks. Plus, this "Vividas" junk is something to avoid in the future as well. They've pegged the lameness meter. More, they've bent the needle.
A so-called "Intrusion Prevention System" is at heart and in practice, just a firewall.
Amusingly, it's a firewall with a default open policy. Sure, it inspects the contents of packets instead of making its decisions based on address and port information alone, which is a good thing in itself. But then an IPS by default allows everything else.
If you want the hell of signature-based anti-virus (signature lag all the way up to signature lack) as your primary network protection, by all means, ditch your real firewalls and shut down your IDSes in favor of the new buzz. Your attackers will thank you.
Sadly, the site designer wants to pop up a new window and have me view the video in my web browser. They're so aggressive about that desire that they demand I break my proxy to allow them to script my system rather than just providing me a download link.
Skip it. No content so "protected" is worth watching.
Wait a minute. You said it was in your bulk folder. Then you start talking about spam. But Hotmail didn't call it spam.
The invite was certainly bulk. It arrived as a part of a large number of substantively identical email messages. Like with posts to properly run mailing lists and other legitimate bulk email, your invite was solicited, so your copy wasn't spam.
Note that bulkiness is measurable. Simply count messages that match fuzzy checksums.
Spamminess, on the other hand, is far harder to measure, as it depends on the users' sometimes erroneous recollections of whether they solicited the bulk messages.
But Hotmail didn't call it spam. They called it bulk. That sounds quite proper and accurate to me.
The "trojan" hype turned out to be about a neat little bit of icon and file type pasting on an application that also contained mp3 data, and not some real worm or the like. But here McCarthy is, still trumpeting it as if it were a big problem. The rest of his hype is of similar significance.
I know there black hats out there with dozens or more exploits for Mac OS. Why doesn't McCarthy track them down and do an article on the real holes instead?
Well, we know the answer, I think. That would take journalism. It's much easier to FUD it up than get real facts.
Nonsense. You're whining about a side-effect as if it's a motivation.
SPEWS is the Spam Prevention Early Warning System. It lists networks likely to spam.
NAC.net has a history of hosting spammers, and not removing them. NAC.net is thus a higher risk than most providers, and more of their network is listed as a result.
You really cross the line with the T word, though. I strongly suggest you grow up and cease throwing it about. Sheesh.
It's rather ironic that Ironport, which makes spam sending appliances, is now going to be behind the two most wildly inaccurate 'spam came from here' lists.
First, they started with their own 'senderbase.org' misfeature. Senderbase.org lists addresses in unassigned, reserved, and even multicast ranges as having sent dozens, hundreds or more spam messages. Apparently, they blindly pick up IP addresses forged by spammers in Received headers, and declare the forged IP as the spam origin.
Second, they'll now be supporting Spamcop. Spamcop relies upon ignorant reporters, and fails to guide them away from commonly understood errors. Thus there is much non-spam reported as spam to Spamcop. Worse, Spamcop obligingly lists the IPs that were misreported.
All in all, I think it's par for the course for spam sending appliance vendor Ironport to build on their highly inaccurate senderbase.org operation by supporting the only slightly less inaccurate Spamcop. Bravo!
Yes, that was already clear from your attempt to call what your company does something different than spam. However, if your company adds addresses to lists without the informed consent of the address owner, no matter how your company got ahold of the address, your company is spamming.
I will put it quite simply: I decide what kind of mail companies can send me. It's my mailbox. It's my property. It's my personal space. So my rules apply.
Offer me a chance to opt-in to a useful information source (deals on a particular type of book, etc.), but refrain from slamming my address into the list without my permission, and you'll be my friend.
Slam me into a list against my will, where you think you can decide what I'm interested in, then force it down my throat until I plead with you to stop (this is called opt-out), and you'll be my enemy.
When I opt out after being slammed by an enemy, I myself ensure that the opt-out works, permanently. That's because I have yet to see a company that's willing to slam me into a list without my permission in the first place ever manage to take me off that list successfully, even if they say they want to.
So I handle the opt-out myself, by banning all email from the list bombing slammer on domains and networks under my control. I've found through harsh personal experience that that's the only successful way to opt out once an unethical mainsleazer has slammed your address.
I strongly urge you to ensure that your company runs its lists without slamming addresses. Do confirmed opt-in, and you'll be my friend.
Actually, it's the particular.edu that doesn't take steps to at least reduce their spam output that sucks. Thankfully, not all.edus are as wont to make excuses in place of taking action and getting their networks under control.
Here's one way a few of the responsible.edus have ended (not just slowed, ended) their open relay abuse problem on all hosts.
Border router blocks all inbound connections to port 25, except those destined to designated campus mail hubs.
Designated campus mail hubs relay inbound mail for campus domain only.
Non-promiscuous hubs have access to internal MX information, and so know which departmental mail server (or which faculty member's linux box) should get the mail.
Outside mail senders see translated MXes (split DNS), with the internal MXes changed to that of the mail hubs.
Mail from outside arrives at mail hubs. If the mail hubs relay for that domain, the mail hubs look up internal MXes, and deliver inward.
Mail arrives; users happy. No spam relaying either, so no ORBS listing; users happy again. But best of all, overstretched sysadmins at the.edu don't have to run around securing sendmail on every single box; sysadmins happy.
If you skip the filtering of port 25 connects inbound, spammers will just port-scan your entire.edu's net and find the open faculty linux relays.
If you skip the MX translation for outside viewing, your filtering will cause timeouts.
It's best to do both the filtering and the MX translation.
If you do both, bingo, your.edu has no more problems with spam sent through promiscuous relays.
Sure, that's possible only if the institution gives a hoot. However, the alternative is continued spam relaying and continued ineffectual whining.
I choose no more whining. We fixed the problem. You can too.
This is at least the 4th, and perhaps the 5th time eBay has "ebayed" user preferences, according to the abuse desk at one of their upstreams.
eBay has apparently done it to more victims this time around, however. I think preferences are going to be ebayed other places as well if eBay continues to get away with their lies.
Hmm, would any speakers of colloquial Russian care to comment on the meaning of the term "ebayed"?
sidebar:
eBay usually sends their spam through spammer-for-hire Annuncio, like they did this time. (For those sins, among others, Annuncio/ann0.net has lost email privileges on the servers I run.) However, eBay has also sent their 'survey' spams direct. It's those we still see here from time to time.
Slashdot Mirror
Actually, it's not available.
All there is is an image containing no picture, but rather rendered text that tells me I have to click on some pop-up to "authorize" a player. Yet the pop-up doesn't show up, of course, as it's probably dependent upon my letting the site run code on my computer -- not going to happen.
What I've learned from this: The studio's marketing group quite sucks. Plus, this "Vividas" junk is something to avoid in the future as well. They've pegged the lameness meter. More, they've bent the needle.
Take a look at the authorized_keys options, in particular the ability to specify which ports can be forwarded (permitopen="host:port").
It would be very useful to have that ability globally, not just when a user has authenticated with a public key.
A so-called "Intrusion Prevention System" is at heart and in practice, just a firewall.
Amusingly, it's a firewall with a default open policy. Sure, it inspects the contents of packets instead of making its decisions based on address and port information alone, which is a good thing in itself. But then an IPS by default allows everything else.
If you want the hell of signature-based anti-virus (signature lag all the way up to signature lack) as your primary network protection, by all means, ditch your real firewalls and shut down your IDSes in favor of the new buzz. Your attackers will thank you.
Sadly, the site designer wants to pop up a new window and have me view the video in my web browser. They're so aggressive about that desire that they demand I break my proxy to allow them to script my system rather than just providing me a download link.
Skip it. No content so "protected" is worth watching.
You might want to read up on Mandatory Access Control. http://www.google.com/search?q=mandatory+access+co ntrol
You may as well want to look in on systrace(1) and systrace(4). http://www.google.com/search?q=systrace
It's not slashdotted...
t s/culture/articles/eav041902.shtml
t s/culture/articles/photo_pages/essay_proj2.cfm?ser ies=sj&ID=1&max=12&ss=off
http://www.eurasianet.org.nyud.net:8090/departmen
http://www.eurasianet.org.nyud.net:8090/departmen
Wait a minute. You said it was in your bulk folder. Then you start talking about spam. But Hotmail didn't call it spam.
The invite was certainly bulk. It arrived as a part of a large number of substantively identical email messages. Like with posts to properly run mailing lists and other legitimate bulk email, your invite was solicited, so your copy wasn't spam.
Note that bulkiness is measurable. Simply count messages that match fuzzy checksums.
Spamminess, on the other hand, is far harder to measure, as it depends on the users' sometimes erroneous recollections of whether they solicited the bulk messages.
But Hotmail didn't call it spam. They called it bulk. That sounds quite proper and accurate to me.
McCarthy seems to be quite the yellow journalist.
The "trojan" hype turned out to be about a neat little bit of icon and file type pasting on an application that also contained mp3 data, and not some real worm or the like. But here McCarthy is, still trumpeting it as if it were a big problem. The rest of his hype is of similar significance.
I know there black hats out there with dozens or more exploits for Mac OS. Why doesn't McCarthy track them down and do an article on the real holes instead?
Well, we know the answer, I think. That would take journalism. It's much easier to FUD it up than get real facts.
Nonsense. You're whining about a side-effect as if it's a motivation.
SPEWS is the Spam Prevention Early Warning System. It lists networks likely to spam.
NAC.net has a history of hosting spammers, and not removing them. NAC.net is thus a higher risk than most providers, and more of their network is listed as a result.
You really cross the line with the T word, though. I strongly suggest you grow up and cease throwing it about. Sheesh.
It's rather ironic that Ironport, which makes spam sending appliances, is now going to be behind the two most wildly inaccurate 'spam came from here' lists.
First, they started with their own 'senderbase.org' misfeature. Senderbase.org lists addresses in unassigned, reserved, and even multicast ranges as having sent dozens, hundreds or more spam messages. Apparently, they blindly pick up IP addresses forged by spammers in Received headers, and declare the forged IP as the spam origin.
Second, they'll now be supporting Spamcop. Spamcop relies upon ignorant reporters, and fails to guide them away from commonly understood errors. Thus there is much non-spam reported as spam to Spamcop. Worse, Spamcop obligingly lists the IPs that were misreported.
All in all, I think it's par for the course for spam sending appliance vendor Ironport to build on their highly inaccurate senderbase.org operation by supporting the only slightly less inaccurate Spamcop. Bravo!
Too bad about using Noos. They don't do jack to rein in their spammers, let alone disconnect their compromised customer boxes. The result:
... ad infinitum
Nov 3 16:45:17 postfix/smtpd[22369]: reject: RCPT from m85.net81-67-178.noos.fr[81.67.178.85]: 554 <twilaknox_mf@anu.andong.ac.kr>: Sender address rejected: anu.andong.ac.kr does not accept bounces (DSNs).; from=<twilaknox_mf@anu.andong.ac.kr> to=<A SPAM TRAP ADDRESS>
Nov 3 16:45:20 postfix/smtpd[4701]: reject: RCPT from m35.net81-64-230.noos.fr[81.64.230.35]: 550 <m35.net81-64-230.noos.fr[81.64.230.35]>: Client host rejected: blocked dom spam inject.; from=<whatcher_kd@centraalbeheer.nl> to=<ANOTHER SPAM TRAP ADDRESS>
Noos is bad news, and is generally not allowed access to my servers for SMTP. Full firewalling is near.
It did indeed make for some nice graphs... along with some politely expressed concern about collision rates.
The wise look at it as an opportunity to test traffic shaping on distributed web clusters.
Yes, that was already clear from your attempt to call what your company does something different than spam. However, if your company adds addresses to lists without the informed consent of the address owner, no matter how your company got ahold of the address, your company is spamming.
I will put it quite simply: I decide what kind of mail companies can send me. It's my mailbox. It's my property. It's my personal space. So my rules apply.
Offer me a chance to opt-in to a useful information source (deals on a particular type of book, etc.), but refrain from slamming my address into the list without my permission, and you'll be my friend.
Slam me into a list against my will, where you think you can decide what I'm interested in, then force it down my throat until I plead with you to stop (this is called opt-out), and you'll be my enemy.
When I opt out after being slammed by an enemy, I myself ensure that the opt-out works, permanently. That's because I have yet to see a company that's willing to slam me into a list without my permission in the first place ever manage to take me off that list successfully, even if they say they want to.
So I handle the opt-out myself, by banning all email from the list bombing slammer on domains and networks under my control. I've found through harsh personal experience that that's the only successful way to opt out once an unethical mainsleazer has slammed your address.
I strongly urge you to ensure that your company runs its lists without slamming addresses. Do confirmed opt-in, and you'll be my friend.
http://www.river.com/users/share/cluetrain/
Here's one way a few of the responsible .edus have ended (not just slowed, ended) their open relay abuse problem on all hosts.
- Border router blocks all inbound connections to port 25, except those destined to designated campus mail hubs.
- Designated campus mail hubs relay inbound mail for campus domain only.
- Non-promiscuous hubs have access to internal MX information, and so know which departmental mail server (or which faculty member's linux box) should get the mail.
- Outside mail senders see translated MXes (split DNS), with the internal MXes changed to that of the mail hubs.
- Mail from outside arrives at mail hubs. If the mail hubs relay for that domain, the mail hubs look up internal MXes, and deliver inward.
- Mail arrives; users happy. No spam relaying either, so no ORBS listing; users happy again. But best of all, overstretched sysadmins at the
.edu don't have to run around securing sendmail on every single box; sysadmins happy.
If you skip the filtering of port 25 connects inbound, spammers will just port-scan your entireIf you skip the MX translation for outside viewing, your filtering will cause timeouts.
It's best to do both the filtering and the MX translation.
If you do both, bingo, your .edu has no more problems with spam sent through promiscuous relays.
Sure, that's possible only if the institution gives a hoot. However, the alternative is continued spam relaying and continued ineffectual whining.
I choose no more whining. We fixed the problem. You can too.
eBay has apparently done it to more victims this time around, however. I think preferences are going to be ebayed other places as well if eBay continues to get away with their lies.
Hmm, would any speakers of colloquial Russian care to comment on the meaning of the term "ebayed"?
sidebar: