SPF

[Spike Ilacqua]

I'm not a huge fan of SPF, as an ISP I see what a pain it will be.
People like sending work mail from home, and home mail from work and
they are not going to be happy when that stops working.  And given how
much spam comes from compromised computers which will have legit SPF
records, it's value is unclear.   And not to mention these are the
spammers that have pretty much beaten everything that's been thrown in
there way, including tricky things like Bayesian filters.

Despite this, Microsoft has announce that Hotmail, MSN, etc will start
enforcing SPF on October 1st, so it's about to become all of the rage.
So that might make it a useful tool with greylisting.  In the case where
the SPF information can be confirmed, greylisting could be (optionally)
skipped.

There are two SPF libraries available:

http://www.libspf.org/
http://libspf2.org/

So some of the leg work is already done...

Thoughts?

->Spike

[Vernon Schryver]

> From: Spike Ilacqua

> I'm not a huge fan of SPF, as an ISP I see what a pain it will be.
> People like sending work mail from home, and home mail from work and
> they are not going to be happy when that stops working.  And given how
> much spam comes from compromised computers which will have legit SPF
> records, it's value is unclear.   And not to mention these are the
> spammers that have pretty much beaten everything that's been thrown in
> there way, including tricky things like Bayesian filters.

And then there are the facts that:

   - SPF was born in a swamp of marketing with a shortage of technical
    clues compared to its predecessors and competitors.  I'm not a fan
    of its competitors, but the other than technically accurate marketing
    behind SPF from the start has irked me.

  - what about .forward files etc.?

   - SPF (or similar) cannot have a significant effect on spam until it
    is widely deployed, but the experience of IPv6 and other things
    shows that could take many years

   - SPF (or similar) can only affect spam sent with forged SMTP envelope
    Mail_From domain names, but judging from the spam I see, that is
    a minority of spam, albeit a large minority.  Many spammers use
    their own domain names even when using Microsoft's spam and virus
    delivery system (zombie proxies).   Consider the domain names used
    by the spammer (or gang) recently calling its self "sh hh" in
    http://www.rhyolite.com/anti-spam/bin/group.cgi?group=151

   - after SPF (or similar) is widely deployed, spammers will stop
    forging domain names, that won't stop them from sending spam

> Despite this, Microsoft has announce that Hotmail, MSN, etc will start
> enforcing SPF on October 1st, so it's about to become all of the rage.

That's not exactly how I read the press reports.
See for example http://www.nwfusion.com/news/2004/0722microtoen.html?net
I thought that Microsoft was promising to support the
IETF's compromise among SPF, Caller-ID, etc.  That September date looks
like the goal from
http://ietf.org/html.charters/marid-charter.html
Skimming the IETF MARID WG archives in
http://www.imc.org/ietf-mxcomp/index.html
makes any repetition of that date sound uninformed.  On the other hand,
that article does say "SPF."

But until MARID finally delivers, how much of the net will install SPF?

> So that might make it a useful tool with greylisting.  In the case where
> the SPF information can be confirmed, greylisting could be (optionally)
> skipped.
>
> There are two SPF libraries available:
>
> http://www.libspf.org/
> http://libspf2.org/
>
> So some of the leg work is already done...

I understand that SPF is not Caller-ID and that neither is whatever
the IETF might someday bless.

In any case, greylisting is currently effective against "sh hh."
I would would not want to turn off a greylist check of mail with a
sender domain name of any approximately 950 domain names in
http://www.rhyolite.com/anti-spam/bin/group.cgi?group=151
simply because "sh hh" adds som RRs to its DNS servers at netfinding.com
netfindindin.com networkns.com networknns.com managernic.com
puzhdns.com pushnic.com stilldns.com stildns.com earlyynic.com
ns-202.com nss-202.com conname.com connname.com dnshall.com dnshill.com
dnssheet.com dnsshet.com ...


Vernon Schryver    vjs@...

[John R. Levine]

> I thought that Microsoft was promising to support the
> IETF's compromise among SPF, Caller-ID, etc.  That September date looks
> like the goal from
> http://ietf.org/html.charters/marid-charter.html

At this point I would guess that what MARID adopts will be close to SPF,
but with an option to check the 2822 From: header as well as the envelope.
The Caller ID XML stuff seems to have gone away, except perhaps as an
option that only MS will publish.

You can easily publish SPF that says anyone can send mail for your domain
from anywhere.  Problem solved (for now.)

I also agree that it's unlikely that anyone you care about will be
rejecting mail based on SPF any time soon, and I think the SPF fans will
be unpleasantly surprised when they see the bad guys' countermeasures.

