DNS uses selectors (names composed of labels) to return elements
(records). With a low number of elements per selector, DNS is able to
return an immediate answer, often in no more than 10 seconds. The
number of these elements within an answer can often be counted on your
fingers. This works well for resolving names to addresses, the
principle use for DNS.
SPF, and its temporal incarnation Sender-ID, used textual scripts to
extend this answer using techniques such as CIDR notation, for network
segments rather than addresses, and links to other textual records as a
means to continue the answer. Normally a host name such as
my-mail-server.my-domain.com resolves to a few addresses. DNS works
well if you know the name of the machine. SPF et al however could not
endure such limited results, as the name was not for a machine. SPF
wished to use the domain of a return mailbox to resolve addresses for
ALL servers that may issue a such a message.
For a large organization, they may directly control dozens of outbound
mail machines where each may have several addresses. So for SPF, this
is not a usual answer found in a single DNS response. But through the
use of scripts and CIDR notation, this answer could fit. This was not
enough however. Mail may originate in or traverse other domains. The
use of script does not help much to reduce the size of linked mailbox
domains.
This calls for an answer that may simply need many answers linked to the
initial selector. The script wizards needed to extend this response to
include these other domains as a means to delegate. So names are added
to the CIDR notation pointing to yet more acceptable mailbox domains.
Where does this end? Hard to know, as these script wizards can't
decide. This process can take forever. Do they limit the time,
recursion depth, number of branches, number of segments, or number of
mailbox domains? Again, they can't decide. What happens if forced to
quit? What does this do to mail delivery?
A company may wish to point to other domains that may handle their
advertising, product support, corporate offices, and factory outlets,
all using the common mailbox domain that often serves as part of the
company trademark. With ten outlets using 4 different network
providers, this company already has a need to cross-reference 7 other
domains. The advertising company uses a complex network of
subcontractors, where, so far, list 50 domains within their records.
Each of these large ISPs have several records for their outbound mail
services.
Now the scripted answer, discovered through the linking of text records,
includes many domains and network segments. Perhaps this can fit in a
few dozen text records, but these are discovered using a series of
sequential queries. A series of queries is always bad, especially if
this must be done for each message seen within a mail stream. This was
primarily to prevent rogue systems from originating mail from machines
not included within the array of network segments, defined within the
matrix of records, linked to the original selector.
These lists may not be comprehensive. After all, it is not often the
complete path of a message is known before hand. It may well be, there
are those wishing to retain the freedom of using any mail access to send
a message and, for them, these lists may be defined as "open." The end
of the exhaustive search through dozens of records reveals that the
message should be marked "unknown" with no other changes to its
handling. (At least thats what it should mean.) Does this lower the
amount of undesirable mail. No. Does this stop the spoofing of return
addresses, absolutely not.
One bug-a-boo comes from a technique spoofing the return path as a means
to deliver mail addressed to a bogus mailbox. This could be prevented
if the recipient could discover valid users before accepting mail, but
that information could lead to more trouble. Making 20 queries of DNS
text records seemed like a better solution than bouncing the message?
SPF will not prevent spoofing, but will likely mean those able to defeat
the SPF checks will have an easier time duping their targets. 70% of
the ISPs don't even bother to authenticate the mail sent on their
networks. What value is there thinking the domain of a message is
confirmed traveling within the what-me-worry.com network?
Who did what? SPF can't resolve that question nor can it determine the
domain of the last SMTP server that offered the message. There is talk
about using the mailbox domain lists to check against the HELO/EHLO
domain. What do these two domains have in common? Nothing. There is a
significant difference between authorizing and authenticating a host and
network segments for an array of mailbox domains. The matrix of
records, composing the array of network segments, attempts to resolve
whether a mailbox domain is acceptable for traversal. CSV uses a single
SRV record as a means to both Authorize and Authenticate the host name
to ascertain access accountability. SPF is not concerned about this
issue.
The host name in the HELO/EHLO announcement offers the natural DNS ratio
of selector to elements. This also means wildcards are not need.
Linked files are not needed. CIDR segment notation is not needed. In
fact, CIDR notation is detrimental. A script based record will not
improve the resilience to a DDoS attack. In fact, a script based record
will not find native support in hundreds of programming languages as
will a SRV record. Does SPF aid enforcement or allow accreditation of
suitable policies that secure access to the mail channel? No.
So why are the script wizards looking to mold CSV into yet another
script? To justify the need for a DNS script parser? To allow an
endless stream of new script based DNS record types? Because they like
inventing script languages, even if they can't decide what is a good
script? Your guess is as good as mine. These script wizards are wrong
about a need to make these records for SPF and CSV "look" the same to
sell SPF. In fact, this will likely lead to confusion about what should
be in the CSV record. Back to the old saw. The E in IETF stands for
Marketing. : )
-Doug