is there an option for a configurable timeout?

[bwdmr]

to configure a timout wherein emails are dropped completely after a preset amount of time that can be included as an option to sending emails.

[yudin-s]

Mailpit already has this at the server-retention level with --max-age; it is not an SMTP option attached to each message.

For example:

mailpit --max-age 24h

--max-age accepts integer hours or days, such as 24h or 7d, and old messages are removed by the cleanup job. Mailpit also has --max for keeping only the most recent N messages, so the two knobs are roughly:

mailpit --max 500 --max-age 24h

Use --max-age if you want time-based expiry, and --max if you mainly want to cap mailbox growth.

If you meant "the sending app chooses a different expiry per email", that is a different feature. For that, you would need custom tagging plus an external cleanup script/API call, or a new Mailpit feature.

That should make the retention setting easier for the next person to find.

[D-i-t-gh]

We use an SMTP proxy (MTA) for this. Mails with a special recipient address get rejected after a delay. Works great, so in our case we don't need this feature in Mailpit.

[bwdmr]

more like an will attempt to queue mail for delivery timeout and error if time window expires.
that way if there is something blocking the process for mail to be forwarded/delivered, there is a determinate time set when it supposed to return an answer.

[axllent]

This has been discussed a few times in the past , but the reasoning is outlined in #547. It's simply out-of-scope for Mailpit which is designed for email capture, and not email relay/server. Whilst it can relay / forward, this kind of queue/retry/reject logic should be handled with a proper mail server like postfix.

[bwdmr]

can the process get stuck and the container freeze up due to a blocked execution?

[axllent]

If auto-forwarding is set, it will just slow down the rate Mailpit can accept messages because the bottleneck will be the relay server. But can it get stuck? - I don't think so - although technically anything can get stuck if you DoS/DDoS it. I will emphasise again however that Mailpit is designed to receive emails, and not as a high performance relay server.

[bwdmr]

no not auto forwarding or any other feature, just a backpressure mechanism that if a job is not completed there is a timeout the service hangs before it deems the attempt insufficient and drops the mail to be processed, to await a new one. returning a failure code.

but yeah its not meant to be a high performance email server, answers it.

[axllent]

Well Mailpit is designed to be very performant, but just for receiving email - not sending it. When relaying messages the relay server becomes the absolute bottleneck (which is not what you're asking). The speed Mailpit can receive messages is entirely dependent on the hardware /network it is running on though. My personal internal server gets about 300 messages per second, Gitlab Actions gets about 400 per second.

There is no "backpressure mechanism" because it's designed to handle hundreds of emails per second, in fact I expect it'll handle much more email than any actual email server on the same system handles because it's not trying to send anything at the same time (it's just storing the messages). If you're getting to the point where regular emails are timing out or even taking several seconds to ingest, then your problem isn't likely to be Mailpit.

[bwdmr]

its interesting because of the storetodatabase function that does actually store to sqlite afaik.
there are several other aspects about mailpit that are interesting thanks for keeping it up