ietf-mxcomp
[Top] [All Lists]

Re: The problem with Unified SPF

2004-06-30 17:12:57

On Wed, 2004-06-30 at 15:03, Meng Weng Wong wrote:
<snip>

The problem statement seems to assume that domain names used
in MAIL FROM will overlap with domain names seen in HELO.
If I read this assumption wrongly, please correct me.

  HELO domain.com
  MAIL FROM:<user(_at_)domain(_dot_)com>

In this situation, an SPF record could easily become
unnecessarily complex for HELO purposes.

  domain.com. TXT "v=spf1 include:this include:that a mx ?all"

If the domain admin changes the HELO string to be:

  HELO mta1.domain.com
  MAIL FROM:<user(_at_)domain(_dot_)com>

Then the problem goes away.

  mta1.domain.com. TXT "v=spf1 a -all"
  domain.com.      TXT "v=spf1 include:this include:that a mx ?all"

Is that any better?

Is Sender-ID depreciated over rejections of XML?  Is there a push to
restore SPF?  It would be nice to see a draft that brings these ideas
(2822 identity schemes) into a "unified" document. : )

There is nothing in this SPF record that ensures this is intended to
define the MTA host name so it can be spoofed with helo strings
selecting the wrong record.  It still requires use of a parser to
understand the record as opposed to using existing libraries that
already include the SRV format.  This SPF string may require additional
queries to read any number of differing records.  The SRV record is able
to return a list of addresses, and where these hosts can be assigned
using existing tools.

CSV and SPF/Sender-ID records are requested at different points within
the process, so there may not be a need to spawn a SPF/Sender-ID parser
if the connection is rejected by the CSV process.  This is a
consideration when receiver side resources are considered.  If CSV is to
provide DDoS protection, using an SRV record improves upon this
protection.  As these lists may tend to look similar for some, there is
great risk of confusion or simply allowing clever spoofing made possible
by this overloading of SPF/Sender-ID/CSV.  Keep CSV separate using SRV.

I do not see these two distinct and separate functions as either
competitors or as incompatible. But again, there is no reason to join
these two mechanisms into a common record, and many reasons not to join
them.

-Doug 



<Prev in Thread] Current Thread [Next in Thread>