On Sun, 2005-03-20 at 23:38, Radu Hociung wrote:
Also this means you are living proof that Andy Bakun was right when he said:
"Many many many people want(ed) to setup SPF and forget it.
Are those simple records accurate?"
My my my, isn't _this_ a rare occurrence?!?! :)
The difference here is that Frank is actually available to make changes
to his record should he realize he needs to -- this is completely
different from the numerous domains who have SPF records and will be
unresponsive to requests to change or optimize them (hopefully rejected
mail will light fires under people's asses in those cases, hopefully
those who are not proactive will at least be reactive).
Radu, you've said that you think that DNS load will be the death of
SPF. I disagree. We've gotten to the point where performance is
actually a discussable issue.
There's been a significant drop-off of "SPF considered harmful" style
rhetoric (or it's moved to channels I don't monitor). I get the
impression that that is because people have either seen its utility or
accepted its inevitability, rather than it falling on the wayside in
favor of other proposals (which there don't appear to be (m)any
forthcoming -- shit, when was the last time even MS said anything
worthwhile about SenderID deployment?)
Rather than focus on trying to convince people that limits should be
lowered or that _all_ records should be as simple as possible, IMHO,
time would be better spent preparing for how to answer and offer
suggestions for when big ISPs with complex setups show up and ask how to
simplify and optimize their records. We need a "best practices"
document, a cookbook. A wizard can not really help with this, as
wizards usually make it so you don't have to think, but in the cases of
complex setups, we need _people_to_do_ the thinking. rr.com's setup is
a good place to start.
At this point, I think we just need to come to agreement on which
optimizations are worthwhile and make sense in any given setup. People
need to know what their options are.
--
Andy Bakun <spf(_at_)leave-it-to-grace(_dot_)com>