On 6/19/2020 2:22 PM, Jim Fenton wrote:
That comes back to the question of whether the domain in the From header
is visible in the MUA, and if visible, does it alter user behavior
(e.g., discourage users from clicking phish links). Different people
have different opinions on that. A couple of messages back on this
thread, the blocking of email was discussed and that does not relate to
visibility of the domain in the MUA.
As an "MUA" author/developer, this is a matter on how aggressive the
end-user client software wishes is to be. We have seen this evolved
and increasingly employed over the years. I can them "Scare Tactics
Ponzi Schemes."
o Code Signing: Today, developers are being forced to fork up money to
order to stop scaring users that they are to install "uncertified"
software. While I believe this has good reason for FIRST TIME
installations, I considered it unethical, unfair for established
developers when the software is already installed and user is merely
upgrading.
o Self-signed SSL certs: Today, the browsers, especially Chrome, are
scaring the "manure" of the laymen users with FALSE complex page
display indications that they domain just intended to reach is not
secured. That is false. The target and common name match and it is
not expired. What remains is, once again, the lack of an authorized
3rd party signature requirement. The domain simply did not wish to
pay extortion fees to a CA that has a mechanism for an SSL trusted
chain. Thanks to Let's Encrypt, this is less of an issue today.
So do we consider advising MUA to add or don't add "Scare Tactics?"
I believe the MUA must begin to become proactive with assisting users
with the mails DKIM Policy and Trust-based indicators. I know some
cites have explored this that was before DKIM POLICY took how. How
will it play to today with DMARC. Overall, as a MUA developer, who
does have new MUA projects in the works, the perpetual mantra that "we
did that and it didn't work" and the idea that one size (one protocol)
must fit all and that is must scale, otherwise its useless, doesn't
really apply anymore.
We need to allow systems who are capable of giving the user more
confidence with what their eyeballs are seeing explore the considerations.
My take with all this since the beginning was since we don't know all
the answers on how people will use protocols, we should at least
provide the considered possible options for them to explore using
DMARC Tag Extensions. Here are few that can apply:
Proposed Tag Extensions:
-Rewrite=0|1 if 1, authorize any list system to rewrite 5322.From,
using the a "standardized" approach that helps keep the domains
original security.
-atps=0|1 if 1, the domain supports RFC6541 "DomainKeys Identified
Mail (DKIM) Authorized Third-Party Signatures"
and this one I just came up with to address this MUA display question,
just winging it now:
-MUA.From={logic to offer MUA on what to display}
The MUA can do its own lookup to see domain's desire to what to
display. Maybe the options can be:
-MUA.From=0 No advice (default)
-MUA.From=1 Display the Address with User Name
-MUA.From=2 Display just the address
-MUA.From=3 Only Display address when signer domain differs
Of course, with change comes new opportunity. If the MUA was updated
to support this tag, then we may not need the tag and just advise the
MUA to prominently display the address and/or when we have a 3rd party
resigner involved.
--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
