Michael Deutschmann wrote:
On Fri, 22 Apr 2011, Hector Santos wrote:
However, I suspect you're getting at the fact that, if it had to be
written today, such a certification standard would be hamstrung by the
fact that ADSP sucks.
Almost... see below.
All it could do is make dkim=discardable *binding*. Since a bank that
wants the freedom to have their employees speak ex-cathedra on ordinary
mailing lists cannot use discardable, they would not be able to take
advantage of the phishing protection.
Its hard for me to imagine a bank's company DKIM email policy for
employees will be not different than a Bank's vendor/user DKIM TOS
(Terms of Service) requirement agreement. So a bank who might begin
to be concern about securing new vendor/user eBank communications (for
PCI reasons) will probably begin to use different domains.
Obviously then, writing an improved ADSP-alike protocol is higher
priority than writing the certification standard.
Overall, I believe it all falls under some form of policy whether its
an author domain policy or signer domain policy, even trust,
certification or reputation policies.
So even when bank has a DKIM TOS requirement for bank/users
transactions, the user host domain will need to be aware of the bank's
DKIM TOS policy whether its ADSP-like and/or TRUST (rfc4871bis) based.
There has to be some form of prior end to end knowledge.
I can provide a perfect real life example of how email or user access
evolved altering many features in a mail hosting system.
There are two forms of MUAs; online and offline.
Most systems started with online only and they came with strong
message controls, for example, Message marked Read/Received and the
ability to snoop or preview a message was a privilege feature for
operators.
When offline MUAs became more important, now you had the roaming user
design problems where the user working from home or work needed the
ability to pick up mail from both machines and that required a "snoop"
idea - not marking the mail received. If the mail was marked received
when he popped in from work, he would not be able to download the same
mail from home.
Offering that feature for the growing offline MUAs became a problem
for subscription services because now the hosting operators lost the
ability to trace important mail receptions, such as Expiration
Warnings, Service Notifications, etc. Out of the box, our system has
a 30, 15, 7 day Expiration Warning with billing details and if the
user was able to "snoop" at these messages, they can claim they never
got the warning.
So new tracking methods were needed to offers users to ability to
preview mail, yet track reception needs for the backend.
For technology that attempts to time-shifted offline communications,
the goal is to offer the same online access/security profiling
requirements in an offline fashion.
How this applies to DKIM?
For the bank or anyone for that matter, if they only focus on online
activity, the offline MUA needs are less important. Mail is not
accessible for POP3, NNTP. You have to go online. If it offered an
IMAP or some Exchange Proxy (Outlook Exchange for Microsoft, Wildcat!
Exchange for us), they begin to offer the same Online Experience in an
offline fashion.
But when it comes to email via store and forward, like POP3 and SMTP,
that offline emulation of online requirements become much harder. For
DKIM, the pressure is higher to make sure the backend (MSA, MDA) to do
the security filtering and if you do this in a single source manner,
then you satisfy both online and offline needs. This is a good
example where Authentication-Results header is only fully trusted at
the backend only.
However, if we are trying to push these controls to the Offline MUA,
without having control of the MUA products designs, its becomes much
harder.
I can see that problem very clearly with my AT&T "Your Online Billing
is Available" email notifications. They have promoting increasingly
users to go online and for those popping in, they send these monthly
unsigned emails with html links. I don't trust them so I ignore them.
But every month I do view the message source to see if there are any
DKIM signatures. I believe there was a period there was some DKIM
signature, but it stopped. Looking at these headers with the body
content, you can clearly see, whether it was by design or the symptom
of young engineers only dealing with html and online access, the
intent is online access to secure the communication with the users
which would not added to their spam box.
I think a piece of the problems in the WG is that are trying to design
for RFC-based MUAs in mixed ways, when in practice, the direction is
going back to online access (i.e. smaller mobile devices now taken for
granted in this new generation).
You also have new centralization and cloud designs with Apple, Google
and Windows the principles in these proprietary networks and there is
a movement for an trusted identity egosystem (see NSTIC - National
Strategic for Trust in CyberSpace). This might even help DKIM with
certification, but I still see it needing to reconsidered author
identities again :)
So my view has always been that you need to secure online first, then
try to emulate the offline RFC rendering as much as possible without
compromising on the security.
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html