For a leisurely good time, try checking the SPF data for blah.slow.sp.am.
(The blah can be anything, slow.sp.am is a real domain that fortunately
doesn't send much mail.  Yet.)

> But until MARID finally delivers, how much of the net will install SPF?

AOL will use SPF to update the IP ranges of whitelisted senders.  That's
one of the few things it's actually good for.

Regards,
John Levine, johnl@..., Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.

[Vernon Schryver]

> From: "John R Levine"

> AOL will use SPF to update the IP ranges of whitelisted senders.  That's
> one of the few things it's actually good for.

That's a new idea to me.  However, the big problem with whitelisting
is not checking for forgery or updating IP addresses (there is something
called the domain name system), but populating your whitelist.

In other words, how many of us are whitelisted by AOL?


Vernon Schryver    vjs@...

[Paul Vixie]

>    - ... I'm not a fan of its competitors, ...

Among other things, Vern could be referring to

        http://sa.vix.com/~vixie/mailfrom.txt

in case any of you here are interested.  See also my comments to:

        http://www.circleid.com/article/634_0_1_0_C/
        http://www.circleid.com/article/635_0_1_0_C/

>    ... marketing behind SPF from the start has irked me.

And me.  SPF is designed to protect domainholders from "brand dilution"
including rules of the form "reject all mail from hotmail.com since that's
what the forger-spammers are using this month."  At least in "mailfrom.txt"
I was up front about the fact that using this kind of technology would not
stop spam, or even slow it down, even a little bit.

>   - what about .forward files etc.?

In mailfrom.txt (see above reference), I wrote:

   3.2. Transport-level e-mail forwarding must be more explicit under this
   specification.  For example if VIXIE@...'s account has a
   ".forward" file pointing at VIXIE@..., then e-mail sent to the
   former will be received by the latter, but with no change in the payload
   of SMTP MAIL FROM.  Thus, ISC's inbound relays would have to be
   configured to implicitly add NETBSD's outbound mail relays as
   "multistage inbound relays."  This could scale poorly and may add
   pressure toward transport remailing (with a new envelope) rather than
   transport forwarding (reusing the old envelope.)

> > Despite this, Microsoft has announce that Hotmail, MSN, etc will start
> > enforcing SPF on October 1st, so it's about to become all of the rage.

Let's assume for a moment that this is an accurate interpretation of the
recent pressware from Microsoft-et-al, and that it won't take an IETF MARID
"rubber stamp" to get this kind of deployment to occur.

Why would that matter?  It's optional technology -- Hotmail and every other
Microsoft service offering, and every other potential SPF deployer, will
only be able to reject-as-forgery e-mail which purports to come from a
domain that actually has SPF records.  That means spammers who want to
forge mail from a domain need only ensure that that domain has no SPF
records "yet".  So even without using "their own" domains, spammers can
trivially bypass SPF.

Nobody, not even the authors of SPF, or any part of Microsoft, has proposed
or planned to reject mail from domains which lack SPF records.  Therefore
the deployment curve will not only have a long slope, but a shallow one.

I think it's safe for anyone who thinks that the deceptive marketing of SPF,
or the technical inadequacy of SPF, or the rubber-stamp relationship of IETF
MARID toward SPF+CallerID, makes the whole thing into a joke, ti just ignore
it and wait for a better solution.

I still favour public hangings of spammers as the only way to actually stop
spam.  But my studies of human nature have left me in a non-positive mood.

[John R. Levine]

Build fails with a missing pthread library.  If I add  -lpthread
to the definition of LDADD, it works fine.

The -lpthread was in LDADD in 1.3.98, didn't get 99-101 so I can't tell
you when it went away.

Regards,
John Levine, johnl@..., Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
DCC mailing list      DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

[Vernon Schryver]

> From: "John R. Levine"
> Subject: DCC 1.3.102 doesn't build on FreeBSD 7

> Build fails with a missing pthread library.  If I add  -lpthread
> to the definition of LDADD, it works fine.
>
> The -lpthread was in LDADD in 1.3.98, didn't get 99-101 so I can't tell
> you when it went away.

I just spent a several hours fighting to do clean-disk install of FreeBSD
7.1-RELEASE i386.  (I needed to that regardless of this problem to see
if it's safe to move to 7.1 on my real systems.)  After a random guess
of `ifconfig xl0 -vlanmtu` fixed NFS, everything including a clean
1.3.102 DCC installation followed by a several `updatedcc`s worked fine.

Is there any chance that the system with the problem has the FreeBSD
threading library confusion?  Some pre-release version of FreeBSD 7.1
had a libc that broke the old threading library.  Because of that mess,
whether -lpthread is used is determined by this fragment from the
./configure script:

    FreeBSD)
        if test 0`/sbin/sysctl -n kern.osreldate 2>/dev/null` -ge 602000; then
            # use new POSIX threads starting with 6.2
            appendvar PTHREAD_LDFLAGS -lpthread
        else
            appendvar PTHREAD_LDFLAGS -pthread
            # use libc_r on ancient versions
            if test -s /usr/lib/libc_r.a; then
                appendvar PTHREAD_LIBS -lc_r
            fi
        fi
        ;;

That stuff has not changed since 1.3.92.


Vernon Schryver    vjs@...
_______________________________________________
DCC mailing list      DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc