Hi Everyone,

Everytime I try to connect to citadel via IMAPS or POP3S I get a crash when using SSL

citadel-1  | citserver[8]: context: session (IMAP) started from 77-172-227-99.fixed.kpn.net (77.172.227.99) uid=-1

citadel-1  | citserver[8]: 1.385 STARTTLS

citadel-1  | citserver[8]: ---- Looking up [STARTTLS] -----

citadel-1  | citserver[8]: Found.

citadel-1  | citserver[8]: crypto: using certificate chain keys/citadel.cer

citadel-1  | citserver[8]: crypto: using private key keys/citadel.key

citadel-1  | citserver[8]: sysdep: new client socket 36

citadel-1  | citserver[8]: context: session (IMAP) started from 77-172-227-99.fixed.kpn.net (77.172.227.99) uid=-1

citadel-1  | citserver[8]: 1.38 STARTTLS

citadel-1  | citserver[8]: ---- Looking up [STARTTLS] -----

citadel-1  | citserver[8]: Found.

citadel-1  | ctdlvisor: pid=8 exited, status=139, exitcode=0

citadel-1  | ctdlvisor: citserver crashed on signal 11

citadel-1  | ctdlvisor: citserver running on pid=16

citadel-1  | ctdlvisor: executing citserver

The certificate I am using where generated with letsencrypt !

Any ideas ?

Hi Everyone,

I am using SSL certificates from letsencrypt and for some reason they crash citadel server when using IMAPS or POP3S

The logs even in highest verbosity are quite bare Any ideas ?

citadel-1  | webcit[9]: Loading with: -> LoadStartpage("dotskip?room=_BASEROOM_", 0)

citadel-1  | citserver[8]: [pierre(2)] CHEK

citadel-1  | citserver[8]: [pierre(2)] GOTO __CitadelSMTPspoolout__

citadel-1  | citserver[8]: room_ops: __CitadelSMTPspoolout__ : 1 seen of 2 total messages, oldest=13, newest=32

citadel-1  | citserver[8]: [pierre(2)] LFLR

citadel-1  | citserver[8]: [pierre(2)] NOOP

citadel-1  | citserver[8]: sysdep: new client socket 37

citadel-1  | citserver[8]: context: session (IMAP) started from 77-172-227-99.fixed.kpn.net (77.172.227.99) uid=-1

citadel-1  | citserver[8]: 1.385 STARTTLS

citadel-1  | citserver[8]: ---- Looking up [STARTTLS] -----

citadel-1  | citserver[8]: Found.

citadel-1  | citserver[8]: crypto: using certificate chain keys/citadel.cer

citadel-1  | citserver[8]: crypto: using private key keys/citadel.key

citadel-1  | citserver[8]: sysdep: new client socket 36

citadel-1  | citserver[8]: context: session (IMAP) started from 77-172-227-99.fixed.kpn.net (77.172.227.99) uid=-1

citadel-1  | citserver[8]: 1.38 STARTTLS

citadel-1  | citserver[8]: ---- Looking up [STARTTLS] -----

citadel-1  | citserver[8]: Found.

citadel-1  | ctdlvisor: pid=8 exited, status=139, exitcode=0

citadel-1  | ctdlvisor: citserver crashed on signal 11

citadel-1  | ctdlvisor: citserver running on pid=16

citadel-1  | ctdlvisor: executing citserver

Hi, I woke this morning to find citserver had crashed on my linux box..  I restarted but still same issue..

I checked the partition and found 100% space was being used.. 

the /data folder had thousands of LOG files (berkely DB logs).   The disk ran out of space (85GB)..

how do I recover from this to get the server back up and running..  I ran the command db_archive -d (to delete unused logs) but the command just sat doing nothing .. after 30mins the space was still using 100%...

please help

Craig.

If you walk me through it I would be happy to. Currently using the docker version.

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:  

Sun Jan 12 2025 23:58:25 UTC from IGnatius T Foobar Subject: Re: citdel db issues (Log)

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.

Found this:

How do I make my system produce core dump files?

On Linux this can be achieved with the ulimit command which is documented in the bash man page.

  ulimit -c 999999

The core files are created in the working directory. Be careful, they can grow and eat up your disk space. Making the whole system create core files on crashes in a central folder can be achieved like this:

# local to citadel by editing /etc/init.d/citadel or /etc/init.d/webcit and add in the second line:
ulimit -c unlimited

# systemwide by doing:
echo 1 > /proc/sys/kernel/core_uses_pid
echo /tmp/core-%e-%p-%t > /proc/sys/kernel/core_pattern

Interesting thing to, dovecot crash also with those certificates ... I wonder what's happening with them, they are from letsencrypt

mailserver  | 2025-01-13T15:33:58.960395+01:00 mail amavis[900]: No decoder for       .zst 

mailserver  | 2025-01-13T15:34:02.631826+01:00 mail dovecot: imap-login: Fatal: master: service(imap-login): child 1001 killed with signal 11 (core dumped) [last ip=149.11.64.115]

mailserver  | 2025-01-13T15:34:02.930774+01:00 mail dovecot: imap-login: Fatal: master: service(imap-login): child 1003 killed with signal 11 (core dumped) [last ip=149.11.64.115]

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

Mon Jan 13 2025 10:55:26 UTC from cjonline Subject: Re: citdel db issues (Log)

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:  

 

Sun Jan 12 2025 23:58:25 UTC from IGnatius T Foobar Subject: Re: citdel db issues (Log)

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.

 

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.

Sun Jan 12 2025 23:58:25 UTC from IGnatius T Foobar Subject: Re: citdel db issues (Log)

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.

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

1. Create Dart binding for the Citadel server protocol based on text client code
2. Create Flutter app based on the bindings
3. Add end-to-end encryption and compression algorithms to both ends
4. ???
5. 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.

Hi IGnatius T Foobar

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!!  :(

Mon Jan 13 2025 17:25:19 UTC from cjonline Subject: Re: citdel db issues (Log)

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

 

 

Mon Jan 13 2025 10:55:26 UTC from cjonline Subject: Re: citdel db issues (Log)

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:  

 

Sun Jan 12 2025 23:58:25 UTC from IGnatius T Foobar Subject: Re: citdel db issues (Log)

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.

 

 

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.