At 06:54 PM 3/23/2005 -0600, Andy Bakun wrote:
On Wed, 2005-03-23 at 16:56 -0700, David MacQuigg wrote:
> If the virus were named "MX-doom" instead of "SPF-doom" it wouldn't have
> the same impact on public opinion. Nobody would believe it had
anything to
> do with MX. SPF has a particular vulnerability here. It may not be
> technically correct. It may not be fair. But it is real, and we need to
> recognize that it is real. If we cannot make the attack completely
> implausible, even to a reporter looking for a story, then we need to at
> least be ready with a quick fix, one that is so easy to install that lazy
> admins all over the world will do that instead of abandoning SPF.
<...>
As for "quick fixes", I can not come up with any that are less work than
disabling SPF all together. Say the quick fix is to change your SPF
record, most likely close to the absolute minimum amount of work there
could possibly be. This is exactly the same amount of work as removing
your SPF record or commenting out a line in your MTA's configuration.
In which case, if someone has negative information concerning SPF,
they'll just remove it.
Simply removing SPF may not be an option. More likely there would be a
worldwide switch to SenderID or another authentication protocol like
DomainKeys, which avoids all these problems.
Looks like "quick fix" was not a good choice of words. What I mean is a
solution that is quick to install later, if and when the need arises, and
will solve the DNS load problem, no matter what the spammers throw at it.
This could be something like a daemon that can be downloaded and installed
on a DNS server in a few minutes. Long before the "SPF-doom" virus hits,
this daemon should be running flawlessly on many DNS servers worldwide, and
should have no compatibility problems working with queries from systems
that are not yet upgraded.
Seems to me that an SPF record-compiling daemon could provide a "quick
fix", but I haven't thought through all the operational details. If admins
are used to working with all the mechanisms in our current spec, that
should stay the same, except they will be editing an off-line record, and
the daemon will update the actual DNS record.
The important thing is that we be ready with some solution, and not appear
to be taken by surprise. That solution must reduce the cost of SPF
checking to negligible, no matter what the spammers do.
-- Dave
************************************************************* *
* David MacQuigg, PhD * email: dmquigg-spf(_at_)yahoo(_dot_)com *
*
* IC Design Engineer * phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* * 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. * Tucson, Arizona 85710 *
************************************************************* *