Citadel? Courier? Cyrus? Dovecot? - I just want to backup my emails

Seems to be saying it’s trying to authenticate as user “cyrus”. Is this valid?

Another thing to check is, is it trying to connect via the imap port (143) or imaps (993)?

FWIW GNU Mailutils comes with an IMAP server too, which I use for about the same purpose as what you seem to be doing. It seemed like a good idea but in practice I rarely use it and read the mailbox movemail writes to directly with an email client instead.

Something like this in /etc/mailutils.conf configures it: " program imap4d {

logging { syslog yes; facility mail; severity debug; };

#debug { # level auth; #};

auth { authentication generic; authorization system; };

login-disabled false; homedir { create false; }

mailbox { mailbox-type "mh"; folder "Mail/"; };

namespace personal { mailbox-mode g=; prefix "" { directory "$home/Mail"; mailbox-type "mh"; }; };

}; "

You need a "mail" group and add users who can log via IMAP to that group.

I've configured Dovecot before too but I find it difficult, so you'd better get advice on that from one of the people who says it's easy.

Yes, I typed this to connect to localmachine, wanting to authenticate as user 'cyrus' with password I've set

I checked this with wireshark on local-loopback. Requests are against port

Thanks! Yes, I see imapd is also created when installing from GNU Mailutils tarball. Confusingly, Raspbian has each a separate package for imapd, pop3, etc. Maybe, they consider this to be easier to just install what's needed, rather than do a 'systemctl disable ...' for all unwanted services.

B.t.w., does GNU Mailutils imapd need mysql to store email details, or is there everything stored in plain text?

Oh sorry, wrong machine... Just reinstalled dovecot to have a clean start.

There are these ports open now and imaps is also up:

PORT STATE SERVICE

I created a user 'dov' for such purposes, hence I have

dov:x:1010:1010::/home/dov:/bin/bash dovecot:x:123:131:Dovecot mail server,,,:/usr/lib/dovecot:/usr/sbin/ nologin dovenull:x:124:130:Dovecot login user,,,:/nonexistent:/usr/sbin/nologin

as dovecot-related users.

At the moment I am stuck because any attempt to log in ends by returning to commandline instantly:

No chance to create a mailbox here. Maybe the definition of who is admin is missing?

Can someone please give a little advice how to log in to create a mailbox and set the password in the right way?

Thank you!

You’re expecting doveadm to enter some kind of interactive command mode? Looking at the various man pages, I don’t think it works that way.

I just tried doveadm as root, and I think it lets me perform admin actions without having to do a dovecot login.

I’ve never used this command before, because I have my Dovecot (and Postfix) setup to keep all mail in ~/.maildir in users’ home directories, and this gets created automatically as mail comes in. Here’s the relevant change to the default configuration that was installed on my Debian setup:

root@theon:~ # diff -u /etc/dovecot/conf.d/10-mail.conf{-orig,}

--- /etc/dovecot/conf.d/10-mail.conf-orig 2025-10-23 12:40:26.294676269 +1300

-mail_path = %{home}/mail

-mail_inbox_path = /var/mail/%{user}

Actually it should be "imap4d".

Probably, and note that when you install from the tarball you won't get the Systemd services added like you (might) get with the packages.

All plain-text, although you can choose the format, MH format in my example. With MH format each email is kept in an individual sequentially-numbered file.

After installing all recommended dependecies, ./configure says

Default mailbox scheme ........ mbox Use PAM ....................... no Use -ltdl ..................... yes Use DBM ....................... no Use GNU TLS ................... yes Use GSASL ..................... yes Use GSSAPI .................... yes Use TCP wrappers .............. yes Pthread support ............... yes Readline support .............. yes Libunistring support .......... yes MySQL support ................. no PostgreSQL support ............ no LDAP support .................. no Radius support ................ no Support for virtual domains ... yes

IPv6 support .................. yes

Interfaces:

Guile ......................... no C++ ........................... no Python ........................ yes

Mailbox formats:

IMAP .......................... yes POP ........................... yes MH ............................ yes maildir ....................... yes dotmail ....................... yes

Mailers:

SMTP .......................... yes Sendmail ...................... yes

Utilities to build:

Servers ....................... pop3d imap4d comsat mda lmtpd Clients ....................... putmail frm mail sieve messages readmsg dotlock movemail mimeview decodemail mh

Wrappers (64bit) is ok, and all services like pop and imap are building. Somehow strange, that it complains about 'C++:no', though gcc is there.

Thanks, best regards, Markus

You have probably installed gcc but not g++.

Hi there,

after a 'make install' to some DESTDIR, I took the created 'usr' dir, chown-ed everything to root:root and verified that the rights are correct.

Then I created a tar.gz archive out of this 'usr' dir.

From this I took alien to convert to rpm: alien --target=`arch` -r gnu-mailutils-3.21.tar.gz

All worked, but when trying to install the rpm I get

This is strange because './configure' said

Default mailbox scheme ........ mbox Use PAM ....................... no Use -ltdl ..................... yes Use DBM ....................... no Use GNU TLS ................... yes Use GSASL ..................... yes Use GSSAPI .................... yes Use TCP wrappers .............. yes Pthread support ............... yes Readline support .............. yes Libunistring support .......... yes MySQL support ................. no PostgreSQL support ............ no LDAP support .................. no Radius support ................ no Support for virtual domains ... yes

