Live data from Hacker News

JMAP: Like IMAP but Not Really

unencumberedbyfacts.com

181–190 of 235 posts

Re: JMAP: Like IMAP but Not Really

#181
post #56

Earlier quoted context omitted.

What is the reason for allowing this? Laziness?

The reason is probably that nothing can stop the successful spoofing of the From header. DKIM is a signature for authenticating a domain, however that domain does not have to match the domain in the From header. Take a look in Gmail at a signed email and you’ll see a “Signed by” field in its header info, with a domain name as a value. Also the SPF setting has nothing to do with the From header either. In other words…

That's tripe.

They know who authenticated to the SMTP server, so they could enforce that the From address is who it was authenticated by. Otherwise, they basically act as an open relay.

Re: JMAP: Like IMAP but Not Really

#182

Earlier quoted context omitted.

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…

> But that’s the point [...] No, that's not the point. > Sure, you might not be able to use Google’s own servers to send that email That is the point. Why does Fastmail allow this where Google doesn't. At best, it's ignorant and intentionally misleading. At worst, downright malicious and ripe for abuse.

There's much I don't know about email, so take what I say with a grain of salt. I imagine that maybe this could simply be a low priority issue for Fastmail because such a restriction would not be a protection for their customers but rather a restriction/disservice to them to potentially protect everyone else.

I also wonder if there are superusers that have a legitimate use for sending emails that have a different "From".

Something to think about is that, looking at the postal mail it was designed after, I don't imagine a postal office would reject me if I tried to drop off mail authored by someone else. They don't check the "From" in the envelope with my ID or anything. In fact, many envelopes don't even have a "From", and you don't even have to face a human when dropping off your mail. All the postal office does is provide access to the global delivery network for a fee.

It might be more apt to think of email providers likewise as network providers that allow transparent access to the global MTA network.

Both postal and electronic mail rely on signatures for proper authentication. It's only that electronic mail's (cryptographic) signatures are more secure but more difficult to use by laymen.

Maybe this issue ought to be thought of a similar to how illiterate people sign paper documents by making an "X". I imagine it's trivially easy to spoof documents supposedly signed by them, and even mail them. I wouldn't blame the postal office for accepting such spoofed documents.

Computers being relatively new and all, perhaps it isn't that bad to think that most of the world is still computer illiterate even if they think otherwise because of their ability to use point-and-click interfaces designed to be used even by illiterate young children.

What I think is needed is better computer education.

As to where this expectation for "From" to be validated comes from, I imagine it's something we've grown accustomed to from our use of centralized services. It would be really bad if a message on Facebook or Twitter could be spoofed, but those services are centralized, so restricting their users equates to properly protecting their users. Email, however, is decentralized. That's a good thing, and the proper way to do authentication in an decentralized service without making it more centralized can only be by non-spoofable signatures and not by trusting validations from independent service providers.

Re: JMAP: Like IMAP but Not Really

#183

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 user@gmail.com or gtalk first name.lastname123@facebook.com.

Re: JMAP: Like IMAP but Not Really

#184
post #165

Earlier quoted context omitted.

Hu? Constantly establishing new connections saves power vs. maintaining one estalished connection? Could you explain how that works? And could you also explain how constantly making new connections makes things work more reliably over unreliable links? Like, does that allow you to transfer data when the network link is down? Does the fact that inside the TLS/TCP connection data is transferred via HTTP instead of IMAP…

Ignoring efficiency concerns, modern mobile oses don't allow applications to keep connections open for long. If you want notifications to work, you need to use the platform notification system. The platform argument is roughly that if they hold open one connection, it's cheaper than each app holding open their own connection. And maybe, if you're optimistic, the platform will be better at figuring out ping intervals…

Well, yeah, if you are very optimistic and generous. In reality, this is yet another way of the manufacturers maintaining power over their customers' property. After all, there is zero reason why any of those things would require them as a middle-man, they could just invent a protocol for that and/or provide a library and a system service on the device that allow applications to maintain a background connection without the need to involve them in any way on the network/server side. The only useful involvement they could have might be providing endpoints for measuring and exchanging NAT timeout information for providers, maybe.

But in any case, none of that is an argument for building a protocol that forces the problems that result from that on all platforms that don't have such restrictions, at best that is an argument in favor of workarounds to make things work as well as possible on such platforms.

Also, I would think that the long-term solution to this problem should be mobile link layer protocols that allow the mobile station to receive incoming packets with little delay while still conserving power. Stuff like high-powered, high SNR alert channels that allow the mobile station to shut down everything apart from a simple, low power, receiver, that only powers on for a few microseconds every few hundred milliseconds to listen for a wakeup signal from the network, so that incoming packets can be delivered with a latency of a few hundred milliseconds at any time. And then you are stuck with a stupid poll-based protocol that's adapted to the limitations of some ancient technology as a replacement for an even more ancient protocol that didn't have that limitation.

