Re: [dmarc-ietf] Why are MUAs hiding or removing the From address?
Joseph Brennan skrev den 2020-07-23 17:05:
Since it is off topic, I will give a short answer. If the Header From
matches /From: anything , check whether domain is one
that needs the rewrite, gmail.com for example, and change the field to
be simply /From: string@domain/.
ok
In Mimedefang, we created a per-message global hash %Header, and
parsed each field (split on :). So for example $Header{from} was the
value of the From header field. The hash was used in various rules. MD
has a built-in function to replace the content of header fields, which
I think is a milter function.
but it fails to not break dkim then
ietf.org have more ips to spare to make not breaking dkim, sadly so many
experts doing the wrong things :(
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Why are MUAs hiding or removing the From address?
On Thu, Jul 23, 2020 at 9:20 AM Benny Pedersen
wrote:
> show the source on how to make this work in mimedefang, or will it
> completely fail with spampd ?
Since it is off topic, I will give a short answer. If the Header From
matches /From: anything , check whether domain is one
that needs the rewrite, gmail.com for example, and change the field to
be simply /From: string@domain/.
In Mimedefang, we created a per-message global hash %Header, and
parsed each field (split on :). So for example $Header{from} was the
value of the From header field. The hash was used in various rules. MD
has a built-in function to replace the content of header fields, which
I think is a milter function.
--
Joseph Brennan
Lead, Email and Systems Applications
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Why are MUAs hiding or removing the From address?
Joseph Brennan skrev den 2020-07-23 15:15: Briliant! I wish we were still using Mimedefang. This wouldn't be hard to code, and the results would be effective. show the source on how to make this work in mimedefang, or will it completely fail with spampd ? ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Why are MUAs hiding or removing the From address?
On Tue, Jul 21, 2020 at 5:45 PM Jesse Thompson wrote: > > Specifically to address BEC we strip the friendly from (at our MTA gateways > prior to ingestion to O365) conditionally (one example: from domains of free > email providers) to force the MUA (Outlook and everything else) to show the > From address. > > It works because now the victims just see "wisc.edu.provos...@gmail.com" > instead of "Office of the Provost" and are more likely to consider the > message hostile, less likely to click on the weird link, less likely to buy > gift cards, and so on. > Briliant! I wish we were still using Mimedefang. This wouldn't be hard to code, and the results would be effective. -- Joseph Brennan Lead, Email and Systems Applications ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Why are MUAs hiding or removing the From address?
On 7/21/20 6:05 AM, Douglas E. Foster wrote: > I would like a better understanding of why MUAs are hiding or removing the > FROM address. > > I have one mail store that formerly used hover-to-view, but recently changed > to always-show. This was done in response to a client request on their > support forum. I have never seen a user ask for the From address to be > hidden or removed. I wonder if this trend is driven only by attempts to > optimize display space. It would be a shame to weaken our protocols in > response to this trend, if the trend lacks a theoretical foundation. > > I also wonder if the trust indicator research is being over-applied when it > is applied to the From Address. From Address is a unique identifier, while > Friendly Name is not. A trust indicator is like putting a green check mark > next to the From Address as a trust indicator. They have different levels > of relevance. > > One attack method steals a contact list, then emails people in that contact > list using friendly names of others in that list. Hiding the From Address > plays into that attack. > > This trust-indicator research also promotes despair. The conclusion is that > users process information poorly. This result then becomes an excuse to > withhold information from those users, or to allow misleading information to > be presented to them. I am not convinced that those are appropriate > responses. "Never" is a hard thing to prove. So it is risky to say users > "Never" use available information correctly, and "cannot be taught" to do > better. > > Attack filtering is designed on a layered defense and a sequence of > probabilities: > > * What is the probability that this attack will get through my spam filter? > * What is the probability that the user will read the message? > * What is the probability that the user will click on the hostile link? > * What is the probability that my web filter will allow access to the > hostile website? > * What is the probability that the web filter will allow the attack to be > downloaded? > * What is the probability that my antivirus program will allow the attack > to proceed? > > The goal is to decrease the probability of a wrong decision at each point in > the process. All I need is for some people to act smarter on some occasions > in response to some available clue. But this cannot happen if the clue is > not provided.. I like this way of thinking, and it seems like a good time to mention the following anecdote for the sake of the "end-users can't make security decisions" argument... Specifically to address BEC we strip the friendly from (at our MTA gateways prior to ingestion to O365) conditionally (one example: from domains of free email providers) to force the MUA (Outlook and everything else) to show the From address. It works because now the victims just see "wisc.edu.provos...@gmail.com" instead of "Office of the Provost" and are more likely to consider the message hostile, less likely to click on the weird link, less likely to buy gift cards, and so on. I can count on one finger how many people have noticed that we're doing it (it wasn't an end-user, but it was our CRM team who uses friendly from to soft match on contacts) for a population of 150,000 mailboxes. Meanwhile, we get very few people claiming that we aren't somewhat mitigating BEC scams. Note that other institutions are tagging Subjects and bodies with EXTERNAL warnings, either to all external sourced email or based on some conditional rules, but they are not directly addressing the display name spoofing itself. I suspect that people learn to ignore those warnings over time and still fall victim to some well crafted scams from a spoofed VIP in their organization. I can't say with certainty which tactic works better (DKIM signature breakage is a wash), but I think forcing the MUA to reveal the sender's identity is more effective, less disruptive, and dovetails nicely with DMARC and the security marketing of the DMARC vendors. Jesse ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Why are MUAs hiding or removing the From address?
On Tue, Jul 21, 2020 at 1:28 PM Brandon Long wrote: > > Do sms/mms programs show the phone number any more? I think there's been a > deliberate strategy to make email clients more like > other messaging clients, and the technical parts like the actual address are > details that most of the time aren't useful to the user... when > they're not being spoofed, of course, or otherwise need to differentiate > between multiple addresses for the same person. > - I think you're right about how non-email messaging clients have influenced email. But even in email, Microsoft's Outlook, with its roots as an intraoffice memo client, has shown only display name as far back as I know, except when Internet mail comes in with a From header that has no display name to show. For all its quirks, Outlook is the only client I can think of that shows the content of the RFC5322 Sender header, even if it is in the peculiar "x on behalf of y" notation, which shows display name when there is one and address otherwise. But we are digressing into a proposal for an Internet Email Client standard. Joseph Brennan Lead, Email and Systems Applications ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Why are MUAs hiding or removing the From address?
I would like a better understanding of why MUAs are hiding or removing the FROM address. I have one mail store that formerly used hover-to-view, but recently changed to always-show. This was done in response to a client request on their support forum. I have never seen a user ask for the From address to be hidden or removed. I wonder if this trend is driven only by attempts to optimize display space. It would be a shame to weaken our protocols in response to this trend, if the trend lacks a theoretical foundation. I also wonder if the trust indicator research is being over-applied when it is applied to the From Address.From Address is a unique identifier, while Friendly Name is not. A trust indicator is like putting a green check mark next to the From Address as a trust indicator. They have different levels of relevance. One attack method steals a contact list, then emails people in that contact list using friendly names of others in that list. Hiding the From Address plays into that attack. This trust-indicator research also promotes despair. The conclusion is that users process information poorly. This result then becomes an excuse to withhold information from those users, or to allow misleading information to be presented to them.I am not convinced that those are appropriate responses. "Never" is a hard thing to prove. So it is risky to say users "Never" use available information correctly, and "cannot be taught" to do better. Attack filtering is designed on a layered defense and a sequence of probabilities: What is the probability that this attack will get through my spam filter?What is the probability that the user will read the message?What is the probability that the user will click on the hostile link?What is the probability that my web filter will allow access to the hostile website?What is the probability that the web filter will allow the attack to be downloaded?What is the probability that my antivirus program will allow the attack to proceed? The goal is to decrease the probability of a wrong decision at each point in the process. All I need is for some people to act smarter on some occasions in response to some available clue. But this cannot happen if the clue is not provided.. Doug Foster ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
