erooster-mail/erooster

A mail suite written in rust meant to be easy to use.

Erooster

A mail suite written in rust meant to be easy to use.

Getting started

Currently, the setup is quite rough.

You need some certificates for your server (PEM format) and a Postgres database as well as dkim keys. The easiest way to get them is to use opendkim like this:

opendkim-genkey \
    --domain=<hostname> \
    --subdomains

you should save the file in the folder at mail.dkim_key_path. You also should add the TXT dns record that is in the txt file to your domain.

To get started you need a config.yml like this, it can either be in /etc/erooster or the working dir:

tls:
  key_path: "./certs/key.pem"
  cert_path: "./certs/cert.pem"
mail:
  maildir_folders: "./maildir"
  hostname: "localhost"
  displayname: Erooster
  dkim_key_path: "/etc/erooster/keys/default.private"
  dkim_key_selector: "default"
database:
  postgres_url: ""
listen_ips:
  - "[::1]"
  - "127.0.0.1"
webserver:
  port: 80
  tls: false
sentry: false
rspamd:
  address: http://localhost:11333

The maildir_folders defines where the emails and folders can be found at. This is close to the maildir format postfix uses. (We use other files to keep track of the state of it)

After that, you can just do cargo run --release to run it. The server is reachable via the usual IMAP ports. STARTTLS is only supported for SMTP.

Setting up users

To set up users, you can use the eroosterctl command. It will talk to the database. So make sure your config file is set up.

To register a user, you simply run eroosterctl register and follow the questions. The password is saved as an argon2 hash inside the database.

To change a password, there is the change-password subcommand. You need to provide the old password and the new one. It is planned that admins can also change this using a pre-encrypted password instead. In the future, this is going to be replaced by an integrated web interface users can directly use.

Note: The status subcommand at this time doesn't actually check the server status.

Features

• Imap4rev2 compatible
• Maildir support
• TLS by default
• Single binary
• Low Resource usage
• Postgres first
• Integrated SMTP server

Non Goal

• Implementing every single piece of optional spec
• MySQL/MariaDB support
• Support for IMAP LOGIN command (It is per rev2 spec)
• Support for POP3
• Support for Exchange (this is subject to change)

Error Reporting

Erooster by default does not auto report any panics or errors. It provides however a GitHub reporting link on panics.

Comparisons

As I made a Reddit post, some comparisons were made in the commands. You can check them out at https://www.reddit.com/r/rust/comments/uyxxrg/comment/ia7qwcg/?utm_source=share&utm_medium=web2x&context=3

Support

Due to personal constraints, I currently do not prove enterprise support for this. Please open issues instead. I will try to reply as soon as I can, but I cannot guarantee a specific time frame.

Contact

To contact the erooster team you can find us at https://matrix.to/#/#erooster:midnightthoughts.space or if an email is absolutely needed please write to [email protected]. As written in the Support section, there is no enterprise support at this time. So please don't ask for it. It will just fill up the mailbox. :)

Note on SQLITE

Note that this isnt officially supported outside of running tests. Some migrations rely on sql functions which sqlite does NOT support.

Running sqlite in prod means no support whatsoever.

erooster's Issues

Consider switching dmarc lib

It seems like https://github.com/stalwartlabs/mail-auth is a lot more powerful and useful. We probably want to move to that

Integration with rspamd

There are currently seemingly 2 ways of connecting this to rspamd.

One being the milter proto and the other one using the http api. On first sight, the http one seems a lot nicer.

I asked about this in https://matrix.to/#/!tNuTutAsraCZsJFZOS:matrix.org/$kijaM-MAMgzHYcpBBhQwLteRbSFFNu3Om_pZBzt7Sew?via=matrix.org&via=midnightthoughts.space (their irc) what the best option is.

It probably makes sense to do this using some kind of modular trait thingy to be able to integrate alternatives too.

