william(at)elan.net wrote:
HELO is different identity and needs new scope.
Why ? Some IPs are allowed to send MAIL FROM:<you(_at_)example(_dot_)com>
And you want a special HELO scope only because they might forge
your HELO example.com without it ? Why should they do this ?
I see your point in the "op=meng" forwarder scenario, where the
trusted forwaders are verified by their HELO, and that bypasses
all further SPF tests. That's very critical.
Or if I don't have any machine using EHLO example.com, I also
may want to specifically say that.
Here I don't see it. If they'd forge your HELO, then they'd
also forge your MAIL FROM, and that's the point where you don't
use + if you cannot avoid these ureliabla mailers completely.
This problem could be solved by "for HELO only a PASS counts,
anything else should be rejected". Or when is this not good
enough ?
I had 5 scopes
| m = rfc2821 mail-from (spf classic)
| h = hello
| s = submit
| i = ip ptr
| p = microsoft pra
m and p was clear. For h I'm not yet sure, is it really better
than the simple "either PASS or reject" ? For i we have no
proposal. You didn't like Meng's brain storming idea for it,
and no other proposal exists, or does it ? Why would somebody
interested in i not use MTAMARK, isn't SPF overkill for this.?
And for s I haven't seen any forwarders saying "yes, that's
what we were waiting for while not implementing SRS/SES". s
is a complete working scope almost ready for a RfC, but still
waiting for somebody wanting to implement it.
Sorry, but all that doesn't convince me yet to invent complex
scope rules, where Mark's positional modifiers would already
work, could also solve other problems, are short (characters),
and simple (as soon as the "immediately behind" idea is clear).
Bye, Frank