spf-discuss
[Top] [All Lists]

Re: Re: DNS load research

2005-03-20 13:35:50
On Sun, 2005-03-20 at 10:30, Radu Hociung wrote:
The people involved with SPF that have the most expensive records
in the world. The rest of the world manages to keep their records
short and sweet.

This could very well mean that those involved with SPF actually know
their mail infrastructure setups and how complex their SPF records thus
need to be.  I would venture to take the (arrogant :) ) position that
that is more likely than the majority of email setups actually being
very simple, especially if those domains are non-vanity.  Many many many
people want(ed) to setup SPF and forget it.  Are those simple records
accurate?

When we first started making SPF records, there was a general position
that they should be as inclusive as possible, to avoid some users
unknown methods of mail submission from not being included.  Make the
record reflect the ACTUAL configuration rather than the IDEAL.  The goal
was to migrate to a more controlled, ideal infrastructure over time
(using SMTP AUTH, etc), and THEN update the SPF record.  It was accepted
that it could take a while for the tools to be created (like the spf
record compiler, various optimizing wizards, etc), and once that was
done, then the ideal records could be created because the ideal email
infrastructure was also realized.

The wizard actually tries to be inclusive by asking all sorts of
questions, because the last thing we wanted was to hear "I used the
wizard, and half my users email was marked as forged because they submit
via a way I didn't know should be included!" or "the wizard didn't ask
me about other machines that send email, and I can't change that
machine's configuration, now all my email is marked as forged!".

As such, leave-it-to-grace.com's SPF records includes more than it needs
to, but I'm still working on simplifying it by bringing the
infrastructure and users under control.  Really, I have no excuse (other
than "that I have not done it yet"), because leave-it-to-grace.com has
only 3 users.  I also control the mbira.com SPF record, which is overly
complex, but I'm still tracking down a few remote users.  If anything,
this is a case study that shows it is going to take a while for these
kinds of changes to happen.  But, getting a more-locked-down email
infrastructure wouldn't be happening at all if SPF wouldn't have made it
this far.

It occurs to me that one of the reasons that complex setups exist is
because people (essentially) asked for it.  Simpler systems that just
listed outbound IP addresss (RMX?) was deemed not usable enough (for
whatever reason).  But what we are seeing is that, since records can be
reduced to a simple list of IP addresses in a lot of cases, a simpler
scheme would have handled a significant portion of the cases.  Although,
hopefully, that's the goal: to make the easy things simple (a, mx) and
the hard things possible (per-user policies).  SPF's 'mx' (which is
really just an include of another RR) was chosen to make the deployment
easier -- it was deemed easier to make expression-evaluating-SPF-clients
rather than getting something added to DNS servers.  But there's nothing
from keeping someone from making a smarter version of bind that compiles
SPF records to simpler format before sending them out.  One of the
advantages of the SPF syntax is administrative ease (SPF record contains
"mx", and if you change your MX RR, only one record needs to be
changed), but that can also be done by the DNS server replacing 'mx'
with 'ip4:xxxxx' if it knows the actual value(s).  This is, rightly,
something for those with complex setups to be concerned about, and
SPF-aware optimizing DNS servers will be created/written if the need
truly arises.  It was a chicken-and-egg problem, and SPF chose the way
it did for deployment-likelyhood reasons.

-- 
Andy Bakun <spf(_at_)leave-it-to-grace(_dot_)com>


<Prev in Thread] Current Thread [Next in Thread>