In <NGBBLEIJOEEEBMEIAPBKOEPIIBAA(_dot_)scott(_at_)kitterman(_dot_)com> Scott
Kitterman <spf2(_at_)kitterman(_dot_)com> writes:
The overall problem on this (and similarly) outstanding item(s),
as far as
I see it, is the difficulty that the decision to make something a
PermError is always closely related to what should happen on PermError.
Which is to say, declaring a PermError cannot be seen apart from what is
to follow that result; and, conversely, what is declared to follow a
PermError, inevitably affects what we wish to call a PermError. For
example, if we were to ignore PermErrors, then declaring something a
PermError has an entirely different consequence than saying, for
instance,
that a PermError should be met with 5.x.x codes.
I agree with Mark's assessment here.
if the spec starts saying i MUST generate a 554 for a Fail result and, say
for some legal reason, i can't reject any message then i can't use SPF
because all the coders will have followed the spec. Never forget, it's my
mta, my rules.
I also agree with Raymond's assessment.
On the other side of the coin, SPF record publishers (senders) need to have
some expectation of how publishing an SPF record will affect their mail. I
agree the spec shouldn't handcuff the receiver with excessive use of MUST,
but if the sender gets chaotic results from using certain mechanisms, then
they won't use those and may well have to abandon SPF publishing.
There is a balance in here between the sender having certainty with what
will happen with their mail due to SPF and the receiver having complete
freedom to do with SPF as they will.
And finally, I agree with Scott's assessment.
Unfortunately, that doesn't mean we are all on agreement about what
should be in the spec. Actually, I think that was what Mark was
pointing out.
Currently the spec does not have much Receiver Policy. It is my
reading of the situation that as time goes on, we (the SPF community)
have continually removed more Receiver Policy out of the spec and have
started make a sharp distinction between Sender Policy and Receiver
Policy.
Now, if you look at the current spec, there is some Receiver Policy
in things like the definition of "SoftFail":
2.5.5. SoftFail
A "SoftFail" result should be treated as somewhere between a "Fail"
and a "Neutral". The domain believes the host isn't authorized but
isn't willing to make that strong of a statement. Receiving software
SHOULD NOT reject the message based solely on this result, but MAY
subject the message to closer scrutiny.
Since the domain has discouraged the use of this host, receivers MAY
try to inform either the sender or the recipient of the e-mail. For
example, the recipient's MUA could highlight the "SoftFail" status,
or the MTA could give the sender a message using a technique called
"greylisting" whereby the MTA can issue an SMTP reply code of 451
(4.3.0 DSN code) with a note the first time the message is received,
but accept it the second time.
There has been some discussion that the second paragraph (and similar
cases) should be removed because it is Receiver Policy. In the last
council meeting I argued against removing this kind of thing, but
don't think I was very clear on the issue.
The reason why I don't think we should remove the second paragraph is
it defines part of what it means to have a "SoftFail". This is
basically Scott's point. Now where does it say "MUST", so Raymond
shouldn't object too much, but it is still Receiver Policy.
One thing I think we could do is rephrase the second paragraph from
"Receiver Policy" into "Sender Policy", such as:
The domain owner wants to discourage the use of this host and so
they desire feedback to when a "SoftFail" result occurs. For
example, the recipient's MUA could highlight the "SoftFail" status,
or the receiving MTA could give the sender a message using a
technique called "greylisting" whereby the MTA can issue an SMTP
reply code of 451 (4.3.0 DSN code) with a note the first time the
message is received, but accept it the second time.
Would this kind of rephrasing of the intended semantics into "Sender
Policy" language useful? Are there better ways to rephrase it?
-wayne