Re: not really to do with Re: WG Review: Domain-based Message Authentication, Reporting & Conformance (dmarc)

[[e-mail]]

> On 7/15/2014 8:12 AM, [e-mail] wrote:
> >> On Tue, Jul 15, 2014 at 09:06:55AM +0100, t.p. wrote:
> >>>> MUAs should expose message origin when different from author.
> ...
> >>> A fine idea, but, as a pragmatic engineer, I know that changes to an MUA
> >>> will take five, may be ten, years to achieve widespread deployment,
> >>> whereas changes to MTA could happen in a matter of weeks, if needs must.
> ...
> >> The expedient approach has not worked, it should have been done right
> >> long ago, and should still be done right in the present.
> >
> > You know, I'm finding it difficult to argue with this.

> I'm not.

> 1. For one thing, I don't know what the reference to 'expedient
> approach' means.  Mostly this thread seems to be making very generic,
> simple assumptions and assertions about problems and remedies.  Without
> specific details on what problem is to be solved, what use cases it will
> satisfy, and why we should believe they will work, the thread is not
> likely to be constructive.

It should go without saying that the context here isn't what's been said on
this specific thread, but rather all of the past exchanges here and on any
number of other lists leading up to this point. Among other things this
includes the posting of several drafts offering concrete proposals.

Both the problem and solution space have been explored in some depth, albeit
rather haphazardly. And while it may be the case that a novel solution will
emerge that blows everything else away, since I've seen that happen exactly
twice in the past 25 years, I'm not betting the farm on it happening here.

> 2. References to changes in MUA appear to be pointing to assumptions
> about efficacy of what is displayed to users.  Such assumptions are
> empirically incorrect, and mostly serve to demonstrate why the IETF is
> the wrong place for discussion about UI/UX/UCD and human usability
> issues.  Really, the disconnect between that one assumption and what is
> actually known about email user behavior is fundamental.

I've been letting this set of assertions float by unchallenged for a long time,
in part because the effort needed to change dogmatic beliefs is considerable,
and in part because like most dogma, there's a kernel of truth buried inside.

This seems like as good a time as any to stop doing that. So: This is little
more than pernicious nonsense.

First, this is essentially a strawman. We're not talking about dictating UI
design here. What we're talking about are the semantics and general handling
requirements for some of the most basic protocol elements in email.

Nobody is saying that we should start specifying what has to be diplayed to
users, let alone how. But saying something like, "From tells you who wrote the
message, sender tells you who sent it if that's someone different, and here are
the various problems that can occur if you fail to take that into account ..."
strikes me as entirely reasonable to say.

For heaven's sake, we have as a process _requirement_ that we provide
security considerations for the stuff we standardize. On what planet does
the failure to make the security semantics and consequences of mishandling
them make sense?

There's also running code in this area: RFC 2049 specifies user agent handling
requirements for MIME conformance. To the extent these have been followed - 
and I admit there's an issue with our ability to affect change in this regard -
I know of no deleterious effects this has had. Nor can I recall any serious
criticisms having been leveled at the document.

Indeed, in hindsight, we didn't go far enough in specifying what conformant
handling of MIME should be, and we've paid the price for that in a variety of
ways.

Finally, there's also a issue with the continued assertion - which AFAIK is
backed up with not one scintilla of evidence - of the total lack of IETF
expertise in UI design. But since that's not relevant here, I'll leave that for
another exchange.

> 3.  Nonetheless, the language in the draft charter provides for the
> possibility of making incompatible changes to DMARC.  However it
> requires /very/ careful documentation of the basis.  See #1, above.

True, but beside the point. The point, at least from my perspective, is the one
I made before: At a minimum any scheme that's produced needs to be compared
against the prospect of a proposal built around embracing the full semantics of
the relevant fields.

> > I've long been a supporter of using From/Sender semantics, but I've also bought
> > into the assumption that current client behavior made use of these semantics
> > problematic.

> Cleaning up From:/Sender: semantics and usage is a worthy goal, as is
> generally developing a much cleaner model of identifying and
> authenticating the various actors involved with a message.

> But it's not likely to have much to do with DMARC, anytime soon.

I've yet to see any evidence that anything being proposed will have any effect
on DMARC in the short term. I've heard a bunch of assertions that if the need
arose MTA changes can be rolled out quickly. I have 25+ years of experience
doing this stuff that says otherwise.

				Ned