Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JMAP: Like IMAP but Not Really

unencumberedbyfacts.com

Post reply on HN
Print view View original

221–230 of 235 posts

Re: JMAP: Like IMAP but Not Really

#221

Post by tya99 »

y4mi wrote: post #102
mehrdadn wrote: post #89

Earlier quoted context omitted.

Holy cow, I will have to look into this. Thanks a ton!!

filters cannot be applied retroactively, however. be sure to write your filters before receiving anything. Especially important if you're importing your email for the first time... and insanely annoying if you want to debug such an advanced filter. as always with fastmail: It has great features... but always with a massive caveat.

Wouldn't using something like https://github.com/lefcha/imapfilter also be an option?

It would be awesome if some day there was a "jmapfilter". I think JMAP would be really efficient for this use case.

Re: JMAP: Like IMAP but Not Really

#222

Post by inputmice »

Mailtemi wrote: post #200
shittyadmin wrote: post #124

So, you say that it doesn't maintain a persistent connection, but that poses a problem - it needs a way to do push notifications still I assume? Those need an open socket somewhere - does JMAP allow for it or does it make you rely on a 3rd party?

If you are mention Ios/Android, yes you need the proxy to redirect push calls from JMAP server to the push services of apple/google.

FWIW this is completely reasonable. Push in XMPP works the same way. They way FCM (Google) and APNS (Apple) work is that only the app vendor with proper credentials can trigger push notification for an app. Therefor it has to be proxied through the app developers server anyway. And of course it cleanly separates the MDA from the various, proprietary push solutions.

Re: JMAP: Like IMAP but Not Really

#223

Post by elFarto »

hardwaresofton wrote: post #3

I really want to see some innovation in the email space. The landscape is like a sea of false promises and dashed dreams. SMTP is one of the bread-and-butters of the internet, yet it just doesn't seem to be moving forward (maybe that's for the best), and no one's building extensions on top of it. Maybe I'm naive in thinking it was possible but we could have avoided this whole "make an account on X messenger so we can…

Honestly I'm surprised no one has suggested replacing SMTP with a HTTP POST request. All you would need is an email address -> HTTP URL conversion (which I believe something like WebFinger already has). Then just POST your message to that URL and you're done. ISPs can run proxies that just authenticate that requests are from users and forwards them on.

Re: JMAP: Like IMAP but Not Really

#224

Post by rakoo »

e12e wrote: post #183
hardwaresofton wrote: post #3

I really want to see some innovation in the email space. The landscape is like a sea of false promises and dashed dreams. SMTP is one of the bread-and-butters of the internet, yet it just doesn't seem to be moving forward (maybe that's for the best), and no one's building extensions on top of it. Maybe I'm naive in thinking it was possible but we could have avoided this whole "make an account on X messenger so we can…

> if someone had just jammed XMPP and SMTP together. Xmpp is/supports federated/ion (user1@server1.com can message user2@server2.com). But the major players (by numbers) wanted silos: Google (talk) and fasebook (first gen of messenger). They basically went lol, screw users (arguably because: spam. But hello, Gmail? And today fb spam...). So thank Google and Facebook for deliberately gimping it so you can't fb message…

The official reason for Google to give up on this is that there was a real problem of incoming spam from lousy domains, and no major player wanted to play the federation game with them. It's not as simple as you make it sound.

Re: JMAP: Like IMAP but Not Really

#225

Post by hardwaresofton »

toomuchtodo wrote: post #219
hardwaresofton wrote: post #217

Earlier quoted context omitted.

This is probably where we differ -- I don't think limiting email to asynchronous communications helps anyone, and it could have been written in an extensible manner to also support synchronous communication. Even if I'm completely wrong and email should be left asynchronous, SMTP could at least have introduced some standard around chat negotiation and a protocol negotiation process for remote chat servers/agents.

> Even if I'm completely wrong and email should be left asynchronous, SMTP could at least have introduced some standard around chat negotiation and a protocol negotiation process for remote chat servers/agents. Wouldn't this be best handled with SRV DNS records or some other service discovery process outside of SMTP? https://wiki.xmpp.org/web/SRV_Records

I agree that it would be but my wanting to bundle it with SMTP is for forcing the linking of the two concepts -- I guess my argument is less technical and more that I think the two concepts should have been linked early on -- I think if we'd bundled email and instant messaging (aka "live" or "instant" email), we would have encouraged service providers to offer the service in a standards compliant way.

