On 7/15/2014 8:12 AM, ned+ietf@xxxxxxxxxxxxxxxxx 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. 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. 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. > 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. d/ -- -- Dave Crocker Brandenburg InternetWorking bbiw.net