4 ms·

I use Fastmail and 1Password, and I do used the masked email functionality. There is a massive gap, though, that makes it very difficult to rely on masked emai

I use Fastmail and 1Password, and I do used the masked email functionality. There is a massive gap, though, that makes it very difficult to rely on masked email. When I sign up for a new account somewhere, I can choose to create a masked email. If I later need to email that company (not reply via an existing email message), I must first somehow look up what email I used for that company, go into fastmail settings and create a "sender identity", remember the email address again, and then when I compose, remember to choose the sender identity that is associated with the masked email address I created for that specific company. If I forget or mess up any of those steps, I end up sending from my primary account or some other masked email address associated with some other company. Multiply that by dozens or even a hundred companies! It would be really nice if adding a masked email automatically created a "sending identity." Further, it would be nice if the masked email account had a nickname that included the domain I was on when I created the account. That way if I need to send an email to support@nike.com, I can use the filter and type "nike.com" and get the correct masked email address.

joshring 3y ago
This was also an issue I had, but there is actually very good support for this hidden by an invisible feature. Simply add an `*@domain` as your email address identity. When you select that as your from address the fastmail UI gives you an input box to use whatever email you want, you don't need to make a new identity each time. For lookup, I just use my password manager.
SparkyMcUnicorn 3y ago
> It would be really nice if adding a masked email automatically created a "sending identity." It does. Just click "... Show all" when choosing a sender, and that will expand the list/search to include masked emails. It should also show you the domain/service it was set up for. And as you noted, the masked email will automatically be used as the sender when replying to an email that was sent to it as well. Using 1Password makes it super easy to see which masked email was used for each service, so I can't really relate to your frustrations there either. I think it's a pretty polished experience, and definitely beats everything else I've used in the past.
- saberworks 3y ago
  > It does. Only sort of. First, this is a new feature, there used to be a whole section on adding "sending identities" and describing how to do it in order to send from a masked email address. I have support emails from 1Password pointing me to those docs as well. That whole section has been removed and now there's a note in the docs saying why (no date, though, so I don't know how recent). Second, your description glosses over the fact that if I click the "from" address dropdown, and then in the filter/search field, type the domain associated with the masked email address, nothing shows up except "Show All." Why wouldn't a filter/search find the address? I have to click "Show All" and then repeat the search. However, if I search/filter for any of the dozens of "sending identities" I created previously, the search/filter works correctly. So the UI is completely broken. When I search/filter something, and nothing shows up except a "Show All" button, that's the UI telling me that there were no matches. Oh, but now I learn that there are matches, they're just hidden under "Show All" (which should be renamed to "show matching masked email addresses" or something!?).
  - SparkyMcUnicorn 3y ago
    > Only sort of. What's missing? The old experience definitely sounds pretty frustrating. Personally, I really like that masked emails are hidden by default. I've got 20 "real" sending identities, so when I'm searching I want a quick selection that doesn't include dozens of masked results. The amount of times I start a new email thread with a masked email would probably be a small handful of times per year. Edit: > I have to click "Show All" and then repeat the search. Maybe that's a bug you can report for your browser? I don't need to retype anything and just hit enter when I get no results, then it expands the results to include masked items.
  - JimDabell 3y ago
    > there used to be a whole section on adding "sending identities" This still exists, by the way. They moved it to Settings => Migration => Import => Add alumni email forwarding address or non-SMTP sending identity, which makes absolutely no sense to me.
  - kenbolton 3y ago
