Paul Vixie paul@vix.com
Sat Jul 24 23:34:59 UTC 2004

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

Among other things, Vern could be referring to


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


>    ... 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@NETBSD.ORG's account has a
   ".forward" file pointing at VIXIE@ISC.ORG, 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.

More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.