RUSTSEC-2022-0093: Double Public Key Signing Function Oracle Attack on `ed25519-dalek`

Double Public Key Signing Function Oracle Attack on ed25519-dalek

Details
Package	ed25519-dalek
Version	1.0.1
URL	https://github.com/MystenLabs/ed25519-unsafe-libs
Date	2022-06-11
Patched versions	>=2

Versions of ed25519-dalek prior to v2.0 model private and public keys as
separate types which can be assembled into a Keypair, and also provide APIs
for serializing and deserializing 64-byte private/public keypairs.

Such APIs and serializations are inherently unsafe as the public key is one of
the inputs used in the deterministic computation of the S part of the signature,
but not in the R value. An adversary could somehow use the signing function as
an oracle that allows arbitrary public keys as input can obtain two signatures
for the same message sharing the same R and only differ on the S part.

Unfortunately, when this happens, one can easily extract the private key.

Revised public APIs in v2.0 of ed25519-dalek do NOT allow a decoupled
private/public keypair as signing input, except as part of specially labeled
"hazmat" APIs which are clearly labeled as being dangerous if misused.

See advisory page for additional details.

IMAP RFCs worth supporting

• https://www.rfc-editor.org/rfc/rfc6154.html

Smtp sending should try tls

Currently we don't try tls which breaks sending to mailcow it seems.

Setup website

A small web presence and maybe a (secured) demo email server over at https://erooster.email would be nice

[Tracking] Client and provider support

Email clients that are known fully working

• None

Email clients known to be able to send emails

• k9mail
• thunderbird

Email clients known to display messages

• k9mail
• thunderbird

Software or providers that (tend to) accept our emails

• Google
• postfix with rspamd and postscreen
• onsite Exchange seems to work (sample set of 1 test both directions)

Improve usability on startup

• Allow changing cert names
• Allow setting maildir path in config
• Prebuilt packages?
• Add a manpage

Unknown command "MGLNDD"

Sentry Issue: EROOSTER-3

Figure out what wants to call "MGLNDD" and figure out what "MGLNDD" is

Add benchmarks

Some benchmarks would be nice to find issues with and performance gains or regressions.

Honeypot mode

This is more a "cool to have" feature to add along the way and should be a compiletime flag.

Basically I receive lots of spam on my test instance. I was wondering if I can safely accept this.

The differences needed would be:

• It should pretend to accept stuff and behave like an open relay
• It should fully not compile the sending parts of the server to make sure this doesnt actually send emails ever.
• It should send things to rspamd
• It should log the content and requests to a file format on disk
• It should generate a list of shasums to check if we got it before.
  • The sum must be only over the body
  • If it is seen multiple times we record the target address among the previous attempt
• We should record the rspamd result
• We should auto commit new files to git
• We should have a way to send undetected things to rspamd to make sure they have learned this.

We seem to do TLS on sending not quite right yet

Sentry Issue: EROOSTER-7

[a0e520ad-5ed6-4d35-94f9-bf7ad861a4e9] Error sending email via tls on port 465: invalid peer certificate contents: invalid peer certificate: CertNotValidForName

RUSTSEC-2023-0052: webpki: CPU denial of service in certificate path building

webpki: CPU denial of service in certificate path building

Details
Package	webpki
Version	0.22.0
Date	2023-08-22

When this crate is given a pathological certificate chain to validate, it will
spend CPU time exponential with the number of candidate certificates at each
step of path building.

Both TLS clients and TLS servers that accept client certificate are affected.

This was previously reported in
<briansmith/webpki#69> and re-reported recently
by Luke Malinowski.

rustls-webpki is a fork of this crate which contains a fix for this issue
and is actively maintained.

See advisory page for additional details.

Provide fail2ban jail setup

It shouldn't be too hard to make logs and a jail for fail2ban :) It seems this currently attracts a lot of fuzzers and attackers. Banning them would be quite nice. In the future an integration with rspamd would be nice as well.

