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

Karsten M. Self kmself@ix.netcom.com
Fri Oct 24 20:15:15 PDT 2003


on Fri, Oct 24, 2003 at 04:53:27PM -0400, Gerald Oskoboiny (gerald@impressive.net) wrote:
> * Andrew Moore <amoore@mooresystems.com> [2003-10-13 16:23-0500]
> > On Sat, Oct 11, 2003 at 02:10:00AM +0100, Karsten M. Self wrote:
> > > ----- Forwarded message from automated-response@earthlink.net -----
> > > Click the link below to request that christgo@earthlink.net add you to this list.
> > > https://webmail.pas.earthlink.net/wam/addme?a=christgo@earthlink.net&id=1a7DZz7li3NZFl40
> > 
> > I wonder how long that link is active. It's now archived on at least
> > one web page, meaning it will invariably be followed by a client of
> > some kind. It won't be long until we can all spam
> > christgo@earthlink.net with mails "from" Karsten.
> > 
> > Does this represent yet another failure of challenge-response
> > systems? Is it a large enough one that it will be exploited by
> > spammers? Will we all start receiving spams "from" archived mailing
> > lists?
> 
> This is a good example of why HTTP GET requests should not have side
> effects like confirming registrations or mailing list subscriptions.
> Fetching a URL should be a "safe" operation.  (though it looks like
> earthlink's isn't.)

Note that the URL will be hit by a Google or other crawl eventually as
well.

> related bits for those interested:
> http://lists.w3.org/Archives/Public/www-archive/2003Oct/0035.html

Good stuff.  Wasn't aware of it but the risks are obvious.

> 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


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.

TCP/IP has been described as "cheap and stupid" with "smart endpoints
called computers".  While this isn't wholly applicable to SMTP, the
basic engineering principle is.

The _beauty_ of SMTP is that all you have to know to send a message to
someone is their email address.  Query the domain to get an MX, and tell
the receiving end "I've got mail for...".  Of course, that's also its
curse.

The various protocol suggestions are mostly concerned with making the
_protocol_ of mail exchange smarter.  That is:  one end of the pipe has
to ask the other something, and the other end has to know the
appropriate response.  Best I can tell, both SPF and RMX require this
(DMP doesn't Google well, got a ref?).  Which means that the systems
work well...when both ends of the connection are using the protocol.

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.

  - 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.

  - 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.


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.

The concept naturally favors the domains with which a site most
frequently corresponds.  Newbies aren't significanlty disadvantaged
(though there may be a service preference associated).  Spammers'
dedicated servers are rapidly detected and shown the door.  Proxy spam
drones (as are increasingly commonly found on broadband residential
connections) are rapidly determined to be same and blocked.

And which this doesn't _require_ sharing information among servers, the
data certainly _can_ be shared.  A given site's reputation base can be
shared (anonymousely or authenticated), signed or otherwise
authenticated if desired, either publicly, or privately among partners,
business units, cabal, whatever.  This acts somewhat as current
RBL/RWL, but largely serves to extend the experience of a given site.


Anyhow, that's *my* take on things.  Open to discussion.

Peace.

-- 
Karsten M. Self <kmself@ix.netcom.com>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
  The revolution will not be televised.
  You can apt-get it from the usual mirrors, however.     http://www.debian.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20031025/7286b2c7/attachment.pgp 


More information about the linux-elitists mailing list