💾 Archived View for bbs.geminispace.org › s › misfin › 5683 captured on 2023-11-04 at 14:13:05. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-09-28)
-=-=-=-=-=-=-
I have received a misfin message that does not identify the sending domain, so I do have any way of replying and connecting to the client IP address returns a zertificate but does establish a TLS connection. The username is @flipperzero, so if anybody knows them, I have received the mail
Ok, i take that back, a previous message identifies the domain as hashnix.club, so i know the user, i will just send them an email
2023-09-28 · 5 weeks ago · 👍 clseibold
Ahh i see then what's happened. 0.0.0.0 does NOT print back my hostname but allows me to send out. Interesting. We posted at the same time btw!
— bbs.geminispace.org/u/flipperzero/5684
I still seem to run into the problem that when I run
misfin make-cert mailbox "blurb" hashnix.club user.pem
although I can generate a certificate, anytime I try to set
misfin receive-as user.pem
under those parameters, I always get back
File "/usr/local/lib/python3.9/dist-packages/misfin-1.0.2-py3.9.egg/misfin/misfin.py", line 272, in receive_forever OSError: [Errno 99] Cannot assign requested address
I wonder what's happening... I modified misfin.py even to broadcast on AF_INET6 instead of INET, and while being able to listen under receive-as, is unable to send with a "blocked" note.
the python server does not have a bind address that can be set, i changed that by editing the line and writing 127.0.0.1 directly into it since i wanted to use it with a port forwarder
@alexlehm I added "listen_addr" to receive_forever(), but only the full server mode passed that argument (from the config file). I've just modified the code to add new arguments to "receive-as" so that we can pass a bind address, with ipv4 or ipv6, pushing the code soon.
The reference implementation, I think, has completely confused everyone (including me) by using the bind address as the same thing as the hostname in the cert, and the docs implying that you can use "localhost" when you make your cert.
The bind address is simply the network interface you want to receive messages from. Putting "0.0.0.0" in there will allow you to receive connections from any network interface on your computer (Ethernet, Wifi, localhost, etc.). Or you can put in the IP address of your network interface - like the IP of your Wifi Card, or the IP of your Ethernet connection - in which case the bind will only let you receive connections on that interface (wifi, Ethernet, etc.)
The SAN of your certificate *must* be your *public-facing* domain that people use to send to your misfin server. The reason is when you send messages to others, they need a way of accessing your server so they can reply. They use the **certificate's** SAN for this.
The bind address and your cert's SAN hostname/domain can be different. If on your local network your *domain* does not resolve to the IP address of a network interface on your server computer, then do not use your domain as the bind address. Your bind address must be (or include) the IP of the network interface that is being port forwarded by your router.
Having a bind address as your local IP address of your computer allows you to send to your server from within your local network by using your local ip address. Using a bind of 0.0.0.0 allows you to use your ip address OR use localhost. Allowing localhost is great for testing and being able to send to yourself, but not necessary for letting others send to you.
Finally, if you are using the python reference implementation, you must manually modify the bind address because the reference implementation assumes that the certs SAN is the same as the bind address.
If you are using gemalaya's fork, there is now a "-bind" argument that can be passed in, as per their messages below.
Hopefully this helps.
Tl;dr: Use "make-cert" with your **domain** as the hostname/SAN, and run the server binding to "0.0.0.0" or your local IP address.
@BBSman I've used @gemalaya's new --bind feature and my message to you worked!
@satch give it another go, my server was down earlier (had to apt upgrade/reboot, forgot to run the listener back up smfh)
Thank you all, gemalaya, clseibold/auragem, and lem, for your contributions to this space and the amazing tech you're all working on. Everything seems to be going a lot smoother now, w.o the need for forcing ipv6 (tho, still, very useful to keep as a feature in case the gemspace expands any further)