Sat Jul 24 23:34:59 UTC 2004
> - ... 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@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