Please wait...
0 files
My approach to that it is to put the following script in /etc/cron.daily
***************
find /root/citadel/* -not -newermt '-176400 seconds' -delete
systemctl stop citadel
zip -j "/root/citadel/citadel_$(date +%F).zip" /usr/local/citadel/data/*
systemctl start citadel
*****************
It is made backups (in the server with citadel) in last 3 days deleting older backups.
In case of disk full due to spam attackers, before restoring data of citadel (with the backups done with the script above), backup the emails in your email client (in a local folder) of last day (or of 3 days). Restore the citadel data files (delete older data files and unzip the backup of the script above to /usr/local/citadel/data/) and then in your email client move back the backuped emails (of last day or 3 days) to the email account folders.
Despite I think that the maintainers of Citadel must investigate that problem.
the /data folder had thousands of LOG files (berkely DB logs). The
disk ran out of space (85GB)..
Citadel Server normally deletes unused database logs on its own, unless you've selected the system configuration option to stop it from doing that ("automatically delete unused database logs (yes/no)"
If the logs are accumulating that fast then your system might be the target of a spammer or something. If you ran a command like "strings" or "hexdump -C" on the logs you might see a clue as to what it's trying to write.
Also, to commit database logs you need a little bit of free disk space, so if you are truly at 100% you'll need to free a little bit of space up first.
Also, you probably already know this, but Citadel Server can't be running when you run any of the db_ commands.
Hello,
Under Push Email and SMS settings it states 'Alternatively, if the administrator has configured it, Citadel can send a text message to you when new mail arrives.'
I can not find any documentation to set this up. Can you provide some guidance to setup SMS notifications please.
Brodes.
Subject: Citadel Protocol binding for Dart Native?
Greetings! First post here so I'll cut to the chase!
Dart Native Client
I want to make a stand-alone Flutter/Dart Native cross-platform app to communicate directly with the Citadel (port 504) server independently of WebCit or the text client. Of course that means that I'll need to make a C-based binding based on the text client sources and Dart's FFI support. If using the protocol from Dart directly is preferred, let me know.
Motives
The WebCit client splits the Citadel protocol up across a half-dozen different modern web protocols and makes it difficult to implement shell filters. My goal is to allow such shell filters as GZip, BZip2, GCrypt and other POSIX shell filters act as adaptations of the single protocol so that compression and end-to-end encryption (in addition to SSL or separate from that) will be practical. Also, if the GCrypt filter is external to the protocol, other algorithms can be substituted later, just be following the existing API.
Steps Involved
- Create Dart binding for the Citadel server protocol based on text client code
- Create Flutter app based on the bindings
- Add end-to-end encryption and compression algorithms to both ends
- ???
- Profit?
Conclusion
I hope I've explained myself well enough so you get the idea. I've also tried to stay to the point and be brief. If you have any questions, I'll be around.
Subject: Re: Citadel Protocol binding for Dart Native?
First of all, it's awesome that you want to build on top of the Citadel system.
Whatever you need to succeed, we will be happy to assist. Let me know if you want to work on it in the Citadel Development room and we can get you access to that.
Second, please ignore anything done by WebCit. :) Both its code and its use of web protocols are awful. That's why it's being completely rewritten.
I don't know if you've taken a look at the git repository, but there's a directory in there called "webcit-ng" in which we are building a completely new version of WebCit that is 100% REST/DAV with the user interface in client-side JavaScript. If this is more to your liking, you might be able to interface with Citadel without using FFI. The downside is that WebCit-NG isn't finished.
The REST/DAV stuff is pretty well fleshed out so it'll work for you, but you'd have to make sure any sites you access have the incomplete WebCit-NG installed, even if on an alternate port.
Depending on your use case, this may or may not work for you.
Barring that, I believe you're correct that the "native" approach would be to write a dart:ffi binding to Citadel's native wire protocol. The upside to this is that it's guaranteed to work and the native protocol is VERY stable and secure.
So there you go. Let me know if any of this tickled your fancy.
Could you please help me get my mail server up and running.. citserver crashes immediately with the segmentation fault. I cant get it back up long enough to even get in to the administration settings..
I've been without email for 4 days.
PLEASE HELP!! :(
Hello,I'm getting further now with this issue, it seems that citserver is crashing around a minute after it starts and restarts/crashes repeats. That's why the log files are generating and not getting flushed.
I ran citserver from console
/citserver -x9
below is the output.. could this message in the outbound queue be causing the segmentation fault? if so, how do I delete it? or infact how do I view/delete the queue as it says there is over 17k messages (I assume spam) waiting to be delivered (relay?)
citserver[22927]: pop3client: scan started
citserver[22927]: pop3client: processing started
citserver[22927]: pop3client: ended
citserver[22927]: listdeliver: sweep started
citserver[22927]: listdeliver: ended
citserver[22927]: smtpclient: start full queue run , last_queue_job_processed=0 , last_queue_job_submitted=0
citserver[22927]: smtpclient: 17596 messages to be processed
citserver[22927]: msgbase: CtdlFetchMessage(112703, 1)
citserver[22927]: smtpclient: attempting delivery of message <112703> now
citserver[22927]: smtpclient: smtp_attempt_delivery(112702, dhruvkaushik@gmail.com)
citserver[22927]: msgbase: CtdlOutputMsg(msgnum=112702, mode=1, section=<>)
citserver[22927]: msgbase: CtdlFetchMessage(112702, 1)
citserver[22927]: msgbase: CtdlOutputPreLoadedMsg(TheMessage=not null, 1, 0, 0, 1
Segmentation fault
Hi,
I already had the "automatically deleted unused logs" setting enabled..
I managed to delete the logs with db_archive util, however, they start appearing again once I deleted them and continued until the disk ran out of space.
I also noticed in /var/log/messages that the Citserver is restarting every 1 minute. How can I find why this is happening?
*** Citadel server engine ***
Jan 13 10:43:03 victor citserver: Version 1007 (build 25012) ***
Jan 13 10:43:03 victor citserver: Copyright (C) 1987-2024 by the Citadel development team.
Jan 13 10:43:03 victor citserver:
Jan 13 10:43:03 victor citserver: This program is open source software. Use, duplication, or disclosure
Jan 13 10:43:03 victor citserver: is subject to the GNU General Public License version 3.
Jan 13 10:43:03 victor citserver:
Jan 13 10:43:03 victor citserver: libcitadel(unnumbered)
Jan 13 10:43:03 victor citserver: main: running in data directory /usr/local/citadel
Jan 13 10:44:18 victor citserver:
Jan 13 10:44:18 victor citserver:
Jan 13 10:44:18 victor citserver: *** Citadel server engine ***
Jan 13 10:44:18 victor citserver: Version 1007 (build 25012) ***
Jan 13 10:44:18 victor citserver: Copyright (C) 1987-2024 by the Citadel development team.
Jan 13 10:44:18 victor citserver:
Jan 13 10:44:18 victor citserver: This program is open source software. Use, duplication, or disclosure
Jan 13 10:44:18 victor citserver: is subject to the GNU General Public License version 3.
Jan 13 10:44:18 victor citserver:
Jan 13 10:44:18 victor citserver: libcitadel(unnumbered)
Jan 13 10:44:18 victor citserver: main: running in data directory /usr/local/citadel
Jan 13 10:45:24 victor citserver:
Jan 13 10:45:24 victor citserver:
Jan 13 10:45:24 victor citserver: *** Citadel server engine ***
Jan 13 10:45:24 victor citserver: Version 1007 (build 25012) ***
Jan 13 10:45:24 victor citserver: Copyright (C) 1987-2024 by the Citadel development team.
Jan 13 10:45:24 victor citserver:
Jan 13 10:45:24 victor citserver: This program is open source software. Use, duplication, or disclosure
Jan 13 10:45:24 victor citserver: is subject to the GNU General Public License version 3.
Jan 13 10:45:24 victor citserver:
Jan 13 10:45:24 victor citserver: libcitadel(unnumbered)
Jan 13 10:45:24 victor citserver: main: running in data directory /usr/local/citadel
Jan 13 10:46:34 victor citserver:
Jan 13 10:46:34 victor citserver:
the /data folder had thousands of LOG files (berkely DB logs). The
disk ran out of space (85GB)..
Citadel Server normally deletes unused database logs on its own, unless you've selected the system configuration option to stop it from doing that ("automatically delete unused database logs (yes/no)"
If the logs are accumulating that fast then your system might be the target of a spammer or something. If you ran a command like "strings" or "hexdump -C" on the logs you might see a clue as to what it's trying to write.
Also, to commit database logs you need a little bit of free disk space, so if you are truly at 100% you'll need to free a little bit of space up first.
Also, you probably already know this, but Citadel Server can't be running when you run any of the db_ commands.
below is the output.. could this message in the outbound queue be
causing the segmentation fault? if so, how do I delete it? or infact
how do I view/delete the queue as it says there is over 17k messages (I
assume spam) waiting to be delivered (relay?)
Ok, I'll go over how to do that in the debugger and we can hopefully figure out why it's crashing and get a hotfix out. But if there are 17000 spams in your queue, you really ought to just restore a backup from before that happened, change all of your users' passwords, and move forward from there.
You *really* don't want to get on Google's "naughty list".
Anyway, once you're ready, start Citadel Server in the debugger like this:
cd /usr/local/citadel
gdb ./citserver
run -x9
Let it run until it crashes, and then type:
thread apply all bt
Post the output of that and hopefully we can figure it out. Now I'm looking through your logs and it sounds like message 112702 is the one that's making the server crash. If you've got extra time, you can try to dump that particular spam message to disk and we can run it through a test system to see if it can choke a test system too and not just yours. The command is:
cd /usr/local/citadel
./ctdldump -y | grep '|112702|' >/tmp/112702.dat
And then get that file over to us somehow (do not post it here, it'll trigger everyone's spam filters)
I'll check in later today to see what you've posted.
Where can I send output of DB Dump?
gdb output
Thread 2 "citserver" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xf4cab200 (LWP 29865)]
strchr () at ../sysdeps/arm/armv6/strchr.S:28
28 ../sysdeps/arm/armv6/strchr.S: No such file or directory.
(gdb) thread apply all bt
Thread 2 (Thread 0xf4cab200 (LWP 29865) "citserver"):
#0 strchr () at ../sysdeps/arm/armv6/strchr.S:28
#1 0x000761f4 in smtp_attempt_delivery (msgid=112702, recp=0xf4ca7a60 "dhruvkaushik@gmail.com", envelope_from=0x0, source_room=0x0, response=0xf4ca9a64 "L\365\002") at server/modules/smtp/serv_smtpclient.c:236
#2 0x00076d24 in smtp_process_one_msg (qmsgnum=112703) at server/modules/smtp/serv_smtpclient.c:420
#3 0x00077420 in smtp_do_queue (type_of_queue_run=0) at server/modules/smtp/serv_smtpclient.c:562
#4 0x000774f0 in smtp_do_queue_full () at server/modules/smtp/serv_smtpclient.c:578
#5 0x00035990 in PerformSessionHooks (EventType=11) at server/serv_extensions.c:439
#6 0x0001f240 in do_housekeeping () at server/housekeeping.c:133
#7 0x00038064 in worker_thread (blah=0x0) at server/sysdep.c:863
#8 0xf7c79310 in start_thread (arg=0xf4cab200) at pthread_create.c:477
#9 0xf7a4f5c8 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:73 from /lib/arm-linux-gnueabihf/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
Thread 1 (Thread 0xf7fde040 (LWP 29858) "citserver"):
#0 0xf7a1030c in __GI___clock_nanosleep_time64 (clock_id=clock_id@entry=0, flags=flags@entry=0, req=0xfffee450, req@entry=0xfffee448, rem=0xfffee460, rem@entry=0xfffee458) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:52
#1 0xf7a10400 in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0xfffee48c, rem=rem@entry=0x0) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:92
#2 0xf7a16bb0 in __GI___nanosleep (requested_time=requested_time@entry=0xfffee48c, remaining=remaining@entry=0x0) at nanosleep.c:27
#3 0xf7a48fd8 in usleep (useconds=<optimized out>) at ../sysdeps/posix/usleep.c:32
#4 0x00038378 in go_threading () at server/threads.c:78
#5 0x00034b60 in main (argc=2, argv=0xfffef684) at server/server_main.c:297
Hexdump of 112702
00000000 6d 73 67 74 65 78 74 7c 31 31 32 37 30 32 7c 2f |msgtext|112702|/|
00000010 77 41 45 53 54 59 33 4e 30 59 7a 52 6a 55 33 4c |wAESTY3N0YzRjU3L|
00000020 54 46 43 4f 44 4e 46 51 47 4e 68 61 6e 4e 76 5a |TFCODNFQGNhanNvZ|
00000030 6e 51 75 59 32 38 75 64 57 73 41 55 48 52 6c 63 |nQuY28udWsAUHRlc|
00000040 33 52 41 59 32 46 71 63 32 39 6d 64 43 35 6a 62 |3RAY2Fqc29mdC5jb|
00000050 79 35 31 61 77 42 55 4d 54 63 7a 4e 6a 4d 35 4d |y51awBUMTczNjM5M|
00000060 6a 55 7a 4e 51 42 50 4d 44 41 77 4d 44 41 77 4d |jUzNQBPMDAwMDAwM|
00000070 44 41 78 4e 53 35 54 5a 57 35 30 49 45 6c 30 5a |DAxNS5TZW50IEl0Z|
00000080 57 31 7a 41 46 5a 6b 61 48 4a 31 64 6d 74 68 64 |W1zAFZkaHJ1dmthd|
00000090 58 4e 6f 61 57 74 41 5a 32 31 68 61 57 77 75 59 |XNoaWtAZ21haWwuY|
000000a0 32 39 74 41 45 31 53 5a 57 4e 6c 61 58 5a 6c 5a |29tAE1SZWNlaXZlZ|
000000b0 44 6f 67 5a 6e 4a 76 62 53 41 78 4d 43 34 31 4c |DogZnJvbSAxMC41L|
000000c0 6a 41 75 4d 69 41 6f 4d 54 55 78 4c 6a 59 77 4c |jAuMiAoMTUxLjYwL|
000000d0 6a 45 34 4d 69 34 78 4f 54 4d 67 57 7a 45 31 4d |jE4Mi4xOTMgWzE1M|
000000e0 53 34 32 4d 43 34 78 4f 44 49 75 4d 54 6b 7a 58 |S42MC4xODIuMTkzX|
000000f0 53 6b 4b 43 57 4a 35 49 47 4e 68 61 6e 4e 76 5a |SkKCWJ5IGNhanNvZ|
00000100 6e 51 75 59 32 38 75 64 57 73 37 49 46 52 6f 64 |nQuY28udWs7IFRod|
00000110 53 77 67 4d 44 6b 67 53 6d 46 75 49 44 49 77 4d |SwgMDkgSmFuIDIwM|
00000120 6a 55 67 4d 44 4d 36 4d 44 41 36 4d 44 51 67 4c |jUgMDM6MDA6MDQgL|
00000130 54 41 77 4d 44 41 4b 43 67 41 3d 7c 0a 6d 73 67 |TAwMDAKCgA=|.msg|
00000140 6d 65 74 61 7c 31 31 32 37 30 32 7c 32 7c 74 65 |meta|112702|2|te|
00000150 78 74 2f 70 6c 61 69 6e 7c 33 30 33 7c 0a |xt/plain|30
Hexdump of 112703
00000000 6d 73 67 74 65 78 74 7c 31 31 32 37 30 33 7c 2f |msgtext|112703|/|
00000010 30 45 45 53 54 59 33 4e 30 59 7a 52 6a 55 33 4c |0EESTY3N0YzRjU3L|
00000020 54 46 43 4f 44 4e 47 51 47 4e 68 61 6e 4e 76 5a |TFCODNGQGNhanNvZ|
00000030 6e 51 75 59 32 38 75 64 57 73 41 55 45 4e 70 64 |nQuY28udWsAUENpd|
00000040 47 46 6b 5a 57 77 41 56 44 45 33 4d 7a 59 7a 4f |GFkZWwAVDE3MzYzO|
00000050 54 49 31 4d 7a 55 41 51 55 4e 70 64 47 46 6b 5a |TI1MzUAQUNpdGFkZ|
00000060 57 77 41 54 31 39 66 51 32 6c 30 59 57 52 6c 62 |WwAT19fQ2l0YWRlb|
00000070 46 4e 4e 56 46 42 7a 63 47 39 76 62 47 39 31 64 |FNNVFBzcG9vbG91d|
00000080 46 39 66 41 45 70 6b 62 79 42 75 62 33 51 67 61 |F9fAEpkbyBub3Qga|
00000090 6d 39 31 63 6d 35 68 62 41 42 56 55 55 31 54 52 |m91cm5hbABVUU1TR|
000000a0 77 42 4e 51 32 39 75 64 47 56 75 64 43 31 30 65 |wBNQ29udGVudC10e|
000000b0 58 42 6c 4f 69 42 68 63 48 42 73 61 57 4e 68 64 |XBlOiBhcHBsaWNhd|
000000c0 47 6c 76 62 69 39 34 4c 57 4e 70 64 47 46 6b 5a |Glvbi94LWNpdGFkZ|
000000d0 57 77 74 5a 47 56 73 61 58 5a 6c 63 6e 6b 74 62 |WwtZGVsaXZlcnktb|
000000e0 47 6c 7a 64 41 6f 4b 62 58 4e 6e 61 57 52 38 4d |GlzdAoKbXNnaWR8M|
000000f0 54 45 79 4e 7a 41 79 43 6e 4e 31 59 6d 31 70 64 |TEyNzAyCnN1Ym1pd|
00000100 48 52 6c 5a 48 77 78 4e 7a 4d 32 4d 7a 6b 79 4e |HRlZHwxNzM2MzkyN|
00000110 54 4d 31 43 6d 4a 76 64 57 35 6a 5a 58 52 76 66 |TM1CmJvdW5jZXRvf|
00000120 48 52 6c 63 33 51 4b 63 6d 56 74 62 33 52 6c 66 |HRlc3QKcmVtb3Rlf|
00000130 47 52 6f 63 6e 56 32 61 32 46 31 63 32 68 70 61 |GRocnV2a2F1c2hpa|
00000140 30 42 6e 62 57 46 70 62 43 35 6a 62 32 31 38 4d |0BnbWFpbC5jb218M|
00000150 48 78 38 43 67 41 3d 7c 0a 6d 73 67 6d 65 74 61 |Hx8CgA=|.msgmeta|
00000160 7c 31 31 32 37 30 33 7c 31 7c 61 70 70 6c 69 63 ||112703|1|applic|
00000170 61 74 69 6f 6e 2f 78 2d 63 69 74 61 64 65 6c 2d |ation/x-citadel-|
00000180 64 65 6c 69 76 65 72 79 2d 6c 69 73 74 7c 32 38 |delivery-list|28|
00000190 37 7c 0a |7|.|
00000193
So, on the plus side, doing my daily lunchtime check of code.citadel.org, I saw that Citadel 1008 has been built.
On the negative side, Easyinstall still gives 1007.
Am I just early to the party? I feel like I might well be, but I just wanted to mention it in case something didn't get updated like it should have down the line.
1008 contains a hotfix that is intended to fix the problem cjonline is describing.
It is now available on Easy Install. I'm still working on his problem so if that turns out not to be the fix there will be another release right behind it.
If you're a user of the text mode client, there has been some significant refactoring of that code. Not a lot of what we did is readily visible but we had a few people who wanted to build on top of it so we did some very nice cleaning up in that part of the system. It was really old code, full of gotos and other horrors, so it needed some love :)
Subject: Re: Citadel Protocol binding for Dart Native?
Wed Jan 15 2025 23:00:26 UTCfrom IGnatius T Foobar Subject: Re: Citadel Protocol binding for Dart Native?
First of all, it's awesome that you want to build on top of the Citadel system.
Whatever you need to succeed, we will be happy to assist. Let me know if you want to work on it in the Citadel Development room and we can get you access to that.
...
Barring that, I believe you're correct that the "native" approach would be to write a dart:ffi binding to Citadel's native wire protocol. The upside to this is that it's guaranteed to work and the native protocol is VERY stable and secure.
So there you go. Let me know if any of this tickled your fancy.
cjonline: I have successfully reproduced your crash and can confirm that the hotfix in Citadel 1008 will prevent the server from crashing.
However, I should warn you that if your queue contains thousands of spams, you definitely don't want to just install the fix and go right back online, because that will cause all of the spams to be delivered (minus the corrupted one that's crashing the server).
If you don't have a backup that was taken before the spams arrived, may I suggest this course of action:
0. Start taking backups in the future. Please.
1. Upgrade the Citadel installation, but don't start it yet.
2. Disconnect your server from the network, *or* if you're proficient with iptables, block outgoing connections on port 25.
3. Start the Citadel Server and log in.
4. Go to the hidden room called __CitadelSMTPspoolout__ (the text client might be good for this)
5. DELETE EVERY MESSAGE IN THAT ROOM. That's the queue.
6. Shut down Citadel Server, take a backup, start it up again, and go back online.
Obviously you're also going to want to audit your system and find the account that was compromised, and change the password.
I hope this is helpful!
Subject: Re: Citadel Protocol binding for Dart Native?
Thanks for the warnings about WebCit. I doubt if I will use WebCit-NG
either, though. At this point it is a toss-up between adapting from the
text client or rewriting the protocol bindings in Dart.
The client protocol handler in the text client (citadel_ipc.c) might be an excellent place to start. The interface to that library, and in particular the CtdlIPCGenericCommand() interface (through which all other commands run) is long term stable. Should your project be a big success, we could even think about splitting it out into a separate component in the future to make updates easier.
In fact, we recently completed a project to make the client more strict about doing 100% of its server communication through either the per-method functions or CtdlIPCGenericCommand() at the very least. The reason for this, aside from being technically correct, is that we want to add other transports (UDP, HTTP, various darknet transports, maybe packet radio) in the future and it will be convenient to be able to just write other transports to that same interface without having to heavily modify the client.
Your project sounds interesting and fun. Looking forward to seeing it.
Subject: Re: No working install posible on debian bookworm or other raspberry pi os
I just thought I'd report that Debian Bookworm on my Cubox i4Pro is working on version 1007! The only part of my server that is not working is the dynamic DNS hack on my parents' router to present a subdomain publicly on the webs but I've logged in through the IP address on the router manually and that worked flawlessly! Of course it will not be as fast when accessing the upstream of an ADSL connection but I thought I'd report that Citadel and WebCit are working on the Cubox.
If you don't feel like looking up the specs of the Cubox i4pro, I'll list some of them here. ARM7, 32-bit instruction set, 2 GiB of total RAM, Gigabit Ethernet (though the CPU can't drive it past half-speed) and the untested parts are the eSATA port with an external drive bay (sold separately). It's a pity those Cubox machines from SolidRun are hard to find. It'd make a mean little server if I found a better internet gateway to put it on. So far it is running fine with a 128 GiB MicroSD card but I've heard that those wear out quickly. Maybe I'll have to hook up an external drive. (Not USB though, since it only has 2 USB2 ports and no USB3, it'll have to be an eSATA and probably a platter drive at that, since I'm too cheap to put an SSD in it.)
TLDR: IT WORKS!
Thanks for your help :)
its finally up and running and not crashing anymore..
How can I bulk delete messages in the smtp queue.. ? there is thousands.
Craig.
cjonline: I have successfully reproduced your crash and can confirm that the hotfix in Citadel 1008 will prevent the server from crashing.
However, I should warn you that if your queue contains thousands of spams, you definitely don't want to just install the fix and go right back online, because that will cause all of the spams to be delivered (minus the corrupted one that's crashing the server).
If you don't have a backup that was taken before the spams arrived, may I suggest this course of action:
0. Start taking backups in the future. Please.
1. Upgrade the Citadel installation, but don't start it yet.
2. Disconnect your server from the network, *or* if you're proficient with iptables, block outgoing connections on port 25.
3. Start the Citadel Server and log in.
4. Go to the hidden room called __CitadelSMTPspoolout__ (the text client might be good for this)
5. DELETE EVERY MESSAGE IN THAT ROOM. That's the queue.
6. Shut down Citadel Server, take a backup, start it up again, and go back online.
Obviously you're also going to want to audit your system and find the account that was compromised, and change the password.
I hope this is helpful!
How can I bulk delete messages in the smtp queue.. ? there is
thousands.
The rude-and-crude way would be to go to the room called __CitadelSMTPspoolout__ and delete the room, then restart Citadel Server. When you restart it a new queue will be created.
When you delete a room its contents are moved to a hidden namespace and resources are reclaimed the next time the auto-purger is run, so you won't see a change in disk space immediately.
Subject: Re: No working install posible on debian bookworm or other raspberry pi os
I just thought I'd report that Debian Bookworm on my Cubox i4Pro is
working on version 1007!
Sounds like a neat project. It sort of has the same vibe as the old Cobalt microservers.
thanks, but I had message in there that I needed to keep... therefore I managed to change the view of the folder to mailbox view and deleted all the messages..
site is back up and mail is working again..
thanks again.
you Rock!
How can I bulk delete messages in the smtp queue.. ? there is
thousands.
The rude-and-crude way would be to go to the room called __CitadelSMTPspoolout__ and delete the room, then restart Citadel Server. When you restart it a new queue will be created.
When you delete a room its contents are moved to a hidden namespace and resources are reclaimed the next time the auto-purger is run, so you won't see a change in disk space immediately.
The default docker ran with the command from the docs
mkdir /usr/local/citadel docker run -i --rm --network host --volume=/usr/local/citadel:/citadel-data citadeldotorg/citadel
opens starttls ports, but not tls ports. Why would this be?