"If you believe that the SPF concept is fundamentally flawed, please subscribe at http://www.imc.org/ietf-mxcomp/"

The following is a greeting when subscribing to spf-discuss:
-------------------------------
> Hi!  You have asked to subscribe to the mailing list
> [email protected].  If this is what you want,
> just reply to this message or click on the link below, 
> and you will be subscribed to the list.
> 
>   http://v2.listbox.com/subscribe/?confirm=xxxxxxxxxxxxxxx
> 
> This list is for open discussion of the proposed SPF standard.
> 
> Subscription to this list, and posting to it, is a privilege, not a
> right.
> The list operates according to the best practices described at
> RFC1855.
> You should also review
> http://www.ietf.org/proceedings/02mar/slides/plenary-3/  
> 
> Revocation of privileges operates according to an abbreviated form of
> BCP83.
> In short: kooks, crazy people, and rude people should expect to be
> unsubscribed.
> ,---
> | The SPF mailing list is intended for constructive discussion and 
> | promotion of SPF. If you believe that the SPF concept is
> | fundamentally flawed, please subscribe instead to the ietf-mxcomp
> | mailing list at http://www.imc.org/ietf-mxcomp/
> '---
> 
> The SPF standard originated as a hybrid of Gordon Fecyk's DMP
> proposal and Hadmut Danisch's RMX proposal.  It now provides
> a superset of their functionality.  More information at
>  http://spf.pobox.com/
> 
> November 2004: The Messaging Anti-Abuse Working Group
> sponsors a white paper titled Sender Authentication: What To Do.
> http://spf.pobox.com/whitepaper.pdf
> Please read it!
> 
> October 2004: Microsoft encourages the publication of SPF
> records.  Microsoft will use a modified form of SPF, known as
> "Sender ID", to check message headers in MUAs.  Most other
> MTA implementations continue to use SPF in its original form,
> to check the return-path at SMTP time.
> 
> Official announcements regarding SPF will be made on this list
> and also on the announcements-only list, [email protected],
> so you don't need to subscribe to both lists.
> 
> List archives are available at
> http://archives.listbox.com/spf-discuss/current/
> 
> Read and contribute documentation at the Wiki!
>   http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/
> 
> FOR DOMAIN OWNERS
> 
> SPF is now ready for widespread adoption.  If you control a
> domain, you should publish SPF records for it now.  You can
> get started at http://spf.pobox.com/wizard.html.  It takes most
> people about 10 minutes to learn about SPF and 5 minutes to
> write the records.
> 
> FOR MAIL ADMINS
> 
> You can download plugins for Postfix, Exim, Qmail, Sendmail,
> Exchange, and other MTAs from http://spf.pobox.com/downloads.html.
> 
> FOR DEVELOPERS
> 
> One of SPF's design goals is to be simple, quick, and easy for domain
> owners to publish records.  We have met this goal at the cost of
> some complexity on the client end.  Most developers accept this
> tradeoff.
-----------------------------------

It would appear subscription to spf-discuss acknowledges acceptance of
the SPF concept.  However, problems related to SPF have become even more
pronounced since dissolution of the MARID WG.  Sender-ID has usurped the
initial SPF record for PRA evaluation, and is advising use of methods in
conflict with bounce-address validation efforts.

The Sender Authentication Whitepaper, passed on to MAAWG from the FTC
conference, has not undergone requested changes.  There are several
assertions that remain misleading and in error.

SPF _is_ fundamentally flawed as it removes accountability from the
email providers, at the expense of the domain owners and consumers.
Contrary to the promotions, SPF will not stop spam.  SPF will not
prevent your domain from being forged, without great diligence by now
anonymous email providers, as well as, universal compliance at each
public MTA, and a slew of modification made to every email client.

I can not accept the premise there are no serious concerns related to
publishing SPF records.  No scheme without a reputation assessment will
prevent email abuse.  Abusers are among the first to adopt changes
offering greater access.  Reputation puts the teeth in any email
protection scheme.  Beware, SPF may bite!

You may get bit by recipients that consider SPF authorization is
equivalent to identifying the source of a message.  This assumption is
unsafe and wholly unfair.  This assumption is unsafe as forgery can
still continue.  This assumption is unfair as a basis for accruing the
reputation of a domain owner, as they often have no administrative
oversight with which to assure their protection.

Instead of SPF records preventing harm when a domain is forged, SPF
authorization may actually cause an otherwise impeccable domain obtain a
bad reputation, when forgery nevertheless continues.  Abusers may
actually utilize your SPF records to usurp previously good reputations.
What is worse, redemption of your reputation may not be practical. 

Abusers may take advantage of your desire to ensure your emails are
delivered.  Abusers may also take advantage of your email provider's
desire to not license Microsoft's Sender-ID algorithm, which sets terms
incompatible with open-source software.

The selected domain offering server authorization is assumed to have
originated the message.  Microsoft calls this unfair assumption, “Sender
Authentication.” Calling Sender-ID “Sender Authentication” would be like
me making a declaration that the postal service is authorized to deliver
my letters, where recipients are then claiming any letter received from
the postal service bearing my name anywhere is authentically or
genuinely from me.  Of course that would be a false assumption, and
Sender-ID is no different.

