Julian Mehnle wrote:
If "+a" was implied, that would majorly break HELO checking.
-v please, "v=spf1 +a -all" is a typical HELO policy.
Yeah, but what if I didn't want "mehnle.net" to send mail saying
"HELO mehnle.net"?
Then you simply wouldn't do it. Nobody else is in the position
to overrule your decision. Talking about it in a policy doesn't
help you.
If you'd insist on talking about it you could publish op=nohelo -
ignoring that op=nohelo is nowhere implemented, and of course
there is no implicit "+a" at the moment.
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 ? If that's it maybe op=nohelo
isn't a complete waste of time...
...but that scenario would also hit MAIL FROM, in other words
an implicit "+a" isn't a good idea unless it can be disabled by
an explicit "-a", and together that's far too confusing.
Tough, let's forget it. For an implicit "+mx" it's different,
that could still fly.
Implicit semantics (AKA "magic") are usually a bad thing.
Depends, for the 2882-From the implicit "this is the Reply-To
if there is no explicit Reply-To, and it's also the Sender if
there is no explicit Sender AND it's one address" makes sense.
Or I only got used to it. And it gets tricky if the Sender is
not the envelope-sender. Maybe you're right, and this is not
a good counter-example... ;-)
[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 ?
As much as I think that SPF should be easy to comprehend, I
also think that SPF shouldn't be dumbed down to please laymen
at the expense of coherence with common DNS terminology.
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.
Macros should generally stay.
Maybe we can at least restrict this 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.
Frank
-------
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