I don't have a preference on exactly how the service discovery would work -- I'm merely suggesting instant messaging could/should have been an extension of the SMTP spec like websockets were an extension of HTTP.

[EDIT] - Looking over the link you sent, that is exactly what would have made a good addition in my mind -- if SMTP had some sort of functionality to suggest that XMPP was available and where to check (DNS SRV records)

Re: JMAP: Like IMAP but Not Really

#226

Post by toomuchtodo »

hardwaresofton wrote: post #225
toomuchtodo wrote: post #219

Earlier quoted context omitted.

> Even if I'm completely wrong and email should be left asynchronous, SMTP could at least have introduced some standard around chat negotiation and a protocol negotiation process for remote chat servers/agents. Wouldn't this be best handled with SRV DNS records or some other service discovery process outside of SMTP? https://wiki.xmpp.org/web/SRV_Records

I agree that it would be but my wanting to bundle it with SMTP is for forcing the linking of the two concepts -- I guess my argument is less technical and more that I think the two concepts should have been linked early on -- I think if we'd bundled email and instant messaging (aka "live" or "instant" email), we would have encouraged service providers to offer the service in a standards compliant way. I don't have a…

After thinking about it some more, I agree with you. There should be some command or extension in SMTP and JMAP that, if the user permits it, the availability of XMPP could be exposed and a redirect of some sort could be provided (similar to intentions on iOS).

Re: JMAP: Like IMAP but Not Really

#227

Post by brongondwana »

hiccuphippo wrote: post #118
eggsampler wrote: post #54

Earlier quoted context omitted.

I've been a happy Fastmail customer too, until I was made aware that you can impersonate other Fastmail customers by just spoofing the email address. Their servers just happily accept it. SPF and DKIM all pass with flying colours, and the only way you'd know it's happened is if you have DMARC on and happen to notice a pass in the report you don't remember sending. Well, that is if the recipient doesn't reply to the s…

You should just send an email impersonating their CEO to their IT telling them to fix it ;)

That will definitely work

Re: JMAP: Like IMAP but Not Really

#228

Post by black-tea »

eggsampler wrote: post #54
bad_user wrote: post #40

FastMail is behind this protocol and from what I've read JMAP has evolved out of their web interface. I've been a happy customer, even though lately I flirted with going back to GSuite for my personal email, but after a trial realized that Gmail does many things well, except for being a good email service. So I went back to FastMail and renewed for another 2 years. Seeing this new protocol is exciting, because JMAP i…

I've been a happy Fastmail customer too, until I was made aware that you can impersonate other Fastmail customers by just spoofing the email address. Their servers just happily accept it. SPF and DKIM all pass with flying colours, and the only way you'd know it's happened is if you have DMARC on and happen to notice a pass in the report you don't remember sending. Well, that is if the recipient doesn't reply to the s…

Use GPG if you're concerned about authenticity. It's the only way. What you describe is not a problem with Fastmail, it's a problem with basic communication without cryptography.

The problem is if any email service did this you'd start trusting the "from" field and that is wrong. Do not trust the from field. It's as simple as that.

Re: JMAP: Like IMAP but Not Really

#229

Post by amaccuish »

Karunamon wrote: post #87
amaccuish wrote: post #70

Earlier quoted context omitted.

I've sadly been looking for, and never found, an open source EWS IMAP/(Cal/Card Dav) gateway. I'd love it if my users could get a full experience using Outlook for Mac for example. Right now I recommend them to just use Apple Mail/Calendar/Contacts or Thunderbird with the tb-sync extensions.

It sounds like you’re describing DAVMail

Wrong way. I want to offer EWS from my linux (not exchange) mail setup. Davmail consumes EWS and offers Cal/Card dav etc.

Re: JMAP: Like IMAP but Not Really

#230

Post by amaccuish »

mschuster91 wrote: post #113
amaccuish wrote: post #70

Earlier quoted context omitted.

I've sadly been looking for, and never found, an open source EWS IMAP/(Cal/Card Dav) gateway. I'd love it if my users could get a full experience using Outlook for Mac for example. Right now I recommend them to just use Apple Mail/Calendar/Contacts or Thunderbird with the tb-sync extensions.

So you'd like for users to keep their familiar Outlook setup, but with a FOSS server backend? Not sure if this is possible, I don't know if Outlook uses the EWS protocol, OWA or something entirely different :/

Yupp. It works well with Windows Outlook, since they can use ActiveSync. But Mac Outlook doesn't have ActiveSync (or Card/Cal dav).
Post reply on HN