Move folder translation code to storage

We dont strip the ending dot from SMTP

Currently, we have a dangling \r\n.\r\n in our mails. :) We should cut that away.

RUSTSEC-2023-0071: Marvin Attack: potential key recovery through timing sidechannels

Marvin Attack: potential key recovery through timing sidechannels

Details
Package	rsa
Version	0.7.2
URL	RustCrypto/RSA#19 (comment)
Date	2023-11-22

Impact

Due to a non-constant-time implementation, information about the private key is leaked through timing information which is observable over the network. An attacker may be able to use that information to recover the key.

Patches

No patch is yet available, however work is underway to migrate to a fully constant-time implementation.

Workarounds

The only currently available workaround is to avoid using the rsa crate in settings where attackers are able to observe timing information, e.g. local use on a non-compromised computer is fine.

References

This vulnerability was discovered as part of the "Marvin Attack", which revealed several implementations of RSA including OpenSSL had not properly mitigated timing sidechannel attacks.

See advisory page for additional details.

Smtp sending tracking issue

Known todos:

• #12
• #13
• Make sure we don't crash the job if only one of the servers didn't like our email.
• dmarc (This is more something for the web interface to generate. I added it to my test setup now)
• spf (This is more something for the web interface to generate. I added it to my test setup now)
• dkim (we dont verify it at this stage)
• Use STARTTLS when sending
• dane
• arc
• Notify the user about the messages' status, similar to how postfix does
• Fix parser: Failed to parse fetch arguments: "Parsing Error: VerboseError { errors: [(\" RFC822.HEADER FLAGS)\", Char(')')), (\"(UID RFC822.SIZE RFC822.HEADER FLAGS)\", Context(\"fetch_arguments\"))] }" request was (UID RFC822.SIZE RFC822.HEADER FLAGS) (Turns out we got deprecated requests)

And likely more...

Make email case insensitive

We seem to currently not make emails case insensitive. This should be fixed as it leads to issues.

Add Received Header to message when we receive something

Other mailservers add a Received header to the message when they receive the message. We should also do this.

We strip the suffix dot incorrect

In https://github.com/MTRNord/erooster/blob/main/src/smtp_servers/sending.rs#L316

The none case means we had no suffix. So we need to just return the string in that case instead of omitting it.

Consider moving to arc-swap for the rwlock

https://docs.rs/arc-swap/latest/arc_swap/index.html

Provide docker image/suite

Some docker files would be nice to make deployment easier.

For now only the server. Later also a docker compose for pg14, the server and then a Web interface

Smtp sending doesn't exit if we get an error on the rcpt to commsnd

Consider Prometheus endpoint

Having a Prometheus endpoint to easily discover issues would be nice. Also adds an easy way to monitor this.

A Webserver will be needed anyway for an api to manage this with later on.

Check LIST/LSUB and SELECT response carefully

Seems like thunderbird is quite unhappy with them. I am not sure what is going on there.

Unlimited size of incoming data can be abused for DOS

RUSTSEC-2021-0141: dotenv is Unmaintained

dotenv is Unmaintained

Details
Status	unmaintained
Package	dotenv
Version	0.15.0
URL	dotenv-rs/dotenv#74
Date	2021-12-24

dotenv by description is meant to be used in development or testing only.

Using this in production may or may not be advisable.

Alternatives

The below may or may not be feasible alternative(s):

• dotenvy

See advisory page for additional details.

RUSTSEC-2020-0077: memmap is unmaintained

memmap is unmaintained

Details
Status	unmaintained
Package	memmap
Version	0.7.0
URL	danburkert/memmap-rs#90
Date	2020-12-02

The author of the memmap crate is unresponsive.

Maintained alternatives:

• memmap2

See advisory page for additional details.

Change Password should verify password every time

Hey, I was just looking through your code. I noticed that you have a verify_password function and a change_password function.

