Re: Response to DDoS using SPF

Actually (sorry for the top post but it works in this context),
SendrID would likely have more problems with this sort of attack....
because it is happening at the RFC2822 level and more likely
implemented by MUAs than MTAs, messages would have to be accepted
before evaluating. Just want to document this in writing before we
move on.

Mike


On Thu, 24 Mar 2005 09:17:17 -0500, Scott Kitterman 
<spf2(_at_)kitterman(_dot_)com> wrote:
> > -----Original Message-----
> > From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
> > [mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of David 
> > MacQuigg
> > Sent: Thursday, March 24, 2005 9:14 AM
> > To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
> > Subject: Re: [spf-discuss] Response to DDoS using SPF
> >
> >
> >
> > > > Simply removing SPF may not be an option.  More likely there would be a
> > > > worldwide switch to SenderID [... ,] which avoids all these problems.
> > > SenderID uses the same record syntax and DNS look-up system as
> > SPF. It is, I
> > > suspect, therefore vulnerable to the same kind of DDOS attack,
> > with the same
> > > potential for amplification.
> > Here is the original quote, in context:
> >
> > > > > 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.
> > The subordinate clause refers to DomainKeys, not SenderID.  SenderID would
> > have the same problems.
> >
> > My statement was not intended to spark a debate over the merits of these
> > different protocols, but simply to say that a successful attack on SPF
> > could result in a worldwide switch to another protocol, even one
> > that might
> > have worse problems.
> >
> > I have a suggestion for these discussions.  Assume that someone is coming
> > into the discussion without having read all the prior posts.  Quote
> > everything in the prior posts that is relevant.  Storage is not an issue,
> > and it is very easy if you are following the discussion closely to just
> > skip past the quotes.
> >
> > Also, I think it is a good idea to delete the automatically inserted
> > who-said-what lines.  The discussion will go more quickly if nobody feels
> > they are being personally attacked, and have to defend some prior
> > statement.
> >
> > -- Dave
> OK.  Your sentence doesn't actually parse the way you are saying it does,
> but if you didn't mean Sender ID, then we should move on....
>
> Scott Kitterman
>
> -------
> Sender Policy Framework: http://spf.pobox.com/
> Archives at http://archives.listbox.com/spf-discuss/current/
> Read the whitepaper!  http://spf.pobox.com/whitepaper.pdf
> To unsubscribe, change your address, or temporarily deactivate your 
> subscription,
> please go to 
> http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com