That, and financial sites that are supposed to be secure, but will only work with IE. The reason? JavaScript bugs that are easily fixed, but not high on their priorities.
To phrase it similarly, SPF doesn't do a damn thing with email headers. It only pays attention to the envelope sender, which is what is specicied in the SMTP MAIL FROM command, and winds up in the Return-Path header due to actions of the receiving server. It's not designed to stop phishing schemes.
Caller ID, on the other hand, was designed to look at things like the From: header. That was designed to stop phishing more than SPF was.
Sender ID isn't one or the other, but the combination of those and some other weird thing M$ came up with. Sender ID is also what's patented, as far as I know, not SPF.
It looks like the patent specifies displaying a menu of software that isn't already installed on the computer. I don't know about Apple's system, having no experience with it, and I don't know about RedHat's either, but Microsoft's update site falls into that category.
As far as I can tell, something like Cygwin's setup program wouldn't, because it displays everything that's available and gives you the option to install, uninstall, upgrade or downgrade (depends on the program and what versions are available, of course).
IANAL, but it seems that way to me after reading the claims...
- they do not want to license foreign Intellectual Property, so they develop their own video format for instance, for both pride and economic reasons as well.
Pride, if anything... last I checked, no one is paying anyone royalties to use IPv4, are they? If anything, they should be handing back the IPv4 address spaces that they'll no longer be using.
Yes, but Wayne says that his list is only a temporary measure. It's not going to be there forever. Besides, not all valid forwarders are in that list... only those that have been found by him or reported as unable to implement SRS (with good reason) by others.
There is nothing that SPF does that DNSBL like systems can't do better using existing software and normal data packets.
I haven't yet seen a DNSBL system that says authoritatively that a given IP is allowed to send email for a certain domain, much less with the same kind of flexibility that is allowed in SPF.
If you don't flag anything that doesn't match as a fail (-all at the end), then you won't see much difference. It also depends on the server receiving such spoofed emails actually doing checks against SPF records.
Most domains out there are defaulting to "neutral" or "softfail" as the default in their SPF records for now until sites that do mail forwarding or web mail (preserving the original envelope FROM address) implement SRS. If you have fairly solid control over where mail from your domain comes from, then you can go ahead and set the default to "fail".
...which is essentially the same article that is linked to in the story.
If you read the entire thing, it's obvious that even the reporter in this case thinks the spam argument is practically bullshit, citing sources saying that IM spam isn't nearly the growing problem that email spam is, and the reasons why.
As it stands, even if Yahoo *isn't* out to break these other clients, they may as well be, because that's the public perception to a situation like this. So take a stand either way.
RTFA... that may not have been the reason last time, but they're explicitly stating that it is this time. Of course, the primary reason they're citing is to prevent spam, but that argument is extremely weak. There's not much that keeps you from doing that with their own software.
Depends on what time you connected. I have a couple friends that use that as well, and they couldn't connect after 6pm PDT (that's when the change went into effect, IIRC).
Have you tested that syntax with the current Mail::SRS module? Unless I'm seriously mistaken, passing the email into a program in.forward passes the entire email.
The current "srs" executable that comes with that module only translates an address, and that address has to be on the command line. The most efficient way to handle SRS rewriting is in the MTA, and there are already patches for a few of them. There's Python SRS, that can be plugged into Exim and sendmail, and there's a similar implementation in Perl that it links to. There is also an implementation for qmail. I haven't seen one yet for Postfix, but I can't see it being that difficult to implement.
In any case, the only sites that really need to implement it are those that do any forwarding or sending of email as if it's coming from a domain other than their own. In the meantime, there's a trusted forwarder list to ease the transition where it's needed.
What broken mailing list software are you using? To repeat what's already been said, only the envelope sender address is checked by SPF, not the one in the message headers. Most mailing lists that I've seen wouldn't be affected.
There is a way around that, though, and a rather easy one to implement depending on the mail server involved. Patches for sender address rewriting are still being developed for different MTAs, but that plus the lag of getting ISPs involved are the two major reasons why SPF isn't in full force yet.
Besides, the article does reference SPF, though indirectly. That and M$'s Caller-ID are the only things that I know of that realistically authenticate by IP address, and they've just recently merged.
Overgeneralization has made it into/. stories before, or have you not been around that long? If you simply RTFA, you'll see that it's mainly just the invites that have gone missing.
Can you fry an egg on it? No? Then I don't want it. C'mon... the heat from that hardware has got to go somewhere. Ever put a laptop directly on your lap?
Anyway, not sure about editing them, but you can store and present them from a Palm OS or Pocket PC unit already. Trying to edit them on a screen that small (VGA resolution or no) seems insane as it is.
Slashdot Mirror
Why not? They invented that :-)
That, and financial sites that are supposed to be secure, but will only work with IE. The reason? JavaScript bugs that are easily fixed, but not high on their priorities.
In other words, they're keeping others from making them look stupid, in order to devote all they can to doing that for themselves.
:-)
Oops... too late
To phrase it similarly, SPF doesn't do a damn thing with email headers. It only pays attention to the envelope sender, which is what is specicied in the SMTP MAIL FROM command, and winds up in the Return-Path header due to actions of the receiving server. It's not designed to stop phishing schemes.
Caller ID, on the other hand, was designed to look at things like the From: header. That was designed to stop phishing more than SPF was.
Sender ID isn't one or the other, but the combination of those and some other weird thing M$ came up with. Sender ID is also what's patented, as far as I know, not SPF.
Too late for that...
M$ didn't invent SPF... they invented Caller ID. Sender ID is just the combination of those two things.
It looks like the patent specifies displaying a menu of software that isn't already installed on the computer. I don't know about Apple's system, having no experience with it, and I don't know about RedHat's either, but Microsoft's update site falls into that category.
As far as I can tell, something like Cygwin's setup program wouldn't, because it displays everything that's available and gives you the option to install, uninstall, upgrade or downgrade (depends on the program and what versions are available, of course).
IANAL, but it seems that way to me after reading the claims...
- they do not want to license foreign Intellectual Property, so they develop their own video format for instance, for both pride and economic reasons as well.
Pride, if anything... last I checked, no one is paying anyone royalties to use IPv4, are they? If anything, they should be handing back the IPv4 address spaces that they'll no longer be using.
Yes, but Wayne says that his list is only a temporary measure. It's not going to be there forever. Besides, not all valid forwarders are in that list... only those that have been found by him or reported as unable to implement SRS (with good reason) by others.
More like 15 now, but they're still all in one place... one guess where :-)
Othere than SPF, there is no sane reason for most DNS servers to issue TXT records.
Really? What rock have you been hiding under?
There is nothing that SPF does that DNSBL like systems can't do better using existing software and normal data packets.
I haven't yet seen a DNSBL system that says authoritatively that a given IP is allowed to send email for a certain domain, much less with the same kind of flexibility that is allowed in SPF.
If you don't flag anything that doesn't match as a fail (-all at the end), then you won't see much difference. It also depends on the server receiving such spoofed emails actually doing checks against SPF records.
Most domains out there are defaulting to "neutral" or "softfail" as the default in their SPF records for now until sites that do mail forwarding or web mail (preserving the original envelope FROM address) implement SRS. If you have fairly solid control over where mail from your domain comes from, then you can go ahead and set the default to "fail".
1) You're getting Orkut/Google confused with Affinity Engines, which are the ones doing the refusing.
.NET code displayed in weird fonts in attempt to "prove" the "theft".
2) Next thing you know, we'll be seeing
...which is essentially the same article that is linked to in the story.
If you read the entire thing, it's obvious that even the reporter in this case thinks the spam argument is practically bullshit, citing sources saying that IM spam isn't nearly the growing problem that email spam is, and the reasons why.
As it stands, even if Yahoo *isn't* out to break these other clients, they may as well be, because that's the public perception to a situation like this. So take a stand either way.
RTFA... that may not have been the reason last time, but they're explicitly stating that it is this time. Of course, the primary reason they're citing is to prevent spam, but that argument is extremely weak. There's not much that keeps you from doing that with their own software.
Depends on what time you connected. I have a couple friends that use that as well, and they couldn't connect after 6pm PDT (that's when the change went into effect, IIRC).
Have you tested that syntax with the current Mail::SRS module? Unless I'm seriously mistaken, passing the email into a program in .forward passes the entire email.
The current "srs" executable that comes with that module only translates an address, and that address has to be on the command line. The most efficient way to handle SRS rewriting is in the MTA, and there are already patches for a few of them. There's Python SRS, that can be plugged into Exim and sendmail, and there's a similar implementation in Perl that it links to. There is also an implementation for qmail. I haven't seen one yet for Postfix, but I can't see it being that difficult to implement.
In any case, the only sites that really need to implement it are those that do any forwarding or sending of email as if it's coming from a domain other than their own. In the meantime, there's a trusted forwarder list to ease the transition where it's needed.
Bouncing = rejecting an email on the receiving end for some reason
/etc/aliases and .forward files do)
Forwarding = sending a nearly identical copy (headers and everything) of an email to another destination (what
"Bouncing" = Forwarding
"Forwarding" = resending (sending a copy of only the contents of the original email inside of a new email message)
What broken mailing list software are you using? To repeat what's already been said, only the envelope sender address is checked by SPF, not the one in the message headers. Most mailing lists that I've seen wouldn't be affected.
There is a way around that, though, and a rather easy one to implement depending on the mail server involved. Patches for sender address rewriting are still being developed for different MTAs, but that plus the lag of getting ISPs involved are the two major reasons why SPF isn't in full force yet.
Besides, the article does reference SPF, though indirectly. That and M$'s Caller-ID are the only things that I know of that realistically authenticate by IP address, and they've just recently merged.
To realize that no one does it? Yeah, I have, hence the comment.
He writes for it, too, apparently :-)
Shouldn't the lameness filter kick him back out, though?
Overgeneralization has made it into /. stories before, or have you not been around that long? If you simply RTFA, you'll see that it's mainly just the invites that have gone missing.
Can you fry an egg on it? No? Then I don't want it. C'mon... the heat from that hardware has got to go somewhere. Ever put a laptop directly on your lap?
Anyway, not sure about editing them, but you can store and present them from a Palm OS or Pocket PC unit already. Trying to edit them on a screen that small (VGA resolution or no) seems insane as it is.