Dave CROCKER wrote:
On 9/13/2010 7:19 AM, MH Michael Hammer (5304) wrote:
If a domain publishing ADSP discardable has not gotten control of their
mailstreams then all I can say is "Darwin was right".
I agree with you completely.
The problem is that customers of a receiving ISP often do /not/ agree with
you.
When their ISP discards mail the customer wanted, the explanation "well, it's
what the author told me to do" typically does not work. And since the
customer's contact is with the receiving ISP, it is the receiving ISP that
must
alter their activity. Since discarding got them in trouble, they will, at
best,
start discarding much more selectively. "Selectively" means using information
beyond ADSP.
Given sufficient selectivity, the mechanism that defines "selective" will
contain enough information to make ADSP redundant.
Dave,
Policy is policy, whether its another form or not, heuristic policy,
classification, reputation or a "selective approach" or what have you,
it is still a sender/receiver "policy" per se.
I don't think anyone wants to delete mail for no good reason, thats no
fun. And that includes mail marked as discardable. For some
implementations, it could just mean a larger negative weight for a
classification policy.
But I think those who believed in strong self-asserting policies, as
in SSH and and SPF will also like to see them in DKIM as well. There
many industry special arrangements where a hard DKIM policy is
desirable before REPUTATION - a requirement I believe, takes place.
The Online Trust Alliance started in its September 2010 "Email
Authentication Adoption Progress Report" [1]
Use of ADSP is recommended for high profile brands at potential
risk of abuse.
The popular MLM Mailman started [2]
To develop standards to assist with email lists as an
alternative to the last option above that provides a neat solution,
there could be a third-party domain signing policies. Some standard
that allows senders to define which third party signatures
receipents
should receive, even if the author domain signature is broken.
SpamAssasin now incorporates logic to "assign" local ADSP policy
overrides for domains that don't have them [3]
The eCert report "Email Sender Authentication Deployment Best
Practices and Considerations" is riddled with recommendations for
strong DKIM Polices [4], even though the 2009 report recognize ADSP is
still work in progress.
The inertia is growing and systems large to small, from all segments
of the industry want to see how DKIM implementation can help besides
just reputation.
The point is - give people the option to screw up and get their
sender/receiver policy and technology right to allow them the learn
how to disseminate their mail more deterministically than what
Reputation currently provides.
One small point. On our system, the stats show a high phishing of our
local domain or hosted domain accounts (MAIL FROM:
phished-name(_at_)hosteddomain(_dot_)com). They are all 100% immediately
rejected simply because the names don't exist.
Some systems will not have a SMTP LEVEL Mail From check (for
scalability reasons or just not capable, not integrated) and if the
mail was allowed to be accepted, only will a DKIM+POLICY provide a
100% equivalent protection. Without policy, many of these exclusive
messages would be passed to the user putting them at risk.
Note there is an operational reason for validating the MAIL FROM. I am
not speaking of CBV (Call back Verifier), but local account
verification. If not checked, a bounce can to a non-existing account.
So we check the return path if its locally hosted domain.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
[1]
https://otalliance.org/resources/authentication/Q3_2010%20Email%20AuthenticationSup9-14.pdf
[2] http://wiki.list.org/display/DEV/DKIM
[3]
http://mail-archives.apache.org/mod_mbox/spamassassin-dev/200903.mbox/%3Cbug-6087-26(_at_)https(_dot_)issues(_dot_)apache(_dot_)org/SpamAssassin/%3E
[4]
http://www.bitsinfo.org/downloads/Publications%20Page/BITSSenderAuthenticationDeploymentFINALJun09.pdf
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html