Craig Humphrey wrote:
But that's what constraints are all about...
Creating more problems than they solve?
Nearly :) It's about the steep learning curve. Once the dust settles on SPF (and/or SenderID), the knowledge on how to set it up correctly (and hopefully simply) will start to disseminate more quickly. At that point, the problems start to go away. It's not too different from the old days when just about every SMTP server out there was happy to relay. There was a time when this was thought to be a "Good Thing" (tm). Times have changed, and when SMTP servers stopped relaying (well, all the responsibly maintained ones...) I wonder how many users weren't able to send emails....
Good luck with explaining that (and SPF) to customers paying you to deliver emails.
-- Juha
Fortunately I don't have to. We don't have customers pay us to deliver email. We're just a firm that needs to send our own emails, do our best to protect our users from SPAM (viri, etc) and be responsible netizins. So I'll certainly be putting SPF records in our DNS and pressing our mail server vendor to support SPF. If I was working for a firm that had customers paying to us to deliver email, then I'd probably be doing my darndest to research SPF (and probably SenderID), learn how best use SPF to protect our clients from SPAM (at least the domain spoofed kind) and how best to explain the ramifications of SPF to my clients. ISP's who relay outbound email for their clients are probably going to have some very complex SPF records if they want it to be tight. Later'ish Craig