ISPs will have a hard time attempting to blame third-parties that
conform with RFC 5321 whenever their headers result in recipients
being deceived. Nor should Redmond be allowed to demand compliance
with their proprietary scheme.
It is my experience that recipients of email do not see the individual
results of the myriad tests run against a piece of mail prior to delivery,
per se.
They _do_ see
- Delivery to the inbox
- Delivery of certified email to the inbox with certain visual indicators,
if they use a webmail client (links and graphics enabled, sometimes a
Goodmail sprite in the chrome)
- Delivery to the bulkbox (again, via webmail, or with when using IMAP which
is fairly rare).
- Non-delivery (they don't see mail they expect).
As to what conclusions a recipient arrives at as a result of any of these
states, I leave as an exercise to this august group; I will say it is my
personal expectation that eventually an ISP located somewhere litigious will
be sued for having delivered somebody some malware or a phish, but if the
only test being run on inbound email by said ISP is authentication, they
deserve to be sued, IMO, and they would probably not lose the case anyway.
My apologies for the tangential interruption, but this is getting just a
little silly.
--
Neil Schwartzman
Director, Standards & Security
Sender Score Certified
Return Path Inc.
0142002038
For SSC system status and client support, visit
http://support.senderscorecertified.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html