-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Frank Ellermann wrote:
Julian Mehnle wrote:
If "+a" was implicit, there wouldn't be any way to prevent it.
It's your domain. It's your IP (if it has an IP). Nobody but you can
get a HELO PASS for your domain. Are you talking about virtual hosts
with a shared IP ?
Right, for example. Or maybe the host isn't shared, but I'm running PHP on
the web server and therefore I'm not very confident that it won't be
compromised (OK, I'm not running PHP!). Or... etc.
[getting rid of the mx-mechanism]
then I couldn't do stuff like:
| $ qspf home.mehnle.net
| "v=spf1 op=auth mx mx:mehnle.net -all"
Yes, you would then say "v=spf1 op=auth a:io.link-m.de -all".
Probably you have a reason why you don't replace mx:mehnle.net
by a:io.link-m.de. What's it, less maintenance, robustness ?
Semantics, mostly. What that policy says is: "all MXes for the domain send
for home.mehnle.net, and all MXes for mehnle.net also do". So that's what
I like the policy to say as well. It's not essential, though. Just a
preference thing.
Okay, but turning the RMX concept into a default if that helps to get rid
of a hypothetical attack vector is tempting. A new "two rcode=3 and
you're out" processing limit doesn't make SPF simpler, it's an additional
paragraph in a "post-experimental" draft.
True, it doesn't make the spec simpler. But it doesn't affect most of the
legitimate cases, as they're supposed not to get any NXDOMAIN responses
anyway.
Maybe we can at least restrict [macros] somehow in future versions.
The important question is: to what end? What problem could
be solved without having to kill macros entirely?
I want more receivers evaluating SPF and rejecting FAIL. The "SPF
script" crowd apparently doesn't like the baroque features. For some
macros it's documented in the spec. that they're not friendly for caches.
If the caching problems make people weary, then maybe we ought to make the
cacheability status of a given policy more accessible in the SPF(v3)
result so receivers can base their decisions on it (e.g. not to complete
SPF processing and do greylisting instead). I need to think about that
more, however I strongly suspect that many of today's common techniques,
such as running every incoming message through SpamAssassin, are creating
significantly higher DNS traffic than the average "bad" SPF record,
"exists:%{l}.spf.${d}" and all included.
BTW, I think this thread has grown WAY out of proportion (and it should
have been renamed to "SPFv3, January 2007 edition" a long time ago), so
I'm going to let it ebb off now...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFFqY0/wL7PKlBZWjsRAsqSAKCxe2SDPF6CqDnmpcQfhA2M2sYdNQCgqXjd
p+gNtuEDxtU7bn+PG9433FE=
=Bw/X
-----END PGP SIGNATURE-----
-------
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