* Frank Ellermann:
Florian Weimer wrote:
<http://www.enyo.de/fw/software/exim/spf-update.html>
Thanks, that's very interesting and clear, after I checked
172800 / 3600 = 48.
Ah, that's the curse of looking at DNS data for too long.
I'm not immediately sure that it's the _fastest_ way to update an
indirectly referenced A, but it certainly demonstrates _one_ way and
explains all problems.
All problems *I* know about, of course. I'm not completely sure if
I've discovered all possible side effects.
(As soon as I've got a better example which actually needs the
procedure in all its glory, I'll use it on the web page.)
Your recommendations:
| If a zone publishes records of both SPF (type 99) and TXT
| type, the SPF record overrides the relevant TXT records.
| No longer signal PermError if their contents does not match.
Didn't make it because alleged "DNS gurus" wanted a PermError.
If this is a problem, I can go guru shopping and find someone with
proper credentials who strongly opposes such a requirement.
However, following this list, I certainly got the message that you and
others were in favor of PermError-ing as often as possible, with all
the consequences (e.g.
<42F32E72(_dot_)7EDB(_at_)xyzzy(_dot_)claranet(_dot_)de>).
As far as I'm concerned "use whatever you get first, in doubt
SPF before TXT" is okay.
I don't have very strong feelings about actual semantics. The actual
problem from a reliability POV (read: no improper bounces) is the
misguided consistency check. You can do such checks reliably without
a consistent cut.
| PermError must only be signaled for syntax errors.
Maybe we need two kinds of PermError, plain syntax errors or
a missing include / redirect. Or two kinds of TempError.
Simply moving the "missing include / redirect" problems to
TempError is dubious, because this is not necessarily "only"
a temporary problem.
That's the curse of a distributed system with an optimistic
replication strategy. You have short-term inconsistencies, and
without watching how things develop over time, you can't even make an
educated guess if an inconsistency is just temporary, or is a
permanent configuration error. (See my other messages how this
discrepancy is partly addressed by MTAs and DNS resolvers.)
Your third point indicates that you'd prefer to treat these
issues as TempErrors. Let's say that they need their own
(third) class of error.
I don't think more error codes help. In the end, all I'm interested
in (as a prospective SPF record publisher) is how receivers interpret
my SPF record, in terms of message rejection, queuing, and so on.
More error codes do not help in this context, because in general, they
introduce more room for interpetation by implementators and system
administrators. This means that the policy expressed in the SPF
record is ambiguous.
By the way, I fear that the SPF standardization process has such a
tendency towards ambiguities (even if they undermine the S in SPF) for
two reasons: Unresolved conflict (and some discussions on this reflect
this), and a desire not to make deployed implementations
non-conforming.
Especially the latter part troubles me because this means that most of
the discussion about defects in the spec becomes pointless.
| Consider abolishing SoftFail.
We did. I bothered Wayne with it until he invented a real
story (= greylisting) how "SoftFail" could be useful. It's
a historical oddity.
I will come back to this point when I have more data on actual
SoftFail usage. My opinion on this matter is probably too
controversial, and I would like to have some evidence backing it.
Typo in your memo: s/two/too/ (5th two). Bye, Frank
Thanks, fixed.