Part of it describes the way that senders publish statements about
their sending practices and the way that receivers can look for those
statements, which is fine, but the rest attempts to tell receivers
what to do with mail they have received, which is not.
For the 1000th time this is simply not true. Repeatedly stating SSP
"dicates receiver behavior", "tells receivers what to do", etc doesn't
make it true.
I found two statements that advise receivers. They state:
"The handling of such messages is at the discretion of the Verifier or
final recipient." (Suspicious definition)
"Messages which are Suspicious from this domain MAY be rejected,
bounced, or otherwise not delivered at the option of the verifier."
(deny)
Here is the text from SSP that defines this guidance to receivers:
2.9. Suspicious
Messages that do not contain a valid Originator Signature and which
are inconsistent with a Sender Signing Practices check (e.g., are
received without a Valid Signature and the sender's signing practices
indicate all messages from the domain are signed) are referred to as
"Suspicious". The handling of such messages is at the discretion of
the Verifier or final recipient. "Suspicious" applies only to the
DKIM evaluation of the message; a Verifier may decide the message
should be accepted on the basis of other information beyond the scope
of this document. Conversely, messages not deemed Suspicious may be
rejected for other reasons.
[There are other mentions of when to declare a message Suspicious but I
reference the instructions to the receiver found here in the
definition.]
4.3 Record Syntax
...
deny Messages which are Suspicious from this domain MAY be
rejected, bounced, or otherwise not delivered at the option of
the verifier.
NON-NORMATIVE EXPLANATION: The "deny" practice is intended
for use by domains that value security over deliverability.
For example, a domain used by a financial institution to
send transactional email, which signs all of its messages,
might consider their concern about phishing messages
purporting to come from their domain to be higher than their
concern about some some legitimate messages not being
delivered. The "handling=deny" practice allows them to
express that concern in a way that can be acted upon by
verifiers, if they so choose.
It really needs to back up and define how a sender publishes its
policy, how a recipient can look up a policy if it wants to do so,
then stop. That's all they need to interoperate.
Many disagree. How about we let people publish their strict/deny
preferences and those who wish to look up a policy and do nothing else
to interoperate simply ignore strict/deny as allowed by SSP?
pat
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html