previous Debian test): Can't generate DH parameters: modulus too
small . This message displays after "attaching to server" but before
I was seeing the same error, so I decided to poke around in the code and see what it's about.
DH in this case is Diffie-Hellman. Crypto stuff involved in setting up the connection to the server, related to perfect forward secrecy. The math eludes me on exactly how this works, but suffice to say it's semi-important to generate a different set of DH parameters for each server.
It looks like the text client is generating a unique set of DH parameters client side, before establishing the connection, in the function CtdlIPC_init_OpenSSL.
The parameters get generated by calling the OpenSSL funciton DH_generate_parameters_ex.
The error occurs because textclient calls that function with a prime_len of 128, which was probably fine years ago when the text client was written, but is a bit dinky (insecure) now. The 'modulus too small' comes from OpenSSL itself.
So, I changed prime_len to 2048 and rebuilt the text client. It works, and the error no longer appears, but it takes maybe 60 seconds to generate the DH parameters on my seriously underpowered VPS. 60 seconds of me sitting there whining because I have to wait to get my uncensored fix.
This API is deprecated in openssl3 anyway. At some point the text client should be rewritten to use the newer OpenSSL APIs. Anybody want a homework assignment?
My advice: ignore it, unless you are doing banking or trading national secrets over citadel. Maybe someday it'll get fixed.
So, I changed prime_len to 2048 and rebuilt the text client. It
512 seems to work well. No error, and the related delay is only a second or so.
I was a bit overzealous with 2048. Been reading too much OpenSSL documentation.
I don't seem to have written a backup script for citadel on Ubuntu. Before coding it up, is there a existing backup script to work from?
So, I changed prime_len to 2048 and rebuilt the text client. It
512 seems to work well. No error, and the related delay is only a second or so.
I was a bit overzealous with 2048. Been reading too much OpenSSL documentation.
Thank you for this and the preceding reply explaining what is going on! Glad to know I was thinking correctly about the issue!
That said, knowing *why* it is happening makes it less annoying -- next time I feel like having some fun I'll do the rebuild with a 512 value and see how that performs for me.
Once again, thank you. ^5!
Subject: mail delivery errors - message ID header not RFC 5322 conform
Hello,
i am a long term user and requesting support for the first time.
In the last weeks i had some errors concerning the deliverability of citadel mails to different companies, caused by stricter implemented delivery rules of counterside servers.
Diagnostic-Codes were: "smtp; 550-5.7.1 [my IP] Messages missing a valid Message-ID header are not 550-5.7.1 accepted."
A closer look in my sended mail headers shows always two ">>" at the end of the message IDs, e.g. "Message-ID: <2024...5F12@dd52404....com>>", which seems to be not RFC 5322 conform.
Could you please check the source code for this bug? Why are here always two closing brackets?
Many thanks
Stefan
Subject: Re: mail delivery errors - message ID header not RFC 5322 conform
A closer look in my sended mail headers shows always two ">>" at the
end of the message IDs, e.g. "Message-ID:
<2024...5F12@dd52404....com>>", which seems to be not RFC 5322
I'm having some trouble reproducing this ... would it be possible for you to post the full headers, redacted of any privacy information if necessary?
Also please let us know how these messages are being entered into the system - from the web client, the text client, an IMAP/SMTP agent, mailing list post, etc.
If we can reproduce the problem this is definitely something we will need to correct immediately.
Subject: Re: mail delivery errors - message ID header not RFC 5322 conform
Wed Apr 10 2024 18:53:01 EDT from IGnatius T Foobar Subject: Re: mail delivery errors - message ID header not RFC 5322 conformA closer look in my sended mail headers shows always two ">>" at the
end of the message IDs, e.g. "Message-ID:
<2024...5F12@dd52404....com>>", which seems to be not RFC 5322
I'm having some trouble reproducing this ... would it be possible for you to post the full headers, redacted of any privacy information if necessary?
Also please let us know how these messages are being entered into the system - from the web client, the text client, an IMAP/SMTP agent, mailing list post, etc.
If we can reproduce the problem this is definitely something we will need to correct immediately.
Thanks for answering.
This problem occured after bringing up the citadel version 998 on a new raspi 4 using the build script for the "easy install instructions". Previously it worked well on the older used citadel versions i used before via debian package sources. So i cannot tell you beginning on which version number this problem has started.
For mail clients i use Mozilla Thunderbird 115.7.0 on debian and K9-Mail 6.801 on Adroid, via SMTP Port 587 STARTTLS and normal password as authentication method. It is the same, always ">>" two brackets are developed on the end of the "Message-ID" line, whatever mail client i use. When i loop back to check the headers i use IMAP 993 SSL/TLS, the outgoing headers show the same data as the incoming, ">>" at the end of the "Message-ID" line.
Here is one of the example headers:
Test
Subject:
Test
From:
"stefan my_domainname" <stefan@my_domainname.link>
Date:
11.04.24, 08:52
To:
stefan@my_domainname.link
Return-Path:
stefan@my_domainname.link
Message-ID:
<f1b1b8d5-a179-4622-9949-8708cee301db@my_domainname.link>>
Received:
from [private_IP_adress] (user.domain.at [public_IP_adress]) by my_domainname.link; Thu, 11 Apr 2024 08:52:26 +0200
MIME-Version:
1.0
User-Agent:
Mozilla Thunderbird
Content-Language:
en-US
Content-Type:
text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding:
7bit
Here you can see the double brackets >> at the end of the Message-ID.
I also took a short look in the dircetly downloaded source code package and it is only a weak quick theory... Is this "Message-ID" line created in "msgbase.c"?
If you look in the lines 2021-2027:
if (mode == MT_RFC822) {
// Construct a fun message id
cprintf("Message-ID: <%s", mid);
if (strchr(mid, '@')==NULL) {
cprintf("@%s", snode);
}
cprintf(">%s", nl);
Possibly the string "mid" containes already a ">" at the end at this position. Then the last line could perhaps simply be modified to
cprintf("%s", nl); ???
Thanks for help.
Subject: Re: mail delivery errors - message ID header not RFC 5322 conform
Wed Apr 10 2024 18:53:01 EDT from IGnatius T Foobar Subject: Re: mail delivery errors - message ID header not RFC 5322 conformA closer look in my sended mail headers shows always two ">>" at the
end of the message IDs, e.g. "Message-ID:
<2024...5F12@dd52404....com>>", which seems to be not RFC 5322
I'm having some trouble reproducing this ... would it be possible for you to post the full headers, redacted of any privacy information if necessary?
Also please let us know how these messages are being entered into the system - from the web client, the text client, an IMAP/SMTP agent, mailing list post, etc.
If we can reproduce the problem this is definitely something we will need to correct immediately.
Now i had the opportunity to test it at home using the local browser based version of citadel support. I have composed a short message via browser and this works fine:
"You are connected to Citadel Server
Running: Citadel Server 998 with WebCit #define CLIENT_VERSION 998 /* This version of WebCit */
Server Build: 998"
Here the problem does NOT occur. The Message-ID header line is closed with one bracket - extracted statement from the output mail header, prompted and saved via thunderbird:
Message-ID:
<66181D91-0000030A@mydomain.link>
So it can be circumscribed: The problem occurs using mail clients like Thunderbird or K-9 Mail for writing and sending emails via SMTP.
Thanks
Hello all, this is my first time trying out this weird style of BBS. I'm used to forum style from a decade or two ago, so I'm pretty confused on how to navigate this place. Is there documentation on how things are grouped together? Right now it seems to be rooms each with a couple forum posts that stretch on for ages and switch topics midway through.
No one is perfect. We all tend to stray OT in a room.
Hello all, this is my first time trying out this weird style of BBS. I'm used to forum style from a decade or two ago, so I'm pretty confused on how to navigate this place. Is there documentation on how things are grouped together? Right now it seems to be rooms each with a couple forum posts that stretch on for ages and switch topics midway through.
pretty confused on how to navigate this place. Is there
documentation on how things are grouped together? Right now it
seems to be rooms each with a couple forum posts that stretch on for
Each room has a topic, and the conversation in each room is linear. Instead of keeping track of threads, you just follow along like a regular conversation.
The next time you return to a room, it will remember where you were last time so you can catch up.
So it's simpler than you might have expected. People who are accustomed to it really love it.
Subject: Re: mail delivery errors - message ID header not RFC 5322 conform
So it can be circumscribed: The problem occurs using mail clients like
Thunderbird or K-9 Mail for writing and sending emails via SMTP.
You are absolutely correct, and I am now able to reproduce the problem. When an external SMTP agent submits a message with the message ID in angle brackets, the bracket on the right is not properly stripped.
What an excellent troubleshoot and bug report. We'll get this fixed right away.
Subject: Re: mail delivery errors - message ID header not RFC 5322 conform
What an excellent troubleshoot and bug report. We'll get this fixed
right away.
...and right away is now. Citadel 999 is now available for download, in both Docker and Easy Install formats.
I guess the next release is going to have to be something really special since it'll be version 1000 :)
Subject: Re: mail delivery errors - message ID header not RFC 5322 conform
webcit NG is released?
( just kidding. i know its a long way out )
Fri Apr 12 2024 17:41:07 EDT from IGnatius T Foobar Subject: Re: mail delivery errors - message ID header not RFC 5322 conform
I guess the next release is going to have to be something really special since it'll be version 1000 :)
Subject: Re: mail delivery errors - message ID header not RFC 5322 conform
Subject: Re: mail delivery errors - message ID header not RFC 5322 conform
Would be for another room, but any pictures worth sharing yet of what is coming?
Subject: Re: mail delivery errors - message ID header not RFC 5322 conform
Fri Apr 12 2024 11:05:58 EDT from IGnatius T Foobar Subject: Re: mail delivery errors - message ID header not RFC 5322 conformSo it can be circumscribed: The problem occurs using mail clients like
Thunderbird or K-9 Mail for writing and sending emails via SMTP.
You are absolutely correct, and I am now able to reproduce the problem. When an external SMTP agent submits a message with the message ID in angle brackets, the bracket on the right is not properly stripped.
What an excellent troubleshoot and bug report. We'll get this fixed right away.
I would like to thank you very much for the quick and professional support!
Some large software companies could take a role model here.
It's great if CalDAV would be included in Citadel. I use it with separate software, which i could quit.
For implementing the update: Is it possible to reinstall the easy install routine on a running raspberry, if citserver and webcit are stopped, without loosing the mail configuration and the content of the IMAP mail boxes? Or is the clean way a fresh installation of the whole system?
Subject: Re: mail delivery errors - message ID header not RFC 5322 conform
Would be for another room, but any pictures worth sharing yet of what is coming?
Yes, thanks for asking :)
https://www.citadel.org/roadmap.html
Has a few screen shots of the Forum and Mail applets.
Subject: Re: mail delivery errors - message ID header not RFC 5322 conform
For implementing the update: Is it possible to reinstall the easy install
routine on a running raspberry, if citserver and webcit are stopped, without
loosing the mail configuration and the content of the IMAP mail boxes? Oris
the clean way a fresh installation of the whole system?
Yes, if you originally installed Citadel using the Easy Install method, you can run Easy Install again at any time to upgrade. Your existing data will be preserved.
Obviously you're going to take a backup first, of course.