f you haven't plugged it in for 6 mths, how are you getting tv schedule updates? If I leave mine unplugged for more than 2 weeks I run out of data and it stops recording. I guess I could do it by time but then it is just a basic vcr.
The DirecTV Tivo gets program schedules via satellite. The only thing you need the phone line for is software updates and PPV stuff. If you don't use PPV, you probably never have to plug it in.
Although, it's not a bad idea to do the updates. I finally let mine phone home and the next day I saw some new features, but I like the idea of waiting until the mainstream has evaluated a patch before applying it, at least in a case like this where it's less likely to be a security issue.
This appears to be an isolated issue that has only affected a small number of owners of much older Tivos (and in reality, ones that probably have a bunch of weird hacks). I'm sure Tivo is going to fix it, and the bug seems to be so obscure, it's probably wise of them to wait before even acknowledging it, especially when there's a chance the bug isn't related to a standard Tivo setup.
If anything, this underlines the value of not plugging your Tivo in and having it automatically update itself. I've left my Tivo unplugged for more than six months and it continues to work fine. There's not often a need for software upgrades.
It's also worth noting that a lot of the posters in the Tivo Community, when confronted with this "bug" used it as reasoning to run out and pick up the new Series 2 units for $79 -- you know you've got a great product with loyal users when, upon confronted with a bug, they purchase more of your products!
Some people just don't seem to respond well to positive reinforcement.
You've hit the nail on the head. That's exactly it.
It really amazes me the lengths people will go through to avoid dealing with reality. This whole diatribe is about that... desperate rationalization to justify avoiding conflict.
Conflict is the basis of all progress. If you don't identify what's wrong with something (or who's wrong), then you're not solving any problem; you're just postponing it. A smart IT person will try to break this cycle. An apathetic IT person will spout on about politesse when in reality, his priority isn't to make things better, but merely to keep his paycheck coming.
Even if the user is wrong every time, it's your responsibility to help them. Some people just never learn, but if you keep helping them in a friendly way, they will worship you and think you are indispensible. When you start to write them off and act like it's always their fault, they will be just as frustrated with you and want to get rid of you.
Where do you work? On the IT department for the Barney the Dinosaur production company?
Most IT people have more things to do than they have time for. A "problem user" that does not follow instructions is a liability to the company. I have found in my experience that being nice to them compounds the problem. And we don't do them any favors by letting their 27th screw-up they were warned about slide.
Then again, the dynamics in your office may be different. I get paid to make things work. The title on my card doesn't say, "Company Counselor".
I completely disagree with you and the author of the original article. If you say, "The Emperor has no clothes", there will always be some people who resent you, but if you work in the kind of environment where the mainstay of your job involves continually dealing with people who don't follow or respect your wisdom, and politesse means more than competence, you're in a bad scene. My users respect me. They know that if they screw something up, I'll tell them in no uncertain terms, and it makes them more capable because in the end, I'm the one person they trust to not blow smoke up their ass. Being honest has more benefits than detriments unless you work for a crappy company, in which case, in the long run, you'll realize alienating yourself and getting fired is the best thing that could happen.
Re:The correct responses
on
Are You Annoying?
·
· Score: 1, Insightful
You're supposed to have an attitude of wanting to help, not proving it's not your fault. Jeez, no wonder people hate IT users, with responses like that.
We always want to help, but we can't help you if you don't help us.
The first 14 times you come to me and say, "It doesn't work" after you've already been asked to make note of the error message and haven't, it can be forgiven, but after that, pardon me, if my patience has been worn a bit thin!
IT has its own annoying quirks. Langer says some IT people label users as neophytes and then blame them for any difficulties. "The user insists their e-mail doesn't work, and the IT person says, 'My e-mail works perfectly,' and assumes the user is the problem. Users really find this annoying," he says.
Ha! Here's how that typical scenario goes...
USER: My e-mail doesn't work.
IT: What's wrong?
USER: I can't send e-mail. E-Mail doesn't work. The system must be down.
IT: None of the other 1700 employees have had any problems at all today with their e-mail. Can you be more specific about what your problem is?
USER: It doesn't work for me.
IT: Did the computer give you any error message?
USER: I think so but I wasn't paying attention.
IT: You realize that when something goes wrong on the computer, it tells you what went wrong? That message helps us know what the problem is?
There is no perfect solution. This solution is good for 99% of the time, unless you contrive some crazy ass scenario that most people don't actually do and won't actually have a problem with. If you have special needs, then you can be accomodated at a cost.
It's obvious you really have no experience in this area if you think this solution is that useful. When you have to administer servers and fight spam on the front lines, you'll change your tune. Until then, you're just background noise IMO.
Just how effective is this filter at cleaning water? If it is cheap enough to be mass produced for soldiers' food, then it would be incredible for humanitarian purposes if it cleans water well. Many parts of the world cannot easily clean their own water.
*cough* It's being sold to the military. Who said anything about being "cheap?"
I wonder how many millions of dollars were spent on this mostly useless technology? Creating food with dirty water or urine is irrelevent. A soldier can last much longer without food than he can without water. Most people will die within five days if they don't get water. If you don't have access to clean water, you're in much worse shape. Lose 12% of your water and you're dead.
So am I, but I'm sick and fucking tired of getting double bounces because some scumbag spammer is using random strings @ mydomain.com as the reply-to or from address. If more email admins got their act together and implemented SPF, maybe they'd realize that "hey, look, this IP address isn't allowed to send email for this domain, I'll just drop it instead of bouncing a zillion fucking emails because the spammer's lists are full of bogus email addresses."
With relay blacklisting, you don't have bounces to deal with because the MTA rejects the connection before validating the headers. The more systems that employ RBLs, the less bounces there will ever be. It's the ideal situation and far superior to SPF.
SPF is to the e-mail bouncing epidemic what CAN-SPAM was to stopping spam. In other words, it won't make any noticeable difference.
It's going to be a long time before anyone is penalized for *not* publishing SPF, and in the meantime, it can seriously cut down on spoofing. The spec does not define the lack of SPF records as a failure; a failed SPF check happens when the published SPF records do not say that this host/sender combination are permitted. Not publishing will get you "Received-SPF: none", and that's about it.
Unfortunately, the reality is, RBLs do a better job RIGHT NOW than SPF ever will, even if it's universally adopted.
SPF checking will require exponentially more resources all around the world than RBLs. With a RBL, you refuse to accept any mail from a system that has been confirmed to be a major, repeating source of spam or worms. Under SPF, this system would continue to be able to connect and pass hoards of forged e-mail, each of which will be checked individually, wasting humongeous amounts of resources whereas with RBL, the system would have simply "hung up" and saved lots of time, resources and bandwidth.
RBLs work. SPF is another scheme to waste bandwidth. It's fine for a few large ISPs like Hotmail, but for everyone else, SPF would be a liability more than a benefit.
I use a T-Mobile Sidekick to send and recieve e-mail on several of my pop3 accounts at different domains. When I send an email with my Sidekick, it uses T-Mobile's email server to send them mail, but puts the email address of my pop3 account in the "From" field so it looks like it came direct from my other mail account.
Is this going to cause me problems?
"Yes, this will cause you problems but we have a solution! For an extra $9.95/month you can have your own T-Mobile Mailbox(tm)! There's no need for you to have another mailbox when you can pay us extra money and we can push the SPF standard so that people like you have to purchase all your Internet products from one company in order to make them work. Thank you for contacting T-Mobile! We're the company who cares about your security!"
I guess DNSBLs should also be boycotted, huh? After all, their use prevents broken, misconfigured, or untrustworthy servers from making direct SMTP connections, and apparently, that's not in the spirit of the Internet. Nor, for that matter, is having your ISP put in packet filter rules next time you get DoSed. Wouldn't want to stop traffic from a source that might conceivably someday send something legit.
Quit with the knee-jerk "THIS IS DIFFERENT!!!!" reaction already. It's going to be quite some time before anyone starts rejecting mail simply because of the nonexistence of SPF records, and in the meantime it has more potential to curb email spoofing than anything out there that's currently viable.
Your logic is flawed.
SPFs block e-mail and penalize legitimate people who haven't necessarily in any way demonstrated that they are irresponsible with their system configurations or they're engaging in unethical activity.
In what's likely to be a very common scenario should SPFs become a standard, users who fail to properly update DNS info will have their services interrupted. I don't know about you, but the majority of my users don't know the difference between a reply-to field and a POP3 username, and they're expected to maintain DNS TXT records to follow them around as they travel? Get real.
RBLs penalize systems that have BEEN PROVEN to be a problem on the Internet. An open relay doesn't get reported unless it has been exploited, and if an RBL blacklists an open relay, in a worst-case-scenario, it's a preemptive move to keep the relay from spamming. But I'm unaware of any major RBLs comprising their lists of open relays. Open relays are essentially a thing of the past and not relevant any more. But if there are open relays, they should be blacklisted no matter what.
SPF is a gimmick that almost exclusively benefits large ISPs and prejudices small and medium-sized companies, or companies that want to focus on things like web hosting and not ISP'ing.
Ultimately, SPF will not stop spam one bit. SPF's will NEVER be as effective as RBLs. In fact, it will be advantageous to spammers to start spoofing large ISPs via SPF. The only way to stop spammers from exploiting wide SPF holes will be to filter port 25 traffic from unauthorized IP space, which will do more to stop spamming and worm propagation than SPF. SPF is useless. The only exception to that is that ISPs who publish SPF records will help RBLs identify where the non-SMTP IP space is so it can be blacklisted.
Basically it's like this.. You have a domain like example.com. You send email from bob@example.com. But you want to send email through some other SMTP server, call it smtp.com, for whatever reason, and keep the From: line as bob@example.com. Since you control the domain, all you need to do is to change the DNS settings for your domain to add SPF records that say "smtp.com is a sender of email for example.com".
Problem solved.
No. Problem is not solved.
Let's say you are on the road and you're dialing in from one of the many ISPs to check your e-mail. You realize you don't have your DNS records updated to indicate this new ISP, and suddenly you can't send mail.
Ok, so let's say you have remote access to update the DNS to put the new ISP host in your DNS records. Now you have to go through that BS, but even then, DNS information has been cached and may not become active until anywhere from one hour to a few days, depending upon the DNS records and the caching configuration of the myriad of servers around the world. What a pain. You may have to wait 24 hours before you can even send mail. Some solution.
Ok, let's say you did have your DNS info updated to reflect the national ISP you were using. Let's say you've authorized "aol.com" in your SPF records so you can travel around and continue to send mail without it getting blocked. That's nice, but in the process of allowing yourself to do this, you've also allowed ALL AOL USERS TO SPOOF YOUR DOMAIN AS WELL. Which means, you still get spam and worms, probably even more because you have to authorize ten million people in order to authorize yourself.
I'm not sure what problem any of this solves unless you're problem is you're in need of some technology-based false sense of security that wastes a lot of time.
It is more practical but not the most practical. The most practical approach is simply to address the problem.
I totally agree with you. But IMO, the real problem is law enforcement not prosecuting the spammers for the illegal activity they perpetrate. It has nothing to do with technology at all.
I think it's safe to say breaking into someone's PC and turning it into a secret spamming zombie is illegal in almost every jurisdiction. That's the problem that needs addressing.
Ok, I have been railing about how SPF is more of a pain than it's worth and primarily favors monster ISPs.
But I just realized that SPF will provide a an even more useful service for "the rest of us" that its supporters may never have intended.
Let the big boys adopt SPF. The process of doing so requires that they FINALLY publicize the location of their legitimate SMTP relays.
The larger the ISP, the more important this is, so even if only a few of the top ISPs adopt this standard, it solves TONS of problems for the rest of us who are constantly fighting off hoards of spam and worms from these big ISPs who won't regulate the unethical/illegal activities of their customers.
NOW, we look up the wholesale IP space of these AOLs, subtract the "authorized SMTP relays" they identify in their SPF records and we have a most excellent relay blacklist and a means to stop worm propagation.
Most of us have been trying to differentiate between rogue and legitimate SMTP IP space. Thanks to the goofy ITs at the top ISPs, we may finally be able to do this. Excellent!
Let's call this SPF-RPF. The process of them authorizing senders will finally allow us to authorize their legitimate mail relays and blacklist everything else.
oooh, you know what I like about this? Not that AOL is using SPF and authorizing SMTP relays, but this advertises which SMTP relays within AOL's IP space it considers legitimate.
What someone needs to do, is use the information above as a mask against the whole of AOL's IP space and stick it in a big RBL. Then we don't need SPF; we finally have a method by which the troublesome ISPs can help us identify the IP space from which no SMTP service should be operating. I like it!
According to spamhaus.org, there are only a few hundred spamming organizations that account for the vast majority of spam. We don't need everyone in the world to adopt SPF, we only need enough to convince these few people to switch from forging legitimate domain names to using their own. Once that happens, the vast majority of bogus bounces will be eliminated.
Bogus bounces IMO are not a problem. Most ISPs/dev/null postmaster in the first place so it's moot. I'm not seeing tons of bounces from forged headers.
I agree there are a small number of "spamming organizations" BUT there is an extremely large number of hosts from which these spammers are sending their junk mail. So I believe your argument is ineffective. There's no way every ISP on the planet is going to adopt this system, and that's the ONLY way you could force spammers to operate under their own domains within the goals of this scheme.
You want to force spammers into a corner? That's a great idea. But you don't do it by verifying the integrity of forged e-mail headers! You do it by verifying the integrity of the IP space from which the mail originates! This is best accomplished by SMTP relay blacklisting, and the improvement to that would be SMTP whitelisting, or authorization, not of individual hosts, but of legitimate mail relays.
Look at the trend changes in spamming. Spammers have actually moved from operating in single locations to exploiting zombie armies of PCs. This happened before the industry suggested SPF. It happened because RBLs are working, and RBLs are based on recognizing the validity of SMTP relays, not hosts.
The SPF scheme puts the burden of legitimizing hosts on EVERYONE, when the real problem isn't forged headers. The real problem is ROGUE MAIL RELAYS, which have nothing to do with the "from" address of an e-mail.
In theory this idea sounds ok, but there are a few fundamental flaws:
1. It only really works if everyone adopts it, so right off the bat, the potential usefulness of the standard is dubious at best.
2. It takes the extreme approach of requiring every host on the Internet to have information specifying authorized relays and hosts.
I still think my idea of an SMTP WHITELIST is more practical than this scheme. Only a fraction of IP space can be considered legitimate SMTP relays, so it makes more sense for those that want to set up an SMTP relay to have to go through any hassle to have their relay recognized and approved. Why make EVERY system on the planet managing domains have to authorize additional parameters for every host?
SPF also doesn't potentially stop the spread of worms and viruses from infected broadband customers. If an ISP authorizes cable/DSL users to send mail from their IP space, then the worm propagation will appear legitimate to SPF-compliant systems. Furthermore, the SPF scheme doesn't do anything to reduce bandwidth - in fact it adds to overhead and basically establishes a system where large ISPs basically continue to let their customers run wild with worm/spam propagating, but might, as an aside, broadcast a few extra bits of information to help other systems decide if the rogue users they have should be listened to. As a result, the ISPs can basically refuse to regulate the illegal activity of their customers in favor of a few 10-minute DNS updates.
I'd estimate that there is probably 1 SMTP relay per 5,000+ domain names in service. The SPF scheme dictates that all 5000+ domain records require special configuration/approval, as opposed to suggesting the 1-in-5000 SMTP hosts have the burden of being authorized. This just doesn't make sense.
Who comes up with these ideas? They must get paid by the hour.
What's the biggest problem with spam right now? Zombie hosts: computers that should not be acting as SMTP relays yet are. The SPF scheme penalizes all systems and all hosts because the ISPs either won't filter port 25 traffic where it doesn't belong, or they won't efficiently contribute their DSL IP space information to RBLs.
We do NOT need a scheme where EVERY HOST on the planet needs to authorize themselves. We need a scheme where ONLY SMTP HOSTS authorize themselves. Instead of requiring 25,000,000+ separate configurations, we implement a system where the 250,000 legitimate SMTP relays are recognized as true sources of e-mail traffic. Then, not only do we shut out spam, but we instantly eradicate the propgation of 99% of all SMTP-based worms.
Is SPF validation done against the hostname of the originating SMTP submission PC, the SMTP relay, or the hostname as indicated in the "from" or "reply-to" address of the mail header?
I am unconvinced this scheme will make much of a difference in the spam epidemic.
If anything, the SPF idea primarily favors the big ISPs and consolidated mail services. Microsoft and others aren't doing the industry a favor at all by adopting this standard. It clearly benefits them more than it does small and medium-sized Internet hosts. I am under the impression that for any Internet operation that doesn't control all the inbound and outbound mail for domains they manage will have a much higher administrative burden than the big guys. So this scheme makes sense for large ISPs and costs more time and money for smaller ones.
And ultimately, it would only stop spam if every system on the planet adopted it. Otherwise a spammer will simply operate from a host that isn't SPF-compliant. Until the lion's share of systems adopt SPF, no ISP can afford to arbitrarily reject non-compliant systems.
This scheme seems to heavily favor the "all-in-one" Internet companies, who manage both sending and receiving. If you're having one company manage your domain and using a local ISP for SMTP, then you run into problems. As an owner of a hosting company, if this scheme were adopted, I'd probably get several phone calls a day from customers freaking out that their mail bounced, and even if I had an automated system where they could specify authorized smtp hosts, I'd still have to waste a bunch of time explaining to them that if they configure their local client to be "from" their domain, and they change ISPs, they need to update these records as well.
Ultimately, this is bad. It makes the largest ISPs, who can afford to offer SMTP and all other services, easier to work with, and the smaller guys have more of an administrative overhead to keep up with DNS management.
Generally, I like this idea, especially from the perspective of controlling misdirected bounces.
Where it seems to be a problem though (someone correct me if I'm wrong), is in a case where someone, for example is doing web hosting and controls a domain, and the customer wants to configure his e-mail client to send mail "from" the domain through a local ISP. The way SPF works, the authorized hosts from which mail with that domain in the header must be defined in the DNS records. This means that if the hosting company isn't the customer's ISP or mail relay, he needs to keep track of what mail relays the customers use. If a customer changes ISPs and doesn't have the DNS info updated, then their mail may suddenly be rejected by SPF servers?
This seems to be good for ISPs and services like Hotmail and gMail, which endeavor to have exclusive control of incoming and outgoing mail under their domains, but for smaller ISPs or scenarios where one person may be managing the domain, with the customer using a local ISP/mail relay, it seems to be a big pain in the butt.
Thanks for reminding me of the good ol' days when slashdotters knew what they were talking about. Boy, that brings back memories. Good times. Good times.
I have had a Treo 600 for almost a year now, and I am quite happy with it. The camera is the worst camera ever created on the planet, but that just means nobody will hassle me in areas where camera phones are prohibited - there's no way anybody would believe the phone could actually take a useful picture.
The Treo has great battery life, and loads of other features. And it's available for Sprint as well as GSM. I am not aware of anything that much better right now.
Slashdot Mirror
f you haven't plugged it in for 6 mths, how are you getting tv schedule updates? If I leave mine unplugged for more than 2 weeks I run out of data and it stops recording. I guess I could do it by time but then it is just a basic vcr.
The DirecTV Tivo gets program schedules via satellite. The only thing you need the phone line for is software updates and PPV stuff. If you don't use PPV, you probably never have to plug it in.
Although, it's not a bad idea to do the updates. I finally let mine phone home and the next day I saw some new features, but I like the idea of waiting until the mainstream has evaluated a patch before applying it, at least in a case like this where it's less likely to be a security issue.
This appears to be an isolated issue that has only affected a small number of owners of much older Tivos (and in reality, ones that probably have a bunch of weird hacks). I'm sure Tivo is going to fix it, and the bug seems to be so obscure, it's probably wise of them to wait before even acknowledging it, especially when there's a chance the bug isn't related to a standard Tivo setup.
If anything, this underlines the value of not plugging your Tivo in and having it automatically update itself. I've left my Tivo unplugged for more than six months and it continues to work fine. There's not often a need for software upgrades.
It's also worth noting that a lot of the posters in the Tivo Community, when confronted with this "bug" used it as reasoning to run out and pick up the new Series 2 units for $79 -- you know you've got a great product with loyal users when, upon confronted with a bug, they purchase more of your products!
Some people just don't seem to respond well to positive reinforcement.
You've hit the nail on the head. That's exactly it.
It really amazes me the lengths people will go through to avoid dealing with reality. This whole diatribe is about that... desperate rationalization to justify avoiding conflict.
Conflict is the basis of all progress. If you don't identify what's wrong with something (or who's wrong), then you're not solving any problem; you're just postponing it. A smart IT person will try to break this cycle. An apathetic IT person will spout on about politesse when in reality, his priority isn't to make things better, but merely to keep his paycheck coming.
Even if the user is wrong every time, it's your responsibility to help them. Some people just never learn, but if you keep helping them in a friendly way, they will worship you and think you are indispensible. When you start to write them off and act like it's always their fault, they will be just as frustrated with you and want to get rid of you.
Where do you work? On the IT department for the Barney the Dinosaur production company?
Most IT people have more things to do than they have time for. A "problem user" that does not follow instructions is a liability to the company. I have found in my experience that being nice to them compounds the problem. And we don't do them any favors by letting their 27th screw-up they were warned about slide.
Then again, the dynamics in your office may be different. I get paid to make things work. The title on my card doesn't say, "Company Counselor".
I completely disagree with you and the author of the original article. If you say, "The Emperor has no clothes", there will always be some people who resent you, but if you work in the kind of environment where the mainstay of your job involves continually dealing with people who don't follow or respect your wisdom, and politesse means more than competence, you're in a bad scene. My users respect me. They know that if they screw something up, I'll tell them in no uncertain terms, and it makes them more capable because in the end, I'm the one person they trust to not blow smoke up their ass. Being honest has more benefits than detriments unless you work for a crappy company, in which case, in the long run, you'll realize alienating yourself and getting fired is the best thing that could happen.
You're supposed to have an attitude of wanting to help, not proving it's not your fault. Jeez, no wonder people hate IT users, with responses like that.
We always want to help, but we can't help you if you don't help us.
The first 14 times you come to me and say, "It doesn't work" after you've already been asked to make note of the error message and haven't, it can be forgiven, but after that, pardon me, if my patience has been worn a bit thin!
IT has its own annoying quirks. Langer says some IT people label users as neophytes and then blame them for any difficulties. "The user insists their e-mail doesn't work, and the IT person says, 'My e-mail works perfectly,' and assumes the user is the problem. Users really find this annoying," he says.
Ha! Here's how that typical scenario goes...
USER: My e-mail doesn't work.
IT: What's wrong?
USER: I can't send e-mail. E-Mail doesn't work. The system must be down.
IT: None of the other 1700 employees have had any problems at all today with their e-mail. Can you be more specific about what your problem is?
USER: It doesn't work for me.
IT: Did the computer give you any error message?
USER: I think so but I wasn't paying attention.
IT: You realize that when something goes wrong on the computer, it tells you what went wrong? That message helps us know what the problem is?
USER: Yes, but e-mail doesn't work.
There is no perfect solution. This solution is good for 99% of the time, unless you contrive some crazy ass scenario that most people don't actually do and won't actually have a problem with. If you have special needs, then you can be accomodated at a cost.
It's obvious you really have no experience in this area if you think this solution is that useful. When you have to administer servers and fight spam on the front lines, you'll change your tune. Until then, you're just background noise IMO.
water is water... you rehydrate your body one way or another, whether it's added to the food and consumed or consumed by itself. You still need water.
Just how effective is this filter at cleaning water? If it is cheap enough to be mass produced for soldiers' food, then it would be incredible for humanitarian purposes if it cleans water well. Many parts of the world cannot easily clean their own water.
*cough* It's being sold to the military. Who said anything about being "cheap?"
I wonder how many millions of dollars were spent on this mostly useless technology? Creating food with dirty water or urine is irrelevent. A soldier can last much longer without food than he can without water. Most people will die within five days if they don't get water. If you don't have access to clean water, you're in much worse shape. Lose 12% of your water and you're dead.
So am I, but I'm sick and fucking tired of getting double bounces because some scumbag spammer is using random strings @ mydomain.com as the reply-to or from address. If more email admins got their act together and implemented SPF, maybe they'd realize that "hey, look, this IP address isn't allowed to send email for this domain, I'll just drop it instead of bouncing a zillion fucking emails because the spammer's lists are full of bogus email addresses."
With relay blacklisting, you don't have bounces to deal with because the MTA rejects the connection before validating the headers. The more systems that employ RBLs, the less bounces there will ever be. It's the ideal situation and far superior to SPF.
SPF is to the e-mail bouncing epidemic what CAN-SPAM was to stopping spam. In other words, it won't make any noticeable difference.
It's going to be a long time before anyone is penalized for *not* publishing SPF, and in the meantime, it can seriously cut down on spoofing. The spec does not define the lack of SPF records as a failure; a failed SPF check happens when the published SPF records do not say that this host/sender combination are permitted. Not publishing will get you "Received-SPF: none", and that's about it.
Unfortunately, the reality is, RBLs do a better job RIGHT NOW than SPF ever will, even if it's universally adopted.
SPF checking will require exponentially more resources all around the world than RBLs. With a RBL, you refuse to accept any mail from a system that has been confirmed to be a major, repeating source of spam or worms. Under SPF, this system would continue to be able to connect and pass hoards of forged e-mail, each of which will be checked individually, wasting humongeous amounts of resources whereas with RBL, the system would have simply "hung up" and saved lots of time, resources and bandwidth.
RBLs work. SPF is another scheme to waste bandwidth. It's fine for a few large ISPs like Hotmail, but for everyone else, SPF would be a liability more than a benefit.
I use a T-Mobile Sidekick to send and recieve e-mail on several of my pop3 accounts at different domains. When I send an email with my Sidekick, it uses T-Mobile's email server to send them mail, but puts the email address of my pop3 account in the "From" field so it looks like it came direct from my other mail account.
Is this going to cause me problems?
"Yes, this will cause you problems but we have a solution! For an extra $9.95/month you can have your own T-Mobile Mailbox(tm)! There's no need for you to have another mailbox when you can pay us extra money and we can push the SPF standard so that people like you have to purchase all your Internet products from one company in order to make them work. Thank you for contacting T-Mobile! We're the company who cares about your security!"
I guess DNSBLs should also be boycotted, huh? After all, their use prevents broken, misconfigured, or untrustworthy servers from making direct SMTP connections, and apparently, that's not in the spirit of the Internet. Nor, for that matter, is having your ISP put in packet filter rules next time you get DoSed. Wouldn't want to stop traffic from a source that might conceivably someday send something legit.
Quit with the knee-jerk "THIS IS DIFFERENT!!!!" reaction already. It's going to be quite some time before anyone starts rejecting mail simply because of the nonexistence of SPF records, and in the meantime it has more potential to curb email spoofing than anything out there that's currently viable.
Your logic is flawed.
SPFs block e-mail and penalize legitimate people who haven't necessarily in any way demonstrated that they are irresponsible with their system configurations or they're engaging in unethical activity.
In what's likely to be a very common scenario should SPFs become a standard, users who fail to properly update DNS info will have their services interrupted. I don't know about you, but the majority of my users don't know the difference between a reply-to field and a POP3 username, and they're expected to maintain DNS TXT records to follow them around as they travel? Get real.
RBLs penalize systems that have BEEN PROVEN to be a problem on the Internet. An open relay doesn't get reported unless it has been exploited, and if an RBL blacklists an open relay, in a worst-case-scenario, it's a preemptive move to keep the relay from spamming. But I'm unaware of any major RBLs comprising their lists of open relays. Open relays are essentially a thing of the past and not relevant any more. But if there are open relays, they should be blacklisted no matter what.
SPF is a gimmick that almost exclusively benefits large ISPs and prejudices small and medium-sized companies, or companies that want to focus on things like web hosting and not ISP'ing.
Ultimately, SPF will not stop spam one bit. SPF's will NEVER be as effective as RBLs. In fact, it will be advantageous to spammers to start spoofing large ISPs via SPF. The only way to stop spammers from exploiting wide SPF holes will be to filter port 25 traffic from unauthorized IP space, which will do more to stop spamming and worm propagation than SPF. SPF is useless. The only exception to that is that ISPs who publish SPF records will help RBLs identify where the non-SMTP IP space is so it can be blacklisted.
Basically it's like this.. You have a domain like example.com. You send email from bob@example.com. But you want to send email through some other SMTP server, call it smtp.com, for whatever reason, and keep the From: line as bob@example.com. Since you control the domain, all you need to do is to change the DNS settings for your domain to add SPF records that say "smtp.com is a sender of email for example.com".
Problem solved.
No. Problem is not solved.
Let's say you are on the road and you're dialing in from one of the many ISPs to check your e-mail. You realize you don't have your DNS records updated to indicate this new ISP, and suddenly you can't send mail.
Ok, so let's say you have remote access to update the DNS to put the new ISP host in your DNS records. Now you have to go through that BS, but even then, DNS information has been cached and may not become active until anywhere from one hour to a few days, depending upon the DNS records and the caching configuration of the myriad of servers around the world. What a pain. You may have to wait 24 hours before you can even send mail. Some solution.
Ok, let's say you did have your DNS info updated to reflect the national ISP you were using. Let's say you've authorized "aol.com" in your SPF records so you can travel around and continue to send mail without it getting blocked. That's nice, but in the process of allowing yourself to do this, you've also allowed ALL AOL USERS TO SPOOF YOUR DOMAIN AS WELL. Which means, you still get spam and worms, probably even more because you have to authorize ten million people in order to authorize yourself.
I'm not sure what problem any of this solves unless you're problem is you're in need of some technology-based false sense of security that wastes a lot of time.
It is more practical but not the most practical. The most practical approach is simply to address the problem.
I totally agree with you. But IMO, the real problem is law enforcement not prosecuting the spammers for the illegal activity they perpetrate. It has nothing to do with technology at all.
I think it's safe to say breaking into someone's PC and turning it into a secret spamming zombie is illegal in almost every jurisdiction. That's the problem that needs addressing.
Ok, I have been railing about how SPF is more of a pain than it's worth and primarily favors monster ISPs.
But I just realized that SPF will provide a an even more useful service for "the rest of us" that its supporters may never have intended.
Let the big boys adopt SPF. The process of doing so requires that they FINALLY publicize the location of their legitimate SMTP relays.
The larger the ISP, the more important this is, so even if only a few of the top ISPs adopt this standard, it solves TONS of problems for the rest of us who are constantly fighting off hoards of spam and worms from these big ISPs who won't regulate the unethical/illegal activities of their customers.
NOW, we look up the wholesale IP space of these AOLs, subtract the "authorized SMTP relays" they identify in their SPF records and we have a most excellent relay blacklist and a means to stop worm propagation.
Most of us have been trying to differentiate between rogue and legitimate SMTP IP space. Thanks to the goofy ITs at the top ISPs, we may finally be able to do this. Excellent!
Let's call this SPF-RPF. The process of them authorizing senders will finally allow us to authorize their legitimate mail relays and blacklist everything else.
$ host -t TXT aol.com
aol.com text "v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all"
oooh, you know what I like about this? Not that AOL is using SPF and authorizing SMTP relays, but this advertises which SMTP relays within AOL's IP space it considers legitimate.
What someone needs to do, is use the information above as a mask against the whole of AOL's IP space and stick it in a big RBL. Then we don't need SPF; we finally have a method by which the troublesome ISPs can help us identify the IP space from which no SMTP service should be operating. I like it!
According to spamhaus.org, there are only a few hundred spamming organizations that account for the vast majority of spam. We don't need everyone in the world to adopt SPF, we only need enough to convince these few people to switch from forging legitimate domain names to using their own. Once that happens, the vast majority of bogus bounces will be eliminated.
/dev/null postmaster in the first place so it's moot. I'm not seeing tons of bounces from forged headers.
Bogus bounces IMO are not a problem. Most ISPs
I agree there are a small number of "spamming organizations" BUT there is an extremely large number of hosts from which these spammers are sending their junk mail. So I believe your argument is ineffective. There's no way every ISP on the planet is going to adopt this system, and that's the ONLY way you could force spammers to operate under their own domains within the goals of this scheme.
You want to force spammers into a corner? That's a great idea. But you don't do it by verifying the integrity of forged e-mail headers! You do it by verifying the integrity of the IP space from which the mail originates! This is best accomplished by SMTP relay blacklisting, and the improvement to that would be SMTP whitelisting, or authorization, not of individual hosts, but of legitimate mail relays.
Look at the trend changes in spamming. Spammers have actually moved from operating in single locations to exploiting zombie armies of PCs. This happened before the industry suggested SPF. It happened because RBLs are working, and RBLs are based on recognizing the validity of SMTP relays, not hosts.
The SPF scheme puts the burden of legitimizing hosts on EVERYONE, when the real problem isn't forged headers. The real problem is ROGUE MAIL RELAYS, which have nothing to do with the "from" address of an e-mail.
In theory this idea sounds ok, but there are a few fundamental flaws:
1. It only really works if everyone adopts it, so right off the bat, the potential usefulness of the standard is dubious at best.
2. It takes the extreme approach of requiring every host on the Internet to have information specifying authorized relays and hosts.
I still think my idea of an SMTP WHITELIST is more practical than this scheme. Only a fraction of IP space can be considered legitimate SMTP relays, so it makes more sense for those that want to set up an SMTP relay to have to go through any hassle to have their relay recognized and approved. Why make EVERY system on the planet managing domains have to authorize additional parameters for every host?
SPF also doesn't potentially stop the spread of worms and viruses from infected broadband customers. If an ISP authorizes cable/DSL users to send mail from their IP space, then the worm propagation will appear legitimate to SPF-compliant systems. Furthermore, the SPF scheme doesn't do anything to reduce bandwidth - in fact it adds to overhead and basically establishes a system where large ISPs basically continue to let their customers run wild with worm/spam propagating, but might, as an aside, broadcast a few extra bits of information to help other systems decide if the rogue users they have should be listened to. As a result, the ISPs can basically refuse to regulate the illegal activity of their customers in favor of a few 10-minute DNS updates.
I'd estimate that there is probably 1 SMTP relay per 5,000+ domain names in service. The SPF scheme dictates that all 5000+ domain records require special configuration/approval, as opposed to suggesting the 1-in-5000 SMTP hosts have the burden of being authorized. This just doesn't make sense.
Who comes up with these ideas? They must get paid by the hour.
What's the biggest problem with spam right now? Zombie hosts: computers that should not be acting as SMTP relays yet are. The SPF scheme penalizes all systems and all hosts because the ISPs either won't filter port 25 traffic where it doesn't belong, or they won't efficiently contribute their DSL IP space information to RBLs.
We do NOT need a scheme where EVERY HOST on the planet needs to authorize themselves. We need a scheme where ONLY SMTP HOSTS authorize themselves. Instead of requiring 25,000,000+ separate configurations, we implement a system where the 250,000 legitimate SMTP relays are recognized as true sources of e-mail traffic. Then, not only do we shut out spam, but we instantly eradicate the propgation of 99% of all SMTP-based worms.
Is SPF validation done against the hostname of the originating SMTP submission PC, the SMTP relay, or the hostname as indicated in the "from" or "reply-to" address of the mail header?
I am unconvinced this scheme will make much of a difference in the spam epidemic.
If anything, the SPF idea primarily favors the big ISPs and consolidated mail services. Microsoft and others aren't doing the industry a favor at all by adopting this standard. It clearly benefits them more than it does small and medium-sized Internet hosts. I am under the impression that for any Internet operation that doesn't control all the inbound and outbound mail for domains they manage will have a much higher administrative burden than the big guys. So this scheme makes sense for large ISPs and costs more time and money for smaller ones.
And ultimately, it would only stop spam if every system on the planet adopted it. Otherwise a spammer will simply operate from a host that isn't SPF-compliant. Until the lion's share of systems adopt SPF, no ISP can afford to arbitrarily reject non-compliant systems.
This scheme seems to heavily favor the "all-in-one" Internet companies, who manage both sending and receiving. If you're having one company manage your domain and using a local ISP for SMTP, then you run into problems. As an owner of a hosting company, if this scheme were adopted, I'd probably get several phone calls a day from customers freaking out that their mail bounced, and even if I had an automated system where they could specify authorized smtp hosts, I'd still have to waste a bunch of time explaining to them that if they configure their local client to be "from" their domain, and they change ISPs, they need to update these records as well.
Ultimately, this is bad. It makes the largest ISPs, who can afford to offer SMTP and all other services, easier to work with, and the smaller guys have more of an administrative overhead to keep up with DNS management.
Generally, I like this idea, especially from the perspective of controlling misdirected bounces.
Where it seems to be a problem though (someone correct me if I'm wrong), is in a case where someone, for example is doing web hosting and controls a domain, and the customer wants to configure his e-mail client to send mail "from" the domain through a local ISP. The way SPF works, the authorized hosts from which mail with that domain in the header must be defined in the DNS records. This means that if the hosting company isn't the customer's ISP or mail relay, he needs to keep track of what mail relays the customers use. If a customer changes ISPs and doesn't have the DNS info updated, then their mail may suddenly be rejected by SPF servers?
This seems to be good for ISPs and services like Hotmail and gMail, which endeavor to have exclusive control of incoming and outgoing mail under their domains, but for smaller ISPs or scenarios where one person may be managing the domain, with the customer using a local ISP/mail relay, it seems to be a big pain in the butt.
Thanks for reminding me of the good ol' days when slashdotters knew what they were talking about. Boy, that brings back memories. Good times. Good times.
Ok, back to Ted Turner bashing.
I have had a Treo 600 for almost a year now, and I am quite happy with it. The camera is the worst camera ever created on the planet, but that just means nobody will hassle me in areas where camera phones are prohibited - there's no way anybody would believe the phone could actually take a useful picture.
The Treo has great battery life, and loads of other features. And it's available for Sprint as well as GSM. I am not aware of anything that much better right now.