echelon 3y ago
Instead of generating a unique email per relationship, it'd be better if the email provider generated a unique key when the relationship is established that the customer or end user can revoke. Email me at my well known identity "whoever@whatever.com" -> my provider gives you a key that you must store and continue to use for the duration of our relationship. I can terminate it if I want. If you lose the key, you must ask for a new one. If you ask too many times, I can silence you forever. You'll have to provide your own identity when asking. For noisy environments, I can choose to give you the key upfront and only allow for that style of relationship. I could imagine encoding the concept of entity or organization type into the keys as well so that we can distinguish individuals from companies. Professionals, academics, official employees, etc. If you delegate your key to another party, I can choose to pre-authorize it, manually approve it, or outright deny it. Extend it haphazardly or without my consent and you may be blocked. I'd like that type of system. Emails shouldn't have to change. The protocol should. Getting parties onboard might be hard unless a key stakeholder (eg. Google) decides to implement this, but they're in a position to unilaterally dictate.
- KyeRussell 3y ago
  OK. Sure. It’d be better, for you, a technologically savvy receiver of email. I can’t see anyone else in the equation that stands to benefit from this. I can’t see non-tech-savvy email receivers caring much about this at all, or any of its effects, until it has near-universal adoption. Part of solution engineering is coming up with something that people actually want to use. So I don’t really see it as better. I see it as pie-in-the-sky fan-fiction to address part of what masked emails aims to address. A significant portion of the time that I used masked email, it’s in service of increasing anonymity (to the organisation i am giving the email address to), not an anti-spam measure.
  - kelnos 3y ago
    While the protocol details would undoubtedly be somewhat complicated, the user-facing UX wouldn't necessarily have to be. The only part I'm not quite sure how to do seamlessly is the initial exchange. You sign up with your email at a new website, and need to also give them the unique key that allows them to correspond with you. This would require browser support, and a standardized protocol for letting the browser request a new key from your email provider. Also means your browser would need your email credentials (well, an OAuth grant, more likely). And the problem here is that, until all browsers (or whatever) support it, you'd have to run the system in a default-allow state. Another option for the initial per-contact setup is a sort of trust-on-first-use kind of thing. First email from a new recipient is allowed through, but at that point your email client will ask if you want further emails to be allowed (and if you do, it'll send the key to the sender behind the scenes). Problem there is that spammers could just burn through new email addresses to keep contacting you. Anyway, I'm sure there are solutions to these problems, even if I can't think of them in the 12 seconds I've allowed myself to do so. I expect this would be something that would remain disabled for a while, until all the infrastructure and client support is in place.
mths 3y ago
> go into fastmail settings and create a "sender identity" Not anymore, they've made it much simpler for you now by combining "aliases" and "sending identities" into "my email addresses". If you thought it was confusing before when you had to click "create new" under "sender identities" in settings, now all you need to do is: 1. Head to Settings → Migration → Import page. 2. Click on Add external sending address (SMTP) without importing emails. 3. Enter the email address and click Next. 4. On the following screen, skip the password prompt and click on Manually configure. 5. Disable the option - User authenticated SMTP when sending. 6. Save the changes. And just like that you can start sending emails with your new address, easy peasy.
- kazinator 3y ago
  What you're describing sounds hokey. A "Sender identity" should just be a different From: mail header; it shouldn't involve disabling SMTP authentication. The SMTP envelope address and authentication are unaffected.

joshring 3y ago

This was also an issue I had, but there is actually very good support for this hidden by an invisible feature. Simply add an `*@domain` as your email address identity. When you select that as your from address the fastmail UI gives you an input box to use whatever email you want, you don't need to make a new identity each time. For lookup, I just use my password manager.

SparkyMcUnicorn 3y ago

> It would be really nice if adding a masked email automatically created a "sending identity." It does. Just click "... Show all" when choosing a sender, and that will expand the list/search to include masked emails. It should also show you the domain/service it was set up for. And as you noted, the masked email will automatically be used as the sender when replying to an email that was sent to it as well. Using 1Password makes it super easy to see which masked email was used for each service, so I can't really relate to your frustrations there either. I think it's a pretty polished experience, and definitely beats everything else I've used in the past.

saberworks 3y ago
> It does. Only sort of. First, this is a new feature, there used to be a whole section on adding "sending identities" and describing how to do it in order to send from a masked email address. I have support emails from 1Password pointing me to those docs as well. That whole section has been removed and now there's a note in the docs saying why (no date, though, so I don't know how recent). Second, your description glosses over the fact that if I click the "from" address dropdown, and then in the filter/search field, type the domain associated with the masked email address, nothing shows up except "Show All." Why wouldn't a filter/search find the address? I have to click "Show All" and then repeat the search. However, if I search/filter for any of the dozens of "sending identities" I created previously, the search/filter works correctly. So the UI is completely broken. When I search/filter something, and nothing shows up except a "Show All" button, that's the UI telling me that there were no matches. Oh, but now I learn that there are matches, they're just hidden under "Show All" (which should be renamed to "show matching masked email addresses" or something!?).
- SparkyMcUnicorn 3y ago
  > Only sort of. What's missing? The old experience definitely sounds pretty frustrating. Personally, I really like that masked emails are hidden by default. I've got 20 "real" sending identities, so when I'm searching I want a quick selection that doesn't include dozens of masked results. The amount of times I start a new email thread with a masked email would probably be a small handful of times per year. Edit: > I have to click "Show All" and then repeat the search. Maybe that's a bug you can report for your browser? I don't need to retype anything and just hit enter when I get no results, then it expands the results to include masked items.
