[HN Gopher] JMAP - a modern email open standard
___________________________________________________________________
JMAP - a modern email open standard
Author : tambourine_man
Score : 534 points
Date : 2023-05-30 17:26 UTC (5 hours ago)
(HTM) web link (jmap.io)
(TXT) w3m dump (jmap.io)
| kitsunesoba wrote:
| I really hope that JMAP starts getting some traction, because
| I've toyed with writing an email client of my own while it's
| certainly _possible_ to do so, my hope of writing one that people
| other than myself might actually want to use is quite low. There
| 's so many little nuances and gotchas with IMAP that make it a
| real bear to work with, plus you have the whole mess of multipart
| encoding which you might have to roll your own for since not all
| languages have a suitable library.
|
| By contrast HTTP JSON-based APIs are incredibly well-trodden and
| practically every language has a high quality JSON
| (de)serializer, many as part of their standard libraries. JMAP
| would lower the bar for writing email clients dramatically.
| solarkraft wrote:
| I'm in the same boat! I dislike the current state of E-Mail
| clients and while there's an uncountable amount of servers, I
| can't really find any clients.
| ashton314 wrote:
| Does anyone know of a JMAP -> Maildir client? I'd love to replace
| mbsync with something faster.
| asim wrote:
| Sendgrid has an inbound email webhook which I've used quite
| effectively. What's great is that you can dynamically map your
| inboxes and provide any address for your domain.
|
| https://docs.sendgrid.com/for-developers/parsing-email/setti...
| tiffanyh wrote:
| Fastmail.com continues to delivery great innovations and open
| sources much of their work.
|
| They are the company largely behind this, check them out.
|
| (I'm not affiliated in any way to them)
| dheera wrote:
| How are they funded, and are they profitable?
|
| I've been using Google Apps for email for 10+ years and I don't
| want my e-mail provider to die at the whim of some Sand Hill
| investor's emotions at a bay area house party.
| balderdash wrote:
| I think the risk of them going out of business overnight/no
| warning, is lower than google arbitrarily locking you out of
| your account with no recourse (at least with the free
| versions)
| scblock wrote:
| You pay them.
| dheera wrote:
| Is that enough for their company to be alive? Many startups
| offer paid services but it isn't enough to cover their own
| costs and salaries in the first several years; everything
| depends on investors willing to fund them through that
| period.
| Semaphor wrote:
| FWIW, they are not a startup, they are 24 years old and
| (after being bought by opera and then buying themselves
| out again) fully independent [0]. They are also probably
| HN's most beloved company, but that just as a side ;)
|
| [0]: https://en.wikipedia.org/wiki/Fastmail
| hackernewds wrote:
| > (after being bought by opera and then buying themselves
| out again)
|
| that history does not assign to me confidence in them as
| custodian of my emails
| koalacola wrote:
| To be fair no one is forcing you to switch, just
| recommending options per your request.
|
| I'd recommend trying them out for a bit and just keeping
| Gmail in your back pocket. May as well decide for
| yourself than listening to randoms on HN.
| Semaphor wrote:
| This was in 2010, not the opera you know today.
| labster wrote:
| For comparison, newcomers like Gmail have only been in
| the market for 19 years.
| no_wizard wrote:
| They're not venture backed[0] and have been around for 15
| years at least
|
| [0]: https://www.crunchbase.com/organization/fastmail-fm
| [deleted]
| error503 wrote:
| It's been fully independent for like 10 years, and
| existed as a commercial product for over 20, so I think
| it is pretty safe from 'startup' risk.
| calvinmorrison wrote:
| Funded? by payments from customers. FastMail has been around
| longer than Gmail and before the endless startup hype cycles
| [deleted]
| mannycalavera42 wrote:
| it's a shame they don't have (yet) a EU hosting :(
| foxtacles wrote:
| Fully agree. I'm also a very happy Fastmail customer of over 10
| years now; I could never go back to gmail
| TylerE wrote:
| I tried, but fm's spam filtering is just hot garbage. Both
| false negatives and (more troublesome) false positives.
|
| It's like stepping back in time 20 years when soamassassin
| with default config is as good as it gets.
| UberFly wrote:
| I experience the opposite of this, but I guess everyone's
| use case is different. They do use SpamAssasin and it seems
| pretty effective.
| chrismorgan wrote:
| I think I'm up to two false positives after six years,
| neither of which was in any way important (in fact, I kinda
| agreed with its judgement), and I'm up to 175 false
| negatives in the last 5 1/3 years (of which 32 are from
| the last twelve months, which suggests a fairly steady rate
| across the whole time; it comes to about one every eleven
| days).
|
| Before that, I used Gmail (on the same address, for about
| six years), and my memory is that its false positive rates
| were around one every month or two, and some of them
| actually mattered; and its false negative rates varied:
| sometimes it'd go for a few months with none, then it might
| let through one or two per day for a few weeks. Certainly
| less consistent. In the last year I've also had to use
| Gmail via a couple of organisations on addresses with very
| low volume (less than one per day) which have never
| received any spam, and both have had at least two false
| positives.
| kelnos wrote:
| I always find it curious how people often have such a
| different experience with the same system. For my part,
| I've found Fastmail's spam filtering to be much better than
| GMail's, especially when it comes to those false positives:
| I would see ham in my GMail spam folder at least a couple
| times a week. I've mostly stopped perusing my Fastmail spam
| folder, as I still have yet to find any false positives
| there.
|
| On the other end of things, GMail and Fastmail both miss
| about the same amount of spam that ends up in my inbox. Not
| a lot, maybe once or twice a week.
|
| I wonder what it is about the emails you receive (vs. the
| emails I receive) that makes us see such different
| outcomes.
| sph wrote:
| I had a major issue with spam on FM and after some back and
| forth with support, I got some understanding of their
| system:
|
| 1. The bayesian filter updates only when you actually
| delete emails from the Spam folder.
|
| 2. There is a global and a personal spam filter. The
| personal one kicks in after 200 spam emails have been
| ingested/deleted. You need to break it in, like a pair of
| leather shoes.
|
| 3. Before this 200 email threshold, make use of automated
| rules to just mark stuff as Spam automatically, if like me,
| they have all a similar pattern. When your personal filter
| kicks in, you're golden and works as expected.
|
| I don't have any spam issue anymore and I don't think I've
| ever seen a false positive either. So now it's smooth
| sailing.
|
| I wish Fastmail documented this process, which was
| explained to me by their support after a dozen exchanges.
|
| Funny aside: all the spam overwhelmingly comes from
| gmail.com accounts. Seems like Google needs to work on
| their terrible _outgoing_ spam issue. They 're the biggest
| spam sender now that no one runs open mail servers on the
| Internet anymore.
| [deleted]
| moozeek wrote:
| I have the exact opposite experience and find Fastnail's
| spam detection quite superior. There is the occasional
| spam.email getting through - maybe 1 per day - despite the
| fact that I have quite a number of custom domains with
| catch-all email addresses.
|
| At the same time I really never have to check my spam
| folder for false positive, everything in there is literal
| spam so I forget checking it for weeks on end. Whereas on n
| Gmail I always need to check the spam folder, Google
| completely overdoes the filtering it and a lot of wanted
| emails end up in spam.
| dbrunton wrote:
| Came here (and used Fastmail for password recovery) to say
| just this. I actually forget what it's like to sell
| advertising on my correspondence!
| gersg wrote:
| If you don't enable "smart" features in gmail you don't see
| ads either.
| stavros wrote:
| Same here, whenever I have to open Gmail for work I'm
| annoyed.
| arp242 wrote:
| You can connect FastMail to gmail and never look at gmail.
| Your employer may not approve if you hillary your emails
| like that though, but that's what I did at a previous
| employer where this wasn't an issue.
| stavros wrote:
| I could, but I don't want to look at work emails outside
| working hours.
| foxtacles wrote:
| Have you considered setting up a rule using the Snooze
| feature[0]? Using this it should be possible to delay all
| incoming work email until a time that is suitable for
| you.
|
| [0]: https://www.fastmail.com/blog/fastmail-snooze/
|
| Edit: If you want your work emails to arrive only during
| work hours and otherwise delay them, you can use a Sieve
| condition in your email rule similar to this:
| anyof (date :value "lt" "date" "hour" "09", date :value
| "ge" "date" "hour" "17")
| stavros wrote:
| Well that's very interesting, thank you!
| hackernewds wrote:
| I like your usage of Hillary as a verb. I don't
| understand the affinity against Gmail though. With the
| fastmail forwarding service are you still not using Gmail
| spam service and have Gmail access to your email anyways
| (not that I'd believe they do unless wearing a tinfoil
| hat)
| arp242 wrote:
| I just don't care much for gmail's UI; that's all there's
| to it. And having all email in one place is more
| convenient for me regardless - saves having to open/check
| another service.
|
| You're still using gmail's spam checking; it just uses
| the API (or IMAP? I forgot) to sync the emails to
| FastMail.
| taftster wrote:
| Would love to use them. But the pricing is too much.
|
| I need a custom domain (or three). And I have a family of 6
| people.
|
| So that's $5 / user / month = $30 / month = $360 / year.
|
| Unfortunately, that's not justifiable for me. And thus why I'm
| stuck using Gmail with a custom domain.
| kstrauser wrote:
| Apple has an incredibly cheap option here. If you subscribe
| to iCloud+ (https://www.apple.com/icloud/), starting at
| $1/month, you can share one or more custom email domains with
| up to 6 people total.
|
| I've been using this for a year or so and my family's been
| happy with it.
| taftster wrote:
| Good to know, thank you for the reply. I'll take a look.
| eikenberry wrote:
| Do they tightly tie anything to the apple ecosystem? That
| is, how friendly is this service if you have no Apple
| hardware/software?
| kstrauser wrote:
| You set it up as standard SMTP/IMAP in your email client.
| There's also a web interface at icloud.com if you want to
| check your mail there, or set up filters, etc.
|
| I don't _think_ you 'd need any Apple gear at all to use
| it, but make no promises.
| dublinben wrote:
| An Apple device (iPhone, iPad, or Mac) is required to
| manage your iCloud+ subscription. It's not intended to
| work as a web service independent of their products, even
| if you could use parts of it from other devices.
|
| https://support.apple.com/en-us/HT201318
| tredre3 wrote:
| > I'm stuck using Gmail with a custom domain.
|
| Google Workspaces is $6 / user / month.
|
| I presume you were grandfathered for free from personal G
| Suite, but for the rest of us fastmail is actually less
| expensive than google's offering (though google also gives
| you Drive space and whatnot).
| Shared404 wrote:
| Migadu is another good host for custom domains.
|
| You pay for mailbox size and number of emails in/out. Can add
| as many domains/users as you like.
|
| I use the micro tier ($20 a year), it's more than enough for
| me.
|
| https://www.migadu.com/pricing/
| asnyder wrote:
| Zoho actually has a free plan for up to 5 users, including a
| single custom domain. However, they force you to use their
| web/mobile mail app unless you upgrade to their paid plans
| which include IMAP/POP and many custom domains. Their paid
| plans are very reasonable and start out at $1 and $1.20
| (5/10GB respectively) a month.
|
| Recently compared Google, Office 365, Proton, Tutanota,
| Skiff, and Zoho. Surprisingly ended up with Zoho. Actually a
| decent experience so far, they've definitely upgraded their
| stack for the better from what I remember it was a decade
| ago.
| ocdtrekkie wrote:
| I believe they changed this, you can now have an account with
| multiple levels of users. I believe as long as you have one
| $5 tier user, you can have additional $3 tier users at your
| domain.
| tass wrote:
| Only one account needs to be a regular account to support
| custom domains. The others can be basic - 2.50 per month
| (when paid annually) or $200/year total for 6 users (1
| standard + 5 basic)
| mathfailure wrote:
| > The protocol is stateless
|
| > Clients can efficiently fetch updates from their current state
| a-la QRESYNC. This can be implemented effectively using the
| MODSEQ data already in modern IMAP servers, or by using a
| transaction log data structure. The server can always indicate to
| the client if it cannot calculate updates from a particular
| client state (for example, because it is too old).
|
| Does not compute.
| Xeoncross wrote:
| So bummed. Encryption is missing again.
|
| > Users expect to be able to search their whole archive, so
| either you need all the data in the client, or the server needs
| to have access to the data... ...JMAP is therefore not
| introducing any new measures to address end-to-end encryption
|
| You don't need to transfer gigs of emails to a client and
| manually search character-by-character through a massive trove of
| data. That isn't how search functions.
|
| You can use probabilistic filters (like bloomfilters) so a client
| can actually run a search on thousands of emails using only a few
| hundred kilobytes (or maybe megabytes) of actual encrypted data.
| Basically, less than a modern webpage.
|
| Each time a new email is downloaded, parse it, add it to an index
| segment, encrypt it, and store it back on the email server.
| Different clients can reuse the same indexes.
| solarkraft wrote:
| I don't know, Tutanota does client side search and I don't like
| it. But they do full text searches. Do bloom filters deliver
| the same accuracy?
| klysm wrote:
| No, they are probabilistic data structures and it's not
| immediately obvious to me how to use them effectively for
| search
| dataangel wrote:
| You use bloom filtering to massively reduce the number of
| possible matching messages, then you do a regular text
| search on the remaining set.
| joelthelion wrote:
| How do you keep your bloom filter up to date if the server
| doesn't have access to the data?
| tiffanyh wrote:
| The proposal for encryption extension to JMAP is already on
| it's 3rd draft for review.
|
| https://www.ietf.org/id/draft-ietf-jmap-smime-sender-extensi...
| crazygringo wrote:
| That still requires the client to have downloaded all emails in
| the past in order to generate the Bloom filters. Those filters
| can't be provided by the server.
|
| Which is maybe fine if you're starting an e-mail account from
| scratch, but it is going to take a long time to set up email
| search on a new phone.
|
| Also e-mails are a pretty bad use case for Bloom filters
| because you need to construct an entire filter per-email for
| search. Since many emails are short (a sentence or two) you'll
| find each Bloom filter may actually be _larger_ than the e-mail
| itself.
|
| I don't know if there are other types of probabilistic filters
| more suited to e-mail search however.
| Xeoncross wrote:
| > That still requires the client to have downloaded all
| emails in the past in order to generate the Bloom filters.
|
| That's generally not an issue. When people first create an
| email there is only 1 welcome email in the account. The
| client web/mobile/desktop downloads that one email and
| creates the search index.
|
| If you get a new client/phone/desktop you can still reuse the
| encrypted index files. It's not like you have to download
| your last 5 years emails on each new device.
| SahAssar wrote:
| In that scenario would each device to publish their index
| files and the others using the same account download and
| use them? Are there good merging methods for this or would
| it just be latest wins?
| eviks wrote:
| Exactly, the explanation doesn't hold water, and it's a pity
| such and important issue is sidestepped in this way
| slaymaker1907 wrote:
| The only way I could see this working would be if there was
| some way for an email client to store its own encrypted data on
| the server that is not an email/attachment and is tied to a
| particular email client. With such an API, clients could just
| do the indexing themselves and then store the index on the
| server. You'd probably want something like oblivious-RAM so
| that clients could avoid reading and writing the entire index
| all at once.
|
| Ok, the more I think this out, the more I like the idea of
| email servers providing ORAM for email clients. The oblivious
| aspect could actually be optional as well since the server only
| needs to provide random access and/or a K/V store.
|
| Maybe this could be implemented currently using a fake email
| draft? Blobs are apparently cleaned up transparently when they
| are no longer referenced so you could just make sure blobs are
| small and treat them as immutable blocks. The remaining problem
| would be encryption of the actual emails, but there is already
| PGP/GPG for that.
| Szpadel wrote:
| from technical point of view this sounds interesting, do you
| have any example of such implementation for text search
| anywhere?
|
| I can see multiple challenges in implementing something like
| this and I would like to educate myself
| Xeoncross wrote:
| https://www.stavros.io/posts/bloom-filter-search-engine/
| Szpadel wrote:
| Either I didn't understand something or this method would
| still require server to have way to decrypt data to create
| that index?
|
| Or this could be computed on client side but that's not
| much different than fetching all emails locally
| Xeoncross wrote:
| Clients already fetch all emails locally over the years
| you use the email. You don't have to build the index in
| one pass. As you read/download each new email, you add it
| to the index segments. The same way you don't have to
| download the internet to create your searchable browser
| history.
| dang wrote:
| Related:
|
| _JMAP: It's Like IMAP but Not Really (2019)_ -
| https://news.ycombinator.com/item?id=32978005 - Sept 2022 (131
| comments)
|
| _How and why we built Masked Email with JMAP, an open API
| standard_ - https://news.ycombinator.com/item?id=29188639 - Nov
| 2021 (4 comments)
|
| _Implementing 'focus and reply' for Fastmail with JMAP_ -
| https://news.ycombinator.com/item?id=24207506 - Aug 2020 (47
| comments)
|
| _JMAP: Modern Mail Standard_ -
| https://news.ycombinator.com/item?id=21599666 - Nov 2019 (17
| comments)
|
| _Making email more modern with JMAP_ -
| https://news.ycombinator.com/item?id=20720630 - Aug 2019 (166
| comments)
|
| _The JSON Meta Application Protocol (JMAP)_ -
| https://news.ycombinator.com/item?id=20477212 - July 2019 (96
| comments)
|
| _JMAP: A modern, open email protocol_ -
| https://news.ycombinator.com/item?id=19839104 - May 2019 (115
| comments)
|
| _JMAP: Like IMAP but Not Really_ -
| https://news.ycombinator.com/item?id=18996200 - Jan 2019 (228
| comments)
|
| _JMAP is on the home straight_ -
| https://news.ycombinator.com/item?id=18766709 - Dec 2018 (50
| comments)
|
| _JMAP - an IMAP replacement_ -
| https://news.ycombinator.com/item?id=14734091 - July 2017 (20
| comments)
|
| _JMAP: A better way to email (2014)_ -
| https://news.ycombinator.com/item?id=14283659 - May 2017 (51
| comments)
|
| _Progress on JMAP, better standard for synchronising mail,
| calendars and contacts_ -
| https://news.ycombinator.com/item?id=10781894 - Dec 2015 (35
| comments)
|
| _An open source JMAP proxy, JavaScript library and webmail demo_
| - https://news.ycombinator.com/item?id=10038547 - Aug 2015 (18
| comments)
|
| _JMAP - a better way to email_ -
| https://news.ycombinator.com/item?id=8785894 - Dec 2014 (115
| comments)
|
| _JSON Mail Access Protocol Specification (JMAP)_ -
| https://news.ycombinator.com/item?id=7141152 - Jan 2014 (61
| comments)
|
| _JSON Mail Access Protocol Specification (JMAP)_ -
| https://news.ycombinator.com/item?id=7141028 - Jan 2014 (1
| comment)
| feldrim wrote:
| I see that the specs are defined in 2019 excluding the Websockets
| spec in 2020. So over 3 years, these specs are implemented almost
| only by Fastmail. It feels like it is yet another standard [0],
| which could not be adopted by neither commercial nor open source
| email servers and clients.
|
| 0. https://xkcd.com/927/
| commoner wrote:
| While the xkcd comic mentions 14-15 competing standards, there
| are only 3 email client standards in wide use: POP/SMTP,
| IMAP/SMTP, and Microsoft Exchange ActiveSync. POP is wholly
| surpassed by IMAP in functionality and ActiveSync is
| proprietary, so we're left with IMAP/SMTP as the only viable
| universal option.
|
| I would really like to see an open email client standard that
| is more reliable and performant than IMAP/SMTP, and JMAP could
| potentially be it. It doesn't seem unreasonable to have 2
| competing standards instead of 1 when IMAP hasn't seen any
| improvements in 20 years.
| calvinmorrison wrote:
| well the other nice benefit is that since JMAP operates by
| talking JSON via HTTP over TLS you get to skip a lot of the
| absolutely bonkers annoying cert stuff, SMTP port issues,
| etc.
| pmontra wrote:
| POP3 is perfect for people like me that download their mail
| and organize it in local folders on their computer. I'm using
| Thunderbird and mail filters to move messages to their
| folder. I backup remotely with duplicity.
| philipwhiuk wrote:
| How do you handle email on other devices?
| pmontra wrote:
| I check my mail with k9 on Android, delete uninteresting
| messages and download on my laptop, maybe only once every
| two or three days. To reply and send from Android and not
| to lose my message I configure k9 to Bcc me. I get my
| message in my mailbox and my filters on Thunderbird will
| put it into the right folder when I eventually download
| mail.
|
| Of course I'm missing the ability to read my past mail
| from my phone but life has proven that it's not important
| neither for my work nor for private matters. Furthermore
| communications are moving more and more to WhatsApp and
| Telegram and those are always available on multiple
| devices.
| aembleton wrote:
| > configure k9 to Bcc me
|
| Is that Bcc to gmail?
| philipwhiuk wrote:
| The EAS switch was annoying because I finally fixed WebDAV
| support before Microsoft moved away, and the EAS Android
| build is a pain in the ass.
| doublepg23 wrote:
| I've grown to despise that XKCD comic. It might be one of the
| more thought-terminating ones he's made.
| arp242 wrote:
| [dead]
| kortex wrote:
| I agree, it really grinds my gears when people use it as an
| objection to any attempt at improving a standard. People
| stopped taking it as what it is (a joke) and using it as an
| actual argument.
| pmontra wrote:
| I think that the idea is that when there are so many
| competing standards it's difficult for them to get any
| meaningful adoption, except for the one or two that for
| some reason (age?) are already widely adopted. A new
| standard must be backed by most of the industry to succeed.
| JMAP doesn't seem to have many chances because the industry
| is Google and Microsoft with their own products.
| bewaretheirs wrote:
| It's available as an alternate protocol in the open-source
| Cyrus IMAP server:
| https://www.cyrusimap.org/3.4/imap/developer/jmap.html
| calvinmorrison wrote:
| which is what FastMail runs internally
| [deleted]
| einpoklum wrote:
| email is a simple textual protocol. FastMail is not offering an
| alternative to that, but an "alternative to proprietary email
| APIs that only work with Gmail".
|
| Well, I don't use GMail (and neither should you! All your email
| is mined for advertising and shared occasionally with the US
| government.) - so it's not clear to me why I need an alternative
| to that stuff.
| crispinb wrote:
| * * *
| chillbill wrote:
| I would really like to see encrypted email integrated with this
| and with Fastmail.
| gcanyon wrote:
| Sounds like the big claim here is that it is faster. That's
| definitely a good thing, but what I want is a protocol where:
|
| 1. Every time I give out my email address, behind the scenes a
| single-source permission/token is created. 2. Thus, that one
| source is able to send me email, from the email address they
| specified at the time. 3. But if they hand over the
| permission/token to anyone else, email from that new source will
| automatically bounce/be marked as suspect/flagged (my choice in
| configuration). 4. Even if the original authorized party tries to
| email me from a different address at the same domain, that email
| will be handled as in (3). 5. Even from the same email address,
| the configuration can specify limits, e.g. only 5 emails total,
| only 3 per week, expire after 10 days, etc. Again, configurable.
|
| Oh, and 6. Of course this means unsubscription becomes a local
| configuration thing that doesn't require the sender's
| participation.
|
| I know current email protocols allow none of that, but if we're
| proposing new protocols, that's what I want out of it. Faster is
| better too.
| Spivak wrote:
| Sounds like you want email to work basically 1-1 with OAuth
| where you authorize the sender the way you would grant access
| to your Google/Spotify account.
|
| I would actually love this flow and you get OpenID style SSO
| for free. Could be the actual password killer.
| ghayes wrote:
| This is a little confusing since it's not just an access
| token (or refresh token) since the OP wants to verify that
| the sender is the correct sender, not just that they have
| access to the token. Otherwise a token holder could simply
| pass the token to spammers, still. This is harder since the
| sender could share his or her sender key, so you'd have to
| disincentive that, but doing so it going to make the system
| even more complex.
| gpvos wrote:
| You don't have to go very far with extra checks and
| disincentives, as the recipient can also invalidate the
| token at the first sign of spam. SPF/DKIM or an equivalent
| can also help with sender authentication.
| Spivak wrote:
| I think the idea is that OAuth token would allow sending
| emails _as a specific sender_ , like if I allow say Lyft to
| send me emails in this flow and they pass the key to
| spammers the emails will appear to come with Lyft.
| ilyt wrote:
| I actually loved XMPP/Jabber flow where sender first need
| your permission to get added to the contact list and get
| their messages thru. Still can be spammed but without any
| meaningful content at least.
| __MatrixMan__ wrote:
| Your vision is further than fastmail can currently take you,
| but a partial solution which I use is to just give out a unique
| email address to each company. that way when you get spam you
| can disable that address for future use and also use it as a
| conversation starter with whoever leaked your data to a
| spammer.
|
| The format I use is {yourname}@{myname}.{mydomain}, so there's
| a unique address for every pair--some of which I've disabled
| delivery for.
| gcanyon wrote:
| Do you have the system automated? Meaning: if I send email
| right now to {somerandomstring}@{yourname}.{yourdomain} does
| it get automatically rejected, or flagged? And if yes, how do
| you add {myname} to your whitelist?
| __MatrixMan__ wrote:
| I have fastmail configured to accept *@{my name}.{my
| domain} and then I have a rule for each blocked sender. So
| it's it opposite of the logic that you want: I'll receive
| they mail until I explicitly block you.
|
| This is still not implicit block like you're after, but
| when I looked through the settings to see how I had it
| configured I discovered this integration with 1password:
| https://1password.com/fastmail/
|
| which, now that I know about, I may start using.
| vidarh wrote:
| Both Gmail and Fastmail supports "+something" in the local
| part of your email address, so you can just add a
| foo+*@domain filter to block everything or move it to a
| folder, and then add a foo+someapprovedsender@domain filter
| before it for anyone you want to reach your inbox.
| davchana wrote:
| Almost every provider (social media, banks, websites and
| spammers) also know this, and routinely remove anything
| after + in @gmail addresses.
|
| Indian Retirement Fund website, NPS, government operated,
| will take your abc+nps@gmail.com at signup, no errors,
| but will not let you login saying, Email Not Found. You
| have to login with abc@gmail.com to get in your account.
| vidarh wrote:
| All the places I've given addresses like that dutifully
| e-mails to the right place, so I guess I must've gotten
| lucky. But if you use your own domain with Fastmail
| (which I'd recommend anyway, so you have an easy way of
| moving elsewhere if you need to - how I was able to
| migrate to Fastmail from Google relatively painlessly in
| the first place) you can also set up catchall addresses
| so you can use the whole local-part instead:
|
| https://www.fastmail.help/hc/en-
| us/articles/1500000277942-Ca...
| freedomben wrote:
| I'm not GP but use a similar system. I just set up a global
| forwarding rule for the domain using forwardemail.net. The
| default is to let it through. If I get a spam message I'll
| check the "to" field in gmail and can quickly see who it
| was that sold it or leaked it. Can also create a rule in
| gmail to send to trash or can even add a forwarding rule
| for that inbox if needed in forwardemail
| actionfromafar wrote:
| Ideally it would be
| {keysigned_string}@{yourname}.{yourdomain}
| mstngl wrote:
| For my hosted E-Mail I've configured one inbox as "catch
| all unknown". This allows me to "generate" e-mail addresses
| on the fly without any configuration (at least receiving).
| Once one of the addresses / aliases was burnt for some
| reason I could make a separate postbox of it with all
| blocking rules and dead end for spam. This is a quite
| comfortable way for me, although the emails are not flagged
| in any way. They will come through in any case and I
| postponed the the work to any malicious event.
| ilyt wrote:
| I (with self hosted config) went a step further and made
| mail+<tagname>@domain.com ones go into a tag/<tagname>
| subdirectory
| masukomi wrote:
| are you aware that comments are a thing in email addresses ?
|
| john.smith(comment)@example.com
|
| there are also tags
|
| john.smith+sometag@example.com
|
| neither of these require any DNS or server muckery and
| _should_ be supported by major mail hosts.
|
| Of course, who knows how many random half-assed email
| validation things people have in their forms that'll prevent
| you from entering them.
| not2b wrote:
| Yes, but many email marketers know this trick and they just
| strip out the comment or tag, or else make you give them an
| address that doesn't have it.
| foresto wrote:
| Even worse: Some of them happily accept such addresses,
| but some time later, silently drop messages to you while
| claiming that they were sent.
| kaetemi wrote:
| And spammers will happily remove those bits from the
| address.
| chmike wrote:
| There is a french company named mailinblack [1] that does this.
| They protect administrations in this way.
|
| [1] https://www.mailinblack.com/
| vidarh wrote:
| Your best bet for something like is simply to set up catchall
| rule to move everything not already shunted elsewhere to a
| "staging" folder, and then use a script to apply whatever
| advanced filtering you want that your provider cant and move
| anything that should be allowed past to your inbox.
| ilyt wrote:
| The simplest hack I can think of is:
|
| * Making a wildcard email address for domain, say _@example.com
|
| _ making a filter that only allows sourcedomain@example.com (or
| user_sourcedomain@example.com) to accept mails from
| @sourcedomain
|
| Could replace it with hash in second part hashing whole
| sender's address with some secret but that might be annoying if
| you have to tell the email via phone and now it needs to be
| generated manually
|
| But
|
| > 4. Even if the original authorized party tries to email me
| from a different address at the same domain, that email will be
| handled as in (3). 5
|
| Would likely bite you HARD as it isn't too uncommon practice to
| respond from other email if say you are contacting some generic
| alias (contact@) but get answer from (john.doe@) that handles
| your case.
| gcanyon wrote:
| Yeah, I abbreviated the spec. If I were putting together a
| full requirements doc for this feature, it would have to
| include different levels/types of filtering. So e.g. if I
| registered my email with signup@walmart.com and then received
| email from noreply@walmart.com, that wouldn't receive the
| same sort of blackholing as an email using the same token but
| from *@sospammy.com
| pravus wrote:
| I had a similar idea to this and wanted to add a couple of more
| features. It essentially is policy-based email so I thought:
| * Every cert is put into a trust classification that can
| dictate a default policy * Policy items could include
| things such as rate limits, message sizes, spam filter weights,
| etc. * Identities can be tied to multiple certs to allow
| for different modes of communication when desired * Allow
| for a trust classification labeled as "public" that is the
| default classification (with strict limits by default) *
| Make common mail items first class objects and allow URLs (e.g.
| attachments are no longer inline but must be a URL with
| metadata that can be verified before my system is willing to
| pull it on my schedule).
|
| I have other ideas as well; This is something I've been
| thinking about a lot lately. One other feature that would be
| nice is if you could somehow link it up to SMTP gateways. I
| realize that sort of defeats the purpose, but that would
| accelerate adoption of any new technology since it has so much
| gravity.
|
| Anyway, just ideas for now...
| gcanyon wrote:
| Nice! If there were a reasonable path to get from here to
| there, I'd say we should share a google doc to firm up the
| definition/requirements. But since (as far as I know) there
| is zero chance of something like this working, we'd both be
| wasting (more of) our time :-(
| nashashmi wrote:
| I guess there is a hack that can work on current systems but it
| is less seamless to setup.
|
| The '+' symbol combined with a 10 char UUID can be used to
| filter
| Hooray_Darakian wrote:
| > Every time I give out my email address, behind the scenes a
| single-source permission/token is created. 2. Thus, that one
| source is able to send me email, from the email address they
| specified at the time. 3. But if they hand over the
| permission/token to anyone else, email from that new source
| will automatically bounce/be marked as suspect/flagged (my
| choice in configuration).
|
| Do you mean hand out in a digital sense or on a business card?
| I'm not sure you can support the business card use case if you
| implement that.
| gcanyon wrote:
| More digital -- I haven't had business cards in ages. But
| even in a card case it should be possible to: 1. print cards
| with a unique token/whatever on each card (I get that this
| isn't the same as old school cards that have to be identical)
| 2. limit any given token to 3 uses (or similar)
| all2 wrote:
| I assume that business cards would have a unique email/end
| point to allow for this case, kind of like how gmail and
| others allow you to add +<stuff> to the end of your email
| address. So you'd have a set of "business card" emails +
| rules that would allow only the first sender to send emails
| to that address (for example).
| jrky wrote:
| >So you'd have a set of "business card" emails + rules that
| would allow only the first sender to send emails to that
| address (for example).
|
| Simple but genius! I love it :-)
| mminer237 wrote:
| So each business card would have to be unique with a unique
| address? I feel like it is generally considered
| unprofessional to have an email address with random letters
| in it, not to mention, you'd need a special business card
| printer to handle that.
| gcanyon wrote:
| I think yes, this would be required. An email address
| with random characters in it _for no reason_ would
| certainly be questionable, but if the use case I 'm
| proposing becomes at all known it would be much more
| understandable I think.
| ivan_gammel wrote:
| The email address can be user-friendly, but card can also
| include an unique code similar to product serial numbers,
| that is redeemed with the first message.
|
| E.g. ,,Max Mustermann"
| <ABCD-1234-XYZW|max@musterfirma.de> is a valid email
| address with unique code part.
| gcanyon wrote:
| Yep -- I wasn't thinking of business cards for this, but
| something like this would be required I think.
| plq wrote:
| > Every time I give out my email address, behind the scenes a
| single-source permission/token is created.
|
| How would this work exactly? You send the token to the
| recipient's email address? Doesn't that become a chicken/egg
| problem because the recipient could very well have the same
| requirement?
| ilyt wrote:
| That's why he wrote it is probably not possible. Per-
| recipient email is probably best you can get
| gcanyon wrote:
| Under current email protocols, 100% agreed. If we get to
| define our own RFC from scratch then much more of this
| becomes possible under a single email.
| gcanyon wrote:
| Exactly what the other replier said -- with current protocols
| almost certainly not possible, and even with complete access
| to *@mydomain.com it would likely be a serious hack, brittle
| in many ways, and not robust in others. But with a new
| protocol underlying, I could see this all being handled
| automatically. (maybe -- I haven't walked through this with a
| technical person).
| yobbo wrote:
| Sounds functionally equivalent to a whitelist of domains you
| accept from?
| gcanyon wrote:
| With much more specificity and control, and automatic.
| throw0101b wrote:
| > _Sounds like the big claim here is that it is faster._
|
| IMAP worked over 2400 bps modem connections; we now have multi-
| megabit connections.
|
| How much faster is JMAP over IMAP and what makes it faster?
| gcanyon wrote:
| In their demo video they show an inbox rendering much more
| quickly, but don't give specifics, so -\\_(tsu)_/-
| gumby wrote:
| Where are the clients though?
|
| Until Apple and Microsoft support it in their default clients,
| who will deploy it on the server?
| mortenjorck wrote:
| The standard looks great, and the IETF publication is a big step,
| but it's still caught in the middle of a chicken-and-egg problem
| between email service providers and OEMs. Even worse, only Apple
| would have any incentive at all to natively support JMAP on
| mobile, as Google would prefer you just use Gmail. It would be
| the exact same problem as trying to get Apple to adopt RCS.
|
| I'd love to see JMAP take off, but I don't see a way forward in
| the current market.
| thecosas wrote:
| Would love to see both Microsoft (for exchange especially, but
| also their free accounts) and Apple implement JMAP. That said, I
| know they don't have many incentives to do so and that makes me
| sad.
| kazinator wrote:
| Executive summary: "Webization of mailbox access for developers
| who don't understand anything outside of the web bubble".
| carlos22 wrote:
| That's a bit harsh given all the problems SMTP and IMAP have.
| They are very dated and have some exotic "features". There is
| not a single mail client that gets _everything_ right!
| [deleted]
| kazinator wrote:
| > _They are very dated_
|
| The words "they", "are", "very" and "dated" are even older,
| so don't use them if you want to be hip.
| chrismorgan wrote:
| Two lines from a song I and rjbs wrote but never quite
| published (set to the tune of Major-General's song):
|
| > _Its JSON-centred roots and HTTP are conventional,_
|
| > _so special parsers are not needed: this is quite
| intentional._
|
| SMTP and IMAP are a pain and problematic to deal with for
| various reasons. Building on popular web tech primitives makes
| everyone's lives _much_ easier, even if you're not making a
| webmail client.
| londons_explore wrote:
| Have you tried to send SMTP email lately? Most residential
| ISP's block SMTP ports and all the encrypted variants of it.
|
| If you want something that works for everyone, it has to be
| port 443 and webby.
|
| And any mobile push notifications better be via Google/Apple
| notification services, because modern OS's don't let
| applications leave a hanging TCP connection open anymore.
| umanwizard wrote:
| Why are you trying to run an MTA on a residential network? I
| suspect you are confused about how things work. The standard
| SMTP port (25) is for communication among MTAs and yes,
| residential networks block it (as they should) as any home PC
| sending on it is 99.999999999% likely to be part of a botnet.
| Sending mail from a home PC to the outside world is done by
| submitting it to an MTA on the SMTP Submission port (587)
| which your email provider should have given you credentials
| to. Home ISPs don't block port 587 AFAIK.
| chrismorgan wrote:
| > _99.999999999%_
|
| Eleven nines is very excessive. Frankly even _six_ nines
| would still feel excessive, though I'm sorry to say that
| five might not be any more. Fifteen years ago, I think even
| three nines would have been excessive. Legitimate outgoing
| SMTP was fairly common in those days, and botnet SMTP
| probably proportionally rarer. You know what, even _one_
| nine might have been excessive less than twenty years ago.
| [deleted]
| kazinator wrote:
| SMTP and IMAP are different things.
|
| Destination e-mail domains to which you want to send mail
| have SMTP servers. To send them mail, you have to contact
| their SMTP server somehow. If not directly, then through an
| intermediary.
|
| > _If you want something that works for everyone, it has to
| be port 443 and webby._
|
| That doesn't follow. SMTP is already authenticated and SSL-
| protected (or can be). The port number isn't the problem,
| it's the spam.
|
| Suppose that I run an alternative mail server, so that you
| can send me mail over HTTPS on 443.
|
| If you're a residential subscriber, I'm still blocking you
| the same way.
|
| Only, it's harder now. I have only one static IP address, and
| have to serve web requests on it on port 443. So I can't
| block you at the IP level; I have to let you access my web
| site (open to all) but block your use of the specific API.
| That's more costly in terms of system resources; I have to
| let you connect, and do the SSL handshake and submit
| requests, instead of turfing your packets at the IP layer.
|
| > _modern OS 's don't let applications leave a hanging TCP
| connection open anymore_
|
| That has been the case since BSD Unix introduced sockets.
| When the application quits, the connections close. (At best,
| there is a graceful shutdown in the background, where the
| protocol stack exchanges the final FIN segments.)
| danpalmer wrote:
| I have a hard time believing that JMAP is good specifically
| because it's yet to grow much further than Fastmail. I love that
| it's open, and I'm a long term happy paying customer of Fastmail,
| but as an engineer I'd be skeptical of JMAP. I don't have the
| expertise to know if JMAP solves the necessary problems, and
| there are probably not that many engineers who do as deep
| IMAP/POP knowledge is somewhat rare at this point.
| ocdtrekkie wrote:
| The problem is Gmail. Google is a bad actor who significantly
| prefers clients have to support a proprietary API, even though
| JMAP takes all of the proprietary hacks Gmail built and
| standardizes them. (Things like snoozed emails, labels, etc.
| cannot be implemented with IMAP, but can with JMAP.) Supporting
| JMAP would mean clients that have hacky issues syncing things
| around labels and snoozed emails could just work, without
| having to use a proprietary Google API to do it. That alone
| would be a huge benefit to JMAP being not just widely used, but
| specifically used by Gmail.
|
| The problem is Gmail compatibility has been used as a club to
| beat down competing OS platforms before, and Google has a
| strong vested interest in requiring clients use their
| proprietary APIs and features. Building walled gardens is the
| core way Google extracts value.
|
| It's amazing how the people who have the hardest time believing
| in JMAP all work or have worked for the company that is most
| strongly vested in it's failure.
| chrismorgan wrote:
| JMAP was initially developed at Fastmail, but it changed shape
| quite a bit during the standardisation process at IETF, with
| significant input from multiple other providers. The end result
| was definitely the better for it. (In the end, RFC 8620 has two
| authors listed--one from Fastmail, one from Oracle.) JMAP's
| good stuff.
|
| (Source/bias: I worked on Fastmail's webmail from 2017-2020.)
| awill wrote:
| First they need to get massive email providers to offer JMAP
| support, and then get clients to support it. Surely this is
| simply too big a ship to steer.
|
| Google is not going to support this, and isn't that >50% of the
| market?
| solarkraft wrote:
| They just need an IMAP/SMTP <-> JMAP bridge. This allows
| (small) providers to add support without much effort and
| there's suddenly a demand for clients (and vice versa good
| clients will increase demand for JMAP support).
|
| The website lists jmap-proxy (https://github.com/jmapio/jmap-
| perl) Its age, technology choice and lack of documentation
| aren't exactly confidence inspiring, however.
|
| Stalwart (https://github.com/stalwartlabs/imap-server/) seems
| to include a proxy feature (for both, though it's non-obvious
| to discover) and be better maintained.
|
| A functioning proxy is make or break for me. If it works I can
| jump right into making a client, if it doesn't there's no
| point.
| awill wrote:
| but a proxy doesn't have any benefit over regular IMAP. It's
| just a stop-gap.
| chrismorgan wrote:
| Stalwart is the other way around: Stalwart JMAP Server is an
| actual JMAP-native server, then Stalwart IMAP Server is an
| IMAP4-to-JMAP proxy, allowing you to connect with IMAP
| clients, and converting that into JMAP.
|
| What you want is a JMAP-to-IMAP4/SMTP proxy, which is what
| the jmap-perl proxy is/was (or at least the IMAP4 part). On
| the matter of technology choice, note that most of Fastmail's
| backend is Perl, so it was an obvious choice for such a tech
| demo being made by Fastmail devs. It wasn't designed for
| production use.
| singpolyma3 wrote:
| It's so hard to remember that JMAP isn't an April fool's joke...
| dathinab wrote:
| The problem is that it still needs a conversion to classical mail
| (just now on the server instead of client side) which comes with
| the problem of braking signing.
|
| I'm not quite up to date wrt. JMAP but the last time I checked
| (quite a while ago) their approach to "fixing" that problem was
| security wise fundamentally broken.
|
| Through then most mails are not signed anyway. So for many use-
| cases this isn't an issue.
| lxgr wrote:
| What do you mean by "classical mail"?
| jeffbee wrote:
| The fact that JMAP has ~zero adoption outside Fastmail itself
| contradicts the "much needed" part of this title.
| Nextgrid wrote:
| The problem is that email has been taken over by a handful of
| providers, all of which have "growth & engagement" as their
| business model and would rather not implement _any_ open
| protocol at all.
|
| IMAP remains supported for backwards-compatibility, but I'm
| sure its shortcomings are seen as a _feature_ to push users
| towards the official clients so there is no incentive to
| implement another open protocol to address them.
| stonogo wrote:
| This is _a_ problem, but the _other_ problem is the tools to
| implement the service. You can use Cyrus, Apache James, or
| Stalwart, and that 's _it_. These tools do not integrate with
| anything; in the case of Stalwart (the only JMAP server not
| in "experimental" status) you can't just install a JMAP
| server attached to an existing email service; you have to
| hand it complete control of everything, even unto the on-disk
| storage of mail. This is a complete non-starter for any email
| service outside of hobby/personal hosting.
|
| In other words, even if someone _wanted_ to make JMAP
| available to their users, they 'd have to tear the whole
| thing down and rebuild it in JMAP's image, and the tools
| available to do so are not fully-featured or integratable
| enough to do so.
| josephg wrote:
| Cyrus is what fastmail use for their own mail servers. And
| even the fastmail web ui uses jmap.
|
| I don't know where it says jmap support is experimental,
| but I think it's pretty stable and well supported in
| practice. The main maintainers of the project depend on it
| utterly.
| StalwartLabs wrote:
| > These tools do not integrate with anything; in the case
| of Stalwart (the only JMAP server not in "experimental"
| status) you can't just install a JMAP server attached to an
| existing email service; you have to hand it complete
| control of everything, even unto the on-disk storage of
| mail.
|
| This point you mention is being improved. The next release
| of Stalwart JMAP (expected in one or two months) will
| delegate user management to either a SQL database or an
| LDAP directory. Messages will be stored in either Maildir
| or MinIO/S3. And all other information will be in either
| SQLite or FoundationDB. All these features were already
| implemented except MinIO/S3. Development progress can be
| tracked at https://github.com/stalwartlabs/mail-
| server/tree/main/crates...
| nousermane wrote:
| Yep. If you go and register a new gmail account today, there
| will likely be no option to enable IMAP access for that
| account, altogether.
| bscphil wrote:
| That appears to be incorrect.
| https://support.google.com/mail/answer/7126229
| jeffbee wrote:
| Why would you post a baseless conspiracy theory that is
| easily disproven by anyone in less than a minute?
| IceWreck wrote:
| Why would you need to enable IMAP ? It works out of the
| box. Every non-android platform uses IMAP to access your
| account (k9 mail, outlook, thunderbird, the iOS/mac email
| client, etc).
| philipwhiuk wrote:
| As a former K9 Mail developer I will say that the Google
| extensions to IMAP for Labels and OAUTH (neither of which
| are standards) are a pain in the backside that no email
| platform would have dealt with were it not for the fact
| they are huge.
|
| (I did a spike development for OAuth and a separate
| investigation into Labels when I had some free time).
|
| So they are definitely not nice IMAP citizens.
|
| Oh and then there's the issues with Labels that their own
| documentation apparently gets wrong...
| jeffbee wrote:
| You do have to go into the gmail settings to enable IMAP,
| FWIW.
| ilyt wrote:
| Case in point: MS making it more and more annoying to use
| IMAP.
|
| Hell, now you need to create oauth2 app _just to login from
| non-approved client_ , as they recently forced OAUTH2 auth on
| IMAP clients. Sure thunderbird works but most lesser known
| clients require a lot of fuckery to make work (and possibly
| admin permissions for domain, not sure).
| ggm wrote:
| https://github.com/simonrob/email-oauth2-proxy
|
| "Just works" I run it with mbsync at the command line.
|
| You do need a client id and some interaction with your O365
| admin.
| xfour wrote:
| I tried to implement this for quite a while but the ecosystem
| situation both server and client seemed to be a status of
| "Weekend Project" rather than a robust implementation. Is there
| commitment to create a reference implementation etc.
| quaintdev wrote:
| There is no incentive for existing email providers to adopt new
| standard. They would never adopt something new & improved
| unless it's groundbreaking.
| jeffbee wrote:
| You can cry conspiracy all you want, but the fact is that
| even Thunderbird, _the_ flagship open-source email client,
| does not support JMAP.
| commoner wrote:
| To anyone interested in bringing JMAP support to
| Thunderbird, the Bugzilla bug is here:
|
| - Add support for new JMAP protocol:
| https://bugzilla.mozilla.org/show_bug.cgi?id=1322991
|
| There's also Ltt.rs, a free and open source JMAP email
| client for Android:
|
| - Ltt.rs source code: https://codeberg.org/iNPUTmice/lttrs-
| android
|
| - Ltt.rs on F-Droid:
| https://f-droid.org/en/packages/rs.ltt.android/
| toomuchtodo wrote:
| Can one donate specifically to Thunderbird to implement
| JMAP?
| commoner wrote:
| I don't think so, but you can ask Thunderbird if they are
| willing to earmark your donation for JMAP specifically:
|
| > Who can I email directly with questions about giving?
|
| > If you have a question about giving to Thunderbird,
| please contact us via this form. We will do our best to
| follow-up with you as soon as we can. If you need
| technical support, please head over to Thunderbird
| Support for assistance.
|
| https://www.thunderbird.net/en-US/donate/
|
| You can also try contacting the developer who offered to
| work on JMAP integration for pay:
|
| > I can't commit to a project of this size however since
| I work freelancing and my availability is fluid. I am
| open to being sponsored/contracted in order to do this as
| part of my job.
|
| https://bugzilla.mozilla.org/show_bug.cgi?id=1322991#c23
| msmithstubbs wrote:
| Mimestream[1] is a new email client for Mac. It's currently
| gmail only but JMAP support is on their roadmap.
|
| https://portal.productboard.com/mimestream/1-mimestream-road...
|
| If anyone else would like to see it supported consider upvoting
| on their roadmap.
|
| [1]: https://mimestream.com/
| crispinb wrote:
| * * *
| ocdtrekkie wrote:
| The issue is that there's a single monopoly provider who very
| much likes forcing all of the client apps to support their
| proprietary API. When 70% of users are Gmail, and Gmail has a
| vested interest in not supporting JMAP even though it's better,
| it's a hard sell for other client apps to invest effort.
|
| The solution, of course, is monopoly regulation. AOL Instant
| Messenger was forced to interoperate and embrace standards. If
| our legislators had the actual courage to do their jobs in this
| day and age, Google would be legally required to shift Gmail
| features to using open standards like JMAP.
| [deleted]
| cdme wrote:
| I love what Fastmail does for open source and the email ecosystem
| writ large -- there's even a dedicated macOS client for JMAP
| https://swiftmail.io (curious when we might see Apple adopt it).
| nailer wrote:
| Just want to say Fastmail is the best. If you find GMail laggy
| and other providers to have weak spam filters, give your money to
| the Fastmail people.
| mkenyon wrote:
| I love JMAP. It's what allowed me and my team (at 1Password) to
| easily add support for Masked Emails, where we randomly generate
| your email address in addition to your password.
|
| Our own Madeline Hanley wrote about that experience, if you'd
| like to see what it's like to work with JMAP:
| https://blog.1password.com/making-masked-email-with-jmap/
| saberworks wrote:
| 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.
| SparkyMcUnicorn wrote:
| > 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 wrote:
| > 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 wrote:
| > 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.
| echelon wrote:
| 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 wrote:
| 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.
| echelon wrote:
| The users don't have to interact with any piece of this.
| It can be 100% a backend implementation detail.
|
| If you did want to surface it, the controls could be as
| simple as "block sender", "opt out of 3rd party
| contacts", "sender X wants you to connect with sender Y -
| allow?", etc. Very coarse grained, very easy and
| intuitive.
| kelnos wrote:
| 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.
| ilyt wrote:
| How JMAP made that better ?
|
| Last time we did something like that new email address was just
| "add entry to a Dovecot database", fully protocol agnostic
| calvinmorrison wrote:
| because the masked email API matches the rest of the JMAP
| API, so it's easy to extend and support. Also, 1Password
| isn't running Dovecot, Fastmail is. So they're asking a 3rd
| party is a fairly standards conformant way to go and create a
| new email alias
| nemoniac wrote:
| Off the current topic but since you're promoting 1Password, I
| notice their cookie policy references EU legislation but
| chooses not to comply with it. Do you know if that's
| intentional?
| remram wrote:
| Indeed that is very awkward: "European Union ("EU")
| legislation requires all website operators to inform website
| visitors about their usage of cookies"
|
| Later: "first-party and third-party cookies are used on:
| 1password.com (...)
|
| Stating that you need consent and not asking for it is
| extremely weird.
| mlhpdx wrote:
| > Every time a change occurs to data within the user, the modseq
| is incremented by one and the new value is associated with the
| changes.
|
| This isn't what I'd call modern, and isn't much fun. I'd really
| like to see a email access API standard that gives way on lock-
| oriented and session-oriented concepts.
| chrismorgan wrote:
| You're quoting https://jmap.io/server.html#modification-
| sequences, about a _server implementation detail_. Clients
| don't get exposed to it directly, but deal with opaque state
| strings given by the server (which _might_ leak this
| implementation detail to some extent, e.g. if you just
| stringify the numbers directly, but a client would be wrong to
| use it that way, and no harm can come if it does anyway).
|
| Back to the server considerations: note that this _isn't_ the
| only way it can be implemented, but it's the simplest and most
| efficient approach.
|
| For the design as a whole, there are very good reasons for it
| all being done the way it is done. The thing to realise to
| begin with is that JMAP isn't actually about email: it's an
| object synchronisation protocol (JMAP core, RFC 8620), that
| just so happens to have email as its first motivating use case
| (JMAP for Mail, RFC 8621).
|
| It's definitely different in shape from what web developers are
| used to; but if you want actual object synchronisation
| (synchronising stuff for offline use, efficiently fetching new
| and updated records, whether for the entire collection or for
| queries (which includes searches and things like single-folder
| views), that kind of thing), it's almost the simplest
| principled design possible. When people implement any form of
| synchronisation or offline support atop their REST or GraphQL
| or whatever APIs, they'll either do something very similar to
| what JMAP does, or build on some other suitable primitive like
| Merkle trees, or (and this is what normally happens) be
| unreliable in ways that make inconsistency _likely_ to occur,
| and data loss distinctly possible.
|
| > _I'd really like to see a email access API standard that
| gives way on lock-oriented and session-oriented concepts._
|
| I'm not sure what you mean. Could you expand?
___________________________________________________________________
(page generated 2023-05-30 23:00 UTC)