271–280 of 294 posts
Earlier quoted context omitted.
err.. You know that emails transit un clear text, right?
Not if the server admins of both sides are even remotely competent. A good "email server" will at least allow, if not enforce encryption client server and (if supported by the other party) server recipients_server.
Earlier quoted context omitted.
No, not every email server supports it. For example, I know that Office 365 Exchange doesn't support it as I tried it yesterday.
that just means Office 365 has a bug in it, not that using that feature is an "email hack" the plus syntax is part of the email address specification. any server that doesn't support it is by definition buggy because some mail won't work as expected or designed.
Earlier quoted context omitted.
Which has its own problems but that's another story.
What are Protonmail's problems?
Earlier quoted context omitted.
> How do you solve the "won't read my emails" problem ? 99% of the people who tell you they wouldn’t use the product unless it can’t read your email wouldn’t actually use it regardless, and are just asking for things they don’t really have any intention of using. edit: I just wanted to add I think it's kind of a dick move on pg's part to ask someone to build this when there are like four different versions that alrea…
what are the four versions that already exist?
Earlier quoted context omitted.
> How do you solve the "won't read my emails" problem? Have the user generate a device-local SMIME certificate for , register their certificate's public key with the server, have the server generate a mobileconfig that enforces SMIME when emailing anyone, and then in Mail.app change the From: address to when emailing the diary address. iOS will remember that From change and use SMIME to encrypt all diary messages to…
Hey! S/MIME is broken (see eFAIL) and I don’t believe there exist any mitigation’s to the attacks that have been published. tl;dr: there exist ways to read your emails without knowing the private keys.
Diary site implementations will need to carefully evaluate whether this is relevant to them or to their users, who may well have been fine emailing plaintext to begin with (if you want an encrypted diary, you probably aren’t going to use email to write in it), before they assume that it’s a concern and begin testing email clients.
Earlier quoted context omitted.
Hey! S/MIME is broken (see eFAIL) and I don’t believe there exist any mitigation’s to the attacks that have been published. tl;dr: there exist ways to read your emails without knowing the private keys.
eFAIL documents a series of client implementation errors in a 2018 paper that allow attackers to exfiltrate plaintext by emailing you your own encrypted messages with an attacker payload. Diary site implementations will need to carefully evaluate whether this is relevant to them or to their users, who may well have been fine emailing plaintext to begin with (if you want an encrypted diary, you probably aren’t going t…
Earlier quoted context omitted.
https://tools.ietf.org/html/rfc822 (viz. not a gmail-specific feature)
I didn't see where the + had any special significance in RFC822 beyond being part of an atom. foo+a and foo+b could be two different recipients if the server desired.
I just email myself ¯\_(ツ)_/¯ e: Also, I used to use https://750words.com which is quite similar.
Earlier quoted context omitted.
Working for a manufacturing company this is of my biggest pet peeves. Our Salesforce (and customers) insist that they _would/could_ sell (or buy) our product if only it had feature x. In my experience, most of those people aren’t really interested to sell (or buy) the product regardless of feature set.
Contingent Purchase Order : You put in a purchase order and we'll build feature x. Separate the wheat from the chaff.
That probably doesn't work for physical products.