Re: So here it is one year later...

On Sat, 2005-01-29 at 13:03 -0600, wayne wrote:
> In <[email protected]> Andrew Newton <[email protected]> writes:
> 
> > On Jan 29, 2005, at 12:32 AM, wayne wrote:
> >> For
> >> some strange reason, the IETF is now considering the SenderID drafts
> >> that still use the same records.  Go figure.
> >
> > If by same records, you mean anything TXT then I'm afraid you will
> > have to live with that... and any other new uses for TXT that come
> > along.
> 
> Nope, I see no problem with using TXT RRs.  (The same goes for CSV's
> use of SRV records or MAPS's use of A records.)

Those publishing SPF records risk causing their mail being forwarded by
various recipients to be blocked or lost, with the same happening to
mail sent through some list servers.  For network security and to
establish accurate reputation, an accountable entity for the mail being
sent can be found by way of the HELO domain.  SPF however can not
indicate which identity checking is desired by the sender.  Is it the
Sender-ID PRA, the SPF MAILFROM, or now the SPF MAILFROM and HELO in
combination?

The design choice of SPF to not use a specific label to access a
potentially large initial TXT RR record, dedicates this TXT RR for use
by one revision of one application.  This is wrong.  This gets even
worse with use of this same TXT RR by more than one faction.  A wildcard
label can not establish policy, so the reasons for avoiding a prefix
proves to have been a major mistake. 

While commending efforts that attempt to establish reasonable limits for
the use of DNS, this effort is like starting with a square block and
chipping away at the corners.  Eventually, one arrives at the wheel.

The new SPF processing limits are stated differently:

   SPF implementations MUST limit the number of mechanism that do DNS
   lookups to at most 10, if this number is exceeded, a PermError MUST
   be returned.  The mechanisms that count against this limit are
   "include", "a", "mx", "ptr", "exists" and the "redirect" modifier.
   The "all", "ip4" and "ip6" mechanisms do not require DNS lookups and
   therefore do not count against this limit.  The "exp" modifier
   requires a DNS lookup, but it is not counted as it is used only in
   the case of errors.

   When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro,
   there MUST be a limit of no more than 10 MX or PTR RRs looked up and
   checked.

A limit of 10 mechanism[s] that do DNS lookups?  Each mechanism is then
allowed 10 lookups?  Would that be a total of 101 lookups?  Will this
prevent attacks?  The average number of queries for each lookup could be
around 3.  The following text and process definitions seem to allow 10
lookups each to resolve the MX, the PTR, and the %{p} macro (reverse DNS
comparison to forward DNS).  Would 10 %{p} count as 20 DNS lookups?

This compares poorly to CSV which uses a single lookup to obtain the
CSV-CSA record.  This record also limits the scope of the identity being
checked to that of the HELO/EHLO.  This record also uses a prefix as to
not usurp a RR type or interfere with other protocols.

CSV makes it clear ONLY the HELO is to be checked, which avoids the
conflicts present with Sender-ID and SPF algorithms.  Sender-ID and SPF
essentially reduce the integrity of mail delivery.  The disruption
caused by these algorithms is without significant benefit, as path
registration authorization does not ensure mail is not being spoofed,
nor which identity is being checked at each stage, nor allow accurately
assessing reputation.

Endorsement of SPF by those that also block bounce messages seems to be
indicating a willingness to trade reliability for expediency.  In the
long run, this approach will be expensive.  There are efforts outside of
SPF that are focusing on the problem.  Mail integrity can be retained,
and accountability accurately determined without putting the email and
DNS system at risk.  May I encourage some of the energy placed upon SPF
to focus on the MASS and CLEAR work groups?

http://mipassoc.org/mass/
http://mipassoc.org/clear/

-Doug