JSON is not the problem (the contact list could also be in XML or whatever other format), but the fact that Google hands out the contact list "script" based on cookie validation only. A simple referrer check should provide "good enough" security.
Yes, the forwarding is my main gripe with SPF. The proposed workaround is ugly at best.
The other main problem is SPFs misunderstanding of the role of the envelope sender. It is nothing more than a return address for bounces. It does not securely identify the sender or his domain.
But then, I admit it is unfair to compare SPF with Domainkeys. They do completely different things on a different "level". You could say that Domainkeys is closer to the user, because they can choose to trust email with their user agents. I think this is the better path to take.
While you are right, this is (sadly) not the way how current ML and other header-munging software works. Current best-practice is to post-pend headers in order to keep Received: headers in a "block" on top.
1. Domainkeys does not break forwarding. 2. Domainkeys can be used either on the MUA or the MTA, for both sender and recipient sides. This makes it possible to still use 3rd party relays. 3. Domainkeys spoof-protects the domain in the "From:" header field, which is what Joe Sixpack sees in his MUA application.
Domainkeys does have the problem that you can't add headers to messages without re-signing them. If you re-sign them you must also rewrite the "From:" header. This will affect mailinglists.
Domainkeys will not ultimatively solve the spam problem, but it is better than the broken SPF.
Slashdot Mirror
JSON is not the problem (the contact list could also be in XML or whatever other format), but the fact that Google hands out the contact list "script" based on cookie validation only. A simple referrer check should provide "good enough" security.
Yes, it actually works on SP2. Fire up Task Manager and watch CPU load reach 100% for ~10 seconds for a single packet.
Here's the code that should compile on Linux.
Yes, the forwarding is my main gripe with SPF. The proposed workaround is ugly at best.
The other main problem is SPFs misunderstanding of the role of the envelope sender. It is nothing more than a return address for bounces. It does not securely identify the sender or his domain.
But then, I admit it is unfair to compare SPF with Domainkeys. They do completely different things on a different "level". You could say that Domainkeys is closer to the user, because they can choose to trust email with their user agents. I think this is the better path to take.
While you are right, this is (sadly) not the way how current ML and other header-munging software works. Current best-practice is to post-pend headers in order to keep Received: headers in a "block" on top.
1. Domainkeys does not break forwarding.
2. Domainkeys can be used either on the MUA or the MTA, for both sender and recipient sides. This makes it possible to still use 3rd party relays.
3. Domainkeys spoof-protects the domain in the "From:" header field, which is what Joe Sixpack sees in his MUA application.
Domainkeys does have the problem that you can't add headers to messages without re-signing them. If you re-sign them you must also rewrite the "From:" header. This will affect mailinglists.
Domainkeys will not ultimatively solve the spam problem, but it is better than the broken SPF.