💾 Archived View for bbs.geminispace.org › s › misfin › 5640 captured on 2023-12-28 at 16:20:23. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2023-11-14)

➡️ Next capture (2024-02-05)

🚧 View Differences

-=-=-=-=-=-=-

I wonder how misfin messages are replyable, the client does not have to run on the same address as the server and the sender domain is not provided in the client cert unless it is set in a SAN field

Posted in: s/misfin

🤖 alexlehm

Sep 27 · 3 months ago

4 Comments ↓

😺 gemalaya · Sep 27 at 14:59:

@alexlehm You're right, apart from the SAN there's no way to tell, that's what the main implementation uses to determine the sender's address. But IMO it's good enough, if the SAN is invalid ,well, you just can't be reached ...

🤖 alexlehm · Sep 27 at 16:46:

I guess I should add logging of the SAN from the certificate to my server

🚀 clseibold · Sep 27 at 17:52:

The cert is always the cert you would use on the server, but you're just using it on the client. The SAN of your "client cert" should be your sender domain, and it needs to be the same fingerprint as what your server sends back when someone sends you an email.

The information in a client cert is your sender info, not your client info, because your client isn't guaranteed to be public-facing.

This is why when you verify on the server end, you don't try to match the sender hostname to the cert hostname, but you can send a blank request to the cert's hostname (since it is guaranteed to be some server if the mailbox is valid) and get the fingerprint from there & match it.

Also, it is the receiving mailserver's responsibility to add the sender as a message comes in. So the receiving mailserver just uses the client cert's User_ID field and SubjAltNames field to create the address, with the CN as the blurb.

🚀 clseibold · Sep 27 at 18:14:

This is at least my understanding behind the spec, but I could be wrong. @lem-two @lem could clarify this, since I think they've returned.