Feature request: search (filter) emails by created (delivery) date

[BoberMod]

Mailpit already implements a lot of useful filters, but it lacks of filter by email delivery date + time.

Example query from Gmail: after:2024/2/26 before:2024/2/29 (there's no time).

Use case: we use Mailpit for integration testing and in some cases there may be very similar emails with dynamically generated content, so we can't easily match it.

As a workaround it's possible to use "search" endpoint and filter by Created on client side, but it would be great to support native filter.

[axllent]

I must admit that I've toyed with this idea a number of times in the past, however I keep getting stuck. The issue is time zones.... Mailpit will use whatever timezone it is using on the server, and all dates/times returned via the API include the timezone used, however when it comes to querying, there is no guarantee the client is even in the same timezone as that set (or not set) on the Mailpit server. It works in Gmail because Google knows your timezone (you're logged in), but that's not the case in Mailpit.

The only reliable way I can think of is if the before/after queries would be fully formatted datetimes including timezone, which users will not get right, so I'm not sure the best approach here. Suggestions?

[BoberMod]

You're right. Using server time zone or fully formatted datetime is ok from API perspective. But from user and UI perspective - it's not user-friendly.

As I can see, local user time zone is used to show time on the UI, so it's expected that user will use local time zone when quering from UI. https://github.com/axllent/mailpit/blob/bfd58377103d29f8c1b5e24b48d603f6c4d53b47/server/ui-src/mixins/CommonMixins.js#L47-L49

But so far I don't see any ideas other than passing the local timezone of the user in requests. Maybe here or in loadMessages function if filter by date/time is present. https://github.com/axllent/mailpit/blob/bfd58377103d29f8c1b5e24b48d603f6c4d53b47/server/ui-src/views/SearchView.vue#L61

With moment-timezone - https://momentjs.com/timezone/docs/#/using-timezones/guessing-user-timezone/ Or with plain JS: Intl.DateTimeFormat().resolvedOptions().timeZone

[axllent]

I think this could work - the browser's timezone could possibly get passed as an (optional) API parameter for searches. Accurate browser timezone detection is not entirely reliable though, so I can predict some complications though. Then there is the date & time parsing on the Go/API side - it's not nearly as flexible as something like PHP's strtotime() which concerns me.

Tell me, how useful would date+time-based filtering really be for you (forgetting for the moment date filtering which I still plan to add)? I understand your use case, but is there not any other option that could possibly help resolve this for you, for instance applying message tags? Surely if you are facing an issue whereby multiple servers (or CI processes) may be testing at the same time, then you still have the risk of time-based searches conflicting too? Could you maybe add a unique tag to the message as it was saved which would give you something far more accurate to filter by (a random number, hostname, commit hash etc.)?

I am busy adding the ability for "plus addressing" (<email>+<tag>@<example.com>), assuming your testing could provide a customised address in any of the from, to, cc, or even bcc fields, or alternatively just add an X-Tags header to the message achieve the same. I don't know your setup, nor how or what you are testing, so I'm throwing out potential alternatives to help solve your issue (without potentially causing all sorts of issues trying to solve date+time searches).

[axllent]

Or alternatively generate a unique message ID for your emails, that way you definitely could filter by something accurate....

[github-actions[bot]]

This issue is stale because it has been open for 14 days with no activity.

[axllent]

Apologies for the long wait, but this is just to let you know that I have released v1.16.0 which has support for before: & :after search filters. I ended up using a fairly flexible library (link in the docs) which also handles times.

The timezone was a tricky one so I have had to add another optional API parameter to the search endpoint called tz where one can specify the timezone, eg /api/v1/search?query=<query>&tz=America/New_York. This timezone, if set, is only used for before:<date> and after:<date> queries.