Julian Mehnle wrote:
If "+a" was implied, that would majorly break HELO checking.
-v please, "v=spf1 +a -all" is a typical HELO policy.
if there's no explicit "mx" mechanism anymore Doug's weirder
SPF-DDoS scenarios simply vanish.
There are better ways to void DougO's DDoS attack vector, such
as limiting the number of mechanism lookups that are allowed
to fail (return an empty response or NXDOMAIN) to, say, 2.
I'm not sure about "better", but it's certainly one possible
solution. Of course that's all theoretical at the moment.
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.
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. 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.
Macros should generally stay.
Maybe we can at least restrict this somehow in future versions.
exp= is unnecessary,
No, I think it is a very nice feature. For example, if you have
it reveal a URL, the web page pointed to can be localized.
Yes, but FAIL explanations are again something receivers aren't
necessarily interested to help with. I'd like to offer localized
versions of why.html. Okay, maybe a future IETF PS can sell the
exp= modifier under its "I18N considerations".
I'd even like it to become more general and apply to non-Fail
results as well.
exp= will be already tricky with UTF8SMTP, don't make it worse.
the "exists" mechanism is too general.
I don't get that one.
See above, e.g. picking DNSBLs isn't the business of the sender.
We have too many "v=spf1 ... ~all" policies out there that will
probably never be changed to "-all" due to a lack of understanding
what SoftFail is supposed to mean.
+1
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