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

201–210 of 235 posts

Re: JMAP: Like IMAP but Not Really

#201

Post by miracle2k »

zAy0LfpBZLC8mAC wrote: post #174
miracle2k wrote: post #155

Earlier quoted context omitted.

Webmail was limited by HTTP, but not because HTTP is stateless; rather, it's because no mail server speaks HTTP, which means every webmail has to implement it's own IMAP proxy, and IMAP as a protocol is very, very bad if you don't want to sync emails to your local machine and thus keep your own copy of the whole mailbox state. On the other hand, JMAP does allow you to get push notifications on changes, outside of the…

> Webmail was limited by HTTP, but not because HTTP is stateless; rather, it's because no mail server speaks HTTP, which means every webmail has to implement it's own IMAP proxy That doesn't explain why it is limited, only why it isn't interoperable. A traditional IMAP client also didn't speak TLS. That wasn't a reason to invent a replacement for IMAP, because you simply stack IMAP on top of TLS, and noone complains…

You obviously disagree, but JMAP made exactly the right choice: A simple, pull based protocol, with a side-channel for notifications. It's not clear why anyone would want a complex websockets-based monstrosity when the simple approach solves the problem perfectly.

I am not at all convinced that JMAP will succeed, I think it's along shot, but it's failure will not be because of the choice of HTTP.

Re: JMAP: Like IMAP but Not Really

#202

Post by Mailtemi »

jasonmunro wrote: post #16
billpg wrote: post #15

Last time I looked at IMAP, I was a little peeved that servers didn't accept messages added to the "Outbox" folder and send them, instead requiring that clients talk SMTP and then (or not) save a copy of the same message to the "Sent" folder. Could JMAP replace SMTP as well as IMAP?

JMAP actually does support replacing both. My next TODO item for Cypht is integrating SMTP support with JMAP.

Just curious, did you build Cyrus yourself or there is beta server already?

Re: JMAP: Like IMAP but Not Really

#203

Post by athenot »

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…

The From header has always been spoofable. It's just most ISPs (and Google) chose to disallow it to address low-hanging fruit in the fight against spam.

But anyone can set up their own postfix/qmail/sendmail server and put anything they want as the From.

Or am I misunderstanding the issue here?

Re: JMAP: Like IMAP but Not Really

#204

Post by ryanlol »

bad_user wrote: post #122
eggsampler wrote: post #110

Earlier quoted context omitted.

Sure, I get that. I get there is a whole weird and wacky world of email use that is considered legitimate and needs to work that way for a myriad of reasons. I don't get why their MTA cannot at least have an option to reject mail from your domains if it's not being sent using your account credentials. The average layperson will not get that. I'm fairly sure if my mother received an email that wasn't delivered to a th…

But that’s the point, you can send a spoofed email to your mother that will not go into her spam folder, even if she uses Gmail. The only way Google could protect you is if the From address is from @gmail.com (maybe, not completely sure). But if you have your own domain, you can’t have that protection. Sure, you might not be able to use Google’s own servers to send that email, but email is federated so you can use so…

FWIW you can inbox mails from spoofed @gmail addresses on gmail.

Re: JMAP: Like IMAP but Not Really

#205

Post by m4lvin »

athenot wrote: post #203
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…

The From header has always been spoofable. It's just most ISPs (and Google) chose to disallow it to address low-hanging fruit in the fight against spam. But anyone can set up their own postfix/qmail/sendmail server and put anything they want as the From. Or am I misunderstanding the issue here?

The difference is that using another fastmail account to spoof someone@fastmail.com will make the email look much more legitimate (DKIM and SPF wise) to other servers than when it comes from your random.emailserver.domain.foo.

Re: JMAP: Like IMAP but Not Really

#206

Post by shittyadmin »

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.

That sucks, I'd like to involve as few parties as possible in my emails. Right now I just have a direct IMAP connection that it can push over even on mobile.

What about for desktop purposes? What would a proper client like Thunderbird or Outlook do?

Re: JMAP: Like IMAP but Not Really

#207

Post by dane-pgp »

majewsky wrote: post #84
ggm wrote: post #12

