Using DNS to deliver the policy is a hurdle toward widespread acceptance.
Here are some advantages of storing the sender policy at the sender's mail
server:
1.) It only requires changing one piece of software: the MTA. Assume for
a
moment that we use DNS TXT records to deliver the policy, and by a
fortunate
blessing all the DNS servers on the Internet implement the feature
properly,
even though it is a relatively obscure feature. Even if we assume this,
it
is still highly likely that there will be changes necessary for
performance
reasons.
This is the crux of the problem from what I can see. I think finding DNS
that can correctly deliver TXT responses will be substantially higher than
you'll find MTAs that would support a new protocol exchange. For example,
BIND supports TXT just fine, but SENDMAIL doesn't support such a protocol
now.
Therefore, this upgrade would take far longer to be adopted because it would
require people change their MTA rather than add a DNS record.
2.) More importantly, using DNS requires the entire Internet to
participate.
By this I don't mean that all the mail servers must participate or that
everybody must publish a sender policy - that's not the case with any
sender
authentication mechanism. I also don't mean that it couldn't function *at
all* without everybody's participation - trial implementations already
exist. What I mean is that the DNS of the entire Internet must work
properly with these new features being proposed, if we're going to use DNS
to distribute the policy *reliably* and *efficiently* with widespread use.
This is a big hurdle.
Second, this doesn't seem to be the case. In order to the MTA solution to
work, the receiving system already has to consult DNS to retrieve the MX
records. But then it not only has to retrieve the MX records, but it has to
contact the MTAs behind those addresses. With a DNS-only solution using
TXT, only the DNS must be consulted, but instead of returning MX, it returns
TXT, and there's no overhead of going to an MTA to do yet another protocol
exchange.
3.) We've just increased our "minimum system requiremenets" for a DNS
server
on the Internet. Will current DNS servers require hardware upgrades to be
able to store the extra information? (In addition to the software
upgrades
that will probably be necessary.) Are we suddenly going to require more
DNS
servers to be added to the infrastructure?
Is that even a reasonable assumption? It would be interesting to note how
much extra capacity a DNS system would need. We host only a few main
domains (perhaps 20), with each having perhaps 5-10 subdomains. Adding the
20 TXT records was not much of an issue, and as I said before, the
processing overhead shouldn't be much different since the query for the TXT
is simply exchanged for the query for the MX.
1.) Currently, DNS's primary role is to locate things. It's the map of
the
Internet, matching up names and IP's. Should we now task DNS with
delivering a document related to a particular Internet application (mail)?
Should we distribute an FTP server's list of mirror sites or policy for
anonymous logins, or an HTTP server's policy for caching documents? Of
course, those examples seem ludicrous - if we want to know that
information,
we get it directly from the server. The same applies to email - it's more
appropriate for mail policy information to be distributed via the mail
system.
This philosophical question seems more to the point for me. Why should DNS
have to return SMTP authentication info. Will others start to abuse DNS for
their various needs? Of course, DNS already has a specialty task for email
as it contains MX records. It doesn't have specialty records for HTTP or
FTP today. Perhaps email is just that special!?
proposal increases the cost of *sending* a mail specifically. In
contrast,
using DNS to store the policy increases the burden on recipients more than
it does on senders!
This doesn't seem true to me since the TXT record had to be queried from DNS
in one scenario, or the MX records from DNS in the other.
storing the policy for every domain in the Internet. However, the general
point remains that unrelated 3rd parties are unnecessarily involved in the
distribution and storage of this information.
Third parties typically only store them according to their caching policies,
and the MTA solution would also have a caching policy, so the it's got to be
cached someplace. Why have DNS cache the MX records and the MTA cache the
policies if there's a way to do it with just the TXT record being cached by
DNS and the parsed TXT being cached by the MTA?
1.) Basic argument against DNS: Using DNS to distribute the sender policy
entails a significant complication to implementation. We place a burden
on
every DNS server in the Internet, both an immediate burden (upgrading
software/hardware) and also an ongoing burden (carrying around sender
policy
records).
2.) Basic argument against my proposal: Senders will have extra
requirements
to meet, especially senders in "unusual" situations.
My feeling is that #1 is a much stronger argument than #2.
My basic argument against would be that it requires software changes on the
MTA to function. The DNS TXT change allows you to participate by publishing
your policy before you actually change the MTAs to enforce them. So, if you
don't care about receiving and checking policies, you don't have to, but
others can begin to check your policy without your having to install
upgraded MTA software.
Other than that, I see no real problem. I believe that a pure MTA solution
would have been preferable beacuse I agree that using TXT is a kludge. The
long term solution, assuming this sender-id change actually has positive
benefits of reducing spam, is to create something like you suggest since it
doesn't mess with DNS.
I do see more attacks against DNS coming, more spams directed at MTAs that
don't implement the receiving side of sender-id so they bounce like before
back to the invalid sender, more spam blasts from ephemeral systems and more
hijacked accounts on outbound SMTP servers so sender-id passes checking.
Harold