-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Wayne Schlitt wrote:
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.
Which I am very happy about.
Now, if you look at the current spec, there is some Receiver Policy
in things like the definition of "SoftFail":
2.5.5. SoftFail
[...]
[...]
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". [...]
Exactly. We must precisely define the meaning of the result codes, but we
should not try to dictate receivers' reactions.
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.
s/feedback to/feedback to the sender/, and I'm gonna like it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
iD8DBQFCj1ctwL7PKlBZWjsRAiUqAKChJNNQc60cBOclTcH/Az9Ci29YbACfYIDF
QskHX+boMZSwkR03pjclCY0=
=VJTg
-----END PGP SIGNATURE-----