The main failure in mail standards is a lack of explicit utf8 clean support lhs@rhs -if this got fixed (it's often called universal acceptance) a lot of things about mail as an ecology would improve. I have view on the spam thing. The whole "your idea will not work because" meme is hugely destructive of innovation in email. It sucks energy and mindshare. It's classic old timer put down. What would (imnsho opinion) ha…

> What would (imnsho opinion) have fixed spam is sender pays. I've debated this with a lot of people. We're 50/50 on it. Fifty agree with me, fifty million don't. I propose a scheme where the sender pays e.g. 5 ct per e-mail (low enough that it does not matter for legitimate use, but high enough to make spam unprofitable). BUT with the following twist: The receiver can generate API tokens that allow free e-mail deliv…

I've been thinking of a similar system, actually, but instead of having each end user pay per transaction, you have each domain put up a bond (in a digital currency) which can be forfeited if the domain is found guilty of spamming.

The one controversial part of this is deciding who is permitted to redeem the bond, i.e. who is the central arbiter of what is and isn't spam? Well, fortunately we already have an entity like that, de facto, since we have the Big 4 email providers ("Gmail, Hotmail, Yahoo, and AOL", or any other similar group that all mail servers must, in practice, comply with the demands of).

In the system I'm proposing, if any of these big providers detect a domain being involved in spam (or N out of M providers, to reduce the risk of false positives), they could redeem the bond. Of course, the bond would be structured such that the only recipient was a non-profit, like the IETF, or possibly an entity like ICANN. That way there is no financial incentive to make false positive claims.

As for how this system would be introduced, that's the easy part. All pre-existing domains would be grandfathered in, so that no current email users would be negatively affected. (Indeed, there is a moral hazard that some email providers would support this system precisely because it only affects new entrants to the market). There would simply be a flag day, after which if you register a new domain, and want to send emails from it, your domain registrar would have a check box saying "Yes, I am happy to be charged an extra $10 and have put it in a bond so that I can send email to the Big 4 providers". After sending a certain amount of legitimate email, a Big 4 provider could then send a transaction which makes the locked funds return to the original issuer of the bond.

Finally, to decide how big the bond has to be, we can look at data like this:

https://krebsonsecurity.com/2018/06/bad-men-at-work-please-d...

If spammers are going to extra effort to save a few dollars on their registration costs, then their margins must be pretty tight. It also means that domain reputation systems are working, since spammers have to keep bulk buying new domains:

http://conferences.sigcomm.org/imc/2013/papers/imc247-haoA.p...

Re: JMAP: Like IMAP but Not Really

#208

Post by m4lvin »

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…

This!!

I reported the same problem to posteo.de in March 2016 and still have not received a satisfactory answer, though it seems they have some counter-measures in their webmailer nowadays. The fun part was that as a "no logs" privacy-oriented provider, they were not even able to track who sent them a complaint from their own support address ¯\\_(ツ)_/¯

As a comparison: at disroot.org I found the same problem, and it took them a few hours to repair their postfix configs.

Re: JMAP: Like IMAP but Not Really

#209

Post by zAy0LfpBZLC8mAC »

miracle2k wrote: post #201
zAy0LfpBZLC8mAC wrote: post #174

Earlier quoted context omitted.

> Webmail was limited by HTTP, but not because HTTP is stateless; rather, it's because no mail server speaks HTTP, which means every webmail has to implement it's own IMAP proxy That doesn't explain why it is limited, only why it isn't interoperable. A traditional IMAP client also didn't speak TLS. That wasn't a reason to invent a replacement for IMAP, because you simply stack IMAP on top of TLS, and noone complains…

You obviously disagree, but JMAP made exactly the right choice: A simple, pull based protocol, with a side-channel for notifications. It's not clear why anyone would want a complex websockets-based monstrosity when the simple approach solves the problem perfectly. I am not at all convinced that JMAP will succeed, I think it's along shot, but it's failure will not be because of the choice of HTTP.

What exactly is the point of simply ignoring what I wrote and making unsubstantiated assertions that contradict what I wrote?

First, it's based on HTTP, so it's obviously not simple. Then, it obviously doesn't solve the problem perfectly if it cannot do the job without an additional side channel (which still doesn't solve the problem perfectly as the side channel obviously is slower and reduces reliability). And what is possibly the monstrosity with websockets, if not the fact that it is kinda-sorta using HTTP for something it wasn't built for ... which you think is best avoided by using HTTP for something it wasn't built for?

And no, I certainly don't want to use websockets, just as I don't want to use any of the other monstrosities that make up "email in a browser". But the great thing about sensible protocols for the purpose, which could work over websockets, is that you can simply drop all that crap and run them over TCP (with TLS in between, preferably).

Re: JMAP: Like IMAP but Not Really

#210

Post by Twisol »

pedrocr wrote: post #186
Twisol wrote: post #173

Earlier quoted context omitted.

> As cruegge has linked the JMAP developers themselves don't consider their API REST. That wasn't my takeaway. They don't consider it HTTP-based REST, but they do consider it RESTful. The FAQ's question is from the perspective of someone who doesn't make that distinction. You can model things RESTfully, but the encoding of REST into a carrier protocol (commonly HTTP, but it doesn't have to be) is a separate matter. T…

It's ambiguous indeed which again reinforces my point. The fact that you can issue several commands at once to be executed in order is strange for REST. And the REST definition also includes using common operations (GET/POST/PUT/etc if using HTTP) and this has invented it's own set that's specific to only this one API. So my read is that they're saying "we're actually more REST than a lot of things around but don't c…

This is entirely fair -- I agree! REST isn't a protocol in the same sense that HTTP is. Although I believe a protocol's semantics and encodings should be distinguished a la REST, a way to talk about a particular encoding would be a very nice thing to have.
Post reply on HN