spf-discuss
[Top] [All Lists]

RE: DNS RRtypes: creating a new RRtype

2003-10-20 09:57:23
Andrew Boling wrote:
It's a tough call, really. It's having to decide between whether SPF
will get more critics from byte-hogs or lazy folks. It'd be nice if
there was a surefire way of satisfying them both.

I don't see why we can't satisfy them both?  I agree that a new RR is
the correct solution.  I also agree that to get this implemented fast
and wide, we need to support using the TXT record method.  Since most
MTA's don't support SPF checks at all right now, I think both methods
need to be defined in the RFC, before MTA maintainers start coding in
support for SPF.  If both methods are defined, when maintainers of MTA's
start adding SPF support, they can add support for both methods (the
dedicated RR would be the preferred I would assume and therefore would
be checked first).  This would increase the number of DNS queries (check
for 'SPF' RR, if it doesn't exist, check for a TXT RR with the "v=spf").
Then, once the experimental RR is eventually approved and becomes a
standard RR, the TXT implementations can be phased out.  By the time the
experimental RR is approved, hopefully most MTA's will support it
(having been previously defined in the SPF RFC), and migration can begin
as soon as DNS servers support the new RR by default.

I propose we go with both, now, even if the experimental RR is only
defined in spec and only used by people who want to add the new RR to
their DNS servers themselves.

---
Dustin D. Trammell
Vulnerability Remediation Alchemist
Citadel Security Software, Inc.

-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.txt
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname(_at_)½§Åv¼ð¦¾Øß´ëù1Ií-»Fqx(_dot_)com


<Prev in Thread] Current Thread [Next in Thread>
  • RE: DNS RRtypes: creating a new RRtype, Dustin Trammell <=