Yahoo Submits DomainKeys Draft To IETF 350
NetWizard writes "According to a mailing list post at the IETF, Yahoo's website and a Wired News story, Yahoo has made the DomainKeys draft public and submitted to the IETF." Russ Nelson explains "Basically, your MTA uses RSA-SHA1 to sign the headers and body of your email and inserts that signature before sending the email. The recipient MTA looks up $selector._domainkey.$domain in the DNS, gets your public key, verifies it, and inserts a notice. There's also a SourceForge project for a DomainKeys library."
An anonymous reader asks "It seems to me that it doesn't offer anything more than the Sender Policy Framework by pobox.com, other than doing relay-based signing of the messages to provide the sender verification. SPF has already grown to over 14,000 domains so far and only requires an addition to your DNS to support (from the sending side). Verifying messages on the receiving MTA is as simple as doing a DNS lookup, most MTAs can support SPF now, the code is available and well tested. What advantages to people see in Domainkeys over SPF that are actually useful, and what standard should people implement?"
Expensive... (Score:3, Insightful)
Basically, your MTA uses RSA-SHA1 to sign the headers and body of your email and inserts that signature before sending the email. The recipient MTA looks up $selector._domainkey.$domain in the DNS, gets your public key, verifies it, and inserts a notice.
Computationaly that sounds mighty expensive...
Re:Expensive... (Score:4, Interesting)
Re:Expensive... (Score:3, Insightful)
The bigest problem is DoS attacks against mail servers by using crafted emails designed to be greater than normally dificult to hash and/or check the signature there-of. And of course if y
Re:Expensive... (Score:4, Insightful)
A common fallacy; the actual situation is just the opposite. Spammers don't use their own computers to send spam. They use hordes of virus-infected Windows machines. Compute costs them nothing or at most some small fee to a virus writer over IRC.
Legitimate organizations use expensive, highly-available, rack-mounted servers. They actually care if they lose a message due to machine failure, and they can't illegally use someone else's machines to do the work for them. Compute for them is very expensive.
Making SMTP more computationally expensive just hurts the good guys. The only reason this proposal has any merit is that it's imposing this penalty to get some other benefit, authentication from the signing, which will actually help identify legitimate mail, since the spammers can't do the computation at all without the private key.
SPF isn't based on IP addresses. (Score:4, Insightful)
And another thing. People keep complaining that SPF and other similar schemes won't stop spam cause spammers use hijacked machines. Duh! What these schemes will stop is worms, not spam. That also explains why Microsoft is interested - rather than fixing their god damned software so it's secure, they want to fix everyone's email so that broken Microsoft software isn't quite so annoying. Well, whatever.
Actually, SPF *is* based on IP addresses. (Score:3, Insightful)
Domain keys does not check the senders' IPs to verify them. Instead, it uses a digital signature. The difference between
To understand... (Score:5, Interesting)
Re:To understand... (Score:2, Informative)
Re:To understand... (Score:5, Informative)
In short - SPF looks like the more elegant solution.
Re:To understand... (Score:5, Informative)
The trouble with SPF is that it's based on IP addresses, and forwarding completely breaks SPF. That's why they need SRS in order to be able to forward at all.
Domain Keys suffers from Replay Attack (Score:4, Interesting)
A spammer sends a single email from his Yahoo! account to himself. He takes the sent message, encrypted with domain key, and then sends this message billions of times to servers across the planet. Since the message is encrypted with Yahoo!'s domain key, it is apparently authorized by Yahoo!.
Domain Keys without SPF won't work, because SPF says which servers are allowed to send email, while domain keys just says an email was signed by a particular key. If Yahoo! had SPF records as well as domain key records, the spammer would have to infiltrate a valid Yahoo! mail server to send the mail.
Re:Domain Keys suffers from Replay Attack (Score:3, Informative)
That attack could work, since I'm pretty sure Domain Keys doesn't sign the envelope.
Yahoo could immediately disable that account, but the spammer could continue to resend the same message. The 'To:' header would likely show only a no longer valid email address for the spammer. The 'From:' would of course be an ex-valid Yahoo account, probably created with bogus info.
But given that the messages would have to be completely identical, solutions like DCC (http://www.rhyolite.com/) would help.
Re:To understand... (Score:3, Insightful)
My mail servers allow our sales guys to log in, receive and send mail through our servers. We have exactly one allowed sender address.
Re:To understand... (Score:5, Funny)
Re:To understand... (Score:3, Informative)
Re:To understand... (Score:3, Informative)
Re:To understand... (Score:3, Insightful)
Not really. They are usually IP-based, and the salesperson would be on their network.
Fine, but does it scale? (Score:3, Insightful)
While working implementations are essential, they are by no means sufficient for estimating the effects of Internet-wide adoption of the proposed solution. Therefore the quality of the theoretical discussion matters a lot too.
When e-mail was first deployed, there was hardly any spam at
We need something allright (Score:2, Interesting)
And it better be an open solution not a proprietary one.
The only way I can see something like this happening though is if a few major backers get behind the same thing and most mta's/clients (depending on what the agreed upon implementation is) start supporting it.
Re:We need something allright (Score:3, Insightful)
You don't want to restrict mail that's not signed, but you can assign non-signed mail a lower "trust" value than signed mail. There will be a dis-incentive to digitally sign mail as a spammer since spammer signatures will soon be found out.
If they sign mail with a new key- the value will be similarly neutral.
PGP web of trust isn't about value of the person, but is the person who we think they are.
all email encrypted = viruses more effective (Score:2, Insightful)
Imagine what it would be like if everyone right now had encrypted email by default so hitting send automatically fetched a users public key to encrypt the data.
Viruses would start using the same methods to encrypt email going to all those users. There would be more viruses getting through to users than there are now since gateways would not be able to scan the email.
PGP? (Score:2, Insightful)
Re:PGP? (Score:4, Insightful)
"OK, Grandma, now type in your PGP passphrase. Ensure it's very long and made up of alphanumerics, symbols and control characters. Make sure you don't forget it..."
Re:PGP? (Score:2)
At least you don't have to wait too long until you can pry her private key from her cold, dead fingers...
Re:PGP? (Score:2)
I don't know about you, but I prefer to stay well away from my grandma's privates.
Re:PGP? (Score:3, Interesting)
The purpose would be to prove to the recipient that the e-mail came from someone who authenticated themselves as the person listed as the sender. You couldn't use it for non-repudiation purposes.
Re:PGP? (Score:2)
Thats just like saying your grandma doesnt have to worry about securing her computer becuase noone would be interested in hacking her system. Thats how you end up with all these worms that feed off random insecure systems. You really think spammers give a shit what the random email address they choose to spoof is? I mean I get emails from xjrr3@gsdfk
Re:PGP? (Score:2)
Unfortunately many ISPs force all outgoing mail to go through them (including mine), which means filtering on the sending MTA is rather crude - e.g. you can either allow or disallow all mail from hotmail.com.
Re:PGP? (Score:2)
Re:PGP? (Score:3, Insightful)
Patent Licensing (Score:2, Interesting)
There's more info on why CID's patent license is harmful at the boycott caller id for email [boycall-em...ler-id.org] site.
Re:Patent Licensing (Score:5, Informative)
Microsoft's implementation requires you to sign away your right to sue them for any patent claim and doesn't allow you to sublicense the technology (ie: GPL/LGPL/BSD-incompatible). This one is less agressive.
Re:commments on boycott-email-caller-id.org/ (Score:3, Informative)
That last bit is not allowed by the GPL. It does not allow further restrictions on the distribution of the software which is under the GPL.
Re:Patent Licensing (Score:2, Interesting)
If it ain't invisible, it's crap (Score:2, Funny)
God fuck me in the ass if I'm going to be required to do all that other crap.
Re:If it ain't invisible, it's crap (Score:2)
Any sort of additional user verification/etc used to try to limit spam and other undesirable mail needs to be transparent otherwise many people (like 3/4th of my family) will decide that e-mail is too hard to use and no longer worth it.
Re:If it ain't invisible, it's crap (Score:2)
Re:If it ain't invisible, it's crap (Score:3, Insightful)
Well, as long as we're running with bad analogies...
If you go in/out of said door 200 times a day, do you lock it every time? If so, you may want to see a mental health professional about that OCD.
One advantage DomainKeys has over SPF... (Score:5, Interesting)
Re:One advantage DomainKeys has over SPF... (Score:2, Informative)
Sender Rewriting Scheme [pobox.com]
Re:One advantage DomainKeys has over SPF... (Score:3, Insightful)
Re:One advantage DomainKeys has over SPF... (Score:4, Informative)
In the real world, people are known by a certain name. They may ask people to call them by another name, but certain legal entities (banks, loan companies, etc.) will insist on having access to that person's official identity. This is vaguely similar to what SPF proposes.
Re:One advantage DomainKeys has over SPF... (Score:3, Insightful)
Umm, no, not even close.
I have an address at ISP (foo@isp.net). I never use it, since it's incovenient to access, plus it gets a ton of spam.
I have several addresses at my domain (foo@mydomain.com, bar@mydomain.com, etc.). I do use them actively.
I have a work address (foo@company.com) which I also use actively.
I have a couple of yahoo addresse
Re:One advantage DomainKeys has over SPF... (Score:5, Insightful)
You are a mailserver admin -- that's a SUPPORT position. You don't decide what your users are allowed to see and you have no rights to demand to know the real name of people who are not even your users, but are just sending email to them.
I'm sorry, but you are incorrect. The mailserver admin is acting on behalf or (or may be in fact) the owners of the hardware that the mail in question is travelling through. That gives them every right to decide, by any standards they like, what mail they accept or don't accept.
This is a simple question of property rights. My property, my rights.
As far as what the users want, sheesh, it's like you just don't trust market forces anymore.. If the admin blocks too much, the users get pissed and find a new ISP. It's a self-correcting problem.
It is the mailserver admin's job to ensure the correct operation of the mailing system, and the owners of the system get to decide what "correct" means. Deal with it.
Re:One advantage DomainKeys has over SPF... (Score:3, Informative)
I am, however, responsible for implementing that policy as best as I c
Re:One advantage DomainKeys has over SPF... (Score:3, Interesting)
I'm hard pressed to come up with a situation in which this would be a real problem. Anyone?
Joe Whistleblower could lose his job if his "real identity" has to be exposed.
Re:One advantage DomainKeys has over SPF... (Score:4, Interesting)
SPF is about overloading existing slots in RFC2822 and DNS in order to cram authentication data into the protocols. The link above cites an alternative that is about replacing the existing protocols with brand new ones.
Both are, IMHO, poor solutions and DomainKeys might just be the correctl long-term solution.
Personally, I was working on a proposal for a way to use existing headers [ajs.com] by adding a slightly out-of-band channel for authenticating mail, but if DomainKeys beats me to it, sounds fine to me.
Re:One advantage DomainKeys has over SPF... (Score:3, Informative)
It is:
http://homepages.tesco.net/~J.deBoynePollard/FGA/
I disagree with the conclusions, but the basic refutation of SPF and SRS seems to be quite sound.
Solveable problem (Score:3, Informative)
Perhaps I'm missing something (Score:5, Insightful)
Based on articles refered here on Slashdot, I'd assumed a major source of spam were machines that have been compromised. Spammers use known lists of unwitting relays to forward spam through legitimate hosts.
Email today will tell me the name of the host where something came from, that doesn't really help. At best, I could (a) contact the owner of the domain (which I can do today) (b) develop a list of open relays that I won't accept mail from (which I can do today).
It seems to me the net effect of this is to limit email to large ISPs. It won't be good enough for me to buy a T1 and run my mail server from there, I'll have to rely on Yahoo, MSN, AOL, Comcast and a few others to be my MTA because people won't accept mail from a small provider (or a single point system) any more.
Re:Perhaps I'm missing something (Score:5, Insightful)
The major source of spam are machines that are compromised is true. The vast majority of such machines are not mail servers at all. Shunning all the small providers and companies might help reduce spam somewhat, but at an enormous expense.
If you accept e-mail only from legitimate e-mail servers, regardless of the size of the ISP or company, you would accomplish pretty much the same thing.
By the way, if the big ISPs have the market cornered on e-mail services, what makes you think they would be anti-spam? The larger reason that they are anti-spam is because of being blocked by the vast numbers of smaller ISPs and companies who pioneered the use of blacklists. Take away that and the big ISPs would love spam because they would be able to collect more money from their captive audience based on the volume of mail handled for that company or smaller ISP.
Re:Perhaps I'm missing something (Score:2)
I'll reserve judgment on the effectiveness of this particular system, and I'm sure there are loopholes (there always are), but I like the concept.
Re:Perhaps I'm missing something (Score:5, Insightful)
Re:Perhaps I'm missing something (Score:2)
Re:Perhaps I'm missing something (Score:4, Interesting)
The road toward reliable, authentication of mail is long, and we've only just started... hopefully our few first missteps will be corrected as we go.
Sure, they'll take your mail... (Score:4, Informative)
Sure they will. With SPF, for example, you setup the SPF rule for your domain to allow that domain to be a sender of mail for the domain.
You will need to have your own domain, I admit.
SPF breaks Forwarding (Score:5, Informative)
SPF is junk. The number one priority of e-mail: Legit mail must reach the recipient.
Re:SPF breaks Forwarding (Score:5, Informative)
"Forwarding services and web-generated email sites need to deploy SRS. Pobox.com, for instance, has already integrated SRS into its bespoke MTA using Mail::SRS.
Hobbyists who provide .forward or /etc/aliases services will also have to get an SRS-enabled MTA.
Sites that do not do .forward or /etc/aliases forwarding to remote sites will not need to do a thing.
Once a majority of forwarding setups are SRS-compliant, SPF publishers can change their defaults from "neutral" or "softfail" to "fail". "
Seems like for fowarding to work.. one method has to become a standard.. And we need to do it right this time. The above text says that everyone would have to install their software to get forwarding to work.
Re:SPF breaks Forwarding (Score:3, Insightful)
I'm sorry, it was a good attempt, but it's just not going to fly given how disruptive it is. Worse, it's disruptive at a distance, so enabling SPF and dutifully enbabling SRS to compensate still forces your users to track down their forwarders and force THEM to use SRS before the scheme works.
Broken systems thwart adoption. I don't know if DK is the solution, but I'll give it a chance. I already gave SPF a chance, and ha
Re:SPF breaks Forwarding (Score:3, Informative)
Yes, folks need to implement things properly. That's largely why SPF has different fail modes, so you can slowly ph
Re:SPF breaks Forwarding (Score:2)
Re:SPF breaks Forwarding (Score:2)
If they
Standards are good (Score:2)
The only additional standard this needs is a "caliber".
SPF breaks relaying (Score:5, Informative)
SPF's handling of relays is broken: [pobox.com]
If DomainKeys takes care of that, I'd choose it over SPF in a heartbeat.
Re:SPF breaks relaying (Score:4, Interesting)
You have a known e-mail server that can vouch for each e-mail that it sends on behalf of it's customers. It is far tighter than SPF.
The one problem with domainkeys (based on my understanding of it) is that it just verifies that the e-mail came from the domain. It doesn't verify that the sender is the real sender.
What I'd prefer is for the e-mail servers to generate a separate PGP or GPG key for each user for signing the e-mail and signing only those e-mail sent by an authenticated user on the machine.
And instead of providing the key by DNS, extend SMTP to handle a key request.
When your server received an e-mail, say from joeblow@example.com, it would check the signature. If the public key for that sender wasn't cached, it would connect to the host the e-mail would come from if it is legitimate and request the key for that user.
It could also be done via mail. Send a request to joeblow-publickey@example.com and the sender would automagically reply with the public key for joeblow@example.com.
And it would be possible for a user to provide his public key to the server for it to use. That way, he could sign his own message instead of the e-mail machine.
Possible method to defeat. (Score:4, Insightful)
Re:Possible method to defeat. (Score:4, Informative)
A really good cipher is resistant even against such a "chosen plaintext attack"; furthermore, it's trivial to defeat such attacks completely by inserting a meaningless random element.
If a system is compromised (i/e: with a virus/worm) couldn't the technology be defeated via that as well?
Not nearly as easily as now, since it requires cooperation from the DNS server.
Re:Possible method to defeat. (Score:3, Informative)
No. If your cipher is good, then you don't need to add random junk to prevent known plaintext analysis- and if it's bad, then the random element won't protect you.
(All the random effect can do is shift the position of the known plaintext within the encrypted message. This will at most increase the effort to brute-force by a factor of message length, so you can do better by choosing a superior cipher.
Re:Possible method to defeat. (Score:3, Informative)
a) If your keys are stolen you can just update your DNS info with new keys, it'll only take a few days to propagate, and DNS security is reasonable to strong.
b) If a particular ISP is misbehaving, you can blacklist them, or filter them more agressively by other means. Once you know for sure who everyone is, blacklisting becomes much easier and much less damaging.
c) Cryptographic signing is well understood, large key sizes are practical, hardware acceleration is cheap, and signing/verifyi
That's "boycott-email-caller-id.org" (Score:4, Informative)
It has a brief mention of domainkeys as well.
What does this mean? (Score:3, Insightful)
Re:What does this mean? (Score:2)
Re:What does this mean? (Score:2)
But, I'm using the DNS server from my registrars ( domaindirect and NetSol ) so, I would need them to support this. Or, I would have to host my own DNS or switch to a DNS host that supports this.
Also, another common problem of small mail servers is reverse lookup. My static DSL IP address reverse maps to a name from my ISP. Is there any dependency on this, or does it use domain names from the e-mail headers
Re:What does this mean? (Score:3, Interesting)
No, DomainKeys does not require reverse DNS.
-russ
SPF and DK solve different problems (Score:5, Informative)
You want to implement both. SPF detects envelope forgeries before you have wasted much bandwidth. You can then use right hand side blacklists on sender domains. Yes, spammers too are adopting SPF. This is OK - those who like spam have something other than instinct to warn them when they are dealing with a scammer instead of a spammer. Those who hate spam can ignore it more efficiently.
Domain Keys validates the message headers. It protects you against forgeries by users in the same domain - e.g. a spammer on yahoo forging an innocent party on yahoo. SPF can also detect envelope sender forgeries from the same domain in conjuction with SES (Signed Envelope Sender) - which adds a crypto cookie to the local part.
You should implement SPF first. It is simpler, and eliminates most forgeries before SMTP DATA. SPF requires sepcial consideration for forwarders (SRS [pobox.com] - Sender Rewriting Scheme) or whitelisting.
DK is a good addon for large ISP domains like yahoo and aol, but is broken by forwarders or mail processing tools that modify the body. For instance, my DSPAM [nuclearelephant.com] bayesian filter adds "tags" to messages.
Re:SPF and DK solve different problems (Score:3, Informative)
Somebody please correct me if I'm wrong
Re:SPF and DK solve different problems (Score:5, Informative)
Consider yourself corrected.
RFC 2821 in section 4.2.5 Reply Codes After DATA and the Subsequent <CRLF>.<CRLF>
makes it clear that if an error code is returned after the final '.' then the receiver is specifically not supposed to handle the message, and any bounces are therefore the responibility of the sender.
-- this is not a
Re:SPF and DK solve different problems (Score:2)
Yet another YRO... (Score:2, Insightful)
This is a way, it seems, to help prevent spoofed header information in spam. I'm certainly glad that right is not infringed, thanks Slashdot.
Really, the constant usage of YRO for these kinds of articles is diluting the effectiveness that YRO is supposed to handle. Keep the
Why domainkeys is better than SPF (Score:5, Informative)
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.
Re:Why domainkeys is better than SPF (Score:3, Interesting)
Not trolling here. I just want you to back up your "broken SPF" statement.
Re:Why domainkeys is better than SPF (Score:2)
Re:Why domainkeys is better than SPF (Score:3, Interesting)
In general, forwarders are selected by the email recipient and handling them correctly when implementing SPF is the responsibility of the email recipient.
SPF and DomainKeys complement each other (Score:5, Insightful)
I quote this from the very top of the SPF FAQ [pobox.com] itself:
"Protecting authorship information is an important goal. However, the technical issues associated with protecting the "From:" header are much more numerous and challenging. The best way to protect the header "From:" is by using a cryptographic signature such as S/MIME, PGP, or (when it is released) Yahoo DomainKeys."
Enforcement is the only way. (Score:2, Insightful)
Marginally better in theory because the sending hosts can change without requiring DNS changes, but in truth neither approach has much of a hope of affecting spam in any significant way. Might as well standardize over SPF which is the more estabilished method, instead of fragmenting further.
Still, even if all of the sender verification and SMTP hardening methods were to be universally
Re:Enforcement is the only way. (Score:3, Insightful)
Bring it on. Fully-authenticated emails would make it a heck of a lot easier to verify that something isn't a joe-job and kick someone off the network. It'd also make it easier to blacklist stuff without huge amounts of collateral damage.
Unfortunately, it sounds like this method would make receiving and sending emails more cpu-time expensive.. but the trade-off isn't as bad as many of the other "solutions".
SPF works with IP addresses, this one doesn't (Score:2, Insightful)
Not bad, but far more complexity.
Do I really want all this extra code in my small, secure qmail-smtpd binary?
Where's the beef? (Score:2, Insightful)
We have the client IP address of incoming mail already, and that address is hardly ever spoofed. Is it helpful to us? No, not as long as the client ISP refuses (or is actually unable) to disclose to the recipient who was using [123.45.67.89] at that time. Are we to believe that the ISP will react differently when
The problem I have with SPF (Score:4, Interesting)
smtpauth isn't always an option, and most DNS hosting providers don't make it terribly convenient to keep on adding and removing temporary TXT records as necessary, nor would a company's IT department be terribly happy about needing to do the same for corporate travellers.
What needs to happen instead is a domain having a public key registry (probably provided via NAPTR records; just do a NAPTR query on, for example, username.example.com and then get either NXDOMAIN or the public signature) and then signed messages. Of course, the fun thing then is the limit of the size of an NAPTR record, so it'd have to be a pretty small key. For this purpose I don't think it's necessary to have more than a 128-bit key or so, though, especially since discarding keys is so trivial (just set a TTL of 30 on the records and use dynamic DNS updates or whatever).
Re:The problem I have with SPF (Score:4, Insightful)
You should not be using the hotel's SMTP server, or any other SMTP server except the one for your domain. Your SMTP server should accept initial mail submission (which is different than mail relay) on something other than port 25! 587 or 465 (SMTPS) work quite well (I strongly suggest SMTP+AUTH+TLS/SSL).
Now your mail originates at the same server all the time, and SPF will work just fine since that IP address is in the SPF record. Your roaming issues are taken care of as well, no more reconfiguring your client software as you move from access point to access point.
Re:The problem I have with SPF (Score:4, Insightful)
Your email server is an open relay? If so, you've got bigger problems than SPF. If you mail does not reply anything coming in from the Internet, then you should not have any problem.
As for remote users, set them up to use SASL SMTP on port 587. That way only they can relay mail from outside your own network.
advantage over SPF (Score:3, Interesting)
SPF does not break forwarding (Score:5, Informative)
Re:SPF does not break forwarding (Score:3, Insightful)
SPF/DK is wortless (Score:3, Interesting)
I think the only way this problem can be solved by ISPs with firewal between Internet and end-users. And may be sell unfirewalled connection to power users.
With SPF/DK spammers will just register bogus domains ($30 and may be even less for single domain in
As always, sorry for my bad english, I hope you understod me
As long as... (Score:5, Insightful)
SRS is nothing but re-hashed bang-pathing, and the SRS folks don't address any of the problems inherent in bang-pathing.
Show me a Unix system that doesn't use
Anyone using SPF with Sendmail? (Score:5, Interesting)
Are there any lightweight milters that would work under FreeBSD that I could use to start using SPF on production systems? While I certainly won't be filtering out unknown mail at this time, I'd like to start inserting result headers to see how accurate it is in the real world.
A solution I've had in mind.... (Score:4, Interesting)
As someone who provides hosting for small companies and usually uses
While I haven't read the DomainKeys proposal, it has occurred to me before that a variation on SPF with encryption could be implemented without having to extend the ESMTP protocol. TTBOMK (To the Best of My Knowledge) ESMTP allows you to send parameters following the "MAIL FROM" command and these parameters would be preserved as part of the message envelope when forwarding. It would seem to me that an PGP/GPG, private key, encrypted string sent as a parameter would allow updated MTAs to verify the original source by decrypting the string with the orignating servers published public key. How does one publish their public key? Simple, use the TXT record in DNS (similiar to SPF's use of DNS). At the same time, this shouldn't in anyway break compatability with receiving SMTP servers that don't recognise the new parameter.
While I haven't RTFA, this has been on my mind for a while, as a "better than SPF" solution and I'm sharing it here. How do you think it stacks up to SPF/DomainKeys?
Re:Big Joe and Phantom 309 (Score:2)
-russ
Re:Here you are (Score:3, Funny)