guy wrote:
I was just about to killall -1 named! :)
Now that's strange, because the concepts were discussed here,
we only need to document it "somewhere".
Scott's HARDPASS has a problem. While it's a valid statement
from the sender's POV, it's irrelevant for receivers. Same
problem as with SOFTFAIL and explanations, they are IMHO
irrelevant for almost all receivers.
Hector's HELO check is relevant for receivers and compatible
with the old draft-mengwong. Reducing it to one statement
as in draft-schlitt is possible, but it doesn't allow senders
to opt-out of this check (IIRC somebody arguing against HELO
wanted this).
With a "helo" property the sender has a choice, and he gets
an explanation why receivers may want this test: To reject
all mails after a forged HELO is efficient.
The "meng" stuff is just what Meng proposed for forwarders, a
local white list + HELO test bypassing the normal SPF tests for
forwarded mail.
William's SUBMITTER is a more elaborated solution for the same
problem, but it's also expensive (= update all affected MTAs),
and we have not yet discussed potential abuses.
Mark explicitly mentioned "forwarders-not-wanting-to-do-SRS"
as "the" important open problem for SPF. That's a fact, I've
heard of at least two admins of universities who do not want
to implement SPF without a better solution for forwarders.
Fortunately they don't confuse "Sender-ID" with a "solution"
of this problem, but they still don't like SPF. So what's
wrong with Hector's and Meng's ideas in your opinion ? Is it
just the p= properties modifier, do you have another idea ?
Greg argued that SUBMITTER can be used to distinguish between
forwarded and submitted mail. His example was pobox.com as
both forwarder and MSA. It's a very theoretical issue, but I
addressed it in the proposed property for trusted forwarders:
| If a forwarder with the "meng" property is also a MSA, then it
| MUST enforce submission rights as sepecified in [RfC 2476].
Finally Williams's idea of an opt-in into 2822 "equivalences"
is simply okay, because he based it on the Return-Path. And
an "anti-phishing" option _is_ important. That's the one
thing SPF doesn't have, but "Sender-ID" _claims_ to have it.
The "Sender-ID" claim is incorrect, so why not add William's
idea to SPF sender policies as an optional modifier ? If you
don't like the properties idea, how about eh=1, or William's
original idea eh=sender,from (or similar) ?
For the p= properties modifier a dot-separated list of names
might be better than my first idea of a comma-separated list.
SPF implementations must be really good with dots as delimiter.
Bye, Frank