On Mon, 18 Oct 2010 20:18:16 +0100, Murray S. Kucherawy
<msk(_at_)cloudmark(_dot_)com> wrote:
This is no more presumptuous than expecting that MUAs will adapt to
consume the output of DKIM as it stands now.
In another message I indicated that I don't presume either, but assert
that there's no middle ground; they will or they won't. If they will,
informative text is sufficient; if they won't, then we have to start
hardening MTAs to defend against MUA attacks because that's where header
changes and other enforcements are possible since, by definition, any
current annotations are invisible and will stay that way.
I'm fine with accepting either model, but we have to understand the
implications of picking one. The latter, in particular, involves some
major scope creep.
No it doesn't. I believe they "won't" (at least not on any short enough
timescale). But we are already in the "hardening" business, because the
basic assumption made by DKIM was that the verification (and resulting
action) could and would be done at the boundary layer as part of, or
closely associated with, the final MTA, and without any change to existing
MUAs.
What options for 'action' are available at that point (or were envisaged
as being available at that point when DKIM was first written)? I can think
of
discarding (silently or noisily)
increased spamassassin score
warning to the end user (e.g. in a changed Subject header)
So all we need is to ensure that those same actions will be activated by
this new threat; in which case the language to bring this about needs to
be just as normative as in the rest of the DKIM specification.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html