On 6/24/2020 10:07 AM, Dave Crocker wrote:
On 6/24/2020 7:04 AM, Jesse Thompson wrote:
Wouldn't MUAs need to consistently display Sender?
They don't consistently display From:
More importantly, MUAs are essentially -- or completely -- irrelevant
to the use of DMARC now. I don't see why that should change.
Again: end-user recipient decision-making is irrelevant to meaningful
email abuse handling.
As a MUA developer, I am not sure this applies as much as it did in
the past. Namely because of the different types of MUA which
predominately fall into three category:
1) Store and forward, offline capable MUAs where all the possible
"decision" data is pushed to the MUA in the RFC822/2822/5322 format.
It uses POP3 for pickup and SMTP for sending. The presumption here was
that the backend has filtered the mail as much as it could for the
user with using both system-wide and per-user-account policies.
Generally, when the user picks up mail with POP3, this stream did not
include the Spam Box.
2) The Online MUA which doesn't get the possible decision data because
the UI is rendered by the backend. The Reader is dumb. If it was text
based, it might ANSI/VT100 to place fields on the screens. It could be
a web-based interface, etc, overall, offline reader has no control
over what is displayed.
3) The Hybrid, that combines elements both 1 and 2. Exchange did this,
IMAP does this.
The MUA 1 and 3 could do its own display but not MUA 2. The MUA 1 and
3 could do more with email abuse handling that was missing or not done
by the backend when it passed the data to the MUA.
Unfortunately, we can't do anything legacy systems that were abandoned
and not possible to upgrade. But with MUA 1 and 3 types still
supported, what we need is technical guidance. If we keep suggesting
that this will never work, them of course, it will continue to be an
unknown of whats possible.
Yes, it is common for us to believe the backend should be
"responsible" to do the dirty filtering work. But what if they are not
doing all the dirty work? all that is possible, for whatever reason,
like the backend doesn't believe in ATPS? There is absolutely no
reason why an modern, advanced MUA could not explore ATPS to fill that
need.
One simple display tibit:
["Message signed with an Authorized domain"].Color = green.
["Message signed with an Unauthorized domain"].Color = red.
Sure, people will suggest, the user will not read this. Would that be
all or some users? Maybe the MUA developers performs an UI ergonomic
survey behind one way mirrors or employed Telemetry to learn how users
react. Maybe they will learn simple colorization is not working well
and instead they find a Modal Popup window is getting the user's
attention:
----------------WARNING!-------------------[X]-
| Message signed with an Unauthorized domain |
| [Continue Reading] [Move to junk box] |
-----------------------------------------------
Sure, maybe the user doesn't want to be bothered with this, so he
turned it off in the MUA's DKIM/DMARC options under the View |
Preference section.
[X] Display Unauthorized DKIM signer warnings
With 40 years with no MUA guidance, of course, it will continue to be
a status quo of no progress.
--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
