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

111–120 of 235 posts

Re: JMAP: Like IMAP but Not Really

#111

Post by [deleted] »

josteink wrote: post #77
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…

> 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…

[deleted]

Re: JMAP: Like IMAP but Not Really

#112

Post by u801e »

xorcist wrote: post #94
willj wrote: post #65

Earlier quoted context omitted.

This freaks me out too, and it turns out it's true: here's a mention on their Bug Bounty page [1]: "Email spoofing bugs do not qualify. We are quite aware that users can set arbitrary From addresses on emails, that our SPF records allow arbitrary hosts to send email as our domains, and that our DMARC policy is not enforcing passes. These policy decisions are by design, and we track the actual sender in a separate hea…

It's not entirely clear to me what they could do about it. Since they are an email provider, they probably don't have control over the networks their customers send email from, and what else their customers do with their domains. Someone could decide to forward their other mail to their fastmail account. Should they then potentially risk email their other customers send to that address? DMARC headers tries to solve t…

They could configure their MTA to rewrite the From: header so that the value matches the authenticated user and that the sender users the Reply-To: header to redirect replies instead.

Re: JMAP: Like IMAP but Not Really

#113

Post by mschuster91 »

amaccuish wrote: post #70
mschuster91 wrote: post #46

From experience, Exchange's Outlook API ("EWS") is pretty decent. It's XML-SOAP, sure, but there are libraries for it that can be readily used. The only thing they did fuck up is the three different kinds of IDs for an object (esp. confusing when accessing delegated team mailboxes/calendar events) but once you get it how it works, it's straightforward and allows you access to anything from email over calendar to addr…

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 :/

Re: JMAP: Like IMAP but Not Really

#114

Post by Riverheart »

eggsampler wrote: post #101
Riverheart wrote: post #100

Earlier quoted context omitted.

Seems to be just Fastmail domains but there might be some setup involved for custom domains. See their docs https://www.fastmail.com/help/technical/senderauthentication...

I have received a spoofed email from my own domain, so I believe it's not just Fastmail domains but any custom domain on an account.

Do you host your custom domain with Fastmail? I may have misread but the article seemed to suggest you could potentially setup dmarc via the DNS page or whoever you host with.

Re: JMAP: Like IMAP but Not Really

#115

Post by rswail »

naasking wrote: post #90
mariusmg wrote: post #76

Earlier quoted context omitted.

Maybe unpopular opinion, but i'd take this any day over a "proper" REST api requiring DELETE and PUT. Also i'd classify a REST api as anything that does http requests and consumes proper JSON. As long as this is true , the rest is squabbling :)

> i'd take this any day over a "proper" REST api requiring DELETE and PUT. REST doesn't need to use any HTTP verbs other than GET and POST.

REST doesn't need to use HTTP.

Re: JMAP: Like IMAP but Not Really

#116

Post by bad_user »

navlelo wrote: post #56
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…

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 the “From” value cannot be protected, unless you sign your email with PGP or S/MIME.

Re: JMAP: Like IMAP but Not Really

#117

Post by pbhjpbhj »

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…

First thought is that international differences in value of a fixed monetary amount might break it. 5¢ is affordable in USA but too much in, I don't know, Mongolia. Lower it to 0.05¢ and you get spam from USA.

Natural solution is a pricing list, but then USA spammers could route via cheapest geographic servers.

How do you get paid? Banks will put a transaction cost making sending email cost stupid money. So, bitcoin? But the built in energy costs for processing a transaction will force a floor on the transaction pricing that's too high?

If a token leaks you'll have to fiddle about to allow a sender's emails to get through ; I guess you could automate that if your MUA had credentials to inform genuine senders of API key updates.

Re: JMAP: Like IMAP but Not Really

#118

Post by hiccuphippo »

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…

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

Re: JMAP: Like IMAP but Not Really

#119

Post by [deleted] »

pjmlp wrote: post #36
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…

Emails are perfectly fine as they are. We also don't keep re-inventing forks, umbrellas, hammers and such.

[deleted]

Re: JMAP: Like IMAP but Not Really

#120

Post by rswail »

pedrocr wrote: post #67

>JMAP is a REST API so it uses HTTP requests and responses to issue commands and get the results. Almost all requests in JMAP are to the same URL using an HTTP POST to submit a JSON body of “methods”. Describing this as REST is really strange. Defining your own operations over an HTTP POST is what SOAP and other RPC style web services do and specifically what REST isn't. But I guess that a lack of a standard behind R…

REST is what Roy Fielding wrote about in his thesis. It is an architectural style, not a protocol.

It involves two endpoints exchanging the state of a shared resource. It needs to be compliant with the constraints of that style.

People think that REST must be over HTTP, but it can be over any protocol. The essence is that it is a style of systems design, so JMAP can be considered RESTful as described in the link above.

REST is one of the real patterns in software architecture, a set of constraints, not a set of structural elements.

Post reply on HN