wayne wrote:
I have lost most of my motivation to participate in the
SPF project and have not really reviewed these drafts.
That's sad. I prefer to blame the IETF for this.
in the record "v=spf1 a k$", if the "a" mechanism passes,
the invalid mechanism "k$" is never detected.
k$ _is_ a syntax error, because there's no $ in a "name",
and therefore implementations MAY throw a PermError (4.6).
2) Unknown mechanisms are a bad idea and are never used
Unrecognized mechanisms throw a PermError (7.1), that's an
excellent reason to never use any unrecognized mechanisms.
The language in the draft is very careful about this issue,
a future version will most probably use a new tag like spf2.0
or v=spf2 for sender policies with new mechanisms.
If you have implemented a solution, where "foo" is handled
like "k$", then you're technically violating 7.1. But in
practice nobody plans to introduce new mechanisms in v=spf1,
so that's only a theoretical problem.
Let's solve it when it's really necessary (SPF2), it's only
a minor issue.
Unknown mechanisms are not an effective method of extending
the SPFv1 semantics.
Yes, that's an obvious consequence of 7.1.
things like "prt:" instead of "ptr:" or "ipv4" instead of
"ip4".
Come on, you know the reason for 7.1, it's not about adding
nonsense in later versions with the old v=spf1 tag, it's about
left-to-right evaluations. If you say that your code won't
accept mechanisms "foo", "prt", or "ipv4", then what you
really want is a SHOULD instead of the MUST in 7.1. I'd be
happy with this solution.
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.
No idea what you're after here, please elaborate. Or better
propose something for the "security considerations" section.
I'm not too thrilled with mentioning well-known attacks if
you can propose something more specific for SPF.
dos.midwestcs.com,
dos.midwestcs.com text = "v=spf1 mx:a.%{d} mx:b.%{d}
mx:c.%{d} mx:d.%{d} mx:e.%{d} mx:f.%{d} mx:g.%{d} mx:h.%{d}
mx:i.%{d} mx:j.%{d} -all"
Resulting in 10 * 13 MX (?) Tiny little mazes, all similar.
None of these 130 MXs exist, is that the idea ?
domain owners must publish SPF records for ever sub-domain.
Very few domain owners realize this.
IMHO covered by the wildcard discussion, what else could you
say about it ?
The %{h} macro-variable has been removed.
Sure, check_host() doesn't know what it's doing. And "we"
(tinw) wanted to be free to define HELO stuff later in any
appropriate way. There was no consensus to keep it "as is",
and it was only optional.
There is *no* good reason to remove it from the SPFv1 spec
and create an incompatible change.
IBTD. One evaluation of check_host() is good enough for the
purpose of SPF1. You've already mentioned DDoS scenarios,
adding another check_host() for the HELO doesn't help. And
the old optional HELO check wasn't a complete solution for
forwarders, or for the HELO sanity checks proposed by Hector.
As I said at the beginning, all of these things have been
pointed out the the authors and either ignored or rejected.
That's IMHO unfair to Mark. He has integrated a lot of the
proposed improvements, and if you'd say that SHOULD instead
of MUST is better in 7.1, then that's true from my POV.
As soon as there are different opinions Mark is forced to
select what he thinks is the best way. The consensus was to
publish a document reflecting best common practice as far as
possible, with one exception (new DNS RR) proposed by the IAB.
The HELO stuff is too important to "burn" it in a SPF1 memo.
SPF1 is about MAIL FROM. Not about PRA / HELO / SUBMIT / foo.
Let's discuss HELO for SPF2.
I will use my best judgement instead.
That's exactly how it should be done. Bye, Frank