draft-schlitt-spf-classic-01.txt

My previous message was to explain why the MARID reflector is being used
for these comments.  SPF could offer white-listing utility, provided
there is consensus on the record's scope.  Such use requires that this
scope be defined, or not used as a basis for accruing reputations.  Of
course, this would make SPF useless for anything other than
white-listing.  Nor would I trust anyone to honor such exclusion.
However, SPF proponents still insist this mechanism is fair with respect
to assessing reputations.  I say it is fundamentally flawed, as
assumptions of assured identifiers place domain owners in serious
jeopardy.

The email provider must be held accountable in any meaningful approach
for abating abuse.  However, SPF avoids such accountability.  A provider
may feel SPF based reputation systems are of little concern to them, but
it should be of tremendous concern for their customers, who are often
little more than domain owners.  Only signatures offer domain owners a
modicum of control and oversight in their pursuit of protecting their
domain's reputation. 


Be that as it may, I see this effort as reducing the harm created by
SPF. : <

1.  Introduction
,----
| The current e-mail infrastructure has the property that any host
| injecting mail into the mail system can identify itself as any domain
| name it wants.  Hosts can do this at a variety of levels: in
| particular, the session, the envelope, and the mail headers.  While
| this feature is desirable in some circumstances, it is a major
| obstacle to reducing Unsolicited Bulk E-mail (UBE, aka "spam").
| Furthermore, many domain name holders are understandably concerned
| about the ease with which other entities may make use of their domain
| names, often with malicious intent.
'----

This paragraph lists many different identities that could be used to
identify the sender, and implies any could be examined to discover
possible server authorization.  As just mentioned, some still consider
this provides a method for performing sender authentication.  These same
individuals will happily block any such domains, once they are assumed
abusers.  After all, abusers can and will also publish SPF records.

A disagreement regarding which of these identifiers MUST be assured by
the sending server (to protect their client's reputation) occurs within
this draft and the draft-lyon-senderid-core-01.txt.  It is amazing that
this happens even though both of these drafts share the same author.  Of
course, protecting one's reputation depends upon this important detail.
However this draft only defines use of MAILFROM within the message, and
ignores this rather serious concern.  This is not FUD, this is just
F. : )

Unless providers can assure their customers that there are no conflicts
within all message PRAs, any other customer would be allowed to create
serious harm.  This harm could originate from a Zombied computer of such
a customer.  The abuser may utilize SPF records to obfuscate where the
message originates to prolong their success, when seeing such messages
are not blocked by the sending server.

SPF based reputation systems could employ local or divergent databases
that attribute domain abuse based upon the "assumed" sender. (I want to
say based upon "Sender Assumptication.")  How can the domain owner
restore the use of their domain, after their provider naively believes
they can assume how a record will be interpreted which has an undefined
scope?  Wouldn't providers be negligent when advising the use of SPF and
not making strict PRA validations?  Publication of a dummy record for
PRA, which may cause loss of messages, does not seem a satisfactory
solution, as provided in the Sender-ID draft.



10.2.  SPF-Authorized E-Mail May Be UBE
,----
| The "MAIL FROM" and "HELO" identity authorizations must not be
| construed to provide more assurance than they do.  It is entirely
| possible for a malicious sender to inject a message using their own
| domain in the identities used by SPF, to have that domain's SPF
| record authorize the sending host, and yet the message content can
| easily claim other identities in the headers.  Unless the user or the
| MUA takes care to note that the authorized identity does not match
| the other more commonly-presented identities (such as the From:
| header), the user may be lulled into a false sense of security.
'----

An interesting, albeit fuzzy, warning indeed.  Add another warning of a
similar nature.  Because there may be an assumption made regarding
server "authorization" (even potentially a neutral authorization) being
equivalent to sender "authentication," your domain may be attributed for
abuse which forges any identifiers other than MAILFROM.  Microsoft
describes a PRA process based upon this specific SPF record, used in
conjunction with SmartScreen, for example.  This creates the potential
for serious harm to the domain owner's reputation, when providers ignore
potential PRA conflicts.      

Add a warning that examination of the PRA is REQUIRED for cases where
the recipient uses draft-lyon-senderid-core-01.txt, which only utilize
the record syntax described in this draft.  Publishing an SPF record
will not ensure which identifier will be held accountable for abuse.  If
your email-provider does not license the PRA algorithm, there should be
no expectation that your domain's reputation is being protected.

I'll be happy to agree with Carl about the white-listing utility of an
SPF record.  To repair this draft, there appears little choice, but to
adopt the later version of the SPF record which includes the scope of
the identifiers assured by the sender.  That was the reason for
including scope in the first place.  Ignoring this issue would be
ignoring a rather big elephant in the room.  It would also represent
serious negligence on the part of the provider.



10.  Security Considerations
,----
| SPF implementations SHOULD limit the total amount of data obtained
| from the DNS queries.  For example, when DNS over TCP or EDNS0 are
| available, there may need to be an explicit limit to how much data
| will be accepted to prevent excessive bandwidth usage or memory
| usage, and DoS attacks.
|
| MTAs or other processors MAY also impose a limit on the maximum
| amount of elapsed time to evaluate check_host().  Such a limit SHOULD
| allow at least 20 seconds.  If such a limit is exceeded, the result
| of authorization SHOULD be "TempError".
'----

With this draft mandating more than one hundred DNS lookups, this raises
a concern regarding how the 20 second time limit is employed.  A local
recursive DNS resolver may act as a UDP amplifier.  Congestion avoidance
depends upon the application making the requests to wait, in order to
maintain stability.  

There should be some language that warns against doing these many
lookups in parallel, and simply timing out the effort to resolve server
authorization for a particular message.  If parsing routines have not
made these provisions, then setting up a two-tier DNS resolver where the
Internet facing DNS resolver is not recursive and is rate limited on
port 53, could offer a solution.

There should also be a warning about acceptance of duplicate records.
The same two-tier approach would offer protection when older DNS
resolvers are being used that do not ensure replicate lookups are
prevented.  
 
-Doug