-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Frank Ellermann wrote:
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"? If "+a" was implicit, there wouldn't be any way to prevent
it.
Implicit semantics (AKA "magic") are usually a bad thing.
The "mx" mechanism is a bit odd because folks on the help list are often
completely confused what it does: The MXs are about receiving mail, not
sending mail. In practice many MXs often also send mail, and then
publishing "mx" can make sense. It's the RMX concept, so far it's fine.
But "mx:else.where.example" can be a dubious idea, it would be better to
use "include:else.where.example" where available, or to enumerate the
sending MTAs by name or by IP. The mx-mechanism can be relatively
expensive. And an implicit MX can't be abused.
But then I couldn't do stuff like:
| $ qspf home.mehnle.net
| "v=spf1 op=auth mx mx:mehnle.net -all"
Yeah, I could use "include:" instead, but only as long as the mehnle.net
policy doesn't authorize other servers not applying to home.mehnle.net.
Maybe I'm looking at it too much from a, well, DNS expert's perspective.
For me, it's all pretty clear, because "foo:" means "look up the FOO-type
record(s) and use the results" (obviously, for "a:", "mx:", and "ptr:"
only, but you get the point). 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.
The macro stuff is also more baroque than KISS.
From writing Mail::SPF I can tell that implementing the macro
stuff was probably less than 10% of the total effort.
Whenever Doug writes "SPF script" I've a crisis, probably I need a better
MUA with a decent killfile.
Yes, you do. Dropping macros just to silence DougO is hopefully out of the
question. ;-) (Besides, he'd still be calling SPF "scripts" as long as it
allows more than one explicit, i.e. definable, directive per policy...)
Macros are IMO the worst part of SPF. If SES didn't exist I'd propose to
kill them in a future "spf3". The "per user policy" feature is a PITA.
SPF policies trying to enforce blacklists with "exists" are in theory a
nice idea. The logging feature is in theory also nice.
But in practice it forces receivers to send useless (from their POV)
queries. Receivers are not interested to help with logging, and they
should pick their own set of DNSBLs, using their own access methods like
rsync, not proposals found in SPF "exists" mechanisms.
I concur that the use of DNSBLs in SPF "exists:" mechanisms is almost
always bogus. However, "exists:" can be used to publish "black box"
policies that cannot be analyzed by the recipient, or DNSWLs (dynamic DNS
_white_ lists), as well as other useful stuff. "exists:" in all its
generality is definitely useful and should therefore stay.
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFFqW0+wL7PKlBZWjsRAhNiAJ47hA1Uum9diO1sZaCvruCu5McqcwCeNebD
R/x36+yQC2JXAu5tyOexiIE=
=/e0y
-----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