In
<C6DDA43B91BFDA49AA2F1E473732113E5DBC64(_at_)mou1wnexm05(_dot_)vcorp(_dot_)ad(_dot_)vrsn(_dot_)com>
"Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com> writes:
SPF macros do indeed provide the functionality I'm looking for. I'm
just trying to justify why I think this functionality should be
considered for inclusion in MARID.
SPF macros are on the verge of being Turing complete.
I've pondered this before and I'm pretty sure that SPF macros are not
Turing complete.
However, I think the point is irrelevant.
In order for SPF to not become a DDoS tool, there must be strict
limits placed on the number of mechanisms that require DNS requests.
Limits low enough to prevent DDoS attacks are low enough to make even
a Turing complete language safe.
Note that you must protect against DoS attacks against the MTA that
implements SPF checking, but you must also protect against a third
party being attacked by MTAs that implement SPF checks.
For example, say badguy.com has an SPF record that says:
"v=spf1 a:%{s}.1.victim.com a:%{s}.2.victim.com a:%{s}.3.victim.com"
Then, when badguy sends email with random sender addresses to various
mail servers that do SPF checks, victim.com will get many DNS
requests. This is true, even if victim.com doesn't have anything to
do with SPF.
There are a bunch of variations on this kind of idea, some of which I
have explored, some of which I'm sure I haven't even thought of.
The key here though is whether the amount of bandwidth consumed by
badguy sending SMTP MAIL FROM: packets is larger or smaller than the
amount of bandwidth sent to victim.com. From my studies of actual
packets, it appears that a reasonably large number of SPF mechanisms
that cause DNS lookups can be allowed before the bandwidth
amplification factor gets unreasonably large.
I think that it is a pretty good thing to ask what the use cases are and
whether they justify that level of complexity. SPF design was constrained in
ways that do not apply to MARID. SPF had to pander to people asking for
features to avoid splits. I think MARID has the opposite issue, the bias
here will be for simplicity.
As I have mentioned here several times before, I have looked at the
SPF records found on the SPF adoption roll. Almost all SPF features
are used by a non-trivial number of domains. There are some
exceptions, such as support for IPv6 and the "delimiter characters"
used to split macro variables. I can't see getting rid of IPv6 and
the delimiter characters are going to be very important in some
per-user policy situations.
Over complexity and over simplicity are both equally bad. The main reason a
lot of specs become complex is when an inadequate design is extended
incrementally (see MTP for an example).
In many ways, the SPF spec is actually *simpler* now that it was early
last fall. By allowing for macro variables, limited as they are,
quite a few specialized mechanisms were eliminated. They also allowed
for things people wanted, such as per-user checks, but were considered
to cause too much bloat. There have been several interesting ideas of
things you can do with SPF records that were thought of *after* the
SPF spec was frozen early last winter.
I agree that SPF is more complicated than I, and many others, would
really like to see. However, from what I can tell, it is about the
least complex system that covers enough of the problem domain to be
really useful.
-wayne