SPF for forgery prevention (was Re: [linux-elitists] http get vs post...)

Gerald Oskoboiny gerald@impressive.net
Sun Oct 26 17:45:44 PST 2003

* Karsten M. Self <kmself@ix.netcom.com> [2003-10-25 04:15+0100]
> on Fri, Oct 24, 2003 at 04:53:27PM -0400, Gerald Oskoboiny (gerald@impressive.net) wrote:

> > Regarding bogus c-r challenges sent to forged addresses, has anyone
> > else been following SMTP forgery-prevention stuff?  (SPF, RMX, DMP,
> > etc.)
> > 
> > SPF in particular seems to be coming along nicely, and has a growing
> > user/developer community.
> > 
> >     http://spf.pobox.com/
> Note that both DMP and RMX are referenced at the following SPF link:
>     http://spf.pobox.com/intro.html

There's an effort underway to merge these various proposals, but
it doesn't seem to have produced much yet.


> I've been composing a reply to the author of one of these for about a
> week now.
> The shrot answer is that while I suspect there are merits to many of
> these proposals, the successful solution will be one that is effective
> while being backward compatible.

I think SPF can accomplish this; it aims to be something that anyone
can deploy today without needing to update their DNS or MTA software.

On the spf-discuss list there was a discussion on whether to
define a new DNS record type for SPF entries or to publish them
as TXT records, and the consensus seems to be to use TXT even
though that's architecturally less clean, because anyone can
publish TXT records.

> The various protocol suggestions are mostly concerned with making the
> _protocol_ of mail exchange smarter.
> The problem of course is that both ends _won't_ be using the protocols,
> most of the time, particularly early on.  Which means:
>   - Gambling on which solution(s) will win.
>   - Investing in up-front configuration time for a relatively small
>     return.

The effort needed to publish SPF records seems fairly low -- many
sites can probably get away with publishing a single TXT record
that says "please reject any mail that claims to originate at
our domain which did not come from one of our MXes."

And spamassassin 2.70 should have SPF support built in.


>   - Not knowing how well the system will work until it's widely
>     deployed.  At which point the aggregate investment may not be worth
>     the results.

Some sites have already been rejecting hundreds of forgeries
using SPF, even at its current barely-deployed level.


I expect the investment to pay for itself very quickly, even if
it only prevents forgeries within my own site. (e.g. mail to public
mailing lists that was forged to appear from people subscribed to
those lists)

>   - All of the suggested systems have an ongoing administrative
>     overhead.  Particularly for aggregated domain administrators, the
>     worst problem isn't for sites which don't use SPF, but for those
>     which _do_, but for which one or more domains have inadvertantly
>     been omitted.  My own ISP (Earthlink) manages to forget periodically
>     that it aquired Netcom some time back, and manages to leave off
>     appropriate configurations or validity checks in various subsystems.
>     jeaniesflowersofstcroix.com running up long-distance bills to
>     Xinghang while trying to straighten out the fact that she can't get
>     boquets sent to Cloverdale doesn't hearten me.

Yup, SPF is just one more thing to make sure you don't mess up.

> Better:  come up with a system that works, immediately, if _one_ end of
> the system is smart, isn't vulnerable to misleading information from a
> remote host.  And has minimal downsides in the event someone's
> wires get crossed over whether or not a host is valid.
> The solution here is to give MTAs brains, and memory.  But let them be
> Donne's island:  not dependent on any information on the remote host
> other than its IP address and prior spam history.
> That is:  as mail comes in, it's tested (at SMTP time) for spamminess,
> and the mailserver keeps a running score of total amounts of mail, ham,
> and spam, associated with a particular IP address.  Essentially a
> reputation system.  This can be tweaked to favor (strongly if necessary)
> recent behavior to discourage submarine attacks.

Sounds like greylisting:


(not sure those are all related, that's just what I happened to
have bookmarked)

Gerald Oskoboiny <gerald@impressive.net>

More information about the linux-elitists mailing list