On Jul 14, 2013, at 2:38 AM, Michael Deutschmann
<michael(_at_)talamasca(_dot_)ocis(_dot_)net> wrote:
"EDSP" would be tier 1 both senderside and receiverside. That's its
selling point.
The "dkim=except-mlist" ADSP enhancement I suggested back in 2011 would
be tier 2 receiverside and just-slightly-below tier 1 senderside. It
would not be obsoleted by "EDSP" or SPF, because when it can be
deployed, it can stop some messages where From: is forged but MAIL FROM
isn't. Although slightly less than ADSP or DMARC in the rare case that
those are deployable senderside.
TPA ADSP enhancements are tier 1 receiverside and just-barely-above tier
3 senderside. They could be as powerful as except-mlist in terms of
false-negative rate where deployed at both ends, but require much more
elaborate setup work at the sender.
Dear Michael,
Envelope-DKIM-Signing Policy?
Isn't this the DMARC policy assertion which includes SPF results as a fallback?
Regardless of policy, DKIM signatures MUST BE ignored when the message includes
invalidly prefixed header fields.
As such, invalidly prefixed header fields MUST BE checked during DKIM signature
evaluations.
It seems doubtful that any large provider will reject messages due to SPF fail.
RFC6541ATPS attempted to adopt concepts found in:
http://tools.ietf.org/html/draft-otis-dkim-tpa-label-06
IMHO, RFC6541flaws will ensure it is never adopted--
1) Requires a special DKIM signature (should depend on the policy scheme
instead)
2) Allows optional per-domain label construction (not manageable by a
community)
3) Omitted authentication methods by assuming DKIM (not easily extensible)
Since sender side policy primarily benefits senders, it should be senders doing
the work. After all, senders should track which third-party services their
users are sending messages. The senders' work can become a community effort,
since the tpa-label specification allowed redirection to various conforming
zones selected by senders.
Why require receivers to guess which third-party services are being used?
How would any such guessing scheme be either fair or safe?
Any policy that lacks the TPA label scheme can never be suitable as an
extension for many of the social services that use email to bridge between the
various groups for extending invitations. Without an invalidly prefixed header
check result added to the Authentication-Results header field, dkim=pass can
not be safely used since rarely will a DKIM domain double list singleton header
fields.
I made an effort to standardize use of an opaque tag added to the DKIM
signature to facilitate abuse reporting. It is absurd to expect large
providers will review timestamps and logs to ascertain problem sources. Lack
of standardization due to an unfounded fear this reduces user privacy simply
misunderstood what is meant by the term opaque. What we have now is definitely
not better at preventing abuse or protecting privacy.
Regards,
Douglas Otis
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html