1) I agree. Maybe Ming's "report=spfmanager(_at_)domain(_dot_)com" would help!
2) I agree.
3) No comment.
4) I can't find spf-draft-200406.txt, but I agree that:
"This means that domain owners must publish SPF records for every
sub-domain. Very few domain owners realize this."
5) I agree.
6) I agree, but what is a good size limit? UDP limit maybe?
Just my 2.71828 cents worth!
Guy
"Sure you saved money, but at what cost?" - Guy Watkins
-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of wayne
Sent: Wednesday, October 13, 2004 2:07 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] [SPF v1 Draft] Last chance before I submit...
In <53BC05C0-1C1C-11D9-B42A-000393A56BB6(_at_)glyphic(_dot_)com> Mark Lentczner
<markl(_at_)glyphic(_dot_)com> writes:
Unless I hear gnashing of teeth, I will prepare it for submission to
the IETF as an internet-draft on Wednesday, and then begin the process
of moving it to experimental RFC status.
I confess that, due to Meng and MS, I have lost most of my motivation
to participate in the SPF project and have not really reviewed these
drafts. The following are all suggestions that I have sent of to Mark
and/or Meng before and have been rejected, so I don't see any reason
that they would be included now.
1) Correct syntax checking is not required.
In section 4.6, it says that if a syntax error is "encountered"
and that checking for syntax errors can be done before any
evaluation, but nothing says that an implementation must check for
and detect syntax errors.
Now, this might seem like a fine point and that word "encountered"
should be enough, but according to Meng, it isn't. For example,
Meng's "reference implementation" manages to avoid "encountering"
any syntax errors, never ever, under any circumstances actually
returns a PermError because of a syntax error.
Even implementations that do some syntax checking, most will stop
checking for syntax errors when the evaluation of the record
reaches a result. That is, in the record "v=spf1 a k$", if the
"a" mechanism passes, the invalid mechanism "k$" is never
detected.
While some will claim that it is a waste of CPU cycles to check
the rest of the record, CPU cycles are generally very cheap on
MTAs and this is really just lazy programming. If you really want
to save CPU cycles, you should do byte compiling like libspf2
does.
2) Unknown mechanisms are a bad idea and are never used
There is nothing you can do with an "unknown" mechanism that you
can't do better with an unknown modifier. Unknown mechanisms are
not an effective method of extending the SPFv1 semantics.
I know of no implmentation that implements mechanisms that aren't
in the SPFv1 spec. Technically "unknown" mechanisms are found
fairly often in real SPF records, but they are almost always the
result of typos. They are things like "prt:" instead of "ptr:",
or "ipv4" instead of "ip4".
The inclusion of unknown mechanisms in the SPFv1 spec just makes
SPF records less reliable. Granted, it also means that SPF
implementation don't have to do much syntax checking and it is
easier for lazy programmers, but I don't see that as a good reason
to reduce reliability of SPF.
3) Process limits and security issues: DDoS attacks.
The process limits put in place by the SPF spec are whole
inadequate to prevent SPF implementations from being used as a
DDoS attack. The language in the Security Section (section 10)
dismisses the DDoS problem and completely misses the point. More
over, an SPF implementation that is safe from being used for DDoS
attacks *MUST* violate the SPF standard because it can not
implement and evaluation the check_host() function in accordance
with section 4.
As a result, libspf2 will *NEVER* conform to the SPFv1 spec. It
would simply be irresponsible to do so.
The problem with DDoS attacks have been mentioned many times and
it involves records such as the ones found at dos.midwestcs.com,
dosinc.midwestcs.com, dosexists.midwestcs.com,
dosredirect.midwestcs.com, and many only slightly less obvious
variations.
4) The zonecut language has been removed.
The language for the zonecut as found in spf-draft-200406.txt has
been removed. This means that domain owners must publish SPF
records for ever sub-domain. Very few domain owners realize
this.
5) The %{h} macro-variable has been removed.
The %{h} macro-variable has always been part of SPFv1. The text
in the spec needed to describe the fact that it has been removed
is larger than the text needed to describe what the macro did.
There is *no* good reason to remove it from the SPFv1 spec and
create an incompatible change.
6) implementations can not restrict the size of SPF records.
There is no language in the SPF standard that allows SPF
implementations to reject SPF records that are too long. While
domain owners are told that they SHOULD limit the size, MTAs that
check SPF records are not allowed to reject SPF records that are
too long. This creates both reliability problems (long records
can not always be correctly fetched) and also DDoS problems.
I'm sure there are many more problems with this draft. I don't much
care. As I said at the beginning, all of these things have been
pointed out the the authors and either ignored or rejected. I do not
intend to use this draft as a reference, I will use my best judgement
instead.
-wayne
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta features
SPF and Sender ID.
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com