jdev - 2020-05-12

  1. user1


  2. user1


  3. user1


  4. user1


  5. Yagizа

    user1, 😉👌

  6. Sam Whited

    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

  7. Zash

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

  8. Zash

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

  9. Sam Whited

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

  10. Kev

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

  11. moparisthebest

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

  12. Kev

    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.

  13. Zash

    You can if you want.

  14. Sam Whited

    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

  15. Sam Whited

    Thanks all

  16. Zash

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

  17. moparisthebest

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

  18. moparisthebest

    https://jmap.io/ see?

  19. Zash


  20. Kev

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

  21. Sam Whited

    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.

  22. Zash

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

  23. Sam Whited

    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.

  24. Zash

    That was the point

  25. Sam Whited

    I'm not sure that the transport matters?

  26. Zash

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

  27. Sam Whited

    Oh sorry, I said SMTP and meant IMAP.

  28. Sam Whited

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

  29. Kev

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

  30. Kev

    I could be wrong.

  31. Sam Whited

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

  32. Kev

    JMAP-for-XMPP would be interesting.

  33. Zash

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

  34. Kev

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

  35. Zash

    Kev: Matrix?

  36. Kev

    I don't think that's quite Matrix.

  37. Martin

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

  38. Zash

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

  39. moparisthebest

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

  40. Sam Whited

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

  41. Sam Whited

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

  42. Kev

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

  43. Zash

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

  44. Martin

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

  45. Sam Whited

    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

  46. jonas’

    Daniel should be able to comment on that

  47. jonas’

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

  48. pulkomandy

    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?

  49. Sam Whited

    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

  50. Zash

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

  51. pulkomandy

    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

  52. jonas’

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

  53. moparisthebest

    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!!!!!'

  54. jonas’

    moparisthebest, don’t kinkshame

  55. Sam Whited

    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)

  56. moparisthebest

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

  57. Zash

    The model is interesting.

  58. Zash

    But ugh, why must everything be JSON and HTTP?

  59. jonas’


  60. Zash


  61. Sam Whited

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

  62. moparisthebest

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

  63. moparisthebest

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

  64. Zash

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

  65. Zash

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

  66. Sam Whited

    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

  67. Zash


  68. Zash

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

  69. jonas’

    DNS doesn’t have a request limit.

  70. Sam Whited

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

  71. pulkomandy

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

  72. Sam Whited

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

  73. jonas’

    it’s a recursion limit, though?

  74. moparisthebest

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

  75. Zash

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

  76. Sam Whited

    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.

  77. pulkomandy

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