It's funny, because this produces situations like the current Microsoft one regarding CIFS/SMB, where almost everyone at MS that knows how the system works internally is gone or hasn't touched the thing for years, and there is more knowledge on the outside in reverse-engineering teams like Samba.
We all love FireFox, but whenever a major update comes out, every couple months, you'll probably have to completely delete the old FireFox off each machine, install the new one, and set it all up again.
Why?
I admit that I haven't used Firefox on every supported platform, but on both Red Hat and Windows, there's nothing that one needs to do other than install over the old copy and start going.
This is a new one. Just because someone dislikes Gentoo does not remotely make them an "anti-Gentoo zealot". I've yet to see someone that I'd categorize as an "anti-Gentoo zealot", though I suppose there are a few, and many that I'd call "Gentoo zealots" -- ignoring reason to argue in favor of their favorite distro.
Now someone is saying: "precompiled binaries will never run as quickly as those compiled with the right optimizations for your own machine."
So, the Gentoo users that are claiming that stuff compiled with the right optimizations *is* faster?
Both wrong and right.
If you choose the "best" optimization choices for your particular machine, you won't lose anything. Of course, those choices vary significantly from package to package, and that doesn't mean that you'll gain much, either.
There are a few packages that can see significant improvements -- gzip is one, but it's quite rare to see significant performance improvements for anything above a basic -O2 -fomit-frame-pointer, and generally binary-based distros provide packages for different architectures for the few packages where a significant difference can be made (the kernel and glibc, for instance). It just doesn't generally make a significant measurable difference in performace as to what optimization options are used. Compilers (especially C compilers) just don't produce a huge difference in optimization.
Oh, distcc has been in Gentoo for a while.. surprised to see it listed like it's a new thing.
Distcc has been available for anyone for a long time, and packaged by a number of people. The reason you don't see a lot of people using it is because most folks don't have a cluster handy, and generally it isn't worth the effort to build a cluster to save compilation time unless you're doing a truly massive amount of compilation, like an entire distro (which obviously has a lot of interest for Gentoo types).
For most developers, ccache is a better idea (if you're just building a single software package consisting of most of the same source most of the time). distcc is really best used when you have huge amounts of code htat will be compiled once.
Why does each and every publisher need to have some grandiose MMORPG in their line-up? It makes no sense - the market is small, the maintenance costs are high, and with the treadmill setup everyone's using there really isn't room for more than one MMORPG (sometimes not even one, since most of them want you to put in at least an hour or two a day) per potential user.
I agree that the market is vastly over-saturated. However, there are reasons why each publisher can be easily convinced that an MMORPG is worth the risks:
* Very, very good antipiracy protection -- you're selling a service, not really the game.
* A subscription model. Aside from making more money per year than a per-copy game, it's easy to get people "subscribed".
* Good, free AIs. Oh, there are disadvantages to having humans running other NPCs (such as out-of-context behavior), but major advantages. People are smart, understand commands in English and can organize tactics. They can become friends (and hence increase the value of the game). If there is competition, there is generally tough competition out there -- in most single-player games, it's possible to beat/out-manuver all the computer AIs.
* A channel to make more sales. If you have a strong media channel to your customers, you can freely push ads to other products that you're making.
* A predictable revenue source. If you have sales numbers for each month, you have nice, predictable numbers to work with to show investors and whatnot.
* Greater freedom from deadlines. If a developer doesn't have to finish all of a game by a deadline -- he can build another country while being paid by revenues from initial sales -- he has the ability to work on a project that is uniquely his for a long period of time.
* Planned obsolescence. There is now a lot of video game content out there. Every person that is still spending time playing Tetris or Pac-Man or Super Metroid is not buying new games. Unless you can somehow springboard new sales from the old, having people continuing to play your game is *bad* -- it means that your market is less interested in buying your next game. I can play a fifteen-year-old videogame for most systems today. With an MMORPG, once the other players are gone, the game is "gone", and a player has nothing to do but buy the next product from the publisher.
* Gambling mentality -- the nature of MMORPGs has shown to exploit well addictive personalities. Vendors love addictive types of people -- they will do a marvelous job of shoveling money into the company's pockets forever. MMORPGs generally have no "end", continually have new content, and generally do a good job of forcing people to *start* playing a little bit per time period, making it easy to play a *lot* per time period without an effort of will.
I haven't worked retail, but honestly, based on what I've seen from just being in retail stores and watching staff and customers interact, I think that it's much more common for the customer to be wrong and the staff to be excessively nice than the customer to be right and the staff to be jackasses. I've had staff be rude to be twice. In each case, I wasn't rude back; I just didn't shop at the store again. I see an amazing number of people who would never *dream* of treating an "ordinary person" so rudely being incredibly abusivve towards retail staff -- calling them "stupid", screaming, and generally trying to game the system (I have just as much dislike as anyone for businesses -- like buy.com -- that are known to publish misleading low prices to suck in customers and then "only have the item available at a higher price"). However, customers that try to "game the system" because of an obvious mistake in an ad are equally irritating -- if there's an order-of-magnitude error, they need to calm down and accept reality instead of trying to rip off the stores.
Other behavior I've seen that really screws over retail staff that's really pretty awful on the part of customers:
* Buying expensive electronic item A, using until warranty expires and then item breaks, buying second instance of electronic item A, swapping new working item for old broken one, returning new item as "broken" to the store. Very lame behavior. Common when it comes to consoles.
* Expecting retail staff to know product minutiae, and becoming rude when they do not. Ultimately, it's nice if retail staff know the details of a particular product, but if you're at a general retail store like Best Buy, Circuit City, or Wal-Mart, there's just no way that the staff is going to be able to do much when it comes to advanced product knowledge.
First of all, get off of the SATA hacks, and realize you're going to need to go to SCSI, whether you end up with disk or tape. You're backing up data, you're going ot want it to be reliably written out, and SCSI is the de facto standard for backup architecture. Yes, you pay more for it, but there's a reason for it: the SCSI equipment I manage at work fails a fraction of the percentage of time that the various IDE/ATA systems fail. While SATA is marketed as a consumer technology, it will never meet the rigors of being a reliable backup methodology.
The SCSI/SATA/PATA debate is silly, and (no offense to you, as I have no idea of your particular situation) often perpetuated by people who make purchasing decisions but don't know enough to evaulate their systems reasonably.
None of the three standards is inherently less reliable than the others. Many SCSI drives push density limits much less than ATA drives, though this is not a constant. In addition, because SCSI drives are often used in high-load environments, they often have higher rotational speeds and operating temperatures (and sometimes even require active cooling systems). These are negative reliability factors -- heat is a huge factor in drive data reliability.
It's not too hard to get a general feel of how reliable a drive is. Take a look at how high the density is, as this is the biggest factor -- drives of a particular generation with low density are likely to be more reliable. Unless you are working with a rack that absolutely will not allow drives in it to undergo impact, rated impact can be significant, as desktops and towers can get knocked about (note that notebook-style 2.5" form-factor drives can generally handle about an order-of-magnitude increase in impact over desktop-style 3.5" drives -- Seagate, for instance, makes the "Savvio" line, an enterprise-clas 2.5" series). Look at rated (while-operating -- non-operating means little) impacts. Operating temperatures should be as hot as possible -- the bigger the margin between you and the maximum operating temperature, the better.
Again you're looking for that silver bullet. SPF can't be used alone (unless we lived in a perfect world, bet then there would be no spammers) SPF gives us one more thing to filter and score based on, but your filters have to be set up with the assumption that there are domains without SPF or with misconfigured SPF:
SPF is really nothing more than an authentication system. I've argued elsewhere in this story that SPF is not a very good authentication system. I'm not sure that basing other antispam systems on SPF *is* a good idea.
People that can't trust their DNS servers not to cache bogus responses to DNS queries shouldn't depend on DNS for anything, they certainly shouldn't be dumping incoming mail based on it.
I'm curious -- what folks are you thinking of that *can* trust their DNS server caches not to be poisoned?
And while I agree that it might be nice not to route/blow away mail based on the relatively insecure DNS, it's also done on a regular basis and is a fundamental element in the way email functions. For a close parallel to SPF's DNS usage, consider mail servers with a reverse-MX-required policy.
Obviously a company should have a policy that does everything to prevent this. But that can happen with or without SPF with todays IP blocklists
Right. But with domain reputation, there may be many sources of input and since reputation is probably not binary, it's hard to know exactly "how in the clear" you are. With an RBL, if you fix your open relay, you're in the clear until next time your mail admin screws up. You can be careful to avoid the problem, and easily demonstrate that you are *not* a spam domain by fixing the open relay and sending email to an RBL service asking them to retest your mail server. With domain reputation, you may lose your entire mail service when a few accounts start spamming, and if reports come in over a period of time, even if your domain is cleared and rerated as "not a spam source", you may have difficulty ensuring that you stay above the threshhold as people read their email and send in futher spam reports.
You allow incoming mail from nonexistent domains?
No. But it's easy to register citibank-customerservice.com and then start sending email that *looks* like it comes from Citibank.
Noone should rely on email for anything of importance today.
That's probably true. However, people are desperate for a form of reliable Internet-based communication, and like it or not, email *is* used for crucial communications every day. Social Security numbers and mother's maiden names are both really awful forms of authentication (and SSNs are *specifically* not supposed to be used for authentication), but both are commonly used for exactly that. An ISP can't just get away with saying "well, you shouldn't have been using email for anything important" to their business clients if they go through a software upgrade that suddenly starts dumping 5% of (legitimate) incoming email.
That would depend on the policy of your ISP. It should be possible for a mail server to decide if/how to perform SPF checks depending on the user the mail is for.
Yes, but it "should be possible" today, but ISPs don't generally provide such an option, nor is there any set of extensions to IMAP/POP3 to let you "set" filtering options.
Well...I think you might be a little harsh. What about the standard theft-in-extreme-situations justification of being starving, coming across a house with nobody in it, and stealing some bread? Would you really avoid stealing the bread in such a situation?
It might be bad in most normal situations, sure.
I won't be a dick about the "theft/copyright-infringment" thing.
To comment on one of your other comments, you compared stealing a movie to stealing Linux. You were ok with the former and opposed to the latter.
No, no. Take another look at my post:
I have an issue with the degree of the criminal penalties (three years in federal prison for taping a movie with no intent for profit seems harsh to me) involved. I'm not upset about copyright law, or the legitimacy of using *civil* law, where the penalties fit the actual damages being caused by the infringer, being used.
I am not arguing that it's okay to illegally duplicate movies, or even that laws intended to prevent such behavior should be eliminated. I just think that the penalty in this case is vastly out of whack with the crime. You could easily get less time in prison (even ignoring good behavior) for manslaughter or other violent offenses that I consider more of an issue to society than copying a movie.
Companies with investors who expect a return on their investments pour money into the production of movies, hiring thousands of people blah blah blah, and then some punk puts a copy of the movie on a website or P2P net and there go thousands of potential viewers.
Sure. So the argument goes "if people have a business plan that depends on people not breaking any laws, and people do in fact break laws, it breaks the system and no more good content will be produced". The same applies to Linux (a lot of the folks and companies working on Linux wouldn't do so if Linux was, say, public domain). I'd furthermore argue not that one is legitimate and the other not, but that Linux development being halted due to the legal system supporting it breaking would cause more damage to society than the development of a movie halting for the same reason. Thus, if someone feels that such a law is inappropriate for Linux (a piece of IP that has much less anti-infringmenet marketing protecting it), then I argue that it is also inappropriate for movie duplication.
And you compare this to stealing Linux, the source for which I can download at any point in time, recompile, and have a functioning copy.
Sure. How does that make it less valuable? You're getting it under certain not-particularly-restrictive-but-still-quite-impor tant licensing terms, the absence of such would severely hamstring or stop Linux development.
As for "combatting a law", I'd rather combat the Patriot Act via petitions than get arrested over a camcorder in a theater.
Well, sure. That goes without saying. As a matter of fact, I have very little interest in getting arrested. However, it's also extremely difficult for a police officer to claim that he has probable cause when you've just held up an empty plastic camcorder shell (actually, it's unlikely that the manager would call the police in the first place). He may not *like* you for having to hassle with you, but neither are you likely to be arrested. Since it's possible to do something that is (IMHO) kind of fun and still help fight a law that I don't like, I'm more interested in doing so.
The problem is that this isn't "major clients" -- even mozilla+enigmail isn't an out-of-box solution. In the case of PGP Universal, you're buying an additional product just to do secure email. It really has to be nothing more than "install email client, use encrypted email with key generated during setup".
Oh, and just to emphasize -- PGP (well, a PGP-like system) is a much, much better solution than SPF. I just think that the reason PGP hasn't taken off isn't because of computational cost, but because the UIs for it on the client are universally bad.
The Internet *does* need a standard way to allow access to files and information (PGP keys, preferences, and the like) across any Internet host securely, but that's a problem for another day and a better authentication scheme.
SPF is not an anti-spam system. SPF is an anti-joe-job system. It happens that the most frequent joe jobs tend to come from spammers, howev
As I've pointed out below in a number of comments, SPF is not a good anti-joe-job system either. A lot of people have identified the fact that SPF does not actually deal with spam very well, have wondered *why* the designers came up with it, and apparently arrived at the conclusion that it's a brilliant way to avoid joe jobs. It's not.
Proper anti-spam systems are based upon dealing with unwanted email, not dealing with non-relevent characteristics. If you create a system that makes it easier to control who gets your email address (such as my solution, Yahoo!'s AddressGuard(tm), and TMDA)
Your solution would be really nice if more ISPs had good mail servers.
I enjoy the use of Carnegie Mellon's Cyrus mail server, which is set up to allow any address that looks like username[+optionaltext]@andrew.cmu.edu to be delivered to username@andrew.cmu.edu. A number of CMU folks use your approach, and you'll see stuff like tom6+compdiscuss@andrew.cmu.edu on a "compdiscuss" forum. It lets people track where people get their email addresses from, in addition to giving them an effectively infinite number of email boxes -- you can tell students to send current problem solutions to jsmith+15676_hw5@andrew.cmu.edu, for instance.
SPF isn't such a system, it's designed to deal with a totally different issue. Arguably, given that it breaks mailing lists and forwarding and has many other documentable faults, it really ought to be being used as a measure of last resort, though it's a good idea for mail receipients to implement the logic so that domains that are having these issues can make the choice when they find themselves being targetted.
I don't think so -- I think that SPF actually is a misguided effort intended to eliminate spam.
SPF is, when all is said and done, an authentication system, and nothing more. The problem is that it fails a number of basic requirements that most people have on authentication systems -- it can be decieved. It does not provide sufficient granularity of identity (no user-level auth) to implement a number of systems that might be built on top of it that *might* be effective antispam systems. If decieved, a great deal of damage can be done. It natively has an extremely generous "trust" system (once something has been accepted by any SPF-enabled system, it's kosher) or an attackable and DoSable trust system (if domain reputations are used, as vaguely proposed by its authors). It does not allow delegation of authority.
SPF is not a good anti-spam system -- it doesn't stop spam unless everyone uses it perfectly Internet-wide (which doesn't work).
It is not a good anti-joe-job system -- it fails to secure a number of links in the mental association process between an email and a trusted authority (I've detailed this in several comments further down).
It is not even a good authentication system to build poential anti-spam, anti-joe-job, or other distributed Internet systems on -- it can be attacked, DoSed, and provides a very limited set of functionality.
Explain: how would you brute force it? One way would be to search until you find a domain without SPF information and fake addresses from that. That will reduce the pool of domains you can fake, and be an incentive for them to start using it. In a way it's shifting the damage over to those that doesn't try to help solving the problem, they decide to be easy targets they take the consequenses.
It sounds more than plasubile to me. So, I'm curious. You propose to try, by social pressure, to force *every single* domain to disallow non-SPF email?
Heck, if *that* kind of approach worked (force everyone to use system Foo and use it correctly), that past few years where people *swore* to use that the answer to stopping spam was just eliminating all the open relays ("sure, it'll be easy") should have solved the spam problem. It doesn't work. You must have a system that does not require Internet-wide perfect cooperation.
It will stop spam from beeing sent with faked addresses from a domain, if the owners of that domain wishes it. That means I will never se a bounce for spam using my address if the recieving end uses SPF, and the reciever willl not see spam that fakes my address as its sender
You don't need to do so now. There are existing, workable systems that don't require an iota of effort on the part of the domain mail admin that work fine. One would be to slap a "X-Fromme:" header in all your emails with a secret in it, or hash of a tuple of the to address and a secret, or whatever makes you happy, and have procmail or whatever system floats your boat. It can all be done without leaving the client or screwing with existing infrastructure.
Why not, all I have to do is configure my mail program to use the correct mailserver for outgoing mailBull. Mail (allegedly) from domains that doesn't publish SPF information will get through, and mail to recievers that doesn't check SPF will come through. Domain owners will be encouraged to implement this because they will se fever (misdirected) abuse reports. Users will be encouraged to implement this because they will see less spam
Users will *not* see less spam when they do this unless everyone implements. Why would spamemrs spam with a forged from address from an SPF-enabled domain when there are an infinite pool of non-SPF-enabled domains (or even non-forged addresses).
You must admit one of two things. Either (a) people don't have to deploy SPF records, and SPF is not an antispam system, or (b) SPF requires everyone to completely and fully deploy and it is not workable (no system requiring all nodes to be trusted and not screw up that I know of has ever worked). You can't have both the benefits of requiring SPF records and not have the drawbacks.
Eventually all spam will use a sender address from domains without SPF informations (or nonexistent domains), people will start dumping mail from domains without SPF (or give it a high spamassassin score) and those domains will effectively be forced to implement SPF or see their users unable to send email
As I said above.
Which is why you have to use additional measures, such as scoring mail without SPF low, blacklisting domains and ISPS that allow spammers and other kinds of filters. There is no tool that will block ALL spam, but the right combination will reduce it drastically
The schemes that the SPF people have proposed are vulnerable to DoS attacks. "Asshats" include those people that want to DoS people. Suppose you spoof a little DNS record or two, setting a high TTL on cacheable lifetime, and manage to make AOL's main mailserver think that MSN's SPF record says that the only legitimate mailserver is somewhere in Korea. It'd be funny when millions of emails start getting bounced as spam, eh? It'd be even *funnier* if asshats use the domain-level-reputation-based-tools that the SPF people are advocating to patch over the fact that SPF can't deal with throwaway domains improperly -- say, compromi
IANAL, but the text of this agreement seems to indicate that this implementation license applies to any products that "implement and are compliant with" Sender ID (section 1.2), and that Microsoft may subsequently terminate the license (section 3).
Don't implement any extensions or non-compliant behavior in your mail server.:-)
Improvements to the scheme are totally unacceptable?
Messages only get rejected when a SPF does exist for the claimed domain and the MTA transmitting the message is not a valid sender for the claimed domain. Messages are NOT rejected simply because the claimed domain fails to publish a SPF record.
Mail servers certainly *can* do this. Every person that claims that SPF can eliminate spam claims that this will at least eventually happen.
It's merely a solution to help us from getting joe-jobbed, having spam "appear" to come from us. Until you voluntarily add SPF records for your domain, you will continute to get joe-jobbed unknowingly
No. SPF does not even do this. For this to happen, the following must occur:
(a) The user must be able to know that email that originates from a server is trusted in content. SPF cannot do anything below domain granularity. If a machine on an "authorized-to-send-mail" IP is compromised, it can send mail, and with most setups out there, mail that looks like it's coming from anyone at the company. Break #1 WRT SPF as an anti-joe-jobbing mechanism -- SPF relies on an invalid assumption that anyone that can send email through a server is trusted. Existing systems like PGP or S/MIME are much more appropriate for this, as they have end-user granularity rather than domain granularity.
(b) The user must have a mental mapping between the institution involved and all domains and contractor domains involved with that institution. This is not currently present. My mother will believe that "Citibank" stuff is legitimate if it comes not only from "citibank.com", but "citibank.net", and more esoteric stuff like "citibank-customerservice.com" or "citibank.bankingsystems.com". This is SPF-as-an-anti-joe-job-mechanism break #2 -- a required mental mapping between institution name and domains are not present.
(c) SPF is broken in a number of ways as an authentication scheme for domains. It uses DNS as a transport (not secure, and makes very little sense, given the limitations of DNS WRT what SPF is trying to do) without attempting to establish a secure transport on top. It uses IP-based authentication for the mail system (did *nobody* learn from the days of the r-services and IP authentication leading to horrible security breeches) *as well* as to the authentication server (the DNS system). This is a third break as an anti-joe-job tool -- just because a domain may be trusted does not mean that the message that you are reciving is a legitimate message from that domain.
SPF is largely, as a friend of mine would put it, a masturbatory system. It lets corporations claim that they're "doing something" about spam, and CIOs feel good about what they're doing. It will employ many sysadmins for a long time who will keep tweaking it in the hope that the next adjustment or just one more deployement will be that Holy Grail to stop spam. In reality, it merely breaks existing functionality and diverts resources and research from legitimate anti-spam efforts, like client-to-client encrytion/signing deployment.
For the foreseeable future, if you don't publish SPF, your email will still work.
This is another thing wrong with SPF.
For a protocol to work on the vastly disorganized and chaotic Internet, it needs to work when members are not fully compliant with the protocol or are acting oddly.
SPF is much like the existing massive effort to try to stop open relays (which has been going on for a long time and clearly has not stopped spam). Both methods are predicated on being able to make everyone fully and correctly implement the behavior for *anyone* to benefit -- or else spam still comes through.
SPF isn't even a good anti joe-job tool, because almost all the time a joe-job/phishing scheme goes on, people don't have a mental mapping from the institution ("Citibank") to all the domains and subcontractors that might be used ("citibank.com"? How about "citibank-customerservice.com"?) I guarantee you that my mother would fall for "citibank.banksystems.net"). Regular Joes aren't familiar with the DNS structure, and in any event, administrative and political structures don't always maintain a hierarchical flow that maps to DNS. I'm sure the registrars would love to push a "register everything spelled like, based on, or sounding like your domain!" solution -- it's wildly impractical.
Remember, over 50% of all email is now spam. Anything so lightweight that will block so much of it for those of us who use that tool, and force the rest of the email to be so much more easily tracked as being from a forgery friendly domain, is a big deal. This also helps put a spike in the growth of "zombied" machines, by helping prevent them from being able to forge valid user's domains. Coupled with mail servers that insist that your domain does, in fact, exist in order to claim that your mail is from a real domain, it helps quite a lot.
The problem is that you're making the (known wrong) assumption that spammers do not adapt and use new tools. Remember the Baysian filtering advocates, that were *sure* that spam was at an end? No, new tools just went out. Yeah, at the time SPF is deployed, a lot of people won't be using updated tools. How long do you think that will last? Even the SPF people's FAQ talks about the fact that they know that SPF isn't sufficient. Where I disagree with the SPF people is that they at least view SPF as a good foundational tool to help build systems that might potentially stop spam someday on. I see SPF as an extremely weak, course-grained, and ill-thought-out authentication system.
Without SPF, you don't know who your email is really from so you can't do domain based reputation.
SPF is the least trustworthy of the the current Big Three domain authentication schemes -- DomainKeys is ahead. None of them are particularly great authentication schemes, especially since all of them are limited to domain-level granularity (one machine with an authorized IP at a company gets compromised, outsiders have to ban the entire company's domain, rather than just the sending key).
Basically, it's awfully easy to DoS a reputation scheme with very minimal compromises involved. And any sort of throwaway-domain scheme is very hard to deal with with a reputation scheme, especially since an integer representing a global reputation may not be sufficient (and is how most folks want to do reputation schemes). Russian company A may trust Russian company B, but I'm less likely to trust random mail from a Russian domain. I'm more likely to trust mail from a person that interacts with people that I interact with than otherwise.
Why doesn't everyone use PGP already? It's been out since 1991. It's never had the success it deserves.
Because it's a pain in the ass to use. You ever tried it? The only client I've seen where it's remotely usable is mozilla+enigmail -- even mutt has serious issues.
For PGP/GPG to be widely used, major clients must:
* Support automatic key downloading.
* Support automatic encryption/signing (*not* having to manually do so on a per message basis or copy/pasting or hitting a special key to decrypt)
* Support opportunistic encryption. The current interface on most clients is that emails are not encrypted unless a person explicitly and manually tells their client to encrypt to a given person, manually imports the key, and manually sets up trust with that person. That isn't going to happen for everyone I know, even though I'm a bit of a security nut. If you have a key in your keyring that purports to belong to someone, it should be used (unless you explicitly tell your client not to do so). It doesn't hurt security, and it can help it. You can always explicitly tell your client "use this key always with these recipients" as you did before, but this means that the *default* is to be secure rather than insecure.
* It should be much more transparent than it is today. If people don't want to deal with key management, they should get what signing and encryption we can give them without it. If they *do* want to use trust management features, then they can take advantage of those and ensure that they're using proper keys and the like. SSH would *never* have taken off as a telnet replacement if it *required* manual key distribution -- yes, automatic key distribution is a bit less secure, but it's generally a Good Thing, and the paranoid nuts who require a secure connection to a place or two can still use good ol manual key distribution.
And before you say "well, why don't you do it", I'm actively submitting patches to achieve exactly this.
One issue that comes to mind is that signature verification is relatively expensive. Another is that it's fragile: regular PGP users often see their signatures fail to verify because an MUA changed the line wrapping. I think we need a standard for canonicalizing messages before hashing, but that's just my opinion.
Hmm...you see this even with MIME-format PGP?
"If you think cryptography can solve your problem, then you don't understand your problem and you don't understand cryptography." That's maybe a little rude but it's good to remember that crypto only changes one problem into a different problem. We'd have to manage the public keys, and we'd still be dealing with today's problem of insecure machines being taken over.
"If you think cryptography isn't necessary to solve your problem, then you don't understand your problem and you don't understand cryptography."
Cryptography is necessary to do the kind of authentication that the anti-spam people want to do.
Sorry, I got so worked up that I failed to finish my last post.
PGP does not answer this question. Neither does Yahoo's DomainKeys. There are many circumstances where the signature can not be verified. You can not use the failure to verify a PGP signature as a reliable means to filter out junk.
SPF and MS Caller ID are designed to answer this second question reliably enough to discard forged messages. They answer this question for all domains that publish SPF records (aol.com, gmail.com, etc) regardless of whether SPF is widely adopted by the rest of the world.
Bullshit. Give me an example of an environment where email could reasonably pass SPF but not DomainKeys.
I'm not even going to get started on how a system (not necessarily PGP) that does client-to-client signing and encryption is so much more intelligent, breaks in so far fewer cases, and is so much stronger and won't need to be thrown out in a few months.
When the claimed domain published a list of designated senders, and the sending MTA's IP number isn't among them, you can be certain the message is a forgey and discard it (or close the connection before the data phase, saving bandwidth).
"Thanks" to new restrictions imposed on mail service by SPF, yes.
PGP and other crypto signature schemes simply do not deliver this ability to detect forgey. They only detect authenticity.
So, what exactly do you *think* SPF is?
It's a weak authentication scheme. A very weak one, with known attacks and only domain-level granularity.
Any other system that authenticates against the domain (Caller ID, DomainKeys) can do a similar act, and any system that authenticates against the sender (PGP, S/MIME, etc) can do not only that, but provide client-level granularity -- with SPF/Caller ID/(and for any sane deployment, DomainKeys), if someone compromises a workstation at a company and starts sending email as a client from that machine to the local mail server using a variety of addresses, the only action an outside person can take is to blocked the entire domain (try doing this to ford.com or apple.com). PGP and similar systems allow only the owner of the compromised workstation to be blocked, as well as the compromised workstation to be easily identified.
Every spam article, someone posts an opinion that if everyone would just use crypto (usually PGP is suggested), all these problems would be solved.
A lot of us are arguing that strong crypto is *necessary*, not that it is *sufficient* on its own.
For a moment, neglect the high costs, complexity, worldwide legality and PKI problems of crypto, which are all solvable at some cost.
The high costs? How many, exactly, CPU cycles would you spend to avoid bandwidth from spam?
Worldwide legality? Get real. Russians haven't supposed to be using OpenSSL for trusted stuff in the government for years. Nobody cares about that, because it's ridiculous. Encryption software is everywhere.
PKI problems of crypto? You have a problem with distributing trusted data to do *crypto*? How about the equivalent trusted-data problems of *SPF*, including the fact that the currently proposed transport mechanism is non-trusted and the designers treat it as trusted, or that the SPF's folks' solution to throwaway domains is some vague hand-waving and the stuggestion of a web of trust -- *exactly* the same thing you're claiming we don't have to deal with.
The only reason anyone is considering SPF is because they're desperate and if you ignore some of the things that the people working on crypto solutions have taken into account (which are necessary to actually have a workable system), you can look sideways at SPF and say "yeah, this probably kinda works". It makes people feel good to have something to deploy, even if it breaks existing legitimate functionality and has zero long-term impact on spam (spammers just run out, buy the latest idot-proof tools, and go to town -- Baysian filtering didn't stop them because they bought *tools* to get around it, and if you think that they won't just buy tools to bypass SPF, you're smoking something). The difference is that SPF breaks far more functionality than Baysian filtering does.
For more problems I have with SPF, I've collected links to a bunch of my earlier posts detailing issues I have with SPF in a response to Meng.
In short -- SPF has severe technical problems. Caller ID has almost all the same severe technical problems (and introduces at least the question of patents). DomainKeys has a large number of drawbacks, and even *it* is much better thought out than either SPF or Caller ID.
Slashdot Mirror
And yet, don't you find it frusterating that blunt honesty is so harshly repaid?
Which, frankly, sucks because there are so many features on Firefox that I like, but it's so slow that I can't use it for everyday browsing.
Would you give a specific example of behavior that is slower in Firefox than in Internet Explorer?
Folks out there would like to know.
If you want changed behavior, you can also file a bug in Bugzilla, which will go directly to the developers.
It's funny, because this produces situations like the current Microsoft one regarding CIFS/SMB, where almost everyone at MS that knows how the system works internally is gone or hasn't touched the thing for years, and there is more knowledge on the outside in reverse-engineering teams like Samba.
We all love FireFox, but whenever a major update comes out, every couple months, you'll probably have to completely delete the old FireFox off each machine, install the new one, and set it all up again.
Why?
I admit that I haven't used Firefox on every supported platform, but on both Red Hat and Windows, there's nothing that one needs to do other than install over the old copy and start going.
Anti-Gentoo zealots
This is a new one. Just because someone dislikes Gentoo does not remotely make them an "anti-Gentoo zealot". I've yet to see someone that I'd categorize as an "anti-Gentoo zealot", though I suppose there are a few, and many that I'd call "Gentoo zealots" -- ignoring reason to argue in favor of their favorite distro.
Now someone is saying: "precompiled binaries will never run as quickly as those compiled with the right optimizations for your own machine."
So, the Gentoo users that are claiming that stuff compiled with the right optimizations *is* faster?
Both wrong and right.
If you choose the "best" optimization choices for your particular machine, you won't lose anything. Of course, those choices vary significantly from package to package, and that doesn't mean that you'll gain much, either.
There are a few packages that can see significant improvements -- gzip is one, but it's quite rare to see significant performance improvements for anything above a basic -O2 -fomit-frame-pointer, and generally binary-based distros provide packages for different architectures for the few packages where a significant difference can be made (the kernel and glibc, for instance). It just doesn't generally make a significant measurable difference in performace as to what optimization options are used. Compilers (especially C compilers) just don't produce a huge difference in optimization.
Oh, distcc has been in Gentoo for a while.. surprised to see it listed like it's a new thing.
Distcc has been available for anyone for a long time, and packaged by a number of people. The reason you don't see a lot of people using it is because most folks don't have a cluster handy, and generally it isn't worth the effort to build a cluster to save compilation time unless you're doing a truly massive amount of compilation, like an entire distro (which obviously has a lot of interest for Gentoo types).
For most developers, ccache is a better idea (if you're just building a single software package consisting of most of the same source most of the time). distcc is really best used when you have huge amounts of code htat will be compiled once.
Why does each and every publisher need to have some grandiose MMORPG in their line-up? It makes no sense - the market is small, the maintenance costs are high, and with the treadmill setup everyone's using there really isn't room for more than one MMORPG (sometimes not even one, since most of them want you to put in at least an hour or two a day) per potential user.
I agree that the market is vastly over-saturated. However, there are reasons why each publisher can be easily convinced that an MMORPG is worth the risks:
* Very, very good antipiracy protection -- you're selling a service, not really the game.
* A subscription model. Aside from making more money per year than a per-copy game, it's easy to get people "subscribed".
* Good, free AIs. Oh, there are disadvantages to having humans running other NPCs (such as out-of-context behavior), but major advantages. People are smart, understand commands in English and can organize tactics. They can become friends (and hence increase the value of the game). If there is competition, there is generally tough competition out there -- in most single-player games, it's possible to beat/out-manuver all the computer AIs.
* A channel to make more sales. If you have a strong media channel to your customers, you can freely push ads to other products that you're making.
* A predictable revenue source. If you have sales numbers for each month, you have nice, predictable numbers to work with to show investors and whatnot.
* Greater freedom from deadlines. If a developer doesn't have to finish all of a game by a deadline -- he can build another country while being paid by revenues from initial sales -- he has the ability to work on a project that is uniquely his for a long period of time.
* Planned obsolescence. There is now a lot of video game content out there. Every person that is still spending time playing Tetris or Pac-Man or Super Metroid is not buying new games. Unless you can somehow springboard new sales from the old, having people continuing to play your game is *bad* -- it means that your market is less interested in buying your next game. I can play a fifteen-year-old videogame for most systems today. With an MMORPG, once the other players are gone, the game is "gone", and a player has nothing to do but buy the next product from the publisher.
* Gambling mentality -- the nature of MMORPGs has shown to exploit well addictive personalities. Vendors love addictive types of people -- they will do a marvelous job of shoveling money into the company's pockets forever. MMORPGs generally have no "end", continually have new content, and generally do a good job of forcing people to *start* playing a little bit per time period, making it easy to play a *lot* per time period without an effort of will.
I haven't worked retail, but honestly, based on what I've seen from just being in retail stores and watching staff and customers interact, I think that it's much more common for the customer to be wrong and the staff to be excessively nice than the customer to be right and the staff to be jackasses. I've had staff be rude to be twice. In each case, I wasn't rude back; I just didn't shop at the store again. I see an amazing number of people who would never *dream* of treating an "ordinary person" so rudely being incredibly abusivve towards retail staff -- calling them "stupid", screaming, and generally trying to game the system (I have just as much dislike as anyone for businesses -- like buy.com -- that are known to publish misleading low prices to suck in customers and then "only have the item available at a higher price"). However, customers that try to "game the system" because of an obvious mistake in an ad are equally irritating -- if there's an order-of-magnitude error, they need to calm down and accept reality instead of trying to rip off the stores.
Other behavior I've seen that really screws over retail staff that's really pretty awful on the part of customers:
* Buying expensive electronic item A, using until warranty expires and then item breaks, buying second instance of electronic item A, swapping new working item for old broken one, returning new item as "broken" to the store. Very lame behavior. Common when it comes to consoles.
* Expecting retail staff to know product minutiae, and becoming rude when they do not. Ultimately, it's nice if retail staff know the details of a particular product, but if you're at a general retail store like Best Buy, Circuit City, or Wal-Mart, there's just no way that the staff is going to be able to do much when it comes to advanced product knowledge.
First of all, get off of the SATA hacks, and realize you're going to need to go to SCSI, whether you end up with disk or tape. You're backing up data, you're going ot want it to be reliably written out, and SCSI is the de facto standard for backup architecture. Yes, you pay more for it, but there's a reason for it: the SCSI equipment I manage at work fails a fraction of the percentage of time that the various IDE/ATA systems fail. While SATA is marketed as a consumer technology, it will never meet the rigors of being a reliable backup methodology.
The SCSI/SATA/PATA debate is silly, and (no offense to you, as I have no idea of your particular situation) often perpetuated by people who make purchasing decisions but don't know enough to evaulate their systems reasonably.
None of the three standards is inherently less reliable than the others. Many SCSI drives push density limits much less than ATA drives, though this is not a constant. In addition, because SCSI drives are often used in high-load environments, they often have higher rotational speeds and operating temperatures (and sometimes even require active cooling systems). These are negative reliability factors -- heat is a huge factor in drive data reliability.
It's not too hard to get a general feel of how reliable a drive is. Take a look at how high the density is, as this is the biggest factor -- drives of a particular generation with low density are likely to be more reliable. Unless you are working with a rack that absolutely will not allow drives in it to undergo impact, rated impact can be significant, as desktops and towers can get knocked about (note that notebook-style 2.5" form-factor drives can generally handle about an order-of-magnitude increase in impact over desktop-style 3.5" drives -- Seagate, for instance, makes the "Savvio" line, an enterprise-clas 2.5" series). Look at rated (while-operating -- non-operating means little) impacts. Operating temperatures should be as hot as possible -- the bigger the margin between you and the maximum operating temperature, the better.
Again you're looking for that silver bullet. SPF can't be used alone (unless we lived in a perfect world, bet then there would be no spammers) SPF gives us one more thing to filter and score based on, but your filters have to be set up with the assumption that there are domains without SPF or with misconfigured SPF:
SPF is really nothing more than an authentication system. I've argued elsewhere in this story that SPF is not a very good authentication system. I'm not sure that basing other antispam systems on SPF *is* a good idea.
People that can't trust their DNS servers not to cache bogus responses to DNS queries shouldn't depend on DNS for anything, they certainly shouldn't be dumping incoming mail based on it.
I'm curious -- what folks are you thinking of that *can* trust their DNS server caches not to be poisoned?
And while I agree that it might be nice not to route/blow away mail based on the relatively insecure DNS, it's also done on a regular basis and is a fundamental element in the way email functions. For a close parallel to SPF's DNS usage, consider mail servers with a reverse-MX-required policy.
Obviously a company should have a policy that does everything to prevent this. But that can happen with or without SPF with todays IP blocklists
Right. But with domain reputation, there may be many sources of input and since reputation is probably not binary, it's hard to know exactly "how in the clear" you are. With an RBL, if you fix your open relay, you're in the clear until next time your mail admin screws up. You can be careful to avoid the problem, and easily demonstrate that you are *not* a spam domain by fixing the open relay and sending email to an RBL service asking them to retest your mail server. With domain reputation, you may lose your entire mail service when a few accounts start spamming, and if reports come in over a period of time, even if your domain is cleared and rerated as "not a spam source", you may have difficulty ensuring that you stay above the threshhold as people read their email and send in futher spam reports.
You allow incoming mail from nonexistent domains?
No. But it's easy to register citibank-customerservice.com and then start sending email that *looks* like it comes from Citibank.
Noone should rely on email for anything of importance today.
That's probably true. However, people are desperate for a form of reliable Internet-based communication, and like it or not, email *is* used for crucial communications every day. Social Security numbers and mother's maiden names are both really awful forms of authentication (and SSNs are *specifically* not supposed to be used for authentication), but both are commonly used for exactly that. An ISP can't just get away with saying "well, you shouldn't have been using email for anything important" to their business clients if they go through a software upgrade that suddenly starts dumping 5% of (legitimate) incoming email.
That would depend on the policy of your ISP. It should be possible for a mail server to decide if/how to perform SPF checks depending on the user the mail is for.
Yes, but it "should be possible" today, but ISPs don't generally provide such an option, nor is there any set of extensions to IMAP/POP3 to let you "set" filtering options.
I think defending theft is always a bad thing.
r tant licensing terms, the absence of such would severely hamstring or stop Linux development.
Well...I think you might be a little harsh. What about the standard theft-in-extreme-situations justification of being starving, coming across a house with nobody in it, and stealing some bread? Would you really avoid stealing the bread in such a situation?
It might be bad in most normal situations, sure.
I won't be a dick about the "theft/copyright-infringment" thing.
To comment on one of your other comments, you compared stealing a movie to stealing Linux. You were ok with the former and opposed to the latter.
No, no. Take another look at my post:
I have an issue with the degree of the criminal penalties (three years in federal prison for taping a movie with no intent for profit seems harsh to me) involved. I'm not upset about copyright law, or the legitimacy of using *civil* law, where the penalties fit the actual damages being caused by the infringer, being used.
I am not arguing that it's okay to illegally duplicate movies, or even that laws intended to prevent such behavior should be eliminated. I just think that the penalty in this case is vastly out of whack with the crime. You could easily get less time in prison (even ignoring good behavior) for manslaughter or other violent offenses that I consider more of an issue to society than copying a movie.
Companies with investors who expect a return on their investments pour money into the production of movies, hiring thousands of people blah blah blah, and then some punk puts a copy of the movie on a website or P2P net and there go thousands of potential viewers.
Sure. So the argument goes "if people have a business plan that depends on people not breaking any laws, and people do in fact break laws, it breaks the system and no more good content will be produced". The same applies to Linux (a lot of the folks and companies working on Linux wouldn't do so if Linux was, say, public domain). I'd furthermore argue not that one is legitimate and the other not, but that Linux development being halted due to the legal system supporting it breaking would cause more damage to society than the development of a movie halting for the same reason. Thus, if someone feels that such a law is inappropriate for Linux (a piece of IP that has much less anti-infringmenet marketing protecting it), then I argue that it is also inappropriate for movie duplication.
And you compare this to stealing Linux, the source for which I can download at any point in time, recompile, and have a functioning copy.
Sure. How does that make it less valuable? You're getting it under certain not-particularly-restrictive-but-still-quite-impo
As for "combatting a law", I'd rather combat the Patriot Act via petitions than get arrested over a camcorder in a theater.
Well, sure. That goes without saying. As a matter of fact, I have very little interest in getting arrested. However, it's also extremely difficult for a police officer to claim that he has probable cause when you've just held up an empty plastic camcorder shell (actually, it's unlikely that the manager would call the police in the first place). He may not *like* you for having to hassle with you, but neither are you likely to be arrested. Since it's possible to do something that is (IMHO) kind of fun and still help fight a law that I don't like, I'm more interested in doing so.
"major clients".
The problem is that this isn't "major clients" -- even mozilla+enigmail isn't an out-of-box solution. In the case of PGP Universal, you're buying an additional product just to do secure email. It really has to be nothing more than "install email client, use encrypted email with key generated during setup".
Oh, and just to emphasize -- PGP (well, a PGP-like system) is a much, much better solution than SPF. I just think that the reason PGP hasn't taken off isn't because of computational cost, but because the UIs for it on the client are universally bad.
Password dialogs.
Well, not often, but I should be able to get trusted password dialogs.
The Internet *does* need a standard way to allow access to files and information (PGP keys, preferences, and the like) across any Internet host securely, but that's a problem for another day and a better authentication scheme.
SPF is not an anti-spam system. SPF is an anti-joe-job system. It happens that the most frequent joe jobs tend to come from spammers, howev
As I've pointed out below in a number of comments, SPF is not a good anti-joe-job system either. A lot of people have identified the fact that SPF does not actually deal with spam very well, have wondered *why* the designers came up with it, and apparently arrived at the conclusion that it's a brilliant way to avoid joe jobs. It's not.
Proper anti-spam systems are based upon dealing with unwanted email, not dealing with non-relevent characteristics. If you create a system that makes it easier to control who gets your email address (such as my solution, Yahoo!'s AddressGuard(tm), and TMDA)
Your solution would be really nice if more ISPs had good mail servers.
I enjoy the use of Carnegie Mellon's Cyrus mail server, which is set up to allow any address that looks like username[+optionaltext]@andrew.cmu.edu to be delivered to username@andrew.cmu.edu. A number of CMU folks use your approach, and you'll see stuff like tom6+compdiscuss@andrew.cmu.edu on a "compdiscuss" forum. It lets people track where people get their email addresses from, in addition to giving them an effectively infinite number of email boxes -- you can tell students to send current problem solutions to jsmith+15676_hw5@andrew.cmu.edu, for instance.
SPF isn't such a system, it's designed to deal with a totally different issue. Arguably, given that it breaks mailing lists and forwarding and has many other documentable faults, it really ought to be being used as a measure of last resort, though it's a good idea for mail receipients to implement the logic so that domains that are having these issues can make the choice when they find themselves being targetted.
I don't think so -- I think that SPF actually is a misguided effort intended to eliminate spam.
SPF is, when all is said and done, an authentication system, and nothing more. The problem is that it fails a number of basic requirements that most people have on authentication systems -- it can be decieved. It does not provide sufficient granularity of identity (no user-level auth) to implement a number of systems that might be built on top of it that *might* be effective antispam systems. If decieved, a great deal of damage can be done. It natively has an extremely generous "trust" system (once something has been accepted by any SPF-enabled system, it's kosher) or an attackable and DoSable trust system (if domain reputations are used, as vaguely proposed by its authors). It does not allow delegation of authority.
SPF is not a good anti-spam system -- it doesn't stop spam unless everyone uses it perfectly Internet-wide (which doesn't work).
It is not a good anti-joe-job system -- it fails to secure a number of links in the mental association process between an email and a trusted authority (I've detailed this in several comments further down).
It is not even a good authentication system to build poential anti-spam, anti-joe-job, or other distributed Internet systems on -- it can be attacked, DoSed, and provides a very limited set of functionality.
Explain: how would you brute force it? One way would be to search until you find a domain without SPF information and fake addresses from that. That will reduce the pool of domains you can fake, and be an incentive for them to start using it. In a way it's shifting the damage over to those that doesn't try to help solving the problem, they decide to be easy targets they take the consequenses.
It sounds more than plasubile to me. So, I'm curious. You propose to try, by social pressure, to force *every single* domain to disallow non-SPF email?
Heck, if *that* kind of approach worked (force everyone to use system Foo and use it correctly), that past few years where people *swore* to use that the answer to stopping spam was just eliminating all the open relays ("sure, it'll be easy") should have solved the spam problem. It doesn't work. You must have a system that does not require Internet-wide perfect cooperation.
It will stop spam from beeing sent with faked addresses from a domain, if the owners of that domain wishes it. That means I will never se a bounce for spam using my address if the recieving end uses SPF, and the reciever willl not see spam that fakes my address as its sender
You don't need to do so now. There are existing, workable systems that don't require an iota of effort on the part of the domain mail admin that work fine. One would be to slap a "X-Fromme:" header in all your emails with a secret in it, or hash of a tuple of the to address and a secret, or whatever makes you happy, and have procmail or whatever system floats your boat. It can all be done without leaving the client or screwing with existing infrastructure.
Why not, all I have to do is configure my mail program to use the correct mailserver for outgoing mailBull. Mail (allegedly) from domains that doesn't publish SPF information will get through, and mail to recievers that doesn't check SPF will come through. Domain owners will be encouraged to implement this because they will se fever (misdirected) abuse reports. Users will be encouraged to implement this because they will see less spam
Users will *not* see less spam when they do this unless everyone implements. Why would spamemrs spam with a forged from address from an SPF-enabled domain when there are an infinite pool of non-SPF-enabled domains (or even non-forged addresses).
You must admit one of two things. Either (a) people don't have to deploy SPF records, and SPF is not an antispam system, or (b) SPF requires everyone to completely and fully deploy and it is not workable (no system requiring all nodes to be trusted and not screw up that I know of has ever worked). You can't have both the benefits of requiring SPF records and not have the drawbacks.
Eventually all spam will use a sender address from domains without SPF informations (or nonexistent domains), people will start dumping mail from domains without SPF (or give it a high spamassassin score) and those domains will effectively be forced to implement SPF or see their users unable to send email
As I said above.
Which is why you have to use additional measures, such as scoring mail without SPF low, blacklisting domains and ISPS that allow spammers and other kinds of filters. There is no tool that will block ALL spam, but the right combination will reduce it drastically
The schemes that the SPF people have proposed are vulnerable to DoS attacks. "Asshats" include those people that want to DoS people. Suppose you spoof a little DNS record or two, setting a high TTL on cacheable lifetime, and manage to make AOL's main mailserver think that MSN's SPF record says that the only legitimate mailserver is somewhere in Korea. It'd be funny when millions of emails start getting bounced as spam, eh? It'd be even *funnier* if asshats use the domain-level-reputation-based-tools that the SPF people are advocating to patch over the fact that SPF can't deal with throwaway domains improperly -- say, compromi
IANAL, but the text of this agreement seems to indicate that this implementation license applies to any products that "implement and are compliant with" Sender ID (section 1.2), and that Microsoft may subsequently terminate the license (section 3).
:-)
Don't implement any extensions or non-compliant behavior in your mail server.
Improvements to the scheme are totally unacceptable?
Messages only get rejected when a SPF does exist for the claimed domain and the MTA transmitting the message is not a valid sender for the claimed domain. Messages are NOT rejected simply because the claimed domain fails to publish a SPF record.
Mail servers certainly *can* do this. Every person that claims that SPF can eliminate spam claims that this will at least eventually happen.
SPF is not a comprehensive solution.
Agreed.
It's merely a solution to help us from getting joe-jobbed, having spam "appear" to come from us. Until you voluntarily add SPF records for your domain, you will continute to get joe-jobbed unknowingly
No. SPF does not even do this. For this to happen, the following must occur:
(a) The user must be able to know that email that originates from a server is trusted in content. SPF cannot do anything below domain granularity. If a machine on an "authorized-to-send-mail" IP is compromised, it can send mail, and with most setups out there, mail that looks like it's coming from anyone at the company. Break #1 WRT SPF as an anti-joe-jobbing mechanism -- SPF relies on an invalid assumption that anyone that can send email through a server is trusted. Existing systems like PGP or S/MIME are much more appropriate for this, as they have end-user granularity rather than domain granularity.
(b) The user must have a mental mapping between the institution involved and all domains and contractor domains involved with that institution. This is not currently present. My mother will believe that "Citibank" stuff is legitimate if it comes not only from "citibank.com", but "citibank.net", and more esoteric stuff like "citibank-customerservice.com" or "citibank.bankingsystems.com". This is SPF-as-an-anti-joe-job-mechanism break #2 -- a required mental mapping between institution name and domains are not present.
(c) SPF is broken in a number of ways as an authentication scheme for domains. It uses DNS as a transport (not secure, and makes very little sense, given the limitations of DNS WRT what SPF is trying to do) without attempting to establish a secure transport on top. It uses IP-based authentication for the mail system (did *nobody* learn from the days of the r-services and IP authentication leading to horrible security breeches) *as well* as to the authentication server (the DNS system). This is a third break as an anti-joe-job tool -- just because a domain may be trusted does not mean that the message that you are reciving is a legitimate message from that domain.
SPF is largely, as a friend of mine would put it, a masturbatory system. It lets corporations claim that they're "doing something" about spam, and CIOs feel good about what they're doing. It will employ many sysadmins for a long time who will keep tweaking it in the hope that the next adjustment or just one more deployement will be that Holy Grail to stop spam. In reality, it merely breaks existing functionality and diverts resources and research from legitimate anti-spam efforts, like client-to-client encrytion/signing deployment.
For the foreseeable future, if you don't publish SPF, your email will still work.
This is another thing wrong with SPF.
For a protocol to work on the vastly disorganized and chaotic Internet, it needs to work when members are not fully compliant with the protocol or are acting oddly.
SPF is much like the existing massive effort to try to stop open relays (which has been going on for a long time and clearly has not stopped spam). Both methods are predicated on being able to make everyone fully and correctly implement the behavior for *anyone* to benefit -- or else spam still comes through.
SPF isn't even a good anti joe-job tool, because almost all the time a joe-job/phishing scheme goes on, people don't have a mental mapping from the institution ("Citibank") to all the domains and subcontractors that might be used ("citibank.com"? How about "citibank-customerservice.com"?) I guarantee you that my mother would fall for "citibank.banksystems.net"). Regular Joes aren't familiar with the DNS structure, and in any event, administrative and political structures don't always maintain a hierarchical flow that maps to DNS. I'm sure the registrars would love to push a "register everything spelled like, based on, or sounding like your domain!" solution -- it's wildly impractical.
Remember, over 50% of all email is now spam. Anything so lightweight that will block so much of it for those of us who use that tool, and force the rest of the email to be so much more easily tracked as being from a forgery friendly domain, is a big deal. This also helps put a spike in the growth of "zombied" machines, by helping prevent them from being able to forge valid user's domains. Coupled with mail servers that insist that your domain does, in fact, exist in order to claim that your mail is from a real domain, it helps quite a lot.
The problem is that you're making the (known wrong) assumption that spammers do not adapt and use new tools. Remember the Baysian filtering advocates, that were *sure* that spam was at an end? No, new tools just went out. Yeah, at the time SPF is deployed, a lot of people won't be using updated tools. How long do you think that will last? Even the SPF people's FAQ talks about the fact that they know that SPF isn't sufficient. Where I disagree with the SPF people is that they at least view SPF as a good foundational tool to help build systems that might potentially stop spam someday on. I see SPF as an extremely weak, course-grained, and ill-thought-out authentication system.
Without SPF, you don't know who your email is really from so you can't do domain based reputation.
SPF is the least trustworthy of the the current Big Three domain authentication schemes -- DomainKeys is ahead. None of them are particularly great authentication schemes, especially since all of them are limited to domain-level granularity (one machine with an authorized IP at a company gets compromised, outsiders have to ban the entire company's domain, rather than just the sending key).
Basically, it's awfully easy to DoS a reputation scheme with very minimal compromises involved. And any sort of throwaway-domain scheme is very hard to deal with with a reputation scheme, especially since an integer representing a global reputation may not be sufficient (and is how most folks want to do reputation schemes). Russian company A may trust Russian company B, but I'm less likely to trust random mail from a Russian domain. I'm more likely to trust mail from a person that interacts with people that I interact with than otherwise.
SPF is a very weak tool to allow doing this.
Why doesn't everyone use PGP already? It's been out since 1991. It's never had the success it deserves.
Because it's a pain in the ass to use. You ever tried it? The only client I've seen where it's remotely usable is mozilla+enigmail -- even mutt has serious issues.
For PGP/GPG to be widely used, major clients must:
* Support automatic key downloading.
* Support automatic encryption/signing (*not* having to manually do so on a per message basis or copy/pasting or hitting a special key to decrypt)
* Support opportunistic encryption. The current interface on most clients is that emails are not encrypted unless a person explicitly and manually tells their client to encrypt to a given person, manually imports the key, and manually sets up trust with that person. That isn't going to happen for everyone I know, even though I'm a bit of a security nut. If you have a key in your keyring that purports to belong to someone, it should be used (unless you explicitly tell your client not to do so). It doesn't hurt security, and it can help it. You can always explicitly tell your client "use this key always with these recipients" as you did before, but this means that the *default* is to be secure rather than insecure.
* It should be much more transparent than it is today. If people don't want to deal with key management, they should get what signing and encryption we can give them without it. If they *do* want to use trust management features, then they can take advantage of those and ensure that they're using proper keys and the like. SSH would *never* have taken off as a telnet replacement if it *required* manual key distribution -- yes, automatic key distribution is a bit less secure, but it's generally a Good Thing, and the paranoid nuts who require a secure connection to a place or two can still use good ol manual key distribution.
And before you say "well, why don't you do it", I'm actively submitting patches to achieve exactly this.
One issue that comes to mind is that signature verification is relatively expensive. Another is that it's fragile: regular PGP users often see their signatures fail to verify because an MUA changed the line wrapping. I think we need a standard for canonicalizing messages before hashing, but that's just my opinion.
Hmm...you see this even with MIME-format PGP?
"If you think cryptography can solve your problem, then you don't understand your problem and you don't understand cryptography." That's maybe a little rude but it's good to remember that crypto only changes one problem into a different problem. We'd have to manage the public keys, and we'd still be dealing with today's problem of insecure machines being taken over.
"If you think cryptography isn't necessary to solve your problem, then you don't understand your problem and you don't understand cryptography."
Cryptography is necessary to do the kind of authentication that the anti-spam people want to do.
It just isn't, alone, sufficient.
Sorry, I got so worked up that I failed to finish my last post.
PGP does not answer this question. Neither does Yahoo's DomainKeys. There are many circumstances where the signature can not be verified. You can not use the failure to verify a PGP signature as a reliable means to filter out junk.
SPF and MS Caller ID are designed to answer this second question reliably enough to discard forged messages. They answer this question for all domains that publish SPF records (aol.com, gmail.com, etc) regardless of whether SPF is widely adopted by the rest of the world.
Bullshit. Give me an example of an environment where email could reasonably pass SPF but not DomainKeys.
I'm not even going to get started on how a system (not necessarily PGP) that does client-to-client signing and encryption is so much more intelligent, breaks in so far fewer cases, and is so much stronger and won't need to be thrown out in a few months.
When the claimed domain published a list of designated senders, and the sending MTA's IP number isn't among them, you can be certain the message is a forgey and discard it (or close the connection before the data phase, saving bandwidth).
"Thanks" to new restrictions imposed on mail service by SPF, yes.
PGP and other crypto signature schemes simply do not deliver this ability to detect forgey. They only detect authenticity.
So, what exactly do you *think* SPF is?
It's a weak authentication scheme. A very weak one, with known attacks and only domain-level granularity.
Any other system that authenticates against the domain (Caller ID, DomainKeys) can do a similar act, and any system that authenticates against the sender (PGP, S/MIME, etc) can do not only that, but provide client-level granularity -- with SPF/Caller ID/(and for any sane deployment, DomainKeys), if someone compromises a workstation at a company and starts sending email as a client from that machine to the local mail server using a variety of addresses, the only action an outside person can take is to blocked the entire domain (try doing this to ford.com or apple.com). PGP and similar systems allow only the owner of the compromised workstation to be blocked, as well as the compromised workstation to be easily identified.
Every spam article, someone posts an opinion that if everyone would just use crypto (usually PGP is suggested), all these problems would be solved.
A lot of us are arguing that strong crypto is *necessary*, not that it is *sufficient* on its own.
For a moment, neglect the high costs, complexity, worldwide legality and PKI problems of crypto, which are all solvable at some cost.
The high costs? How many, exactly, CPU cycles would you spend to avoid bandwidth from spam?
Worldwide legality? Get real. Russians haven't supposed to be using OpenSSL for trusted stuff in the government for years. Nobody cares about that, because it's ridiculous. Encryption software is everywhere.
PKI problems of crypto? You have a problem with distributing trusted data to do *crypto*? How about the equivalent trusted-data problems of *SPF*, including the fact that the currently proposed transport mechanism is non-trusted and the designers treat it as trusted, or that the SPF's folks' solution to throwaway domains is some vague hand-waving and the stuggestion of a web of trust -- *exactly* the same thing you're claiming we don't have to deal with.
The only reason anyone is considering SPF is because they're desperate and if you ignore some of the things that the people working on crypto solutions have taken into account (which are necessary to actually have a workable system), you can look sideways at SPF and say "yeah, this probably kinda works". It makes people feel good to have something to deploy, even if it breaks existing legitimate functionality and has zero long-term impact on spam (spammers just run out, buy the latest idot-proof tools, and go to town -- Baysian filtering didn't stop them because they bought *tools* to get around it, and if you think that they won't just buy tools to bypass SPF, you're smoking something). The difference is that SPF breaks far more functionality than Baysian filtering does.
For more problems I have with SPF, I've collected links to a bunch of my earlier posts detailing issues I have with SPF in a response to Meng.
In short -- SPF has severe technical problems. Caller ID has almost all the same severe technical problems (and introduces at least the question of patents). DomainKeys has a large number of drawbacks, and even *it* is much better thought out than either SPF or Caller ID.