It would probably be more ideal from a security perspective if you called the verify_password function inside the change_password function. This will allow you to reuse your change_password function (when you start to implement multiple ways to access the system. I.e. Website, terminal, etc.) It'll prevent you from forgetting to add a verification into every implementation.

I noticed when you create a new user, you use the change_password function as well here:
https://github.com/MTRNord/erooster/blob/b7c1da4c3fba816b3fc25e94a92d2b7826b283ac/src/cmds/eroosterctl.rs#L270

If you wanted to refactor it you could add the password field to your add_user SQL query/function. then add in a current_password parameter to your change_password function, and then call verify_password inside change_password.
After all it makes more sense, since you aren't 'changing' a password that hasn't been set.

I hope that makes sense. This is an interesting project and I'd be happy to contribute if you're accepting PR's.

Fix tests

Tests are outdated again.

UIDVALIDITY probably should only be updated when (max) UID is changed for mailbox

I think? Need to double check. It may explain the jumpy list in thunderbird.

Implement the Require TLS smtp RFC

https://www.rfc-editor.org/rfc/rfc8689.html

Requires Dane and Dnssec 1 2 3

RUSTSEC-2021-0139: ansi_term is Unmaintained

ansi_term is Unmaintained

Details
Status	unmaintained
Package	ansi_term
Version	0.12.1
URL	ogham/rust-ansi-term#72
Date	2021-08-18

The maintainer has adviced this crate is deprecated and will not
receive any maintenance.

The crate does not seem to have much dependencies and may or may not be ok to use as-is.

Last release seems to have been three years ago.

Possible Alternative(s)

The below list has not been vetted in any way and may or may not contain alternatives;

• anstyle
• console
• nu-ansi-term
• owo-colors
• yansi

See advisory page for additional details.

[CLIENT SUPPORT] [Tracking] K9mail missing features

Tracking issue for (known) stuff missing for K9mail to work:

• support the UID SEARCH command

RUSTSEC-2023-0071: Marvin Attack: potential key recovery through timing sidechannels

Marvin Attack: potential key recovery through timing sidechannels

Details
Package	rsa
Version	0.9.5
URL	RustCrypto/RSA#19 (comment)
Date	2023-11-22

Impact

Due to a non-constant-time implementation, information about the private key is leaked through timing information which is observable over the network. An attacker may be able to use that information to recover the key.

Patches

No patch is yet available, however work is underway to migrate to a fully constant-time implementation.

Workarounds

The only currently available workaround is to avoid using the rsa crate in settings where attackers are able to observe timing information, e.g. local use on a non-compromised computer is fine.

References

This vulnerability was discovered as part of the "Marvin Attack", which revealed several implementations of RSA including OpenSSL had not properly mitigated timing sidechannel attacks.

See advisory page for additional details.

Do not scope UIDs globally

As per https://datatracker.ietf.org/doc/html/rfc2683#autoid-22 we should NOT have global UIDs. Instead they should be per mailbox (aka. folder)

Management interface tracking issue

Stage 1

• Build a cli
  • Allow creation of users
  • Allow deletion of users
  • Allow changing passwords
    • Allow changing passwords in already argon2 hashed form so that the admin doesn't know the password
  • Allow creation of aliases
  • Allow removal of aliases
  • Allow moving aliases

Stage 2

• Build a Web interface
• Port same features as cli has
• Allow multiple domains
• Allow dkim relevant things to be set up (see mailu)
• Allow users to change their own passwords.

Reference: mailu and mailcow.

RUSTSEC-2020-0168: mach is unmaintained

mach is unmaintained

Details
Status	unmaintained
Package	mach
Version	0.3.2
URL	fitzgen/mach#63
Date	2020-07-14

Last release was almost 4 years ago.

Maintainer(s) seem to be completely unreachable.

Possible Alternative(s)

These may or may not be suitable alternatives and have not been vetted in any way;

• mach2 - direct fork

See advisory page for additional details.

