[HN Gopher] JMAP - a modern email open standard
___________________________________________________________________
JMAP - a modern email open standard
Author : tambourine_man
Score : 984 points
Date : 2023-05-30 17:26 UTC (1 days ago)
(HTM) web link (jmap.io)
(TXT) w3m dump (jmap.io)
| mildred593 wrote:
| JMAP is great but is not nearly enough. it would still need some
| improvements... on the protocols and on the available servers. I
| experienced slowdowns with Cyrus (which is the most advanced
| implementation I believe) on complex requests.
|
| Also, the great idea behind JMAP is to chain requests so a series
| of tasks is performed on the server and the client then get the
| end result. This works great for the majority of cases but the
| replacement syntax (to replace results from a previous request in
| a following request) is not powerful enough in some cases (when
| trying to reuse complex responses in follow-up requests)
|
| The other issue is that there is no way to easily groups e-mails
| from a given contact. There are JMAP extensions for CardDAV and
| CalDAV that can be of some use but it's difficult to bridge them
| with the Email spec and get all e-mails from a given contact for
| instance.
|
| Last, it lacks editing features like appending a custom header to
| existing e-mails. The fact that JMAP abstract away all of the
| MIME format is great, but makes it difficult to just add a single
| header to an email.
| xvilka wrote:
| Worth checking once implemented in Mutt and Thunderbird.
| ceving wrote:
| No end-to-end encryption. Just another useless example how to do
| the same in another way.
| 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.
| rockorager wrote:
| There aren't any that go direct to maildir. There is mujmap
| that syncs to notmuch. I wasn't able to get it to work the way
| I wanted, and wrote my own that I'd be happy to share. I've
| been using it for around a month with no issues but that's
| certainly not much confidence yet!
|
| The advantage of going straight to notmuch is that the data
| model is so similar to JMAP that synchronizing is just that
| much easier. Both ends can give you a state and all emails
| which have changed from that state. Then it's just a matter of
| updating the tags on those to each end or uploading/downloading
| the email if it's new.
|
| I get something like 1.7kB round trip data usage when there are
| no updates (really it's 0kB save for the keepalive when used in
| daemon mode) and ~100ms for that round trip. This is in
| comparison to several megabytes for a single mbsync poll (even
| when there are 0 changes) and ~5 seconds
| 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...
| deknos wrote:
| Does thunderbird and evolution support this nowadays?
| 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.
| danielheath wrote:
| Really? A staff buyout is one of the best indicators I
| can think of.
|
| I'd rather entrust my mail service to someone who wants
| to keep running it strongly enough that they'll put their
| own money down to keep doing it.
|
| The alternatives are mostly investor-owned companies - if
| this years CEO decides to fuck you over, they can replace
| any staff who object.
| labster wrote:
| For comparison, newcomers like Gmail have only been in
| the market for 19 years.
| [deleted]
| 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.
| jfb wrote:
| They're a business, that the users of their services pay
| money to. The only differences between them and Google is who
| their users are, and who is significantly more likely to
| shoot useful products in the head.
| brongondwana wrote:
| Perfectly legitimate question - and I don't think you should
| have been downvoted for asking.
|
| We're entirely funded by our customers, and fully self-
| bootstrapped. We have no debts to outside parties.
|
| We have 8 owners, 7 of which work in the business and the 8th
| is the brother of one of the founders (and only owns a couple
| of percent).
|
| Source: I'm CEO. Have worked here since 2004, through the
| Opera acquisition (I moved to Norway for nearly 2 years) and
| back. We've controlled our growth such that we keep our
| spending under our income - I know, what a shocking idea in
| current day!
| 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.
| kevincox wrote:
| I had the same experience and ended up leaving after my
| trial.
|
| I contacted support and the just said "yup, those emails
| were suspicious and were correctly rejected." Err, no. If
| I'm the customer and day I want to receive an email you
| shouldn't be rejecting it.
|
| I likely wouldn't have noticed if I didn't run a service
| that was emailing me. But after that I noticed other
| senders also being blocked. Adding to my address book also
| didn't work, I guess that whitelist runs after the
| accept/reflect decision.
| jeltz wrote:
| A pity because Google also has the same issue. They
| silently just throw a ton of mails away.
| kevincox wrote:
| I heard a rumour that a huge portion of messages that hit
| Google servers are outright dropped. Not the spam folder,
| gone forever. Apparently the dropped number was much
| closer to 50% than 0%.
| 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.
| eproxus wrote:
| For a long time I thought the spam filtering was not very
| good, but what eventually led to that was my own mistake
| of setting "learn as spam" on the spam folder itself. In
| Fastmail's own words:
|
| > Note: We recommend that you do not mark your Spam/Junk
| Mail folder to automatically learn as spam. This can
| create a false positive feedback loop. Imagine an email
| is incorrectly classified as spam, put in your Spam/Junk
| Mail folder, and then learned as spam. That means future
| emails that aren't spam are now more likely to be
| incorrectly marked as spam, sent to your Spam/Junk Mail
| folder, and learned as spam. Only mark folders to learn
| as spam if they're folders you manually move email to.
| sillystuff wrote:
| > all the spam overwhelmingly comes from gmail.com
| accounts.
|
| Report it to google, and make the world a better place.
|
| But, first check the first received header that was added
| by your mail provider's servers to make sure the spam
| really is coming from gmail's servers-- oldest received
| headers are at the bottom, newer as you go up (e.g., view
| message source, view headers, or some such option in your
| client; look for received: from...).
|
| Add a short blurb at the top of your message about spam
| received from their domain, include the message with full
| headers as text at the end of the email message body
| (some clients like MS outlook break mail, so this may be
| the only way the recipient will be able to view the
| headers if the sender is using one of these broken
| clients. Also attach the original spam message as an
| attachment (this will provide something useful to the
| recipient when sent by most ?all? non-Microsoft mail
| clients).
|
| Send it to abuse@gmail.com
|
| Report the stuff your spam filter catches too.
|
| At past jobs, we took these reports very seriously. They
| were usually an indication that a user's account was
| compromised.
| denton-scratch wrote:
| > Report it to google, and make the world a better place.
|
| Are you kidding? The Goo has never paid any attention to
| the victims of spam emanating from gmail accounts.
| sph wrote:
| Thanks for the advice. That said, there's hundreds of
| email addresses I get spammed from.
|
| > Report it to google, and make the world a better place.
|
| That's line is not gonna work on me. Google is a trillion
| dollar company that only cares about its bottom line, not
| a public good. They can sort it out themselves.
|
| I have better things to do with my time than do Google
| spam team's job for free by reporting each spam email I
| receive manually.
| hnthrowaway8860 wrote:
| They literally don't care. Tried many times. It's like
| trying to talk to a black hole. :(
| [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.
| ndr wrote:
| I wish their android app supported offline access.
|
| It's a huge PITA when you're offline (say in a venue with no
| cover) and need to pull a ticket out of your inbox.
|
| I'm a customer and can't believe they've been in business for
| so long. I guess this feature will never come.
| dogmatism wrote:
| That's what imap clients are for
| the_pwner224 wrote:
| Unfortunately all the FOSS email clients for Android have
| horrible UI/UX.
| synecdoche wrote:
| Could FairEmail be of interest?
| https://email.faircode.eu/
| qingcharles wrote:
| 20 years here. One of the only companies I don't have a
| complaint about.
| 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.
| psankar wrote:
| > If you hillary your emails
|
| LOL
| 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.
| datkam wrote:
| [dead]
| 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
| ekianjo wrote:
| > It's not intended to work as a web service independent
| of their product
|
| So I guess this is tied up then.
| abhibeckert wrote:
| iCloud+ is primarily cloud backup and storage solution
| for iPhones. Those two are both very tightly integrated.
|
| The custom email domain is a side feature... but it does
| work well, and it's essentially free (assuming you want
| your photos properly backed up... and who doesn't).
|
| I'm not sure if that help article is accurate though - I
| would think you can subscribe to iCloud+ from their
| website. You have to go to the website to manage your
| email domains for example.
| [deleted]
| crossroadsguy wrote:
| You are forced with 2-3 email addresses on your own domain
| when you have to send a mail from while you can receive on
| any. That's a huge bummer.
| kstrauser wrote:
| It's not infinitely flexible, but for $1/month for
| dependable SMTP/IMAP, I think it's still a hell of a
| bargain.
| 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).
| dejan wrote:
| You could also stick with free Gmail accounts and add on
| top all addresses and domains you need via gmailify.com[1]
| for flat $6 per year. It's custom domains extensions for
| Gmail with own dedicated relays.
|
| [1] https://www.gmailify.com
| lilyball wrote:
| FWIW Fastmail has their own Files space that you get too,
| though it doesn't have the level of integration with other
| stuff that Drive does.
| Sander_Marechal wrote:
| I use Soverin: https://soverin.net/ which lets you create
| multiple mailboxes on the same 3.25/month package.
| 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/
| nocoiner wrote:
| Seems 99% reasonable, but the per-message limits make it a
| non-starter for me. I get why they're doing it and totally
| understand where they're coming from, but the off-chance
| that an incoming email gets bounced due to no fault of my
| own (other than subscribing to a higher tier) just doesn't
| work for me.
| itsrajju wrote:
| Their message in/out limits are not strict. They send a
| warning if you go over, and allow for some tolerance upto
| 25% above the plan limit.
|
| https://www.migadu.com/pricing/#what-after-reaching-
| limits
| Shared404 wrote:
| Can confirm, I've gotten warnings when sending lots of
| outgoing mail.
| demurgos wrote:
| I can also vouch for Migadu. I've been using it for 6-7
| years with 4 different domain names because they only
| charge for usage; not per domain or user. The few times
| when I contacted support they were also very helpful.
| garrickvanburen wrote:
| I wrung my hands over pricing for quite a while.
|
| Then I realized the alternatives (including letting everyone
| in the family decide their own email solution) were worse.
| denkmoon wrote:
| I think Fastmail are missing out by not having a "Family"
| plan for this kind of use case, but just because you're not
| handing over money doesn't mean Gmail is cheap.
| fastball wrote:
| I use Purelymail[1], which costs me $10 per year for our 13
| family accounts.
|
| [1] https://purelymail.com
| kolp wrote:
| Another happy user of Purelymail here. The GUI is
| unpolished, but deliverability and reliability have been
| excellent for me in the few years that I've used it.
| Unlimited custom domains and inexpensive.
|
| It's not suitable for bulk sending, but for transactional
| and personal email, I've found it meets my needs.
|
| Be warned, however, that it appears to be a one-man band,
| and if he goes under a bus...
|
| I'm also a happy user of Migadu. More polished GUI and more
| features. I've never hit their limits, so not sure how
| suitable it would be for a medium-sized enterprise. As with
| Purelymail, it's not intended to be used as a bulk sending
| service.
| nkko wrote:
| Did I read somewhere that Scott is training his brother
| as a failsafe. Joking aside, I love the service as it is
| just what I need for not mission-critical stuff, as I
| tend to board domains and love to experiment with stuff.
| Would love somewhere else instead of Roundcube, but not
| sure is there anything modern enough. The only killer
| feature I need is super fast power search.
| speleding wrote:
| Only one account needs to be the $5 one to get the custom
| domain, the rest of the family can have a $3 / month account
| and they can use the custom domain too.
| 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.
| DANmode wrote:
| Can anyone speak to the current state of their security?
| WordSkill wrote:
| "You can build an account where you mix and match the plan
| level to each user. For example, you can build a Fastmail
| Family by adding additional Standard and Basic plans for
| adults and children." - https://www.fastmail.com/pricing/
|
| Only one of your accounts needs to be Standard tier ($50/y)
| to allow up to 100 custom domains. The other 5 accounts can
| be Basic tier ($30/y) and still use as many custom domains as
| you give them access to. Total undiscounted cost for your
| family would be $200/y.
|
| Use the 25% 1Password discount to reduce your total to
| $150/y. You have the option to extend that 25% discount up to
| 3yrs and receive an additional discount for paying in
| advance. Your total for your first 3 years would be $420,
| then $560 for each 3 years thereafter.
|
| Alternatively, you could consider allowing all your family
| members use the same Standard account ($105 for the first
| 3yrs) but with multiple email addresses. Use labels to
| surface each address for the relevant family member.
|
| In my case, I created a family@surname address for any family
| business, and a name@surname address for each family member.
| Each family member has set their Fastmail app to focus on
| their own address. Yes, technically, they can see each
| other's email, but it hasn't been a problem. I presume they
| use throwaway gmail accounts for stuff they want to keep
| totally private.
|
| We share a specific custom domain for our masked emails and
| love that feature, especially the 1Password integration
| although that has some rough edges.
| 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.
| d-man wrote:
| I have a similar situation and I think that you might be able
| to have 1 standard account and 5 basic accounts in this
| situation. Depending on what capabilities the other 5 people
| need.
| tjbiddle wrote:
| Fastmail is a business expense for me, so I don't bat an eye
| at those numbers compared to my other software charges.
|
| But honestly, I think even if I didn't expense - I'd still
| pay for it. It's a great product; everything is top-notch.
| 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)
| kiwijamo wrote:
| I did look into that for my family domain but the storage
| space for the basic plan was so low I ended up sticking
| with regular accounts. Only two accounts though so
| bearable. If I was in OP's situation with six family
| members I probably wouldn't have gone down the FastMail
| route.
| pazimzadeh wrote:
| Infomaniak is good too
|
| https://www.infomaniak.com/en/hosting/service-mail/
| bullen wrote:
| SMTP is the main protocol, how you store things is not supposed
| to be a standard?
| 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.
| chrismorgan wrote:
| The _protocol_ is stateless, just as HTTP is stateless1. This
| means that every request is handled independently. Pagination
| is like "please give me page one for the query 'foo'" followed
| by "please give me page two for the query 'foo'"--so if you
| lost your connection in the middle, you're fine. By contrast,
| IMAP is stateful, and pagination can be more like "I'm starting
| a query 'foo', please give me the results" followed by "please
| give me the next page", with the result that a dropped
| connection can leave you stranded high and dry, having to do
| everything over again if it's even possible to. (In practice,
| now-widely-adopted extensions have been developed to avoid this
| happening. And really this whole paragraph is a simplification
| of reality.)
|
| --***--
|
| 1 Well, HTTP is stateless, but in the HTTP/2 and HTTP/3 wire
| formats, the HPACK and QPACK header compression schemes use
| connection-level state. But developers talk in terms of HTTP
| requests, not HTTP/2 or HTTP/3 frames, so it's OK and HTTP is
| still stateless.
| userbinator wrote:
| JSON? At least it's not XML.
| juped wrote:
| JSON makes me realize how good we actually had it with XML.
| 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.
| klysm wrote:
| But how do you actually index text with a single bloom
| filter?
| j16sdiz wrote:
| You don't.
|
| You put mail into buckets (using some hashes), and hands
| out the bloom filter for each bucket.
|
| It is better than downloading all mail, but it is nowhere
| near the speed I want my email search to be.
| klysm wrote:
| And there is a bucket for each word? That seems like a
| lot of bloom filters
| 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...
| Avamander wrote:
| Eugh, that might fly in some enterprise contexts but it
| violates a lot of principles what S/MIME is meant to be used
| for.
|
| Is there a draft for strict JMAP transport security?
| chrismorgan wrote:
| JMAP is already TLS-only <https://datatracker.ietf.org/doc/
| html/rfc8620#section-8.1>:
|
| > _To ensure the confidentiality and integrity of data sent
| and received via JMAP, all requests MUST use TLS 1.2 or
| later, following the recommendations in RFC 7525. Servers
| SHOULD support TLS 1.3 or later._
|
| > _Clients MUST validate TLS certificate chains to protect
| against man-in-the-middle attacks._
| Avamander wrote:
| That's not "MUST prevent the end-user from trivially
| accepting the invalid chain" though, which is also an
| issue with current MUAs and IMAP/SMTP.
| 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?
| Xeoncross wrote:
| They would reuse a few large fragments. Maybe one each
| month or year. There would need to be some sort of
| locking mech to keep clients from clobbering each other,
| or maybe not since the final state of the filter would
| probably be the same anyway.
| willhackett wrote:
| You can possibly generate these filters on the server-side
| and serialize them for the client. I like the idea of only
| needing to store some pointers and metadata locally; that
| said I do prefer all my mail is available offline.
| 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.
| Avamander wrote:
| The receiving mail server could encrypt everything for the
| mailbox owner's S/MIME keypair, that would be really rather
| seamless with already existing protocols and clients. This
| "only" leaves the problem of key management to the user,
| which in my opinion is far out of scope for JMAP as well.
|
| Search will also become difficult but it can be done. At
| least most mail clients could display all your mail if you
| have the key.
| 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.
| j16sdiz wrote:
| It don't help with my existing multi-GB email archive.
| eviks wrote:
| You could also have the bigger desktop client fetch
| everything for the purposes of building an index (and
| also having a backup of your email), then your smaller
| phone doesn't have to fetch everything
| 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.
| eviks wrote:
| With such a huge limitations you've described in your next
| reply, it's awfully closer to awful than to prefect
| philipwhiuk wrote:
| How do you handle email on other devices?
| gsich wrote:
| You could leave the mails on the server.
| 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?
| pmontra wrote:
| I do have a Gmail account because of Android and maybe I
| self squatted a Gmail account before I had an Android
| phone. I can't remember.
|
| However I have a POP3 mailbox bundled with a domain I own
| since last century. That's my personal email. I never
| moved it to Gmail because I always downloaded my mail:
| some emacs package, then Netscape, then Outlook express,
| then Thunderbird. As a software developer I'm always
| close to my laptop and before smartphones it was normal
| not to access email when we were on vacation or on
| weekends, holidays, etc. When I'm on vacation now I read
| my mail on my phone, reply and bcc me, leave all messages
| on the server and download them when I'm back home.
|
| My work email is managed in the same way. Another POP3
| account bundled with my own work domain name. No friend
| or customer ever complained about anything in almost 20
| years, hence constant access to the archive of past email
| is a nice to have feature but not an important one.
| [deleted]
| 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.
| kortex wrote:
| I know the idea, but it's usually not 14-15 standards,
| it's usually like _one_ really entrenched old crusty
| standard (if you are lucky) or (more likely) emergent
| glued-together patchwork of hacks.
|
| It's definitely an uphill battle to introduce any new
| standard, but it does happen. USB-C, HTML5, ECMA6, I
| would say are some success stories.
| 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.
| csb6 wrote:
| > so it's not clear to me why I need an alternative to that
| stuff.
|
| It seems like you don't need it. However, a lot of people
| access their email across multiple devices and want everything
| to be kept in sync/efficient to fetch. Currently IMAP is the
| standard for this, but JMAP is attempting to provide a less
| complicated replacement.
| jeltz wrote:
| Nothing about IMAP is simple. JMAP was created partially due to
| IMAP being so complicated to implement and use.
| crispinb wrote:
| Does anyone other than Fastmail use it?
| amluto wrote:
| I'm mystified by one thing about JMAP: JMAP is supposed to
| support offline clients, but the Fastmail iOS app has no offline
| support whatsoever. What gives?
| mildred593 wrote:
| Offline is just a matter stable identifiers on the server. It's
| the client that is responsible for caching the e-mail content
| on the device.
|
| Also, the fact that JMAP makes it convenient to only download
| part of a message, and let the server do all of the message
| parsing does not encourage the client developer to do much
| processing client-side and keep e-mails blob in cache to be
| processed offline.
| chillbill wrote:
| I would really like to see encrypted email integrated with this
| and with Fastmail.
| doodlesdev wrote:
| > A lot of the optimisations for efficient client-server sync
| require the server to be able to read the message. If everything
| were encrypted, the server would basically be a dumb blob store.
| This is particularly bad for mobile, where you only want to sync
| partial information. 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. The best advice is probably to run your own "JMAP
| server" on trusted hardware; otherwise you need to sync the
| entire multi-gigabyte mail spool to all your devices. JMAP is
| also simple enough that you could run the server on multiple
| machines with an underlying replication protocol over encrypted
| links and have that do your smarts.
|
| They lost a huge opportunity. Encryption at rest of emails and
| E2EE should've been how we built these protocols from the start,
| here we get a chance to try it and... no, just "self-host"
| instead.
|
| I enjoy self-hosting stuff, but it's just not what normal people
| will be doing, and they deserve privacy too. Also, self-hosting
| email is possibly the most complicated self-hosting task you can
| think of due to deliverability issues.
|
| My biggest pain point with mail providers that support
| encryption, such as Proton or Tutanota, is that I have to run a
| "bridge" application that hosts the IMAP server on my machine,
| since otherwise there's no way to get the encrypted payloads into
| my mail client. Otherwise, I will have to use their proprietary
| client (proprietary in the sense it implements their own
| protocols). This sucks, and it could be solved at the protocol
| level with JMAP. I expected this to be a top priority of the
| Fastmail team when developing this, but unfortunately it's not.
| danielheath wrote:
| > They lost a huge opportunity. Encryption at rest of emails
| and E2EE
|
| To implement E2EE for email would involve replacing literally
| every part of the tech stack at literally every provider.
|
| You can't lose an opportunity you never had.
| drdaeman wrote:
| I don't think so. I mean, I can't imagine what exactly needs
| to be replaced, and I'm not really getting what that GP quote
| is talking about, unless it's email metadata (encryption of
| which is impossible in practice) or full-text search (I
| always forget about it, as I don't really use it myself)
|
| First, at-rest encryption is perfectly doable with most
| typical software setups (Postfix/Exim/Dovecot/Cyrus/etc), and
| I think should be not so hard to achieve with proprietary
| systems as long as they a) capable of dealing with MIME
| messages (don't reprocess emails for storage) and b) have
| milter-like capabilities in their local delivery pipeline.
| You just throw in a milter that encrypts messages to a user-
| provided key (such as S/MIME or - hey, don't throw anything
| at me - PGP public key, or whatever MUA may support), and
| rely on the mail user agent (aka mail client) to be able to
| decrypt this mail.
|
| Second, I'm not sure how E2EE is even in the picture. It - by
| definition - should be all happening on the endpoints, so I'm
| not sure how providers (let alone protocols they use) even
| fit in the picture. And if anything, it's not on IMAP but on
| SMTP. But even then, SMTP/LMTP are delivering MIME-
| encapsulated data (that typically happens to be HTML or text
| pieces), and they don't really care about what sort of data
| is in there. This significantly hinders anti-spam
| capabilities, though.
| danielheath wrote:
| > should be all happening on the endpoints
|
| Right - but Fastmail never had the opportunity to do that,
| which is what I read GP as asking for.
| userbinator wrote:
| There's already something called PGP.
| j16sdiz wrote:
| .... and S/MIME
|
| Nothing got enough adoption
| Avamander wrote:
| S/MIME is almost everywhere though. From Outlook to Gmail.
|
| PGP is just quite sucky, that's indeed supported by only a
| select few.
| myself248 wrote:
| In spirit, I would love to self-host, but I have neither the
| sysadmin skills to do it, nor the time to keep up on security
| patches, etc.
|
| I definitely don't want a "hosted" offering where my stuff
| lives on someone else's hardware and vanishes when they go out
| of business.
|
| What I would love is a "sysadmin contractor" who runs my stuff
| for me, _on my hardware, on my bandwidth_. I pay them not for
| the hosting, but for the admin skill. Probably a step up from
| fiverr, but not a full-time employee.
|
| This wouldn't scale very well if the contractor wanted to work
| for a hundred-plus people like me and learn all our individual
| tech stacks. But if I could pick from the contractor's menu of
| supported stuff, and configure it with a menu of supported
| connections, they should be able to automate a great deal of
| the administration across all their clients.
|
| Does anything like this exist? I'm aware of various host-it-
| yourself platforms and distros, but they all expect me to be my
| own admin, which is a dealbreaker.
| alwayslikethis wrote:
| Self-hosting email is just hugely problematic because of the
| extensive anti-spam measures by major providers, causing
| deliverability issues if you don't use a lot of effort to
| keep your domains and IPs clean. As the saying goes, friends
| don't let friends host their own email.
| Kalium wrote:
| Encryption at rest is beyond the scope of any reasonable
| systems data interchange protocol. That's not a missed
| opportunity, it's a nonexistent one.
| chrismorgan wrote:
| > _This sucks, and it could be solved at the protocol level
| with JMAP._
|
| It couldn't. You've failed to understand the reasoning
| summarised in the first paragraph. E2EE comes at a significant
| and _fundamental_ cost, and not one most people want to pay.
|
| There's a reason why your Proton Mail and the likes are
| crippled in ways like this: because that's the best we know how
| to do with that kind of approach.
|
| There's also the matter that first-party end-to-end encryption
| is snake oil: <https://hn.algolia.com/?query=chrismorgan+snake+
| oil&type=com...>. See also Fastmail's reasoning for not
| offering any of this kind of thing:
| <https://www.fastmail.com/blog/why-we-dont-offer-pgp/>.
| akulbe wrote:
| Three questions.
|
| 1. How hard would it be to get 19 years worth of Gmail to
| Fastmail?
|
| 2. I have 4 different domains worth of mail all coming in to one
| mailbox? Would this be an insane cost on Fastmail?
|
| 3. For those of you who have already switched from Gmail ->
| Fastmail, is there anything you miss after the move?
| 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.
| gcanyon wrote:
| At least from the promo video that seems very much like
| Apple's "supply a unique email" feature. Which is better
| than nothing, but waaaaay less feature-ful and much more
| manual than my ideal setup.
| 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.
| lilyball wrote:
| Fastmail supports both yourname+foo@example.com and
| foo@yourname.example.com. I use the latter precisely to
| avoid the problem of sites that don't play well with plus
| addresses.
| 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}
| kevincox wrote:
| This is basically what I do. {tag}-{signature}@{domain}.
|
| The upside is that it is easy to generate new addresses,
| I don't need to talk to my mailserver. The small number
| of addresses that need to be revoked are manually added
| to a backlist.
| 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.
| afiori wrote:
| The obvious solution would be to use
| john.smith+me@example.com and treat
| john.smith@example.com as a semi-spam folder
| kevincox wrote:
| Yup, since I'm using my own domain domain I use kevincox@
| for public sharing and generated emails for sharing with
| companies. Therefore there is no obvious path from the
| email I give them (which bypasses the spam filter and can
| be revoked) to my general email address. Although it is
| easy to find my general address online it is fairly
| heavily spam-filtered. And unknown address is subject to
| an very harsh filter if it wants to end up in my inbox.
|
| So basically there are three tiers:
|
| - Single relationship emails. Guaranteed delivery until
| revoked.
|
| - General inbox.
|
| - Unknown to addresses, unlikely to hit the inbox.
|
| (The address are actually signed and blacklisted rather
| than generated+revoked but that is just an implementation
| detail)
| lilyball wrote:
| Comments aren't semantically meaningful, anyone can strip
| them out without changing the meaning of the email address.
| kaetemi wrote:
| And spammers will happily remove those bits from the
| address.
| [deleted]
| 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 :-(
| grepfru_it wrote:
| I think this would work, question is what's the market and
| does the product fit? If there's a (potential) user base
| I'll jump in a build with ya!
| gcanyon wrote:
| I think the market is: 1. anyone who
| wants a clean inbox -- maybe less profitable 2.
| any company that wants better protection against phishing
| attacks -- maybe more profitable 3. Edit to add:
| someone pointed to https://www.mailinblack.com/ I don't
| speak French, but that's apparently a company that
| (somehow) provides a service similar to the description
| here to high-profile targets.
|
| If the skateboard version of this seems technically do-
| able _without_ having to convince the entire world to
| switch to a new protocol I 'd be happy to jump into a
| google doc to noodle it further.
|
| On the surface it seems like: 1. it
| would have to rely on email addresses alone -- I don't
| know another way to transmit information from sender to
| receiver that fits within current "what's your email?"
| standards. 2. it would have to have a sparse
| enough address space that accidental collisions are
| unlikely -- so maybe 8 alphanumerics for ~41 bits?
|
| But if you have other ideas I'd love to hear them --
| griping about email has been a thing of mine for 20
| years...
| 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)
| Hooray_Darakian wrote:
| I think the more practical issue is that if each business
| card has its own single use token then your printer is
| doing one copy of each card. Doable, but not how any
| business card company is setup today. I do get the desire
| for this sort of thing, but I also think most users of
| email treat an address as a static entity.
| 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.
| danielheath wrote:
| I'm on fastmail. 1 and 6 are a feature they offer (I use it).
|
| In place of automation for features 2-5 - anytime I feel an
| address is misused, I add a rule that forwards messages to
| trash (or spam, for egregious offenders).
| gcanyon wrote:
| Can you describe (or point me to the docs) how 1 works? Do
| they generate custom email address extensions, or...?
| 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.
| thomasfl wrote:
| Looking forward to see all kinds of chat, messaging and
| discussions systems being implemented on top of JMAP. Next
| generation messaging will hopefully be more open.
| 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]
| eschaton wrote:
| In other words, "they don't sit atop the currently-
| fashionable implementation techniques that are the only thing
| webshits happen to know."
|
| Well, no shit, they were designed before HTML and HTTP, not
| just JavaScript, and there's zero need to actually shove them
| into that mold because they already exist and are fine as
| they are in terms of protocol-level features. If you can't
| deal with that maybe you shouldn't be trying to do
| development at that level.
|
| Meanwhile, all that energy spent reinventing the protocol
| layer to be maximally aesthetic to people for whom all the
| world is JavaScript running in a browser could have been used
| to actually improve the applications running over the
| protocol.
| mildred593 wrote:
| JMAP really solves many problems and allows you to do many
| things that are just not possible with IMAP. Also, IMAP has
| many ways to (badly) perform the same task, not all
| supported by all servers or all clients. MIME parsing is
| not easy to do and there is not always quality libraries
| available for your language... JMAP solves all of this.
| kazinator wrote:
| JMAP doesn't solve any problems that I have. That's
| because I'm not a monolithic mail company trying to take
| a slice out of Gmail's pie.
| 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.
| kazinator wrote:
| SMTP and IMAP are a solved problem.
|
| They are problematic for only one kind of entity: someone who
| has delusions of becoming the next gmail.
|
| Everyone else can just set up an open source SMTP and IMAP
| setup using existing programs that work, without writing a
| single line of parsing code.
|
| I don't trust this "open standard" bullshit. When the only
| thing running JMAP is Fastmail, it's a Fastmail-specific
| protocol.
|
| If you want developers to interface with it, you can't hide
| it: you have to document what the requests and responses look
| like. The "open standard" rhetoric has good optics; even more
| so with the IETF rubber stamp.
|
| The underlying idea behind JMAP is that the future consists
| of only large mail operators who somehow forward mail among
| themselves. Routing to SMTP servers is gone, and so is self-
| hosting, mostly.
|
| If you want your own mail domain, you can do that, but to
| operate it, your instance must connect over some web protocol
| to an e-mail monopolist.
|
| The IETF may have signed off on this, but I look forward to
| what the EFF have to say.
| chrismorgan wrote:
| Speaking as one who has drunk the JMAP kool-aid (I worked
| for Fastmail for a few years): you sound like you've never
| tried to write an email client, or done much with email in
| general. Because the conclusions you're coming to are
| _completely_ back-to-front.
|
| Suppose you want to write a client that can do email
| sending (SMTP), email reading (IMAP), contact book
| (CardDAV) and calendar (CalDAV) interactions.
|
| SMTP/IMAP autodiscovery is limited at best, and
| CardDAV/CalDAV autodiscovery nonexistent, I think, so new
| users will have to find the details for several things,
| which is a big hurdle--or else you'll have to recognise and
| special-case individual providers, which basically means
| Google and Microsoft get a massive unfair advantage. By
| contrast, JMAP handles autodiscovery of all this: type in
| an email address, and it finds the JMAP endpoint, which
| handles all of the stuff. (I will admit that this is
| currently more aspirational than real: to begin with it
| requires a DNS SRV record and/or a /.well-known/jmap HTTP
| response; and the means of authentication is deliberately
| unspecified at this stage, so we kinda need to wait around
| to see what providers settle on for authentication, with
| some kind of OAuth arrangement probably most likely.)
|
| And then perhaps your client is webmail; if so, you simply
| can't use IMAP or SMTP. I guess you _could_ try talking
| them over WebSocket or something like that (still requiring
| a proxy of some kind, even if a pass-through one), but
| that'd be painful; instead, _everyone_ rolls their own
| thing, and so there's never any webmail cross-
| compatibility. In JMAP, by contrast, the _only_ thing you
| can't do from a browser is looking up DNS SRV records.
| Everything else works, so that you can run your own webmail
| client that talks directly to the origin server. This
| allows you to disentangle the provision of service and
| software, which is very desirable for decentralisation.
|
| Well, now you want your client to produce notifications
| when new messages come in. If you're writing for a desktop
| platform, fine: you can keep your IMAP connection open. But
| if you're on a mobile platform, you probably can't do that,
| and certainly can't reliably, so... you're stuck needing
| some kind of proxy and server component again. No good. But
| with JMAP, you set up a push subscription and it works just
| like any other app, without needing to keep a connection
| open.
|
| So there are three simple and concrete advantages of JMAP
| over the legacy protocols. JMAP actively bolsters
| decentralisation, in email providers, in domain names, in
| contact book and calendar support, in webmail, and in
| mobile notifications. There are other functional advantages
| too. JMAP enables some moderately complex batching that
| makes some sorts of realistic operations vastly faster than
| IMAP due to being able to skip many round trips. And JMAP's
| pleasantness to work with _directly_ should not be
| understated: no one wants to work with SMTP or IMAP
| directly because they're painful protocols, and so _of
| course_ all of that stuff tends to get extracted into a
| single library that protects you from them; by contrast,
| working in raw JMAP is pleasant and easy, which can
| genuinely open you up to doing things that would have been
| too painful to do through your IMAP library. And if you use
| JMAP, your mail client can skip worrying about MIME parsing
| (which is landmine-filled territory) if you choose. You can
| write a useful and complex standalone email workflow with
| nothing more than HTTP and JSON libraries.
|
| > _The underlying idea behind JMAP is that the future
| consists of only large mail operators who somehow forward
| mail among themselves. Routing to SMTP servers is gone, and
| so is self-hosting, mostly._
|
| This is all completely wrong: JMAP is for client-server
| communications and doesn't replace server-server
| communications, which still use SMTP. JMAP does not prop up
| email monopolists.
|
| > _If you want developers to interface with it, you can 't
| hide it: you have to document what the requests and
| responses look like._
|
| I have no idea what this is about. The spec shows examples.
|
| > _The "open standard" rhetoric has good optics; even more
| so with the IETF rubber stamp._
|
| There was no IETF rubber stamp (which I take you to be
| using as a pejorative). There was collaborative process
| with people from a variety of companies who took what
| Fastmail had designed for their own use and wanted to
| share, and made it considerably better.
| kazinator wrote:
| I've worked in the mail area, though not recently. Twenty
| years ago I worked on an IMAP4 transport, optimized for
| wireless, for Windows CE ("Microsoft Mobile OS" or
| whatever it was called).
|
| I don't find your arguments rationally convincing. You're
| comparing developing mail software using _libraries_ for
| JSON, HTTPS and other pieces, versus doing the same thing
| while developing IMAP _from scratch_.
|
| It boils down to "web developers don't have nice
| libraries for IMAP access and are too busy making another
| clone of React or Typescript to make one".
|
| It's not realistic to develop a new mail client without
| IMAP (complete non-starter) even if it suports JMAP.
|
| This shit only benefits people who are trying to be the
| next Gmail. On the surface, it's somewhat good for users
| who rely on monolithic mail service in that if there are
| more such services, they have more choice.
|
| It's bad for everyone is not using a monolithic mail
| service, who doesn't want a new mail client speaking a
| new protocol or to install services for that or anything
| else.
|
| > _And then perhaps your client is webmail; if so, you
| simply can't use IMAP or SMTP._
|
| That claim is amazing; in another browser tab right here
| I'm logged into my self-hosted RoundCube webmail which is
| accessing my inbox with IMAP, and sends with SMTP. Of
| course, it does those things at the PHP back end.
|
| I think you may be conflating "webmail" with a "browser-
| based, purely local mail client application not accessed
| over the network".
|
| If such a thing is not able to speak SMTP or IMAP, maybe
| the Javscript world should tool up?
| chrismorgan wrote:
| > _You 're comparing developing mail software using
| libraries for JSON, HTTPS and other pieces, versus doing
| the same thing while developing IMAP from scratch._
|
| This is nonsense. Most of my comment was describing
| protocol-level advantages of JMAP over IMAP: things that
| you can't get with IMAP (+ SMTP + CalDAV + CardDAV +
| ...), and things that affect the user experience. I did
| mention at one point that JMAP is such that you don't
| even _need_ any library to achieve useful things with it,
| whereas you wouldn't tend to get far without such
| libraries on SMTP /IMAP, but I wasn't making that
| comparison in any other way.
|
| > _It 's not realistic to develop a new mail client
| without IMAP (complete non-starter) even if it suports
| JMAP._
|
| Not true. It depends on who you're targeting and what
| you're trying to achieve. Sure, most will still want to
| support IMAP/SMTP due to JMAP's current lack of
| widespread adoption, but honestly going native JMAP only
| carries some pretty compelling technical and functional
| advantages.
|
| > _This only benefits people who are trying to be the
| next Gmail._
|
| I rebutted this fairly clearly in my previous comment.
| You seem to be fixing on first-party software, where
| service and software are provided by the same entity, but
| this is something that JMAP is _better_ about compared to
| IMAP /SMTP, removing some of the unfair advantage first-
| party software had and levelling the field for all
| service providers and domain names, due to autodiscovery
| that works, and exposing the server in a way that even a
| web frontend can _directly_ access.
|
| Just because Fastmail is _currently_ the only notable
| provider shipping JMAP doesn't mean that JMAP is about
| Fastmail. There's a fair bit of interest from other
| providers, it just takes time. Also I would point out
| that Fastmail has not the slightest ambition of being
| "the next Gmail"; their business model, history and
| market positioning should make that very clear.
|
| > _I 'm logged into my self-hosted RoundCube webmail
| which is accessing my inbox with IMAP, and sends with
| SMTP. Of course, it does those things at the PHP back
| end._
|
| That RoundCube requires a backend, and its frontend has
| to talk something other than IMAP and SMTP, is a problem.
| Until JMAP, every single webmail client has done its own
| thing for a client-server protocol, and they've almost
| all been terrible, and so you've kinda had to learn _two_
| things to develop it, and you'll have functional
| limitations all over the place that make developing the
| frontend hard. By contrast, with JMAP, a webmail frontend
| and a desktop app are talking the same protocol. That's
| _very_ valuable.
|
| I did go a little too hard on this in that a backend
| _can_ allow you to connect to arbitrary mail sources
| (though in practice webmail is almost always first-party,
| service and software coming from the same provider), but
| that fact that you _need_ that extra backend is still a
| problem, for performance and for privacy: your software
| vendor shouldn't need to be able to access all your mail;
| it's much better if the software can talk directly to the
| service provider.
|
| > _If such a thing is not able to speak SMTP or IMAP,
| maybe the Javscript world should tool up?_
|
| It's not possible due to the web's security model; it'd
| be a fiasco if browsers let JS initiate arbitrary TCP
| connections--far too much software assumes that only
| trusted software can talk on the local network. From time
| to time there are ideas about relaxing this limitation by
| server opt-in (along the lines of CORS preflight
| requests), but they've never gone anywhere yet and I
| don't think they will any time soon, and certainly it
| will never be _fully_ relaxed.
| kazinator wrote:
| Things that you can't get with IMAP and SMTP are not
| e-mail, pretty much by definition. They are in the area
| of embracing and extending e-mail.
|
| > _You seem to be fixing on first-party software, where
| service and software are provided by the same entity_
|
| No I'm not. It's a given that those are unbundled.
|
| For instance, today, you don't have to use a Google mail
| client with Gmail, right?
|
| Maintaining their dominance doesn't depend on locking
| people to the Gmail webmail interface.
|
| I take it for granted that the purveyors of JMAP want
| people to go nuts developing clients.
| kazinator wrote:
| > _doesn't replace server-server communications, which
| still use SMTP._
|
| Sure, for now!
| chrismorgan wrote:
| JMAP is completely unsuitable for server-server message
| delivery. JMAP is an object synchronisation protocol for
| working with persistent, per-user resources. None of that
| is in the slightest bit useful for server-server message
| delivery: there is no user account, and there are no
| persistent objects--what you need is purely fire-and-
| forget. Your scoffing suggests that you haven't
| understood what JMAP is.
| kazinator wrote:
| > _JMAP is completely unsuitable for server-server
| message delivery_
|
| That is obvious; but the scum who want to disrupt and
| destroy e-mail won't stop there.
|
| Of course, big, monolithic mail companies would love to
| get people off the old protocols. Once that is in place,
| they will make deals to move mail among themselves in
| some new ways, and e-mail as you know it is finished.
|
| > _Your scoffing suggests that you haven't understood
| what JMAP is._
|
| I'm not assuming you or anyone else in this thread is an
| idiot; please return the favor.
|
| (I _am_ assuming that you 're naive ... sorry about
| that.)
| eschaton wrote:
| Amen, all of the actually-interesting features could have been
| done within the framework that MRC (RIP) laid down for IMAP,
| without going wholly into "screw line oriented text protocols,
| gotta be Web 2.0!" bullshit.
| kazinator wrote:
| JSON is not "modern".
|
| * curly braces are not modern.
|
| * quotes around strings are not modern, and neither are
| backslash escapes like \n
|
| * commas and colons to separate items are not modern; square
| brackets for arrays are not modern
|
| * JSON's printed floating-point format which looks like
| 123.56E+78 can be seen in computing-related documents from
| the late 1950's.
|
| * HTTPS isn't new, and sending formatted data over web
| transport as an API is soon going to be approaching thirty;
| remember SOAP from the 1990's?
|
| The SOAP was handled by so many hands it shrank down to JSON.
| 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.
| kazinator wrote:
| You misunderstand the state of the e-mail world. Running an
| MTA on a residential network for receiving is completely
| fine.
|
| _Sending_ mail directly from a residential network by
| connecting to the given mail domain is a nonstarter. Hasn
| 't worked in twenty years or more. That doesn't require a
| MTA; only a MUA.
|
| Your mail program (MUA) like Thunderbird or Outlook, or the
| _mail_ utility in a Unix-like OS, can perfectly well work
| without a configured SMTP server. You send to
| bob@example.com. The mail program will do a MX type DNS
| query for example.com and find out that the
| mail.example.com is the mail host for that domain. It will
| resolve that again with an A query to get an IP address,
| and connect to port 25 of that host to send the mail.
|
| In a world without spammers, that's how things would work.
|
| In a world with spammers, mail servers block connections
| from random addresses like residential IP addresses.
|
| Users (who want to send mail from home) have to resort to
| using forwarding hosts: their mail client is configured to
| make an SMTP connection not directly to a target mail
| domain, but to a configured host, like something run by
| their ISP or some commercial SMTP provider.
| 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]
| gsich wrote:
| No, they don't. 465 and 587 should always be open. If not,
| complain, you have crippled service you pay for.
|
| Other MX might reject you on port 25 due to a residential IP,
| but that is not an ISP block.
| 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.
| danpalmer wrote:
| As I said, I'm a long time paying Fastmail user, and working
| at Google hasn't caused me to rethink that.
|
| It's worth remembering that the Gmail API does more than IMAP
| can, and predates JMAP. I understand how Google would get to
| this point.
| ocdtrekkie wrote:
| I understand how they got to this point, but I hope you
| understand that fifteen years ago, Google would've lead the
| charge to make these things a standard, and today they will
| sit inside their moat behind their castle walls and ensure
| even the standard someone else built for them doesn't
| succeed because openness is harmful to their bottom line.
| danpalmer wrote:
| I do get your point, but I also wonder if this could be
| the exception rather than the rule. Google still appears
| very active in setting web standards and contributing a
| lot of open technology and standards.
| ocdtrekkie wrote:
| I would say that Google is active in setting web
| standards that help Google, less so setting web standards
| that help anyone else. Which, for what it's worth, is
| capitalism, but unregulated monopoly remains a
| fundamental flaw in the design of capitalism.
| 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.)
| danpalmer wrote:
| Oh that's really good to know, I didn't realise it had that
| much outside input. In that case I'd feel a lot more
| comfortable betting on it.
| kovac wrote:
| I'm not sure if I understand the claimed benefit of jmap being an
| open standard. Isn't imap already an open standard? If so, if
| Gmail adopted jmap and added proprietary APIs to it, wouldn't we
| end up where we are now?
| buzzert wrote:
| IMAP is a really difficult and antiquated protocol to work with
| also. It's responses are in a non-regular grammar (as opposed
| to JSON), and IMAP server implementations vary wildly.
|
| As a result, properly functioning IMAP clients/libraries are
| really few and far-between.
| TimTheTinker wrote:
| The benefits are that (a) JMAP is superior to IMAP in ways that
| really affect end-users of email clients, and (b) as opposed to
| other high-performance email protocols, JMAP is an open
| standard.
|
| > if Gmail adopted jmap and added proprietary APIs to it,
| wouldn't we end up where we are now?
|
| The promise is that vendors would be able to use JMAP out of
| the box.
| catiopatio wrote:
| > in ways that really affect end-users of email clients
|
| If you don't mind enumerating what you have in mind, what
| specifically?
| chrismorgan wrote:
| I worked through a few in
| https://news.ycombinator.com/item?id=36134733.
| 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.
| solarkraft wrote:
| It has all the benefit. I don't want to have to worry about
| IMAP and that's what it allows me to do - with not only
| theoretical browser compatibility, but a complete complete
| client library fully ready.
| mildred593 wrote:
| The problem with the proxy is that to be efficient, I believe
| the proxy will need to store all IMAP messages in an indexed
| form on the proxy-side.
|
| The problem with IMAP is that some requests are not possible
| efficiently, and the real breakthrough of JMAP is that those
| requests are now possible and clients are now allowed to be
| fast. For that though, the server-side JMAP needs to access
| the indexed mail store directly.
| 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.
| solarkraft wrote:
| Oh, that's unfortunate. I had hope for Stalwart, not so
| much for the Perl proxy.
|
| Is there anything else on the horizon? Switching away from
| my current E-Mail provider isn't a realistic option for me
| and won't be for almost anyone else.
|
| Man, that sucks.
| chrismorgan wrote:
| jmap-perl was only ever a tech demo and somewhat
| incomplete (e.g. it lacks push subscriptions, and a few
| bits that could theoretically be supported are stubs),
| but it's not actually _all_ that much code--even in
| fairly verbose Perl and including contacts and calendar
| support, the entire repository is around 11,000 lines of
| code (naturally depending on libraries for things like
| HTTP, OAuth, IMAP, SMTP, CalDAV and CardDAV), and could
| be shorter.
| singpolyma3 wrote:
| It's so hard to remember that JMAP isn't an April fool's joke...
| eschaton wrote:
| I sincerely thought it was when I first heard of it.
|
| At least Microsoft had an excuse with the wacky variations of
| the Exchange protocol: They built a Big Thing before Internet
| email "won" and thus have a bunch of legacy to carry forward.
| This is just a "solution" looking for a problem.
| chrismorgan wrote:
| Take a look through
| https://news.ycombinator.com/item?id=36134733 to see some of
| the concrete problems JMAP solves.
| 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"?
| dathinab wrote:
| The normal MIME based mail format with all it's pain in
| header encoding, multi part bodies, language and encoding
| annotations etc.
|
| EDIT: Note to be confused with Media-Types which are a (very)
| small part of the MIME specification and are sometimes called
| MIME Types. Due to their use in http they got their own spec
| later on (and are also redefined in the HTTP spec instead of
| referring to the mime spec, funnily their re-definition in
| the HTTP spec doesn't 100% match the specification in the
| MIME spec, luckily only in "don't do this every" parts).
| btown wrote:
| I was hopeful that https://www.nylas.com/ would be the de-facto
| "adapter" placing a common API surface on top of the major
| providers and dragging them into a modern-API world. They even
| had an email client of their own as a proof of concept (forked by
| one of the original authors as
| https://github.com/Foundry376/Mailspring - and its reusable core
| https://github.com/Foundry376/Mailspring-Sync may be interesting
| to many here). But they've pivoted towards making their API only
| available behind B2B contracts and opaque pricing, and primarily
| used for corporate email monitoring and CRM use cases - perhaps
| because security and privacy considerations are nontrivial. I'm
| still rooting for them but it's a shadow of what it could have
| been.
| AnonC wrote:
| More than a year ago, I had posted an "Ask HN: Where is JMAP
| (jmap.io) implemented or being implemented?" [1] but it didn't
| get any engagement. The situation doesn't seem to have changed
| much in the meantime. Fastmail (the main developer) seems to be
| the only one deploying it on a large scale.
|
| [1]: https://news.ycombinator.com/item?id=30088483
| 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.
| stonogo wrote:
| They don't use the word "experimental" any more but they
| call it a "work in progress":
| https://www.cyrusimap.org/imap/developer/jmap.html bottom
| of the page.
| Avamander wrote:
| The file storage approach is unfortunately super common and
| makes a bunch of really basic things difficult and slow.
| Need to phase it out more heavily, especially from new
| implementations.
| stonogo wrote:
| Telling people who have decades of perfectly serviceable
| email solutions that they need to 'phase out' what works
| is a great example of an unconvincing argument. What you
| say might be true from a developer's perspective but
| maildir is a battle-tested, accessible, well-understood
| and interoperable storage format. Bundling everything up
| behind some bespoke SQL schema might ease performance
| hurdles but it sucks for everything else.
| Avamander wrote:
| Does it work though? Nobody runs such systems at scale,
| for very good reasons, because maildir just sucks in so
| many ways. Horses have also been battle-tested, they're
| well-understood, but they don't transport tonnes of cargo
| and getting kicked in your face because they don't like
| you isn't pleasant.
|
| So if it takes a custom schema in a (No)SQL database, so
| be it, it's simply so much more performant, scalable,
| reliable and usable. It's simply idiotic how much
| maildir-based software starts "dying" at around 100000
| emails in a folder, in 2023!
| 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...
| Avamander wrote:
| It really really hasn't been. Email is just an enormously
| massive ecosystem with tremendous amount of variance that
| anything new will take a long time to adopt and a lot of
| convincing and proving.
|
| Just look at how far the deployment of something as essential
| as DMARC is, it's sad. That's not some big vendor's fault,
| it's all the small legacy cruft nobody wants to clean out as
| it might break things.
| 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?
| salutis wrote:
| FYI, the above is true for "child accounts", as my son
| painfully discovered the other day, after his school
| shoved Gmail down his throat. No IMAP in the settings, or
| anywhere else, for the next generation of users, not
| until they are 16+ in my country.
| jeffbee wrote:
| What makes you think this is for youth accounts, and is
| not simply the preference of the workspace administrator
| for your school?
| 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).
| drdaeman wrote:
| Are you sure?
|
| Because, IIRC, IMAP access must be explicitly enabled by
| going to Settings -> Forwarding and POP/IMAP -> IMAP
| access: (o) Enable IMAP. And I think it is not enabled by
| default.
| 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...
| Avamander wrote:
| To be fair here, labels are a great feature and the
| default limitation of a letter existing in only a single
| folder is a dumb remnant of ancient times.
|
| If it's still not standardized then the pitchforks are
| aimed in the wrong direction.
| 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.
| ilyt wrote:
| This looks promising, thanks.
|
| I did the song and dance for claws-mail and one day it
| just... stopped working ;/
| jojobas wrote:
| I would be migrating away (to anything) if my email
| provider pulled that on me.
| alwayslikethis wrote:
| My university uses MS for their services, and they
| stubbornly refuse to let me use IMAP (not even with OAuth).
| I have to either use GNOME Evolution for Micro$oft exchange
| protocol or a proprietary app on my phone, which enforces
| bullshit control on a device I paid for.
| AnonC wrote:
| Effectively, MS has bulldozed companies that use
| Microsoft365 into using its own proprietary protocols and
| applications (Outlook). It scares companies into not
| enabling IMAP (even with OAuth2).
| 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
| mildred593 wrote:
| What would be the benefit to using JMAP in thunderbird?
|
| JMAP main benefit is that it allows a mail client to to
| things efficiently in JMAP that are extremely difficult
| to do in IMAP or take a long time to do. Merely adding
| JMAP support in Thunderbird will not add any benefit.
|
| The benefit will come if Thunderbird is refactored
| internally to make use of the nice properties of JMAP,
| but then there will be a problem with IMAP compatibility
| which must be kept.
|
| JMAP is nice for new mail clients that can move away from
| a folder-centric paradigm, but if you already managed to
| use IMAP then it's less useful.
| 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:
| Unmet needs are legion.
| 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]
| alooPotato wrote:
| The query syntax is interesting. A json schema defining an order
| of operations to perform server side. Looks kind of gnarly tbh.
|
| At that point, seems simpler to just treat email data as a bunch
| of sql tables (i.e. lists, messages, threads, mailboxes, etc) and
| have the clients issue SQL statements to the server. Would be so
| much easier to create and read the requests and server
| implementers could lean on all the SQL tooling available.
| mildred593 wrote:
| SQLite have a bunch of features that would allow limiting what
| you can do in a request, and if you limit the access to a
| database by the user that puts e-mails in that database this is
| easily doable.
|
| I started looking at implementing that
| 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/
| Avamander wrote:
| Yet your 1password.eu DMARC is set to a very shameful p=none.
| Priorities...
| 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.
| mths wrote:
| > 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 wrote:
| 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.
| 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!?).
| JimDabell wrote:
| > 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 wrote:
| > (no date, though, so I don't know how recent).
|
| This has been one of my biggest peeves about the WWW
| since 1993. Please include publication and/or change
| dates and/or include a changelog on your pages. Do not
| force your users to resort to reading metadata, the URL
| path, the Wayback Machine, or dark magic to figure out
| when and what changed. Diff is a solved problem; why
| can't I diff a generic web page?
| 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.
| joshring wrote:
| 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.
| 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.
| brongondwana wrote:
| Also, every website would have to have a way to do this.
| That's a massive bootstrapping effort that, you can't
| change every website in the world very easily, there'd
| have to be a very massive advantage for them. I don't see
| the evolutionary pathway to get your suggestion
| implemented.
|
| Besides, this already exists anyway, it's basically:
|
| brong+secretkey@fastmail.com
|
| Or if you have fastmail style subaddressing:
|
| secretkey@brong.fastmail.com
| echelon wrote:
| `+secretkey` is easy to remove.
|
| I don't think changes are hard to push forward. Soon
| every website will require SSL. Tech giants can move the
| needle on adoption of new standards.
|
| Wanting to stay in contact with your customer is a pretty
| big forcing function for adoption.
| zrail wrote:
| > Soon every website will require SSL.
|
| This has been a very gradual change. The earliest
| announcement I can find is from 2018[1] but I'm pretty
| sure it was in the works long before. That's more than
| five years to implement a technology that browsers and
| servers at the time already had known how to do for a
| decade or more.
|
| Massively coordinated change is _hard_.
|
| [1]: https://blog.chromium.org/2018/02/a-secure-web-is-
| here-to-st...
| kazinator wrote:
| I easily implemented throw-away mailing addresses over an
| IMAP/SMTP setup.
|
| https://www.kylheku.com/cgit/tamarind/
|
| This is a CGI-scripted web application without any kind of web
| framework, in an original programming language.
|
| It authenticates you using IMAP or SASL: with direct socket
| work in a few lines of code. (That's the only integration with
| IMAP.)
|
| It manages aliases in a standard aliases file. If configured,
| it can work with the master /etc/aliases file, in which cases
| it will carve out a section of the file for itself and respect
| the surrounding file when it adds or removes aliases. I run a
| separate aliases file, though.
| kazinator wrote:
| I do most of my mailing using the RoundCube webmail
| interface. I made some patches to it.
|
| In connection with the throw-away mail aliases, the issue
| that comes up is that when you use them for sending, rather
| than just receiving mails, you want that to be available in
| the list of sender identities in the mail client.
|
| While it isn't automatic, I put in a hack which at least
| makes it easier to identify the mail identities. In
| RoundCube, a mail identity has an "Organization" field: what
| org you belong to. There is a mail header for that, IIRC.
|
| I changed the UI so that when you look at the identities list
| box, the Organization field is listed in parentheses (if it
| is non-blank). Then I use Organization to describe the
| purpose of the mail alias, e.g "Foo Mailing List" or "ABC
| Company".
|
| Only a small subset of my throw-away mail aliases become
| sender identities; I do that manually.
| nilespotter wrote:
| I use catch all aliasing and sieve out the offenders. Seems
| easier.
| kazinator wrote:
| Yes; this is for the control freak that wants to shut down
| the offenders at the SMTP level.
|
| Plus there are some other benefits.
|
| Each one is associated with note field. URLs in the note
| field are rendered navigable. I use the note fields not
| only as a reminder about what the alias is for but also for
| PW management. Throwaway mail aliases often have throwaway
| passwords associated with them too.
|
| The explicitly created aliases track their creation date,
| which can be informative from time to time.
|
| UI has a regex search over the aliases (any field).
| 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?
| abhibeckert wrote:
| Not from 1Password, but refusing to comply with EU cookie
| legislation seems to be almost universal.
|
| Is _any_ company compliant?!
|
| (I'm being facetious... my company is compliant or at least I
| think it is - not a lawyer... but it's very rare)
| 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.
| Asooka wrote:
| AFAIK, certain classes of cookies do not require consent.
| For example, login cookies.
| speleding wrote:
| The legislation requires you to ask consent for non-
| essential (ie. tracking) cookies. So unless they put a
| tracking cookie on their site the behaviour is correct, and
| that text is simply incorrect.
| matteason wrote:
| They do use nonessential cookies - Google Analytics,
| affiliate tracking cookies and more:
| https://1password.com/legal/cookies/#cookies-we-use-on-
| our-w...
| remram wrote:
| That's my bad for not quoting further, the very next
| paragraph is:
|
| > First-party cookies are set by 1Password. They help
| calculate things like page views and visitors to the
| website. Third-party cookies are set by 1Password
| affiliates for commission and advertising purposes.
|
| https://1password.com/legal/cookies/
|
| They make it clear that they know consent is required,
| that they absolutely fall into that category, and then
| don't ask.
| 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?
| karmanyaahm wrote:
| Having WebPush style push notifications is a huge advantage of
| JMAP. Right now, 3rd party mobile email clients are stuck to
| polling every few minutes or keeping a connection open.
|
| I'm looking forward to more JMAP adoption, especially on FOSS
| Android platforms.
| amluto wrote:
| The _Fastmail app_, which one might assume is the flagship
| client, doesn't work at all offline. So I'm unimpressed. Every
| other non-Webmail client I've ever used, whether POP3, IMAP,
| Exchange, or proprietary, worked at least to a reasonable
| extent offline.
| rcarmo wrote:
| I see this popping up every year (sometimes multiple times a
| year) and, as someone who used to be a postmaster and did _a lot_
| of IMAP tweaking, I have to say that even though IMAP is old and
| gnarly and increasingly out of favor (I just can't use it on
| Google anymore, only on outlook.com and my own archive), JMAP
| seems to pretty much have failed adoption-wise -- I don't see any
| relevant e-mail clients supporting it, no webmail front-ends
| claim to use it, no other providers besides FastMail seem to
| support it, and even old-style ISPs (of which there are still a
| few) don't seem to have any interest in it (source: I used to
| work in telco-run ISPs until some years ago, and still have
| friends doing that).
|
| Are there any third-party implementations of servers or clients
| with significant adoption?
| aidenn0 wrote:
| Only servers I'm aware of that support JMAP are Cyrus and
| James. Clients do seem to be thin on the ground right now, with
| https://github.com/jmapio/jmap-demo-webmail still being the one
| to use (as far as I know).
| marcus_holmes wrote:
| I'm a Fastmail customer, and speaking to them for my last
| startup, they were adamant that we couldn't use them for
| sending transactional emails to our customers. So I'm a bit
| confused why they're letting 1Password do this.
|
| Are we allowed to use JMAP for sending transactional emails via
| Fastmail now? If not, then JMAP seems to be just a method for
| creating new Fastmail email clients, because no-one else
| supports it and Fastmail doesn't allow anything but
| conventional end-user activity.
|
| Or is this wrong?
|
| If I wanted to use JMAP for my next startup, is there a
| transactional email provider who supports it?
___________________________________________________________________
(page generated 2023-05-31 23:02 UTC)