On Jun 6, 2007, at 7:24 AM, <Bill(_dot_)Oxley(_at_)cox(_dot_)com> <Bill(_dot_)Oxley(_at_)cox(_dot_)com>
wrote:
(1) Some messages from this entity are not signed;
the message SHOULD be presumed to be legitimate in the absence
of a valid signature. This is the default policy.
2) All messages from this entity are signed; all messages from
this entity SHOULD have a valid signature, either directly on
behalf of the originator or on behalf of a third
arty (e.g., a mailing list or an outsourcing house) handling the
message.
(3) All valid messages from this entity are signed, and SHOULD
have a valid signature from this entity. Third-party signatures
SHOULD not be accepted.
4) Signing policy for this domain is expressed at the individual
address level. A second Sender Signing Policy Check should be
performed specifying the individual address
(5) This Domain does not send messages/This domain only signs
third party messages
(6) yer sister resembles a goat
Policy assertion 5 and 6 harm no one, please some and voting is
something you do repeatedly to get the result you want. Some here
assert
that policy assertion 5 can be done elsewhere. I was under the
assumption that SSP sender's signing policy was to be complete. If I
cannot assert that I sign but never send, the SSP is not complete.
Thanks,
Agreed.
Obtaining comprehensive DKIM policy to efficiently establish DKIM's
disposition of a message should not _require_ processing sets of
disjointed records.
That necessary to obtain an optimal DKIM handling process _should_ be
included within DKIM policy. An iterative process of selecting
policy items in abstract does not provide clarity in regard to the
overall process. Reviewing the overall process appears to be what is
_desperately_ needed.
To that end:
Obsoleting the A record discovery process will establish one location
for _any_ email related policy record, and not just that for DKIM.
Rather than allowing email to create large volumes of unnecessary
queries (spam is often responsible for >90% of this), email should
drop a now very problematic option causing dangerous domain
transversals or excessive use of wildcards. This simplification
represents a significant reduction in DDoS related risks and gives
email a fighting chance.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html