jdev - 2020-05-12

hello

😄

😄

test

user1, 😉👌

Most servers I've looked at have separate configuration for S2S ports and C2S ports. Is there any reason other than legacy to actually use another port though? I can't think what bad thing would happen if you just listened for all connections on all ports that you listen on

https://prosody.im/doc/modules/mod_net_multiplex :P

You might want to apply different firewall policies to c2s / s2s

That's fair, or present different TLS certs or something. Maybe it's just to make ops' job easier

You may well want to prioritise different sockets differently in your eventloop or whatever, too.

Sam Whited, xep-0368 supports that just fine also with different alpn strings

I think having a single port for both C2S and S2S is one of those things that's entirely possible, but doesn't buy a lot and there are edge reasons not to.

You can if you want.

Yah, that all makes sense, I was thinking XMPP level stuff but it makes sense that existing tools that don't know or care about the application level protocol would operate on ports so you'd want to keep them separate

Thanks all

Email also has different ports for c2s (submission(s), imap(s) etc) and s2s (smtp)

right but if it was designed nowadays it'd just use https over 443

https://jmap.io/ see?

:(

Oh, does JMAP do federation over JMAP too? I had in my head it was the client-facing side only for some reason.

I don't know much about the JMAP protocol but SMTP needs to die in a fire and Fastmail got a *lot* faster and had less weird edge cases when they switched to JMAP. Could be an implementation thing and not an actual protocol thing, of course, but geeze SMTP needs an update.

This seems to me like arguing that XMPP s2s needs to die beacuse XMPP c2s over websockets is better than BOSH?

I don't follow the analogy. SMTP just doesn't work very well when you have more than one device, JMAP seems to work very well.

That was the point

I'm not sure that the transport matters?

I don't see how SMTP has anything to do with IMAP/JMAP

Oh sorry, I said SMTP and meant IMAP.

Although SMTP needs to die in a fire too, but I'm not sure if JMAP replaces that too or not.

My (limited) understanding was that JMAP did both the C2S protocols (SMTP/IMAP) but not the S2S protocol (SMTP).

I could be wrong.

Yah, the intro to the RFC suggests it's just client-to-server

JMAP-for-XMPP would be interesting.

Less confusing to refer to c2s-SMTP as submission (587 or tls on 465)

(Rather, something for XMPP as JMAP is for IMAP/SMTP Submission)

Kev: Matrix?

I don't think that's quite Matrix.

Sam Whited: I guess you'd be in the mood for Amon Amarth - Death In Fire today. 😂

Kev, so what properties are you after? Batched operations and magic?

wait does JMAP replace SMTP too? I thought it just replaced IMAP

Martin: I'm not normally a death metal kind of guy, but if they sang about killing SMTP/IMAP I'd totally listen to that :)

moparisthebest: it sounds like it replaces the C2S side of SMTP, but not the S2S side

Zash: I said 'interesting', rather than that I was actually after something.

No idea what "JMAP for XMPP" would be then.

Sam Whited: Unfortunately Viking lyrics, no it problems in those golden times. 😃

JMAP is effectively just a generic syncronization protocol with nice routing rules, so maybe the whole discussion about rewriting carbons for the millionth time will effectively be JMAP-over-XMPP just without their wire format

Daniel should be able to comment on that

given that he’s building a JMAP client as a side project

I think one problem with IMAP is arbitrary limitations in servers, and clients just adjusting to that because who are you to ask google or microsoft to configure their servers properly?

oh neat, didn't know that, I'd be curious to hear if he likes the protocol or not. I don't know any real specifics about it

I've heard nothing but praise of JMAP from email related folks

At least I remember last time I tried to use the Haiku mail client I ended up having to tweak a lot of things in Dovecot to have it working

FTR https://github.com/iNPUTmice/lttrs-android

Zash, like "you can stop using this cheese grater on your leg, instead use this wire brush, it's slightly less painful" "OH YES THIS IS THE BEST THING EVER!!!!!'

moparisthebest, don’t kinkshame

moparisthebest: what is wrong with it that's slighly less bad? So far I've mostly heard good things too (but like I said, I haven't implemented it)

email folks like pain, I didn't say there was anything wrong with it :P

The model is interesting.

But ugh, why must everything be JSON and HTTP?

SIMPLE!

CoAP?

Because it's widely understood and seems to work well enough. Better than inventing yet another custom transport anyways

don't forget DNS, half of email is in DNS now

dkim, spf, dmarc, and that new one I forget the name of

> yet another custom transport *ahem* HTTP/1.1, HTTP/2, HTTP/3

moparisthebest, myeah, that's kinda gone too far IMO

oh geeze, dkim/spf are *really* bad. Those should probably be moved to http / .well-known or whatever. You use like 3 third party services that require SPF records and you run up against the 10 request limit in DNS *really* fast

NO!

There's already one email thing that requires https:///.well-known, don't need more

DNS doesn’t have a request limit.

lookup limit, I mean. The SPF specification limits you to 10.

Don't you use DoH for the DNS part anyway? :p

It's an SPF problem, not a general DNS problem.

it’s a recursion limit, though?

ARC is the 4th one I couldn't remember https://en.wikipedia.org/wiki/Authenticated_Received_Chain

The XMPP s2s model always seemed much saner than all the weird things people have done to patch up email.

jonas’: yes. And every company tries to setup mailchimp/email provider/thing-that-sends-out-alerts, etc. and they all have their own records and then you're hosed and have to try to use different subdomains or split it up somehow when you just want a handful of things to be able to send emails on your behalf.

All of this to send mails no one really wants to read :D