- JimDabell 3y ago
  > there used to be a whole section on adding "sending identities" This still exists, by the way. They moved it to Settings => Migration => Import => Add alumni email forwarding address or non-SMTP sending identity, which makes absolutely no sense to me.
- kenbolton 3y ago

echelon 3y ago

Instead of generating a unique email per relationship, it'd be better if the email provider generated a unique key when the relationship is established that the customer or end user can revoke. Email me at my well known identity "whoever@whatever.com" -> my provider gives you a key that you must store and continue to use for the duration of our relationship. I can terminate it if I want. If you lose the key, you must ask for a new one. If you ask too many times, I can silence you forever. You'll have to provide your own identity when asking. For noisy environments, I can choose to give you the key upfront and only allow for that style of relationship. I could imagine encoding the concept of entity or organization type into the keys as well so that we can distinguish individuals from companies. Professionals, academics, official employees, etc. If you delegate your key to another party, I can choose to pre-authorize it, manually approve it, or outright deny it. Extend it haphazardly or without my consent and you may be blocked. I'd like that type of system. Emails shouldn't have to change. The protocol should. Getting parties onboard might be hard unless a key stakeholder (eg. Google) decides to implement this, but they're in a position to unilaterally dictate.

KyeRussell 3y ago
OK. Sure. It’d be better, for you, a technologically savvy receiver of email. I can’t see anyone else in the equation that stands to benefit from this. I can’t see non-tech-savvy email receivers caring much about this at all, or any of its effects, until it has near-universal adoption. Part of solution engineering is coming up with something that people actually want to use. So I don’t really see it as better. I see it as pie-in-the-sky fan-fiction to address part of what masked emails aims to address. A significant portion of the time that I used masked email, it’s in service of increasing anonymity (to the organisation i am giving the email address to), not an anti-spam measure.
- kelnos 3y ago
  While the protocol details would undoubtedly be somewhat complicated, the user-facing UX wouldn't necessarily have to be. The only part I'm not quite sure how to do seamlessly is the initial exchange. You sign up with your email at a new website, and need to also give them the unique key that allows them to correspond with you. This would require browser support, and a standardized protocol for letting the browser request a new key from your email provider. Also means your browser would need your email credentials (well, an OAuth grant, more likely). And the problem here is that, until all browsers (or whatever) support it, you'd have to run the system in a default-allow state. Another option for the initial per-contact setup is a sort of trust-on-first-use kind of thing. First email from a new recipient is allowed through, but at that point your email client will ask if you want further emails to be allowed (and if you do, it'll send the key to the sender behind the scenes). Problem there is that spammers could just burn through new email addresses to keep contacting you. Anyway, I'm sure there are solutions to these problems, even if I can't think of them in the 12 seconds I've allowed myself to do so. I expect this would be something that would remain disabled for a while, until all the infrastructure and client support is in place.

mths 3y ago

> go into fastmail settings and create a "sender identity" Not anymore, they've made it much simpler for you now by combining "aliases" and "sending identities" into "my email addresses". If you thought it was confusing before when you had to click "create new" under "sender identities" in settings, now all you need to do is: 1. Head to Settings → Migration → Import page. 2. Click on Add external sending address (SMTP) without importing emails. 3. Enter the email address and click Next. 4. On the following screen, skip the password prompt and click on Manually configure. 5. Disable the option - User authenticated SMTP when sending. 6. Save the changes. And just like that you can start sending emails with your new address, easy peasy.

kazinator 3y ago
What you're describing sounds hokey. A "Sender identity" should just be a different From: mail header; it shouldn't involve disabling SMTP authentication. The SMTP envelope address and authentication are unaffected.