Re: Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Sep 2, 2013, at 5:54 AM, Phillip Hallam-Baker <hallam@xxxxxxxxx> wrote:

On Thu, Aug 29, 2013 at 12:30 PM, Dan Schlitt <schlitt@xxxxxxxxxxxx> wrote:
As the manager of a modestly large network I found the TXT record as a useful tool in management of the network. Such a use was even suggested by other system managers. That was a time when the Internet was a friendlier place. Today I might do things differently and not make some of the TXT records visible on the public Internet. But they would still be useful for internal management.

TXT records can be useful for ad-hoc local configs and the SPF use has made this harder. But it is hard to see how the SPF record makes that situation any better.


Probably a better solution would be to take a chunk of the reserved RR code space and stipulate that these have TXT form records so folk have 10,16 or so records for this use.

In the longer term, the problem with the SPF RR is that it is a point solution to 'fix' only one protocol. It is an MX record equivalent. Which was OK given the circumstances when it was developed.


A shift from TXT to SPF records is not likely to happen for the niche SPF spec. But may well be practical for a wider client/initiator policy spec.

Dear Phillip,

It seems many of the larger providers are unwilling to process SPF macros due to inherent risks and inefficiency.  Rather than accessing data using the DNS resource selectors of Name, Type, and Class, SPF uses mechanisms above DNS to utilize an additional domain, IP address, and email address input parameters merged with results generated from a series of proscribed DNS transactions.  The macro feature was envisioned as leveraging these additional inputs to influence query construction. It seems lack of support by large providers has ensured scant few macros are published.

in the beginning, there were several wanting a macro language to  managing DNS processing with little idea where this would be headed.  At the time there was already a dedicated binary resource record able to fully satisfied the information now obtained and used from SPF.  Policy aspects of SPF are largely ignored due to exceptions often required.   An SRV resource record resolving the location of a service could include an APL RR with CIDR information of all outbound IP addresses.  This would offer load balancing and system priorities, while mapping outbound address space within two DNS transactions instead of the 111 recursive transactions expected by SPF.  If one were starting over, DANE TLS or DTLS is a better solution that should be even easier to administer since it avoids a need to trust IP addresses and NATs.   As with PKI, there are too many actors influencing routing's integrity.

Regards,
Douglas Otis




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]