IPv6 support .................. yes

Interfaces:

Guile ......................... no C++ ........................... no Python ........................ yes

Mailbox formats:

IMAP .......................... yes POP ........................... yes MH ............................ yes maildir ....................... yes dotmail ....................... yes

Mailers:

SMTP .......................... yes Sendmail ...................... yes

Utilities to build:

Servers ....................... pop3d imap4d comsat mda lmtpd Clients ....................... putmail frm mail sieve messages readmsg dotlock movemail mimeview decodemail mh

The 3 devel-s withing the 'rpm -i' error alert were installed as devel, and the 2 gsasl-s, not sure, but maybe they are runtime requirements.

Any idea what's still missing here?

Thank you!

On Raspbian there is a package 'g++' to cover the c++ things.

While, on Mageia I cannot find such package. Instead there is 'gcc-c++', which claims 'This package adds C++ support to the GNU C compiler'. I have installed 'gcc-c++', so, maybe GNU-mailutil's './configure' is being confused here?

Thank you!

On a closer look it looks like that bit of output depends on whether you use an --enable-cxx option. I’ve no idea what it’s for but unless it corresponds to something you know you want, I’d ignore it.

x86_64? This is in the Raspberry Pi Group. Did you pick the wrong newsgroup to discuss this or are you trying to complile on a PC but run Mailutils on a RPi? That's possible, but difficult, and for this you'd be much better compiling Mailutils on the RPi instead.

The configure script worked if you got the mailutils binaries built, which it sounds like you did (otherwise DESTDIR will be empty). I've never used "alien" and don't know how it goes about making packages, but it looks like something must be going wrong there. If you're trying to install to RPi (ARM) a package built for x86_64, then that's definitely what's going wrong.

That seems a very roundabout process. On Debian, after doing “apt-get source” to get the package source and making the desired changes, rebuilding the .deb file is as easy as using the “debuild” command.

Is there not something directly equivalent for your rpm-based distro?

Hello, thanks! And, no, I did not click onto the wrong group. Instead, the desperate situation is like that:

On latest raspbian, debian for ARM, there is only an ancient version 3.10. Good to play with, but that's all.

On debian for intel, there is version 3.20 - but it is not complete. imap4d and pop3d are missing and other stuff. Just left away.

On Redhat / Mageia for intel, which I am also running, there is even no such package like GNU mailutils at all.

So, no big difference, in which group to ask. No 'one group for all'. Whatever you want to achieve, you have to try yourself.

__But, as far as I see, here are the experts.__

So, I take this chance to say thank you for all the hints I already got.

Besides this:

Looking at the 'Failed dependencies' message above, this looks as if the devel packages have to be linked statically, otherwise movemail and others cannot access them and are asking for them again. Do you dispose this to be so?

Thank you!

Best regards,

Markus

IMAP and POP support is in separate packages -- typical Debian philosophy, you install just the ones you need:

$ apt-cache search -n mailutils libmailutils-dev - development files for GNU mailutils libmailutils9t64 - GNU Mail abstraction library mailutils - GNU mailutils utilities for handling mail mailutils-common - common files for GNU mailutils mailutils-comsatd - GNU mailutils-based comsatd daemon mailutils-doc - documentation files for GNU mailutils mailutils-guile - GNU mailutils Guile interpreter and modules mailutils-imap4d - GNU mailutils-based IMAP4 Daemon mailutils-mda - GNU mailutils utilities for handling mail -- MDA mailutils-mh - GNU mailutils-based MH utilities mailutils-pop3d - GNU mailutils-based POP3 Daemon python3-mailutils - GNU Mail abstraction library (Python3 interface)

Just note that nothing you do "on intel" will just work on ARM. If you want Mailutils on both ARM and "intel", you need to build it twice. If you just want it on one ARM system, then repeat everything on the ARM system and just do "sudo make install" without the DESTDIR and package stuff which only matters if you want to install easily to other RPis (and even then I'd personally just make a tarball and unpack that to "/" after installing the dependencies manually, rather than making an RPM package).

Static linking should avoid any dependency problem when it's built on ARM. Building on x86_64 "intel", nothing will work on ARM unless you install and use a cross-compiling environment. But don't do that unless you're desperate for a challenge, just build on ARM in the first place, since any RPi is capable of compiling Mailutils.

If you want the same build to run on Debian and "Redhat / Mageia", then static linking can achieve that more reliably. Note that it will prevent security updates to gnutls being applied when running Mailutils with encrypted connections, until you rebuild the static binary. You should be able to use the Debian x86_64 Mailutils packages at least, so you probably don't need to try running the Mageia build on there. Just compile and install Mailutils normally on "Redhat / Mageia for intel" and "debian for ARM" as two separate processes.

I don’t know RPM well but for most packaging systems, if it says you’re missing a dependency then it just means you need to install the package containing that dependency.

Certainly within Debian the norm is for executables to be dynamically linked and the package containing then to have a dependency on the runtime packages for each shared library. Static executables are rare at best.

In your case, I thought you were trying to do a local build and install. So I don’t see why RPM is involved at all.

By exporting to some DESTDIR, then create a tar.gz / slackware install archive, and then convert this into a deb or rpm with the help of alien conversion tool, you have full control over the location of the files (derived from make install), and this guarantees that nothing is overwritten by accident. Also, every install is tracked.

Meaning, same as make install directly, but with full control over it