...and they're STILL arriving on port 25 on the target box. Where were you planning on doing the "remote assembly?" THAT box is STILL going to have to hit port 25 on the target mailserver.
I reiterate that the TARGET PORT on the mailserver is still going to have to be port 25/TCP, unless you're bringing up a very non-standard non-SMTP target.
It'd be a whole lot easier to deal with Comcast's crap if they'd simply publish SPF records for their mailservers.
Anyone who had no interest in communicating with Comcast client boxes could just drop non-SPF-validated traffic with no further ado, without having to track Comcast's use of "client," "client1," "client2," et cetera ad nauseam.
Other hosts could whitelist individual servers if they needed to/chose to.
Fabulous. Try delivering e-mail to any "real" mailserver on any port other than port 25. Go ahead. I dare you.
You can SEND FROM any port you like, but you're going to have to connect to a destination port 25 on the target box before anything gets delivered, in the vast majority of circumstances. (i.e., barring any misconfiguration, deliberate or otherwise, that results in the SMTPD listening on ports other than 25.)
Please go do some reading on the subject before embarrassing yourself again.
They now have a choice - how much is it going to cost them if they do NOT implement some policy that prevents their users from spamming the entire world, and they end up getting all of their e-mail blocked?
And how much money could have been saved if they'd implemented such a policy when people started telling them it was a problem (it's been several years since people started telling Comcast that their users were a load of USDA Prime Clue-Free Spam Zombies...)
It's interesting how much money can be saved by paying attention to the small, seemingly innocent details before they add up to be monstrous problems.
Let's assume for a moment that someone is running a mailserver on their own machine, but they've configured it to relay outbounce through Comcast's own mailservers.
Now, assume that the mailserver in question is listening on port 25 to ANY incoming e-mail, and is also configured to function as an open relay.
This is commonly called a "multistage relay," and will result in Comcast's mailservers being listed on various DNSBLs in a real hurry.
If a provider is going to be blocking port 25, I believe they need to be blocking it in both directions, if only in self-preservation.
If a spammer wants to send a message to a machine that they've compromised, yes, they can send it to any bloody port they feel like configuring and using.
If they want to drop spam on a well-configured and usable mail server, they MUST deliver the spam to port 25 on that server (or other ports that are deliberately configure to receive incoming SMTP traffic.)
It doesn the spammer absolute no good to attempt delivery to any mailserver I control on port 25. They're either going to get a connection denied, or let their outbound spam rattle the cage on, say, port 80 or 443 - end result, a couple of lines of log entries on Apache, and no spam delivered.
If those zombie machines are not allowed to send mail out to target port 25, then they cannot deliver spam.
If the spammer wants to *send* spam out, they're going to aim at port 25 on the target box.
If they aim at any other port, they're very likely to see nothing but "Connection denied" messages.
I've already got most of Comcast simply blocked from my mailservers, simply because I never see anything but spam coming from them:/^.*\.client\.comcast\.net/ 550 comcast direct-to-mx
If they REALLY want to send me e-mail, they need to send it through a non-client address (for example, through Comcast's own mailservers...)
It's nice to see that someone at Comcast is waking up, though. I'd been reporting spam coming from a triplet of IP addresses for approximately four months before I simply blackholed the entire/24 there.
Now, to see if they can actually *do* anything about the problem they just noticed...
"But upgrading to XP 64 could mean giving up functionality without getting much in return. In fact, XP 64 looks like a throwback to Windows past: Its interface mirrors that of Windows 2000 or even Win 98. Microsoft has not disclosed what else will be in the OS, so it is possible that you'll still get most of XP's other features.
XP 64 won't have the 32-bit XP's support for DOS apps at all, nor will it run 16-bit apps (but it should have no trouble with 32-bit software). More important, 64-bit drivers for common hardware, such as printers, will be scarce when the OS debuts."
In moving from a Dual 1GHz G4 (Quicksilver 2002) to a Dual 2GHz G5, I have yet to find any software incompatibilities - everything works just fine.
This may change once my copy of Panther shows up, but my printer and other hardware continue to work for now.
Are you saying that driving with your head tilted 80 degrees to the side to press the tiny cellphone against your shoulder doesn't increase the level of "distraction" by any measurable amount?
Or that trying to juggle the stick shift, the steering wheel, the $BEVERAGE, and the cellphone isn't more dangerous than just the stick, wheel, and $BEVERAGE?
I've lost count of the number of times I've seen the silly bint in front of me try to look into his rearview mirror so he can try merging left, only to lose the cellphone he was holding between his empty head and his shoulder, then try to recover from dropping it while swerving halfway into *both* of the other lanes (left *and* right!)
I won't go so far as to say using a headset *removes* the distraction, but it certainly reduces it by quite a lot over trying to drive with the damned thing in your hand. Voice control over the headset also removes the distraction of trying to *dial* while driving.
That seems... odd. When I was working independently doing contracting, it was a two-hour minimum, and most of my business came from four or five customers who repeatedly called back for more.
So Korea leads the world in broadband connections... They also lead the world in open relays and in spamming people with messages they can't even read.
My own mailserver doesn't accept incoming connections from Korea - at the time I inserted korea.blackholes.us into the dnsbl list, I had received ONE legitimate e-mail from Korea, and over four thousand spams from Korea.
"Buh-bye, Korea." I'll take them out of the filters as soon as the logs indicate less than once bounce per week instead of 30-50 bounces per day.
Hell's bells... back in the late 1990's, (1998ish?) even MOTOROLA, the manufacturer of the chips that Apple uses, decided to phase out all of their aging Macintoshes and replace them with Wintel machines running NT.
Of course, I think this had less to do with the NT boxes being easier to use or cheaper to support than the fact that Apple yanked Motorola's clone license...
Slashdot Mirror
No, Comcast was suggesting blocking/redirecting outbound traffic that targeted port 25, regardless of source port.
Reread the article.
...and they're STILL arriving on port 25 on the target box. Where were you planning on doing the "remote assembly?" THAT box is STILL going to have to hit port 25 on the target mailserver.
I reiterate that the TARGET PORT on the mailserver is still going to have to be port 25/TCP, unless you're bringing up a very non-standard non-SMTP target.
It'd be a whole lot easier to deal with Comcast's crap if they'd simply publish SPF records for their mailservers.
Anyone who had no interest in communicating with Comcast client boxes could just drop non-SPF-validated traffic with no further ado, without having to track Comcast's use of "client," "client1," "client2," et cetera ad nauseam.
Other hosts could whitelist individual servers if they needed to/chose to.
Fabulous. Try delivering e-mail to any "real" mailserver on any port other than port 25. Go ahead. I dare you.
You can SEND FROM any port you like, but you're going to have to connect to a destination port 25 on the target box before anything gets delivered, in the vast majority of circumstances. (i.e., barring any misconfiguration, deliberate or otherwise, that results in the SMTPD listening on ports other than 25.)
Please go do some reading on the subject before embarrassing yourself again.
They now have a choice - how much is it going to cost them if they do NOT implement some policy that prevents their users from spamming the entire world, and they end up getting all of their e-mail blocked?
And how much money could have been saved if they'd implemented such a policy when people started telling them it was a problem (it's been several years since people started telling Comcast that their users were a load of USDA Prime Clue-Free Spam Zombies...)
It's interesting how much money can be saved by paying attention to the small, seemingly innocent details before they add up to be monstrous problems.
Let's assume for a moment that someone is running a mailserver on their own machine, but they've configured it to relay outbounce through Comcast's own mailservers.
Now, assume that the mailserver in question is listening on port 25 to ANY incoming e-mail, and is also configured to function as an open relay.
This is commonly called a "multistage relay," and will result in Comcast's mailservers being listed on various DNSBLs in a real hurry.
If a provider is going to be blocking port 25, I believe they need to be blocking it in both directions, if only in self-preservation.
Minor correction: "It doesn't do the spammer any good to attempt delivery on any port OTHER than 25..."
You've missed the point entirely.
If a spammer wants to send a message to a machine that they've compromised, yes, they can send it to any bloody port they feel like configuring and using.
If they want to drop spam on a well-configured and usable mail server, they MUST deliver the spam to port 25 on that server (or other ports that are deliberately configure to receive incoming SMTP traffic.)
It doesn the spammer absolute no good to attempt delivery to any mailserver I control on port 25. They're either going to get a connection denied, or let their outbound spam rattle the cage on, say, port 80 or 443 - end result, a couple of lines of log entries on Apache, and no spam delivered.
If those zombie machines are not allowed to send mail out to target port 25, then they cannot deliver spam.
If the spammer wants to *send* spam out, they're going to aim at port 25 on the target box.
/^.*\.client\.comcast\.net/ 550 comcast direct-to-mx
/24 there.
If they aim at any other port, they're very likely to see nothing but "Connection denied" messages.
I've already got most of Comcast simply blocked from my mailservers, simply because I never see anything but spam coming from them:
If they REALLY want to send me e-mail, they need to send it through a non-client address (for example, through Comcast's own mailservers...)
It's nice to see that someone at Comcast is waking up, though. I'd been reporting spam coming from a triplet of IP addresses for approximately four months before I simply blackholed the entire
Now, to see if they can actually *do* anything about the problem they just noticed...
Why would I want to buy a virus scanner?
ClamAV, among others, compiles and runs just fine under Mac OS X...
I was actually a user on the ISP from which Canter and Siegel spammed - "Internet Direct," in Phoenix, Arizona.
We were pretty much without e-mail for three or four days as the world reacted to their Usenet spam runs.
There's a pretty good synopsis of the whole mess at the Spam Warz page. Scroll down to "Enter the Spam Warriors."
Working toward that. A bit difficult in the current local market, so I'll just be using Windows "in the office" for a few more months at least.
You mean like the different flavors of Solaris, Linux, and BSD I have running on the machines here in my lab?
Unfortunately, convincing "management" to let me run anything but Windows on a "company" machine is an exercise in futility.
From the article:
"But upgrading to XP 64 could mean giving up functionality without getting much in return. In fact, XP 64 looks like a throwback to Windows past: Its interface mirrors that of Windows 2000 or even Win 98. Microsoft has not disclosed what else will be in the OS, so it is possible that you'll still get most of XP's other features.
XP 64 won't have the 32-bit XP's support for DOS apps at all, nor will it run 16-bit apps (but it should have no trouble with 32-bit software). More important, 64-bit drivers for common hardware, such as printers, will be scarce when the OS debuts."
In moving from a Dual 1GHz G4 (Quicksilver 2002) to a Dual 2GHz G5, I have yet to find any software incompatibilities - everything works just fine.
This may change once my copy of Panther shows up, but my printer and other hardware continue to work for now.
Google for "Pandora Project." It's been discussed.
Are you saying that driving with your head tilted 80 degrees to the side to press the tiny cellphone against your shoulder doesn't increase the level of "distraction" by any measurable amount?
Or that trying to juggle the stick shift, the steering wheel, the $BEVERAGE, and the cellphone isn't more dangerous than just the stick, wheel, and $BEVERAGE?
I've lost count of the number of times I've seen the silly bint in front of me try to look into his rearview mirror so he can try merging left, only to lose the cellphone he was holding between his empty head and his shoulder, then try to recover from dropping it while swerving halfway into *both* of the other lanes (left *and* right!)
I won't go so far as to say using a headset *removes* the distraction, but it certainly reduces it by quite a lot over trying to drive with the damned thing in your hand. Voice control over the headset also removes the distraction of trying to *dial* while driving.
I can get a suitcase of Pabst Blue Ribbon for the cost of a six-pack of Guinness.
Does that mean Pabst is the better beer?
Heinlein also "invented" the waterbed, being a method to support a body that wasn't acclimated to higher gravity.
Supposedly, he came up with this idea when he was still in the Navy, and would sneak over the face to float in a pool at night.
You don't bill for anything under 30 minutes?
That seems... odd. When I was working independently doing contracting, it was a two-hour minimum, and most of my business came from four or five customers who repeatedly called back for more.
So Korea leads the world in broadband connections... They also lead the world in open relays and in spamming people with messages they can't even read.
My own mailserver doesn't accept incoming connections from Korea - at the time I inserted korea.blackholes.us into the dnsbl list, I had received ONE legitimate e-mail from Korea, and over four thousand spams from Korea.
"Buh-bye, Korea." I'll take them out of the filters as soon as the logs indicate less than once bounce per week instead of 30-50 bounces per day.
Hell's bells... back in the late 1990's, (1998ish?) even MOTOROLA, the manufacturer of the chips that Apple uses, decided to phase out all of their aging Macintoshes and replace them with Wintel machines running NT.
Of course, I think this had less to do with the NT boxes being easier to use or cheaper to support than the fact that Apple yanked Motorola's clone license...
The only "energy" involved in the underwater glider is in shifting ballast and increasing or decreasing buoyancy.
It's an incredibly efficient method of moving stuff, albeit slow.
I'd be interested in seeing what effects various currents might have on possible freight routes using large UW gliders.
Nice to see that *someone* got the joke...
The cost of bookshelves will go up because people can't (or won't) RTFM.
Am I the only one who sees a certain irony in this?
In any case, you can't make anything foolproof - as soon as you do, someone breeds a dumber fool.
I'd agree that with current materials, SSTO vehicles won't work.
With harder ceramics, lighter composites, et cetera ad absurdum, they *will* be feasible.
The problem is that research projects keep getting killed in favor of feeding the breeders.