Improve IMAP response codes

https://www.rfc-editor.org/rfc/rfc5530.html

Evaluate if we follow the state checks close enough

It may be that we don't follow all the state checks yet. While this usually will just crash the connection, we should make sure to print proper errors in those cases instead.

RUSTSEC-2021-0127: serde_cbor is unmaintained

serde_cbor is unmaintained

Details
Status	unmaintained
Package	serde_cbor
Version	0.11.2
URL	https://github.com/pyfisch/cbor
Date	2021-08-15

The serde_cbor crate is unmaintained. The author has archived the github repository.

Alternatives proposed by the author:

• ciborium
• minicbor

See advisory page for additional details.

RUSTSEC-2020-0071: Potential segfault in the time crate

Potential segfault in the time crate

Details
Package	time
Version	0.1.43
URL	time-rs/time#293
Date	2020-11-18
Patched versions	>=0.2.23
Unaffected versions	=0.2.0,=0.2.1,=0.2.2,=0.2.3,=0.2.4,=0.2.5,=0.2.6

Impact

Unix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.

The affected functions from time 0.2.7 through 0.2.22 are:

• time::UtcOffset::local_offset_at
• time::UtcOffset::try_local_offset_at
• time::UtcOffset::current_local_offset
• time::UtcOffset::try_current_local_offset
• time::OffsetDateTime::now_local
• time::OffsetDateTime::try_now_local

The affected functions in time 0.1 (all versions) are:

• at
• at_utc
• now

Non-Unix targets (including Windows and wasm) are unaffected.

Patches

Pending a proper fix, the internal method that determines the local offset has been modified to always return None on the affected operating systems. This has the effect of returning an Err on the try_* methods and UTC on the non-try_* methods.

Users and library authors with time in their dependency tree should perform cargo update, which will pull in the updated, unaffected code.

Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3 series.

Workarounds

No workarounds are known.

References

time-rs/time#293

See advisory page for additional details.

Nix flake TODOs

• Add postgres dep
• Figure out how configs are supposed to work with flakes

Store needs to update the db as we otherwise get the wrong (now non existent) email after we set the first flag

Abstract the mail storage to later allow multiple backends

Currently, this is maildir only.

We can provide a trait for example to abstract this in the future if someone wants to use some other backend for their mail.

panic: Failed to parse fetch arguments: "Parsing Error: VerboseError { errors: [(\".PEEK[HEADER.FIELDS (...

We seem to not yet correctly parse the args for fetch:

Sentry Issue: EROOSTER-2

panic: Failed to parse fetch arguments: "Parsing Error: VerboseError { errors: [(\".PEEK[HEADER.FIELDS (From To Cc Bcc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Content-Type Reply-To x-spamd-result x-spam-score x-rspamd-score x-spam-status x-mailscanner-spamcheck X-Spam-Flag x-spam-level)])\", Char(')')), (\"(UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (From To Cc Bcc Subject Date Message-ID Priority X-Priority References Newsgroups In-Reply-To Content-Type Reply-To x-spamd-result x-spam-score x-rspamd-score x-spam-status x-mailscanner-spamcheck X-Spam-Flag x-spam-level)])\", Context(\"fetch_arguments\"))] }"
  File "panicking.rs", line 584, in rust_begin_unwind
  ?, in erooster::imap_commands::uid::Uid::exec::{{closure}}
  ?, in erooster::imap_commands::Data::parse::{{closure}}
  ?, in tokio::runtime::task::core::CoreStage<T>::poll
  ?, in tokio::runtime::task::harness::poll_future
...
(21 additional frame(s) were not displayed)

Make it possible to implement other auth mechanisms

Currently, this is hard-tied into the Postgres db. It would be nice to allow multiple auth mechanisms to be added.

Based on: https://www.reddit.com/r/rust/comments/uyxxrg/comment/iaak1ls/?utm_source=share&utm_medium=web2x&context=3