1

To my knowledge, there's no common standard for sysadmins to publish trusted domains for specific use cases.

If it exists, I would presume that this might limit phishing attacks. Think of my question here as an extension of SPF/DMARC/DKIM, where you go beyond simply saying what domains are authorized to what each domain should be used for.

For instance, if I delegate support desk to zendesk.mydomain.com but Zendesk gets hacked and starts sending fake forgot password emails, you can mitigate that by telling email providers that zendesk.mydomain.com isn't designated for that purpose.

Beyond the infosec concern, I think this would yield some user experience benefits as well. Thinking of myself as an end user, I would want this feature so that I could proactively manage my inbox when signing up for a new website such as marketing emails, policy change announcements, order receipts, forgot password emails, etc. Without an official record to check, you have to guess. And even if you guess right, a sysadmin can change email addresses without giving any notice.

To illustrate the idea I'm looking for, there's a couple solutions I can think of that could achieve this:

  • robots.txt to suggest how bots engage with web content.
  • /.well-known/security.txt for contact info and standard operating procedure to notify admins of infosec concerns.

Would anyone happen to know of a solution that fits this use case? I feel like it's such an obvious thing that there should be something out there even if it's not exactly like the examples I've mentioned so far. Also interested to hear what problems or concerns complicate this idea.

Caleb Faruki
  • 195
  • 6
  • I don't see an information **security** aspect of your question, i.e. I consider it off-topic. – Steffen Ullrich Mar 06 '22 at 11:30
  • The information security aspect is in mitigation of phishing attacks. Official accounts published in a standard way. Think of my question here as an extension of SPF/DMARC/DKIM, where you go beyond simply saying what domains are authorized to what domains are used for which conventional use cases. – Caleb Faruki Mar 06 '22 at 11:32
  • For instance, if I delegate support desk to zendesk.mydomain.com, but Zendesk gets hacked and starts sending fake forgot password emails, you can mitigate that by telling email providers that zendesk.mydomain.com isn't designated for that purpose. – Caleb Faruki Mar 06 '22 at 11:37
  • While based on the comments there might be a relation to security I see no such relation yet in the question. Currently it is only about managing inbox and making sure to not accidentally flag important stuff as spam. Please update your question to clearly describe the security aspect. – Steffen Ullrich Mar 06 '22 at 11:42
  • @SteffenUllrich edited. Better? – Caleb Faruki Mar 06 '22 at 11:48
  • 3
    Better. I'm still wondering how useful the approach you envision would be in practice though. With DMARC it can be automatically checked if the mail comes from the shown domain or not. With your approach there is some "purpose" added on top of this - but how to automatically get the purpose from the mail in order to automatically match it with the sender? – Steffen Ullrich Mar 06 '22 at 12:22
  • If the feature is implemented like SPF/DKIM/DMARC, which are DNS records, then it only protects *legit* senders when their SMTP servers are hacked but their nameservers aren't. It does nothing to protect against hostile senders who can simply claim their domain are totally for password reset email etc. In your hypothetical situation, what's stopping attackers from sending seemingly normal emails as usual but with links to malware/data collecting site? – Martheen Mar 06 '22 at 13:50
  • @SteffenUllrich the security benefit is limited for sure. It presumes that an email address can be compromised and therefore you add "purpose" to limit the damage by making sure that the sender is only trusted for specific comms. If it's a DNS record or a TXT file hosted on a webserver, you can simply fetch the information before or after you receive a message to verify if the sender is approved for that kind of message. – Caleb Faruki Mar 06 '22 at 17:20
  • @Martheen I'm asking more about how to give recipients another way to check the authenticity of a message. Continuing with my example, I accept risk when I use Zendesk because my business would set up an authorized email domain (e.g. "zendesk@mycompany.com") I'd have SPF/DMARC/DKIM set up of course. But if Zendesk is compromised, I give an attacker an authorized domain to run phishing attacks. The question is whether a standard exists for telling recipients what domains to trust for what kind of communications? It's intentionally open-ended because there's a lot of issues to consider. – Caleb Faruki Mar 06 '22 at 17:39
  • @CalebFaruki: Again, the problem I have with your approach is the practicality. It requires that the end user determines the purpose and then checks if the sender mail matches the purpose - which I consider infeasible for the average user. Letting the sender tag the mail with a purpose can be simply bypassed by making the attacker send untagged phishing mails - the difference is not obvious for the average end user. In other words: I don't think that it actually solves the problem you propose it for. – Steffen Ullrich Mar 06 '22 at 17:43
  • @SteffenUllrich I would focus on the "standardization" point of the question. Using my examples as reference, if there's a machine-readable document to categorize what email addresses send what kind of messages, then that's the scope of the solution. The end-user experience part is a latent benefit I mentioned and probably spent too much time explaining as you rightly pointed out. – Caleb Faruki Mar 06 '22 at 17:50
  • @CalebFaruki: As far as I know there is no standard for this in the context of security - which in my opinion is because it does not provide any security benefit in practice. As for use cases outside security - off-topic here. – Steffen Ullrich Mar 06 '22 at 17:55
  • Let's say I work for an enterprise company. We want to buy a SaaS service that requires an email inbox. IT says they won't approve it unless it is locked to saas.mycompany.com. Then the SaaS company is hacked. IT can edit/delete the DNS record to blacklist further emails. But how long does it take to find out about the hack? There's a window of time where it's open season for the attacker. If you can say that the subdomain is for a specific use case, Gmail could check the approved purpose against the content of the email to detect that something is amiss. How's that? @SteffenUllrich – Caleb Faruki Mar 06 '22 at 18:04
  • 2
    @CalebFaruki: *"check the approved purpose against the content of the email"* - this exactly is the weak point. How does one reliably extract the purpose of the mail? One cannot rely on the mail having a clear content describing the purpose since an attacker will deliberately construct the mail to bypass such detection - while still being believable enough for the victim. – Steffen Ullrich Mar 06 '22 at 18:12
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/134607/discussion-between-steffen-ullrich-and-caleb-faruki). – Steffen Ullrich Mar 06 '22 at 18:17

0 Answers0