Frank Ellermann <mailto:nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote on
Friday,
January 12, 2007 9:59 AM -0600:
wayne wrote:
doubt will be an obstacle. This thread is full of FUD.
I have to concur.
Yeah, I strongly agree also.
I don't. We've already seen cases where the v=spf1 record was fine,
but in combination with other records the TXT RR set was too big.
While I'm sure this is true, it's more of theoretical than practical
interest. Considering the corner cases is required, but if you fall
into the trap of giving them equal weight, any protocol will become
complicated enough to limit its primary utility. The argument that
several major uses of TXT would often cause it overflow are technically
correct, but it is only of real interest when there are indeed several
major uses. This is the first one, and the onus is more on subsequent
protocols. The DNS folks may cry foul, but that describes the current
situation.
Like many other things, it is far easier to ask for forgiveness than
permission. TXT is here, type99 is not. I suggest that it's time to
admit that querying for type99 records today will only increase DNS
traffic without materially increasing the number of fetched records over
just querying TXT. From the domain owners standpoint, sane SPF
recipient implementations need to query TXT, so publishing duplicate
information in type99 is a liability with no real gain.
More important than all the technical arguments, if MS doesn't support
type99 records, domain owners are not going to publish those records, no
matter what we think. I favor FOSS products, but communicating with MS
mail servers is required, and MS does not care what others consider the
best way to do that.
I think a large part of SPF's success over similar protocols like
RMX, DMP, FSV, etc. is the easy of creating SPF records.
Not easy enough. The "+mx" and "+a" could be implied, each policy
automatically has it. MTAs know how to handle MX queries. And if
there's no explicit "mx" mechanism anymore Doug's weirder SPF-DDoS
scenarios simply vanish.
For that matter, you could imply ip4: as well. OTOH, when presented
with the SPF record, you don't know if a name is a host name or domain
name, and this burns up queries from your quota. Explicitly stating
whether it is a hostname or domain name saves DNS queries, so implying
"a" and "MX" may not be a win.
The macro stuff is also more baroque than KISS.
+1
Per-user policies aren't necessary,
Agreed, but ... there's no per-user macro, you get it by combining
others.
exp= is unnecessary,
So are comments in code, but they're very helpful. -1 unless there's an
easy way for a domain owner to supply the same information.
and the "exists" mechanism is too general.
-1 unless you can show that making it less general makes it simpler.
SOFTFAIL could be replaced by op=testing.
While I have always disliked softfail and wouldn't mind expressing
softfail as a mechanism/modifier rather than a result, I have always
found op= to be arcane. I'd support a specific mechanism or modifier
for the purpose, but not a general one like this that encourages more
arcane features. Let's not create another PERL.
Now you have some people promoting type99 SPF records even though
it has no technical advantages.
Of course it has, in theory.
Theoretically, there's no difference between theory and practice.
As soon as some other protocol abuses TXT for its own purposes
- because that's the most simple way around the limitations of an
MS API - there's not enough space. Anybody wanting to use both
protocols would be forced to deal with stuff like "continuation
records" (for SPF redirect=). And "continuaton records" need more
DNS queries.
As do type99 queries. The difference is that you only ask for a
continuation record when you need one, so you get something back.
Making type99 queries may be theoretically pleasing, but all that
traffic will get you next to zero new data, at least today. Type99 is a
much bigger waste of DNS resources than the very infrequent continuation
record. While it would be nice to create a new record type for every
experimental protocol that could make use of one, the chicken-and-egg
problem of lack of support in DNS software will kill the protocol that
relies on a new record. This is fighting someone else's battle, and
it's not our fault things are set up to make "the right way"
impractical. New record types can be added later, and the present usage
of TXT deprecated but still accepted. Not pretty, but realistic.
For SPFv1, I think we shouldn't touch it.
Sure. Julian's last 2*2 table was fine, it favours backwards
compatibility wrt error conditions. In essence it says "use the
TXT result for TempError if you query both SPF and TXT".
+1 from me, but does it conflict with 4408? In addition, put something
on openspf.org to this effect:
"Domains can optionally query and publish type99 records to gain
experience with them. This record type was created for both SPF and SID
to address potential problems with long TXT records in DNS. Supporting
type99 records is not a requirement of either SPF or SID, and it will
likely not become one unless DNS software packages widely support this
record type."
--
Seth Goodman
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735