4 ms·

I've seen noreply@ useful/necessary in cases where the original message contained sensitive information that you wouldn't want forwarded to support staff if som

I've seen noreply@ useful/necessary in cases where the original message contained sensitive information that you wouldn't want forwarded to support staff if someone chose to reply.

mattlondon 9y ago
There are some products that will help you strip that information out automatically, e.g. https://cloud.google.com/dlp/ https://cloud.google.com/dlp/ Demo: https://www.youtube.com/watch?v=GXTCIDbLdfw https://www.youtube.com/watch?v=GXTCIDbLdfw Others probably exist, but that is the one I know about.
- tehlike 9y ago
  Stripping is prone to human errors. Noreply as a blanket is probably less so.
  - mattlondon 9y ago
    That service is not done by humans :-)
    - rainbowmverse 9y ago
      Humans build their flaws into their machines.
    - tehlike 9y ago
      Well... Who identifies whar to strip? Who ensures that an email that is sent by an engineer in a department will definitely go through the sanitization? Like another poster said, people can build their flaws into machines.
jacobparker 9y ago
That's sounds pretty easy to solve redacting the sensitive content when it hits your mail server before going to support staff. If you're sending out HTML email you can also make easy and extensible by having a custom class for redactable contents. Realistically customers are going to fwd those emails anyway so this approach is more robust. It seems like most information in these emails would be available to support staff typically though. It sounds like a niche case.
- pavel_lishin 9y ago
  > That's sounds pretty easy to solve Everything does if you just glance at someone's comment online and dash one off. How do you recognize which is the sensitive content and which isn't? How do you handle the case where you send out HTML emails, but the response strips all of the HTML and sends plain text back?
CodeWriter23 9y ago
I can't help but seeing a multi-fail here. First, it's ok for the company to send confidential info via email? I don't think so. Email is not a secure transport mechanism. Second, email accounts are often the target of phishing and cyber attacks, so that's the last place you should enable the customer to store sensitive information. Third, how does "noreply@" actually prevent the customer from sending a reply, disclosing the confidential information at every hop along the way to being bounced by your server? It doesn't. Or to "support" personnel; well maybe if you exclude your admins from the "support" classification but they're likely collecting those emails in an unnamed inbox or logging them somewhere? And what if the customer's (possibly third-party) admins are collecting bounces as they proactively monitor SMTP reputation for the domain and IP address? Please, just erase the idea that it's ok to send confidential information via email from your head. Send a link to a password-protected page. If you want to be extra vigilant, require temp password via SMS to reset that password. And if you want to be hyper-vigilant, use TOTP as a 2FA mechanism for password reset. And if it really requires secrecy, send it via courier followed by an assassin to kill the courier. (Joking, not an incitement to criminal activity)

I've seen noreply@ useful/necessary in cases where the original message contained sensitive information that you wouldn't want forwarded to support staff if someone chose to reply.

mattlondon 9y ago

There are some products that will help you strip that information out automatically, e.g. https://cloud.google.com/dlp/ https://cloud.google.com/dlp/ Demo: https://www.youtube.com/watch?v=GXTCIDbLdfw https://www.youtube.com/watch?v=GXTCIDbLdfw Others probably exist, but that is the one I know about.

tehlike 9y ago
Stripping is prone to human errors. Noreply as a blanket is probably less so.
- mattlondon 9y ago
  That service is not done by humans :-)
  - rainbowmverse 9y ago
    Humans build their flaws into their machines.
  - tehlike 9y ago
    Well... Who identifies whar to strip? Who ensures that an email that is sent by an engineer in a department will definitely go through the sanitization? Like another poster said, people can build their flaws into machines.

jacobparker 9y ago

That's sounds pretty easy to solve redacting the sensitive content when it hits your mail server before going to support staff. If you're sending out HTML email you can also make easy and extensible by having a custom class for redactable contents. Realistically customers are going to fwd those emails anyway so this approach is more robust. It seems like most information in these emails would be available to support staff typically though. It sounds like a niche case.

pavel_lishin 9y ago
> That's sounds pretty easy to solve Everything does if you just glance at someone's comment online and dash one off. How do you recognize which is the sensitive content and which isn't? How do you handle the case where you send out HTML emails, but the response strips all of the HTML and sends plain text back?

CodeWriter23 9y ago

I can't help but seeing a multi-fail here. First, it's ok for the company to send confidential info via email? I don't think so. Email is not a secure transport mechanism. Second, email accounts are often the target of phishing and cyber attacks, so that's the last place you should enable the customer to store sensitive information. Third, how does "noreply@" actually prevent the customer from sending a reply, disclosing the confidential information at every hop along the way to being bounced by your server? It doesn't. Or to "support" personnel; well maybe if you exclude your admins from the "support" classification but they're likely collecting those emails in an unnamed inbox or logging them somewhere? And what if the customer's (possibly third-party) admins are collecting bounces as they proactively monitor SMTP reputation for the domain and IP address? Please, just erase the idea that it's ok to send confidential information via email from your head. Send a link to a password-protected page. If you want to be extra vigilant, require temp password via SMS to reset that password. And if you want to be hyper-vigilant, use TOTP as a 2FA mechanism for password reset. And if it really requires secrecy, send it via courier followed by an assassin to kill the courier. (Joking, not an incitement to criminal activity)