From: David MacQuigg [mailto:dmquigg-spf(_at_)yahoo(_dot_)com]
Sent: Thursday, September 01, 2005 6:31 AM
<...>
It would be helpful to provide all record types, at least the
ones that are
commonly used. SPF and SRV should be added as soon as possible.
Bashar,
Thanks for coming here to announce your plans to support SPF. Welcome to
the community!
While I respect David's opinion, my advice is that implementing SRV at this
stage is premature. It is still under active development by a small group
and has not garnered sufficient support, IMO, to justify adoption at a
commercial site. As you look into it more carefully, you will find that it
provides only a subset of what SPF does. If SRV eventually does generate
sufficient user demand, you can always add support for it later.
SPF currently has around 750,000 domains with published records, a stable
IETF internet draft, numerous implementations, an elected governing council
and a help site run by volunteers that give free, expert, one-on-one SPF
support. The people donating time to the help service have been involved in
the development of the protocol and are truly experts, not inexperienced
users. These are all resources that you can take advantage of right now and
there is steadily increasing demand to publish SPF records. We have learned
and adapted the protocol through the experiences of numerous participants
and valuable feedback from the help service, so I think it is safe to say we
are beyond the early adopter stage. We have also learned, by experience,
what are the most common mistakes that people make and how to fix them. You
have come into this at an excellent time!
One suggestion is that you support both TXT and SPF RR types right from the
start, even though not all SPF checkers and resolvers today know about the
SPF RR. When both records are present, they MUST be the same, so I suggest
that your control panel enforces this. While the SPF RR is relatively new,
it is planned to eventually replace the TXT record, but both will be around
for a long time. Differences between the TXT and SPF RR's will cause
problems that are hard to diagnose, so publishing both and forcing them to
be the same would be doing your users a great service. It is not hard, and
it would distinguish your implementation from many others that have not yet
taken this step.
Another common problem in DNS control panels is the lack of support for the
underscore character. While this character is not permitted in a host name,
it _is_ definitely allowed in an A record. It is useful in the SPF context
to define a record that will be included in numerous other records. For
example, a user may own a dozen domains that all use the same outgoing
MTA's, and thus should have the same SPF record, or at least a common core
part of the record. It makes administration much easier to create a common
record at a domain such as _spf.maindomain.com that can never be the name of
an actual host. You use the include: mechanism to include the contents of
this record in each of the dozen separate domain SPF records. You can then
change the SPF record in all twelve domains simultaneously by editing a
single record. This is useful in cases where it is undesirable to CNAME the
domains together.
One further piece of advice is to discourage the use of the ptr: mechanism.
It is expensive for your resolvers and slows down SPF record evaluation.
There are usually other ways to accomplish the same thing, though it is part
of the specification and must be supported. For some cases, it really
simplifies the records and allows extra flexibility, and that is why it is
still there. The typical user, however, should be discouraged from
publishing a record with a ptr: mechanism.
The signup form and the web interface are confusing. See
domainsmadeeasy.com for an example of how to organize a DNS service.
Yes, they have done a good job. Though I am a satisfied customer of theirs,
the SPF wizard and validator they provide could stand some improvement.
Fortunately, Scott Kitterman on this list has written an excellent
validator, which he actively maintains, so you may want to contact him for
permission to link to it or host your own copy. Unlike some of the other
validators around, Scott actively solicited feedback from the very
knowledgeable and fastidious (to put it politely) members of this forum.
IMHO, this continues to make it higher quality than most others out there.
I would defer to others on the list for what they consider as the best SPF
wizard out there.
Thank you for choosing to support SPF for your new service. If you have any
questions or concerns, we are here to help, online or off.
--
Seth Goodman
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com