> On Apr 14, 2016, at 7:35 AM, Mark Keymer <m...@viviotech.net> wrote: > > On 4/14/2016 6:52 AM, Rich Kulawiec wrote: >> On Wed, Apr 13, 2016 at 08:35:54PM -0700, Jay Hennigan wrote: >>> It also sounds like the recipient is in all cases being asked to >>> click on a link in email which is likely to be from an unknown >>> sender (to avoid DMARC issues). This is a potential malware vector. >> Agreed: it's also a spyware/tracking/surveillance vector, *and* it's a >> worst practice in mail system engineering. Users should never need a >> web browser (in any sense of that term) in order to read their email. >> >> ---rsk >> > Keep in mind this isn't "Normal" e-mail. This is a way to send encrypted > mail. Yes I know there are other methods. Sharing keys and using > encrypted/decrypt plugins. However that method is also difficult when you > have a lawyer sending a regular internet user something that needs to be > encrypted. Most end users simply don't know how to deal with that. > > Along the same lines would be to have encryption/decryption setup on > appliances like a Sophos UTM for both the sender and receiver. This really > only works with enterprises talking to known other enterprises that get this > configured. > > Could do a encrypted PDF which might work better. I know some mail server > will not deliver encrypted pdf's. > > I do know that many hospitals, banks etc. Do use this type of encryption to > e-mail the client and basically tell them to log into there web portal to > view the encrypted e-mail. > > What other options are our there for sending encrypted e-mails?
By far the best, if you're dealing with consumers, is not to send the message in the email at all. Add a "messages" section to your customer web portal - where they're already required to log in to access it. When you want to send a new message, add it to their messages section in the web portal and send them an email telling them that there is a new message waiting for them. Best practices for that email would be: 1. Using styling consistent with your other communication, including branding 2. Not including a direct link to the portal, rely on the customers having bookmarked it or being able to find it easily from your main site 3. Sending the mail From: your main corporate domain, or *maybe* a subdomain thereof. Definitely not a third-party domain or a "lookalike" domain. 4. Authenticate the mail using both SPF and DKIM 5. Consider whether DMARC might be appropriate for your mail stream 6. If the information is of particularly high value, look at what the more competent end of banks and other financial institutions do to add trust Actual encrypted mail (S/MIME or PGP) isn't usable by the general public, though it could be usable in *some* B2B applications. Any outsourced "encrypted" mail provider is not going to be able to do as good a job at this particular requirement, regardless of how competent they are, as an in-house implementation just because of the integration with existing web content. That in-house implementation may well choose to send the outgoing emails through an ESP though, either an API-based one such as sendgrid or a more traditional ESP with triggered/transactional mail support such as Salesforce Marketing Cloud - but using a real ESP that can authenticate mail sent using your real domain in the From: address. (I've investigated several outsourced "send 'encrypted' email by sending a URL to the recipient that goes to the real content" providers over the years and none of them have done particularly well). If you're needing to send "encrypted" email to strangers then what needs fixing is likely the business model rather than the mechanics of sending email. Cheers, Steve _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
