[linux-elitists] SPF

Karsten M. Self kmself@ix.netcom.com
Wed Jan 28 02:04:56 PST 2004


on Tue, Jan 27, 2004 at 08:45:49PM -0800, Don Marti (dmarti@zgp.org) wrote:
> begin Aaron Lehmann quotation of Tue, Jan 27, 2004 at 07:44:31PM -0800:
> 
> > SPF sounds interesting but at present I think it would break things if
> > implemented on my domain.
> 
> Causing wanton breakage is not an excuse for not trying something,
> on this list anyway.  Principled objections to SPF, anyone?

This is half off the top of my head, half from reviewing comments and
the SPF FAQ and online, of which this is a good critical summary:

    http://tinyurl.com/2bfjl


SPF isn't (and doesn't bill itself as) a solution for spam.  It does
make spoofing mail from a domain more difficult.  For some mail
recipients and senders, this can be a benefit:

  - If you're a large mail recipient, you're seeing a lot of spoofed
    mail from other large domains, and you have an SPF-aware MX, you can
    avoid spam spoofing other SPF-registered domains.

  - If you're a large mail sender, you're seeing a lot of complaints
    from people on mail that's spoofing your domain, you may be able to
    reduce the amount of misdirected spam reports you're seeing[1].

  - If you're being Joe-jobbed, *and* if SPF becomes widely adopted,
    you're a little less likely to get spammed by a bunch of idiots.
    Everyone receiving AV spam please raise your hand....


SPF breaks a few things:

  - Free-form ability to send mail from various places.  E.g.:  you're a
    customer of Big Provider Megacorp (BPM), and roam around with your
    laptop, using temporary links provided by friends, WiFi hotspots,
    contracting assignments, etc.  You can't send your BPM mail from
    outside BPM's own networks as you previously might have been able
    to.  There are some workarounds.

  - .forward.  There's a workaround in the PSF FAQ, but I'll bet there
    are a number of otherwise idle .forward accounts which will break as
    SPF is more widely adopted and utilized.  The popular ACM forward,
    for example, would fail[2].


SPF makes things somewhat easier for some classes of recipients and
senders.  You've got slightly more assurance that mail is from who it
claims to be from, in some instances, and your own abuse box may have
slightly more relevant content.  This depends highly on _other_ sites,
however, adopting and using SPF to test incoming mail.



There's the question as to what this buys you:

  - Spammers will continue to spoof domains, but will shift to smaller
    and lesser domains not implementing SPF.

  - Systems which don't utilize SPF will continue to accept, and/or
    misreport, inappropriate mail.

  - Existing SMTP-time checks, including rDNS and DNSBL lookups, are
    highly effective at rejecting mail from improperly configured
    systems, and at identifying if not spam, then highly probable spam.
    Of the set of DNSBLs[3] I'm using in my reportSpam script[4], 90% of
    spam trips at least one flag.  It could be argued that MTAs should
    already _at least_ be doing an rDNS check to see if the actual IP of
    a remote SMTP server matches its HELO and reported IP.

  - There are sufficiently many spam-friendly systems around that
    there's little to keep spammers from either running from systems
    without SPF (reducing their accountability) or _with_ SPF (polluting
    the value of SPF for the rest of us).  It's not enough to validate
    that mail comes from who it says it comes from.  You still need to
    trust the origin.  Existing DNSBLs do a good job of this.

  - Joe jobbing is itself a characteristic of trusting unvalidated
    content.  It's a problem in which the instigators of the Joe jobs
    are misbehaving.  This is indicative of, while perhaps legal, highly
    deprecated MTA configuration.  Justifying SPF on this basis is
    misguided at best.  An alternative solution -- a DNSBL aimed at
    highlighting the Joe Jobbers themselves -- has been proposed under
    the rubric "beefmail".



In balance?

There are clearly issues with SMTP abuse.  There's also a 24 year
history of (S)MTP with many existing systems based on stated and
unstated assumptions about its behavior.

_Misbehavior_ of the system is largely due to deliberate abuse of
varioius characteristics.  That abuse, while spread widely over the Net,
is also concentrated in a very small number, proportionately, of IPs,
most of these clustering among know problem areas, defineable by IP,
netblock, ISP, or ASN.  Even the generally acknowledge aggressive
coverage of SPEWS is only 0.1% - 0.2% of all IP address space.

One way of looking at this is as a matter of whether we've got a
protocol problem, or a higeine problem.  The vocabulary of email abuse:
outbreaks, viruses, worms, plauge -- the language of public health and
epidemiology.   I'm _not_ familiar with any serious discussion of public
health measures advocating "market-based" approaches to response.
Simply:  markets don't effectively allocate resources under epidemic
situations.  There's profiteering, hoarding, quackery, inappropriate
dosing or prescription based on ability to pay rather than clinical
indication -- rather than appropriate dispensing of therapies,
isolation, quarantine, and systematic disinfection.

While SPF doesn't directly exhibit all of these faults, I see several --
it makes the email system overall less flexible.  There's a rather
minimal gain.  A gross change which in the existence of long-established
patterns of behavior (of not standards compliance) is probably not
supported on a principle of conservitavsism.  It has potential effects
to close off Net access for classes of services and users, and increase
control points in a way that may be a net negative[5].

The tools of epidemiology are:  identification; quarantine; attending to
cleanliness standards; where appropriate treatments are available,
distribution of same; and above all, information on the extent and
nature of the problem.  


There are a few small benefits, most of which would be far better
addressed through direct means.

I see problem in search of a problem.

I'd stay away from it, and let others break things, myself.



Peace.

--------------------
Notes:


1.  Fat chance.  The idiots who send misdirected reports will continue
    to do so after SPF is around, so long as their own systems don't
    block the mail.  So this is a long-term payoff at best.

2.  http://tinyurl.com/2hd5v  "The sort of forwarding done by the ACM
    would be dead unless the really bad hack proposed on the SPF site
    (or something like it) was adopted by forwarders or some other
    special accomodations were made." Bill Cole (bill@scconsult.com)

3.  For the record:  Spamhaus, SpamCop, Relays ORDB, Relays VISI,
    Composite BL, Dynablock BL, DNSBL Proxy, DNSBL Multihop, SORBS Open
    Relay, SPEWS L1, SPEWS L2, Blitzed Open Proxy, RFC-Ignorant
    postmaster / abuse / whois / bogusmx / ipwhois.

4.  http://linuxmafia.com/~karsten/SpamTools.tar.gz  Still alpha, but
    usable.

5.  Pun unintended, but what the heck.

-- 
Karsten M. Self <kmself@ix.netcom.com>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
    The major problem facing social networks is that they scarf up
    personal information far more efficiently than a Carnivore system.
    People really aren't going to trust them if they view these
    start-ups as honeypots for future marketroids to reap everything we
    didn't want them to know. Let alone allow a passing hacker to scarf
    up this potential archive of great exploitable value.
    -- Andrew Orlowski, on Orkut, Friendster, and ilk.
-------------- 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/20040128/29f1ac57/attachment.pgp 


More information about the linux-elitists mailing list