Re: JMAP: Like IMAP but Not Really

#185

Earlier quoted context omitted.

The reason is probably that nothing can stop the successful spoofing of the From header. DKIM is a signature for authenticating a domain, however that domain does not have to match the domain in the From header. Take a look in Gmail at a signed email and you’ll see a “Signed by” field in its header info, with a domain name as a value. Also the SPF setting has nothing to do with the From header either. In other words…

That's tripe. They know who authenticated to the SMTP server, so they could enforce that the From address is who it was authenticated by. Otherwise, they basically act as an open relay.

Sending from multiple From addresses is a common use case. I send from at least 4 different email addresses all hosted by fastmail in the same account. Having to create different logins to authenticate each sender would be a huge pain.

Plus it's not a unique problem to fastmail.

Re: JMAP: Like IMAP but Not Really

#186
post #173

Earlier quoted context omitted.

I know all this, but this API doesn't meet that definition. As cruegge has linked the JMAP developers themselves don't consider their API REST. From the description it seems more like an RPC that's transaction oriented and for very good reasons. The fact that this is a discussion though makes my point. By REST being only an achitecture style with very loose definitions makes it arguably fit for all different kinds of…

> 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 consider ourselves that".

>The "very loose definitions" largely stem from the encoding, not the modeling.

Sure, but the fact that we don't have strict definitions for common encodings means that you then have a discussion on it every time. It would be nice to have Standard A, that defines a common way to encode a common type of REST API (HTTP/JSON/etc) and we can just say our software uses that and REST is implied. Instead we get a situation where JSON-over-HTTP is perceived as being REST when it actually fails as a test in both ways. Some things are REST and don't use JSON or HTTP and some things are not REST and still use JSON and HTTP.

Re: JMAP: Like IMAP but Not Really

#187
post #166

Earlier quoted context omitted.

> after a trial realized that Gmail does many things well, except for being a good email service. This. I remember back when Gmail was new and hot. It was unlike any other email service out there, and ridiculing people for using inferior email-solutions could to a certain extent be justified. While other webmails were slow, had constantly reloading pages and what not, Gmail was fast . It was amazingly fast. Gone wher…

The main thing gmail offered back then was a frickin GB of email storage. (Which spawned a host of other things, like a FUSE filesystem backed by Gmail.) No other free provider was even close! Hotmail offered email measured in 10s of MB and I'm sure Yahoo was similar. (I got my first gmail account in 2004.) Yeah, the UI wasn't bad, but there was less email back then and I didn't (still don't) really mind being served…

Hotmail provided just 2MB of space when gmail launched on 01 Apr 2004. They increased it to 250MB in June 2004.

source: https://www.pcworld.com/article/116657/article.html

Re: JMAP: Like IMAP but Not Really

#188
post #123

Earlier quoted context omitted.

They need to provide the ability to use SMTP servers other than their own for @fastmail.com users. SPF, DKIM and DMARC do not provide authentication of non-envelope headers like From: and To: etc, unless they are specifically included, but there is no way to publish that you require those headers as part of the DKIM signature.

Exactly. This is also what makes SPF and friends a bit of a pointless exercise. Even if they had global unanimous support end users don't really care about the envelope from anyway. Stopping phishing is hard . End users mostly are fooled by a little padlock in their web browser, and that's a much simpler trust model. Eliminating email dressed up as web pages would probably do more to combat that than authenticated se…

I think the thing that is concerning to me is not so much that users don't care about the envelope from, so much as it is that other email providers' anti-spam measures may block my email if some spammer start spoofing me. Then, poof! I can't email any gmail accounts anymore.

Re: JMAP: Like IMAP but Not Really

#189
post #170
post #86

Earlier quoted context omitted.

fastmail lets you write complete scripts for filtering using the Sieve programming language. https://www.fastmail.com/help/technical/sieve.html

Sieve is great. I highly recommend it over, say, procmail, or Outlook filters (especially Outlook Web Access).

Isn't procmail dead?

Re: JMAP: Like IMAP but Not Really

#190
post #145

Earlier quoted context omitted.

> Also from what I understand JMAP should be friendly for mobile usage. They kept notifications out of it, you're supposed to implement notifications using whatever the mobile platform provides. Interacting via JMAP is via plain HTTP requests, which is super cool. Sounds actually not cool. Is there really no standardized way to do notifications? The world consists not only of shitty mobile walled gardens which insist…

If you want good battery life, there is no alternative to the mobile notifications provided by the platform, because otherwise you have to always keep your own connection open to your server.

please don't spread misinformation - abusing long live socket connections is what drain the battery - having one open and managing it in sane manner is quite battery efficient. Google brainwashed everyone to force them to use their push service, which is just plain awful... (and requires open connection... sic!)
Post reply on HN