ietf-clear
[Top] [All Lists]

[ietf-clear] Re: Make CSV backwards compatible with legacy SPF records?

2004-12-01 22:58:04


Warning:

The Matthew cross-posted his message to both the CLEAR and SPF mailing
lists.  I suspect that this isn't very productive, so I'm only going
to drill in the idea that HELO checking in SPF is NOT NEW.


In <41AE65A1(_dot_)70402(_at_)elvey(_dot_)com> Matthew Elvey 
<matthew(_at_)elvey(_dot_)com> writes:

On 11/18/2004 11:38 AM, wayne sent forth electrons to convey:

If someone can explain the differences to me, I would be happy, but
the discussions on the MARID list and during the Jabber sessions lead
me to believe that, for whatever reason, I'm just not getting it.
Repeating those same explanations will probably not help me.


Here are some simple explanations of why checking the HELO domain
against SPF records isn't as good as doing CSV checks.

This coming from someone who thinks it's a good idea to try (and
thinks he came up with the idea) [...]

The idea of checking the HELO domain when the MAIL FROM was NULL was,
to the best of my knownledge, first suggested by Justin Mason on Sept
29, 2003.  See:
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200309/0044.html

Checking the HELO domain for an SPF record exists in the oldest SPF
spec that I have handy (Nov 13 2003).

As far as checking the HELO domain with SPF even when the MAIL FROM is
not NULL,  On Jan 21 2004, I wrote:
"I think using SPF to check the HELO string has some merit"
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200401/0803.html

On Mar 23 2004, the same day Matthew Elvey first posted to the MARID
list, I wrote again:  "HELO checking should always be done"
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200403/0428.html
MARID list started: Mar 5

Later, Hector Santos lobbied much harder for optional HELO checking to
be added to SPF, even when the MAIL FROM wasn't NULL, and Meng added
it to the SPF draft spec of Apr 21 (spf-draft-200403.txt).


The point is that SPF has had, for a *very* long time, the checking of
the HELO domain. 



I. Surely, you understand that the SPF record discovery algorithm is
inherently less efficient/more costly than CSV's.  That's obvious, no?
How many DNS queries does it take to resolve elvey.com's SPF record to
a list of IPs?  A dozen or so?

For the purposes of HELO checking, the question is how many DNS
lookups does it take to resolve the SPF record for whatever HELO
domain you use, not elvey.com.  In most cases, this will be "v=spf1 a -all",
and that will require two DNS queries.  Yes, it is not optimal, but we
are about a year to late to change it in SPF now.


II. Here are some simple, concrete examples of where checking the HELO
domain against SPF records isn't as good as doing CSV checks.
 1)The domain owner used an SPF wizard (M$' or pobox's) to create an
 SPF record. The wizards are buggy.  They don't take steps to ensure
 that the owner creates an SPF record that will match the HELO domains
 his servers use.

Yes, Microsoft's wizard still has problems.  (Or at least it did as of
the FTC summit.)  It is unfortunate that Microsoft doesn't understand
and/or test the system they claim to support, but there is little I
can do about it.

Pobox's, on the other hand, has for a very long time given the SPF
records that you need to place in the spots for the HELO domain
checks.  Check it out.


Note, there are other *important* differences (SPF checks against HELO
are  inherently much more vulnerable to DNS security attacks than CSV;
the meaning of "checking the HELO domain against SPF records" is
vague;

No it is not vague.  It has been in the SPF specs for a very long
time.  Granted, the HELO checking isn't in the SenderID spec as
developed during the MARID process, but that's because it wasn't
supposed to be there.


-wayne