Frank Ellermann wrote on Saturday, January 13, 2007 3:12 PM -0600:
Seth Goodman wrote:
[implicit "+mx +a"]
For that matter, you could imply ip4: as well.
No, IPs don't have SPF policies.
I must have been unclear as to what I meant.
"v=spf1 ip4:192.168.0.1 ip4:192.168.0.3 ip4:192.168.0.5 -all"
"v=spf1 192.168.0.1 192.168.0.3 192.168.0.5 -all"
This would be difficult to misinterpret. Along the same lines, I liked
previous suggestions for contiguous ranges that do not align with bit
masks (192.168.0.5:192.168.0.9 or 192.168.0.5:192.168.0.9 or
192.168.0.5-9). Like most syntax, it's personal preference.
when presented with the SPF record, you don't
know if a name is a host name or domain name
Most domains relevant for SPF are also hosts.
Pure mail domains (with an MX but no IP) are
rare, and for an implicit "+mx +a" strategy
negative results (no IP or no MX) are cached.
I don't agree that domains commonly use the bare domain name as a
hostname. Many domains use mail.example.com for their MX with no host
named example.com specifically to avoid confusion.
this burns up queries from your quota.
Yes, but "v=spf1 +a/24 +mx/24 ?all" used to be
a "best guess policy", it's not too bad: MTAs
trying "call back verification" (CBV) query the
MX (or the IP if there's no MX) anyway.
It's bad if it's not what you intended, and that's why best guess
shouldn't be implicit in the standard. It's very important that things
work as they appear and not have surprising side effects.
Explicitly stating whether it is a hostname or
domain name saves DNS queries, so implying
"a" and "MX" may not be a win.
JFTR, an SPF policy for fqdn.example without "+a"
can be still a host fqdn.example, and it can run
a smtpd. And a policy for fqdn.example without
"+mx" doesn't imply that fqdn.example is a host.
That's not directly related.
My definition of "host" is "LDH + IP", does that
match your definition ?
That's an A record that refers to a host. Here's how I use those terms
for forward DNS:
host: machine on a network
IP: host address
hostname: alias for IP
domain: node in the DNS tree
An alias can be a hostname, a domain, both or neither (CNAME). Let's
say we did permit the use of aliases in the SPF record with no
mechanism, i.e.
"v=spf1 example.com -all"
Does this mean IP's listed in all A records or all MX records of
example.com? They're not the same, and if you can't tell by looking at
the SPF record, we've created confusion. A domain can also delegate an
MX to another domain, in which case the A record for that host is not in
this zone and matching on any A record wouldn't find it. It looks like
there would be both confusion and unintended consequences if you made a:
and mx: implicit.
Per-user policies aren't necessary,
Agreed, but ... there's no per-user macro, you
get it by combining others.
%l (local part) is needed for "per user policy",
the implementors will have some fun when they'll
try to integrate UTF8SMTP into their programs ;->
So the question is whether %l is needed. Apart from per-user policy, it
can also be used (also with exists) to track the complete return-paths
recipients are seeing. I also would have preferred fewer macros. Now
that they're in place, there's little benefit in deprecating them as
checkhost() would still have to support them. Overall, it's still
pretty simple, so I'm not unhappy.
the "exists" mechanism is too general.
-1 unless you can show that making it less
general makes it simpler.
*_IFF_* that's possible at all it should somehow
combine %l and "exists" into what's required for
SES. An "ses" mechanism replacing "exists" (?)
Since %l is only used with exists, combining them makes at least some
sense. To make it worthwhile, the end result would have to be simpler
or easier to understand than the current exists mechanism.
The exists mechanism allow you to cause a DNS query that does SES, which
is fine if you implement a validation server that speaks DNS. The only
facility missing is one that would cause exists to generate a SMTP CBV
to an address alias (use mx for any domain mx), rather than a DNS query
to your nameserver. Such a modifier might be query=smtp:mx or
qtype=smtp:mx. This would also provide an alternate way to implement
per-user policy and return-path tracking by using your MTA rather than
your DNS.
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.
op= is for anything "yes/no" "0/1" "true/false", the
least verbose way to arrange such "properties" like
"testing". Of course "options=" or "flags=" or a
similar name introducing such lists would be more
obvious, but also longer. The op= is a shorthand
for optional.properties=. I don't see an advantage
for "testing=true helo=never" in comparison with a
combined list "op=testing.nohelo". op= is shorter,
admittedly it's not nicer.
Let's not create another PERL.
It's about the UDP limit, not about inventing crude
abbreviations. Would you really insist on 5 bytes
more as in "options=" ? That could be the 5 bytes
needed for " -all" at the end.
Thanks for the explanation. I mistakenly thought that "op" stood for
"operation". It makes much more sense if it means "options" :) I don't
know if any others had trouble with it, but if so, maybe "opt" would be
better. If it only occurs once in a record, then "options" is not so
bad.
As for replacing softfail (and perhaps neutral) using a modifier, it
would be a lot cleaner, but the whole thing needs more thought. The
problem with softfail, aside from it complicating the results, is that
the sender is not notified unless the recipient rejects the message.
That's not what you want for testing. Rather, you want recipients to
inform the sender of an SPF failure, but not to use that result to
reject messages. A modifier that declares testing mode doesn't fix that
problem.
The question is how to cause the recipient to notify the sender on
particular results? SPF records were not meant to do this. They
evaluate mechanisms from left to right until one matches. The default
is the last mechanism, which we often think of as the only place where
something fails, but that's not necessarily true. As long as the only
mechanism designating fail or softfail is "all", you could replace -all
or ~all with an exists mechanism to create a failure log. Your DNS
server doesn't have to return anything, because if no mechanism in the
record matches, the result is neutral. When you're ready to move out of
testing, just replace the exists with the appropriate flavor of "all".
This is very good for testing, but it requires some DNS moxie to set up
and using macros is daunting to new SPF users. An example of this
approach is:
"v=spf1 mx exists:%{i}._spf_fail.%{d}"
If you use "-" or "~" on any mechanisms before "all", you can no longer
use exists to log failures because a match terminates evaluation. In
that case, you'd need a modifier to change the way that fail or softfail
results were handled, specifically to cause notification of the sender.
This would be a significant change and it's messy. One possibility
would be to create a new modifier that causes a DNS query on a
particular result:
fail=dns:%{i}._fail.%{d}
This modifier would cause any mechanism that produced a fail result to
perform a DNS query and then change the result to neutral. There could
be similar modifiers for all other results to make more general testing
possible.
I don't particularly like this, but it's one way to do it.
--
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