How will abusers take advantage of these normal desires and false
assumptions?  While strictly limiting authorization to just the email
provider's servers reduces some risk of your domain being forged, this
may cause your messages to become lost as a result.  This loss may occur
when recipients use providers that select accountable domains based upon
the “classic” bounce-address algorithm.  The recipient may forward
messages, which then makes your message appear to be from an
unauthorized server.  Your message may also become lost when sent
through some list-servers, or through servers running older versions of
email protocol.  Why quibble over who is responsible for implementing a
plethora of fixes, where any change to email often takes decades?

The remedy for the loss of your messages is to leave your SPF server
authorization list open-ended.  When from an unknown server, the
open-ended list then declares a lowered level of authorization.  This
lowered level of authorization is intended to alert recipients to
increase the scrutiny given such messages.  However, this lowered level
of authorization will not ensure your reputation remains protected from
forgery.

For example, abusers take advantage of Microsoft's automatic
image fetching to compile valuable lists of active email accounts, just
by using encoded image links.  These abusers don't really care which
folder or level of authorization they obtain.  They don't care that
recipients fail to respond to their email either.  These abusers would
be thrilled to see recipients unsubscribe.  Your concern is whether the
recipient also clicks the “spam” button, when these messages have forged
your domain. 

With SPF records being very public, your domain's reputation will be
exposed to any abuse possible.  Publishing open-ended SPF records may
even act as an invitation, should a SPF reference become mandated by
some providers.  Furthermore, a provider that does not ensure Sender-ID
headers are not in conflict with any of their other customers, may risk
your domain's reputation, especially when this provider's limitation
becomes known.  When viewed by Sender-ID, such providers can not ensure
your domain will not be forged.  Of course, Microsoft may see this
problem as being to their advantage.  Once this becomes enough of a
problem for domain owners, providers may find it necessary to license
Microsoft's algorithm after all.

With phishing techniques becoming seemingly epidemic, Microsoft is quick
to offer Sender-ID as a remedy.  With respect to phishing, Sender-ID
considers the From header as the lowest priority for basing acceptance,
even though this is the header typically seen by the recipient.
Microsoft has made this problem worse by displaying the user friendly
name, known as the “pretty” name, rather than the actual mailbox
address.

Phishing ploys often use disposable domain names for obfuscated links,
which could also provide SPF authorizations. SPF records can also be
constructed to covertly and fully authorize all servers within the
entire Internet.  SPF can covertly enable Zombies anywhere in the world.
Sender-ID, even as a lame phishing deterrent, presumes wide adoption of
proprietary algorithms by mail clients and providers.  Assurances
offered by Sender-ID aware applications are dangerous, due to the
acceptance of hidden headers, and expectations of compliance to these
proprietary algorithms.  This may actually place consumers trusting such
assurances in greater peril.

Sender-ID itself may weaken the integrity of the DNS, where Microsoft
only offers the advice that providers use "properly paranoid DNS
resolvers.”  Sender-ID requires that domain owners trust their email
providers, although many providers do not authenticate their own
customers.  Heedless publishing of SPF will expose domain owners to
substantial risk.  In addition, Sender-ID does not identify these
providers either, so there is little to directly motivate email provider
diligence.

Signatures are a safer alternative to this nonsensical approach that
depends upon a magic wand that mysteriously transforms “server
authorization” into “sender authentication.”  There is already a digital
signature technology, S/MIME, that can be handled by more than 400
million email clients such as Outlook, Outlook Express, Lotus Notes,
Novell Groupwise, Netscape, Mac Mail, Mozilla, Thunderbird, Eudora,
Becky!, Bat!, Mulberry, Blackberry, and more.  Surely, financial
institutions being phished can afford the digital certificates needed to
verify their From address.

Very soon major providers will offer DomainKeys signatures on outbound
messages, and will be checking these signatures when messages enter
their email gateway. The use of email signatures is on the near horizon.
DomainKeys can be deployed within email gateways, and easily
implemented.  Compared to S/MIME with browser Certificate Authorities,
DomainKeys lowers cost barriers, and does not depend upon the end-user
email applications.  When deployed for solicitations unrelated to
commerce, cost is often a greater concern as well.  Signatures can
indicate where the message originated, regardless of the use of
subsequent relays, or message forwarding, and offer a truly safe means
to defeat phishing attempts. 

Unlike signature methods, Sender-ID limits the domain owner's choice of
providers, and will likely create endless consumer complaints.
Signatures indicate where the message originated without changing
email's architectural paradigms.  Signature verification only requires
the recipient make the required checks, and is not required that these
checks be performed at every intervening server that relays the message.

Even spoofed bounce messages can be curtailed by signing the
bounce-address using Bounce Address Tag Validation.  Domain owners can
sign their own email, and safely use providers that may exercise dubious
diligence, without jeopardizing their domain's reputation or exposing
their recipients to phishing threats.  There is little benefit derived
from jumping upon the Sender-ID bandwagon, but there is much more to
loose when publishing SPF records.  Consider DomainKeys instead.

-Doug