The issue are all those very popular applications that use only MySQL. Such as WordPress. For many of them, migrating to Postgres is not trivial.
Well said. When your app is a big ball of mud, moving from an old, soft foundation to a newer, stronger foundation is very difficult without breaking the big ball of mud.
If your referential integrity is in your application then your database engine is broken. His professor had it right. He wasn't writing to a product, he was writing to just about any modern relational database management system *except* for MySQL and SQLite. At least SQLite never pretended to have a complete feature set. MySQL lacked and blamed its lack on "avoiding bloat."
And constraints in MySQL? Is that why CHECK constraints were silently ignored for so many years? What you call "constraints," I call "the vast subset of constraints that MySQL managed to support in a timely fashion." Big difference.
You can simulate 3NF with application patches, but without actual DB support, it's smoke and mirrors. Without enforced foreign keys, it's not an ACID database. A database engine missing ACID is like an operating system with cooperative multitasking. Sure you can have multiple apps running at the same time, but don't for a second pretend that it's the same thing as preemptive multitasking as long as you have proper application support. To assert as much is missing the underlying point altogether.
Please cite where Smalltalk is shown to be anywhere near the speed of Java. A quick Google search reveals this language comparison where Smalltalk gets its ass handed to it, and that was written in 2004. Say what you will about Smalltalk's elegance, but speed was never truly its forte.
Yeah, Javadoc should have a place for that stuff. Oh wait, it does! It even has a style guide for information about your fields, methods, classes, and packages. They even describe how to embed (wonder of wonders) diagrams and other images into your source documentation.
It's not like Javadoc (or any other documentation tool) can magically create annotated code samples and training tools on its own. Don't blame Javadoc, blame the lazy bums who never bother to actually document their stuff.
Anyway, if they're teaching dangerous programming practices, they should be removed. We don't need generations of ignorant PHP programmers causing SQL-injection in their projects. Good point. I recommend we start with php.net. Eventually the problem should go away.;-)
That's hardly specific to PHP though, I find Java worse than PHP for that. "why is this code using HashMap instead of Vector" etc... Idiocy transcends language boundaries. Java is worse than PHP? Because of *that*!? For one, I think you meant to say, "Why is this code using Hashtable instead of HashMap," or perhaps say, "Why is this code using Vector instead of ArrayList?" For anything since Java 1.2 (many years ago), you should only be using Vector or Hashtable for legacy code that must work with very old VMs or if you need to access the data structure from multiple threads. Pretty straightforward to me as any Java programmer worth their salt knows this.
The fact that just about everyone uses javadoc is clearly another reason why Java is better than PHP.
Keyword "generally". I've got several small apps that exist as single PHP files. Forcing separation (or even OOP) here is not a good thing, it's pointless and stupid. And in those cases, JSP files would work just as well. (Or ColdFusion or ASP or just about any other solution out there. The simplest cases are handled well by everyone; PHP is nothing special here.)
Do a quick search for all of the times that people have wanted to load a page with XmlHttpRequest only to find the target is not valid XHTML (XML). It works some of the time and the framework may be XHTML, but the framework (usually PHP) happily embeds snippets that aren't well-formed.
The main problem with DKIM is that it is policy-optional. The policy is the thing that tells you a domain's signing policy. Then why is there a "Sender Signing Policy" section in the DKIM spec for precisely this purpose?
Do they sign all of their mail? Once again, see the Sender Signing Policy.
Where should you find the public key? Maybe the location/method specified in the DKIM-Signature header in the email... When you see "q=dns" in the header, you query DNS. Did you even look at the spec before posting?
Do they have a particular third party handle all their signing? No, that was one of the design goals of DKIM: no mandatory third-parties necessary; you don't have to pay to play. If you make people pay for a technology, there's less chance they'll adopt it on a large scale.
Here's your primary mistake: DKIM is not now nor has it ever been an anti-spam technology. It is an authentication technology. It makes sure you are who you say you are. Used in conjunction with deny lists and reputation services like Spamhaus, it can block spam. But more importantly, no one can send from "paypal.com" except PayPal. If spammers/phishers cannot spoof domains, you may still get Viagra ads, but you won't get eBay hacks. Once spammers are cornered to their own domains, those ISPs will be systematically blocked with nowhere to go. ISPs that tolerate or aid spamming/phishing will find that they are no longer able to communicate with the world anymore.
A better system, that's been consistently rejected by the DKIM developers, would be policy is required. You get a mail, you look up the domain's policy, and you can decide in a concrete way if this mail really came from that domain. Man! Where do you get this stuff? When you receive a signed message, you don't have to look up a policy. All you have to do is look up the public key associated with the message category (the "c" attribute in the DKIM-Signature header). The message will either pass or fail. Done. No policy lookup necessary. If it should be signed in some other fashion, there wouldn't be a valid public key for it in the first place!. If there is no valid signature, then you look up the policy using the extremely well documented steps for doing so.
DKIM makes sense only if there are very few email signers... Wrong! DKIM was *designed* so that third-party authorities were not necessary. All you need at the minimum is to generate a public key pair and deploy them. Your private key is stolen? No problem! Generate a new pair, sign all new mail with the new private key and publish the new public key on your DNS server. DKIM makes absolute sense even with ZERO third-party authorities. The only ones who push that line are the third-party authorities because they want your two bits.
Please stop discussing DKIM. You obviously do not know enough about it to give reasoned advice on the topic.
S/MIME requires a certificate signed by a third-party certificate authority to be even remotely useful. DKIM does not. A self signed cert wouldn't work for S/MIME because any spammer could then just generate their own key pair and send.
PGP is an end-to-end signature and encryption solution. This is a completely different problem domain. PGP/GPG can guarantee that userA@placeA.com actually wrote the email to userB@placeB.com and that only userB@placeB.com could have written it.
BUT...
This requires that every single user on the internet gets a copy of PGP and shares their public key with everyone they know. Most businesses (even the legitimate ones) don't know all of the people that contact them. Could you imagine telling a sales department that they can only converse with people with people they have previously talked to? I'm sure they'd all quit long before you went bankrupt.
DKIM can work (and usually does work) at the organizational and domain levels. This is a huge win for adoptability since most folks haven't even heard of PGP let alone public key encryption let alone how to use them.
Your comment about SPF is almost correct, but the failure to widely commit to SPF is not because of apathy. After years of growing their IT infrastructure out, to list all possible SMTP launch points is not only prohibitively expensive, but hard to manage for very large organizations that span multiple subnets and multiple continents.
DKIM signs header fields, it's true, but organizations decide which fields are used for the signature. It's not like DKIM uses all fields. In fact, it can use the content of the email or a subset of the content as part of the signature as well.
Matching on the envelope is a *bad* idea. It was a bad idea for other technologies, and it'll be a bad idea for the next crop of technologies that use it. As soon as you have an email redirection from one relay to the other, the headers will usually remain intact but the envelope will most certainly change.
DKIM breaks on relay more than SPF? You are obviously high. DKIM was *designed* to be more relay friendly than SPF. If DKIM is causing you problems when going through relays, the problem lies with your DKIM setup, not with DKIM.
Would only be an issue if the email were sent from the user's own domain. If they tried to spoof PayPal, eBay, or Citibank, they would be identified and isolated quickly using DKIM.
Anti-forgery technologies mean that the spammers have to send from their own DKIM-signed domains instead of spoofing PayPal et al. At that point, a DNSbl like Spamhaus will identify them for what they are so you can take them out.
As for the scenario of a company wanting to censor MP3 attachments, they can do so already just by looking for the MIME attachments. They've been able to do that since day one. It has nothing to do with DKIM.
In a discussion where so many people have no idea what they're talking about, especially with regards to DKIM, it's refreshing to see such an accurate point.
I don't blame them. SPF doesn't cut it. In theory, making an audit of all SMTP hosts allowed to send email for your domain and listing them in an SPF record makes sense. In practice, when you have a large, multinational organization with many subnets and even more SMTP senders, it simply doesn't make economic sense -- especially when it's a technology intimately tied to something as flakey as DNS. Check to see if that bank has a DKIM record instead.
The DKIM records show up as a complete "_domainkey" subdomain, not a single TXT record like SPF.
DKIM can create a signature based on the email content as well, not just from email header fields. It can even work on a subset of the email content so that automatically generated footers don't gum up the works.
The only way you could think that SPF was better was if you did not understand DKIM or hadn't read the DKIM spec.
Also, just because you add DKIM support doesn't mean you have to dump SPF; they are not conflicting technologies. DKIM is simply a better technology. I would even venture to say that generating a private key pair is easier than enumerating all of the IPs and host names in your domain in perpetuity like you do with SPF.
Check your SPF record. Does it end in "~all" like most domains? Are you really satisfied with a technology where the usual answer to a query is "maybe?"
DKIM is email-based, not email user name-based. It *can* use the email address as part of the signature, but this is not necessary. Unlike SPF, you can also have multiple signatures per domain so that all of your eggs are not in one basket.
Basically the email server has the private key in a cryptographic key pair. The public key is placed in a special DNS domain entry (but this special entry does not violate standard DNS syntax). The SMTP server (or client) adds the header "DKIM-Signature" to each email, which contains the query mechanism, the cypher type, which other headers and bits of content were used to generate the signature, etc. When the recipient's email server gets the DKIM-signed email, the receiving server queries for the public key (usually from DNS, but that is not a requirement of the DKIM spec) and verifies from the signature that the email is valid.
It is a much better solution than SPF in that DKIM works through relays without any problems, is not dependent upon DNS should DNS ever get updated or replaced, and does not rely upon a fixed list of server IPs or host names to function correctly. DKIM could work from a laptop in a hotel room provided the email client understands DKIM and you have a valid private key. Once again, the public/private key pair for the laptop need not be the same key pair for the rest of the organization. In fact, DKIM even allows for expiring old keys and putting new ones in place without interrupting service.
In summary, SPF was marginal at best when it was the only game in town. DKIM does everything SPF does, it does it better, and does a lot more with fewer headaches.
Let SPF die and do not mourn its passing.
(And in case you were wondering, yes, I have maintained mail servers before and have worked in the past for two different companies that sell SMTP servers and software. I was the one who wrote the section about DomainKeys, DKIM, SPF, SenderID, GoodMail, etc. in the product manual.)
DKIM allows the sender to specify which headers to include and also limits on the how much of the content to use for the cryptographic hash (so that automatically added footers don't spoil the party). DKIM was *designed* to work with relays without causing problems, extra work from administrators, single points of failure, etc.
DKIM isn't even intimately tied to DNS; it just uses DNS because that's what people have today. Any other domain lookup mechanism would work including LDAP or an HTTP request.
SPF is broken in that "tracking exists: mechanism" is still spoofable and requires constant maintenance. The cryptographic key of DKIM cannot be spoofed today.
Another huge win is that SPF requires that you make an audit of all of your sending servers or risk bouncing messages. This is why most companies still have a "~all" at the end of their SPF records. What good is "allow all when in doubt"? DKIM solves this by sidestepping the server IP enumeration issue altogether. The only requirement is that your MTA software (not email client!) supports DKIM.
One of the strengths of DKIM is that it can work with existing infrastructure like DNS. DNS knows nothing about individual addresses. Many SMTP servers don't even know much about individual addresses since they are just relays.
That said, there can be more than one DKIM signature per domain. Hell, it's technically possible to create as many DKIM signatures as there are email addresses, it would just be a major PITA to maintain.
With DKIM you can at least hold domains accountable to their users' behavior and indemnify them against the behavior of nefarious individuals outside of their network. It truly is an elegant solution to the problem of authentication and reputation.
If you want security on just your own email address, use PGP/GPG to sign/encrypt the email. Problem solved. The point to DKIM is that an ISP can implement it without having to educate users or alter their workflow a single iota.
What XML is not, and never will be, is a standard way for different programs written by different people to pass data around for an extended amount of time.
Like XHTML? Like the metadata for many file formats like OGG? Or did you mean when XML is used without a validating schema?
Slashdot Mirror
Well said. When your app is a big ball of mud, moving from an old, soft foundation to a newer, stronger foundation is very difficult without breaking the big ball of mud.
If your referential integrity is in your application then your database engine is broken. His professor had it right. He wasn't writing to a product, he was writing to just about any modern relational database management system *except* for MySQL and SQLite. At least SQLite never pretended to have a complete feature set. MySQL lacked and blamed its lack on "avoiding bloat."
And constraints in MySQL? Is that why CHECK constraints were silently ignored for so many years? What you call "constraints," I call "the vast subset of constraints that MySQL managed to support in a timely fashion." Big difference.
You can simulate 3NF with application patches, but without actual DB support, it's smoke and mirrors. Without enforced foreign keys, it's not an ACID database. A database engine missing ACID is like an operating system with cooperative multitasking. Sure you can have multiple apps running at the same time, but don't for a second pretend that it's the same thing as preemptive multitasking as long as you have proper application support. To assert as much is missing the underlying point altogether.
Please cite where Smalltalk is shown to be anywhere near the speed of Java. A quick Google search reveals this language comparison where Smalltalk gets its ass handed to it, and that was written in 2004. Say what you will about Smalltalk's elegance, but speed was never truly its forte.
Yeah, Javadoc should have a place for that stuff. Oh wait, it does! It even has a style guide for information about your fields, methods, classes, and packages. They even describe how to embed (wonder of wonders) diagrams and other images into your source documentation.
It's not like Javadoc (or any other documentation tool) can magically create annotated code samples and training tools on its own. Don't blame Javadoc, blame the lazy bums who never bother to actually document their stuff.
The fact that just about everyone uses javadoc is clearly another reason why Java is better than PHP. Keyword "generally". I've got several small apps that exist as single PHP files. Forcing separation (or even OOP) here is not a good thing, it's pointless and stupid. And in those cases, JSP files would work just as well. (Or ColdFusion or ASP or just about any other solution out there. The simplest cases are handled well by everyone; PHP is nothing special here.)
I consider Safari on the iPhone/iPod Touch to be a damn good browser for a portable, smart phone, PDA, etc.
Unfortunately I don't have a link for you.
Do a quick search for all of the times that people have wanted to load a page with XmlHttpRequest only to find the target is not valid XHTML (XML). It works some of the time and the framework may be XHTML, but the framework (usually PHP) happily embeds snippets that aren't well-formed.
Happens all of the time.
That's one way of doing it. Another is with XML as specified by Xiph.
Here's your primary mistake: DKIM is not now nor has it ever been an anti-spam technology. It is an authentication technology. It makes sure you are who you say you are. Used in conjunction with deny lists and reputation services like Spamhaus, it can block spam. But more importantly, no one can send from "paypal.com" except PayPal. If spammers/phishers cannot spoof domains, you may still get Viagra ads, but you won't get eBay hacks. Once spammers are cornered to their own domains, those ISPs will be systematically blocked with nowhere to go. ISPs that tolerate or aid spamming/phishing will find that they are no longer able to communicate with the world anymore. A better system, that's been consistently rejected by the DKIM developers, would be policy is required. You get a mail, you look up the domain's policy, and you can decide in a concrete way if this mail really came from that domain. Man! Where do you get this stuff? When you receive a signed message, you don't have to look up a policy. All you have to do is look up the public key associated with the message category (the "c" attribute in the DKIM-Signature header). The message will either pass or fail. Done. No policy lookup necessary. If it should be signed in some other fashion, there wouldn't be a valid public key for it in the first place!. If there is no valid signature, then you look up the policy using the extremely well documented steps for doing so. DKIM makes sense only if there are very few email signers... Wrong! DKIM was *designed* so that third-party authorities were not necessary. All you need at the minimum is to generate a public key pair and deploy them. Your private key is stolen? No problem! Generate a new pair, sign all new mail with the new private key and publish the new public key on your DNS server. DKIM makes absolute sense even with ZERO third-party authorities. The only ones who push that line are the third-party authorities because they want your two bits.
Please stop discussing DKIM. You obviously do not know enough about it to give reasoned advice on the topic.
You are so far from correct, you're not even wrong.
S/MIME requires a certificate signed by a third-party certificate authority to be even remotely useful. DKIM does not. A self signed cert wouldn't work for S/MIME because any spammer could then just generate their own key pair and send.
PGP is an end-to-end signature and encryption solution. This is a completely different problem domain. PGP/GPG can guarantee that userA@placeA.com actually wrote the email to userB@placeB.com and that only userB@placeB.com could have written it.
BUT...
This requires that every single user on the internet gets a copy of PGP and shares their public key with everyone they know. Most businesses (even the legitimate ones) don't know all of the people that contact them. Could you imagine telling a sales department that they can only converse with people with people they have previously talked to? I'm sure they'd all quit long before you went bankrupt.
DKIM can work (and usually does work) at the organizational and domain levels. This is a huge win for adoptability since most folks haven't even heard of PGP let alone public key encryption let alone how to use them.
Your comment about SPF is almost correct, but the failure to widely commit to SPF is not because of apathy. After years of growing their IT infrastructure out, to list all possible SMTP launch points is not only prohibitively expensive, but hard to manage for very large organizations that span multiple subnets and multiple continents.
DKIM signs header fields, it's true, but organizations decide which fields are used for the signature. It's not like DKIM uses all fields. In fact, it can use the content of the email or a subset of the content as part of the signature as well.
Matching on the envelope is a *bad* idea. It was a bad idea for other technologies, and it'll be a bad idea for the next crop of technologies that use it. As soon as you have an email redirection from one relay to the other, the headers will usually remain intact but the envelope will most certainly change.
DKIM breaks on relay more than SPF? You are obviously high. DKIM was *designed* to be more relay friendly than SPF. If DKIM is causing you problems when going through relays, the problem lies with your DKIM setup, not with DKIM.
Would only be an issue if the email were sent from the user's own domain. If they tried to spoof PayPal, eBay, or Citibank, they would be identified and isolated quickly using DKIM.
Anti-forgery technologies mean that the spammers have to send from their own DKIM-signed domains instead of spoofing PayPal et al. At that point, a DNSbl like Spamhaus will identify them for what they are so you can take them out.
Here are the technical details on DKIM that you're looking for.
As for the scenario of a company wanting to censor MP3 attachments, they can do so already just by looking for the MIME attachments. They've been able to do that since day one. It has nothing to do with DKIM.
In a discussion where so many people have no idea what they're talking about, especially with regards to DKIM, it's refreshing to see such an accurate point.
DKIM + DNSbl = dead spam
I don't blame them. SPF doesn't cut it. In theory, making an audit of all SMTP hosts allowed to send email for your domain and listing them in an SPF record makes sense. In practice, when you have a large, multinational organization with many subnets and even more SMTP senders, it simply doesn't make economic sense -- especially when it's a technology intimately tied to something as flakey as DNS. Check to see if that bank has a DKIM record instead.
The DKIM records show up as a complete "_domainkey" subdomain, not a single TXT record like SPF.
DKIM can create a signature based on the email content as well, not just from email header fields. It can even work on a subset of the email content so that automatically generated footers don't gum up the works.
The only way you could think that SPF was better was if you did not understand DKIM or hadn't read the DKIM spec.
Also, just because you add DKIM support doesn't mean you have to dump SPF; they are not conflicting technologies. DKIM is simply a better technology. I would even venture to say that generating a private key pair is easier than enumerating all of the IPs and host names in your domain in perpetuity like you do with SPF.
Check your SPF record. Does it end in "~all" like most domains? Are you really satisfied with a technology where the usual answer to a query is "maybe?"
DKIM is email-based, not email user name-based. It *can* use the email address as part of the signature, but this is not necessary. Unlike SPF, you can also have multiple signatures per domain so that all of your eggs are not in one basket.
Basically the email server has the private key in a cryptographic key pair. The public key is placed in a special DNS domain entry (but this special entry does not violate standard DNS syntax). The SMTP server (or client) adds the header "DKIM-Signature" to each email, which contains the query mechanism, the cypher type, which other headers and bits of content were used to generate the signature, etc. When the recipient's email server gets the DKIM-signed email, the receiving server queries for the public key (usually from DNS, but that is not a requirement of the DKIM spec) and verifies from the signature that the email is valid.
It is a much better solution than SPF in that DKIM works through relays without any problems, is not dependent upon DNS should DNS ever get updated or replaced, and does not rely upon a fixed list of server IPs or host names to function correctly. DKIM could work from a laptop in a hotel room provided the email client understands DKIM and you have a valid private key. Once again, the public/private key pair for the laptop need not be the same key pair for the rest of the organization. In fact, DKIM even allows for expiring old keys and putting new ones in place without interrupting service.
In summary, SPF was marginal at best when it was the only game in town. DKIM does everything SPF does, it does it better, and does a lot more with fewer headaches.
Let SPF die and do not mourn its passing.
(And in case you were wondering, yes, I have maintained mail servers before and have worked in the past for two different companies that sell SMTP servers and software. I was the one who wrote the section about DomainKeys, DKIM, SPF, SenderID, GoodMail, etc. in the product manual.)
DKIM allows the sender to specify which headers to include and also limits on the how much of the content to use for the cryptographic hash (so that automatically added footers don't spoil the party). DKIM was *designed* to work with relays without causing problems, extra work from administrators, single points of failure, etc.
DKIM isn't even intimately tied to DNS; it just uses DNS because that's what people have today. Any other domain lookup mechanism would work including LDAP or an HTTP request.
SPF is broken in that "tracking exists: mechanism" is still spoofable and requires constant maintenance. The cryptographic key of DKIM cannot be spoofed today.
Another huge win is that SPF requires that you make an audit of all of your sending servers or risk bouncing messages. This is why most companies still have a "~all" at the end of their SPF records. What good is "allow all when in doubt"? DKIM solves this by sidestepping the server IP enumeration issue altogether. The only requirement is that your MTA software (not email client!) supports DKIM.
Individuals don't have to do anything. It's a domain-based technology, so your ISP would be the one to implement it.
You didn't read the article nor read up on how DKIM actually works, did you?
One of the strengths of DKIM is that it can work with existing infrastructure like DNS. DNS knows nothing about individual addresses. Many SMTP servers don't even know much about individual addresses since they are just relays.
That said, there can be more than one DKIM signature per domain. Hell, it's technically possible to create as many DKIM signatures as there are email addresses, it would just be a major PITA to maintain.
With DKIM you can at least hold domains accountable to their users' behavior and indemnify them against the behavior of nefarious individuals outside of their network. It truly is an elegant solution to the problem of authentication and reputation.
If you want security on just your own email address, use PGP/GPG to sign/encrypt the email. Problem solved. The point to DKIM is that an ISP can implement it without having to educate users or alter their workflow a single iota.
Point taken, still an important feature lacking in S-expressions, but point taken.
Like XHTML? Like the metadata for many file formats like OGG? Or did you mean when XML is used without a validating schema?