Save Emails in a DB

[jumoog]

It should be possible to save emails.

I want use MailDev for my Website as Email Server

[djfarrelly]

Thanks for the idea @jumoog! MailDev has never preserved state before and I think it might be too drastic a change if that was added to the core, especially something as specific as Mongo. I had thought about adding something like sqlite a while back, but since it's geared more towards development, I thought it would be better to keep it a bit simpler.

I would be open to the idea of creating a way to accept different storage backends which would be published independently on NPM (similar to how browserify has transforms). They could be passed via options. I'm not quite sure how to do this right away, but here's how I could see it working:

$ maildev --plugin maildev-mongo

Or

$ maildev --store mongo
$ maildev --store sqlite

As a side note, are you using MailDev on your own server for development purposes, or to act as your own email client? If you're using it for real world email, I would suggest maybe using something like Haraka?

Let me know what you think!

[jumoog]

Haraka is to complex .. MailDev is easy to use and come with a nice gui

mongodb is perfect because we getting the email as json object and mongodb works with json

[djfarrelly]

I'll try to think about a plugin/storage implementation, but I might not have the time right now to hack on this feature, sorry. Currently #30 is the highest priority task for the project. If you need something faster, I would recommend forking the project and trying using something like Mongoose.

[pkat]

I agree that maildev is geared toward development, however it would be convenient to have some sort of simple persistence, when you can't keep maildev always running and still want to view or compare previous emails. Something like Redis may be really easy to implement for fast and simple storage.

[djfarrelly]

@pkat thanks for your thoughts! Adding a Redis adapter into the main project might lead to the desire to add other adapters like Memcached, SQLite, Mongo, etc. I'm totally open the idea of some persistance options, but maybe in the form of a plugin. Perhaps there could be some usage like:

$ maildev --storage=maildev-redis
$ maildev --storage=/path/to/custom-module

Which would use a compatible storage module either installed via npm or potentially something custom written that's API-compatible. What do you think?

[pkat]

Yeah that makes sense. Going the adapter router would keep things more modular and lightweight and allow for any number of data stores. Reminds me of Nodemailer's concept of transport method plugins.

[dlitty]

I too would like to see some kind of persistence; not because I want to keep them long term, but rather when developing and testing we need to be able refer to emails across process shutdowns / server reboots. It can problematic to run a test on a system that generates email, make a change, then run it again - hoping to compare the results between the emails - if the process or server has shut down in the mean time.

Even just writing them to files in a path other than /tmp would be very useful.

[donut87]

I kind of already explored that option
https://github.com/donut87/MailDev/tree/persistMails

I stopped using this tool so I did not persue this branch any further. But recall that persisting in temp files was not that hard.

[dlitty]

@donut87 - Did you stop using it because you no longer needed it, or because you changed to another tool?

[donut87]

We did not switch to another tool. I would not say we did not need it, but we changed the way we send mails and did not reimplement this.

[joshuaadickerson]

I like this idea for development. I don't daemonize my Docker containers when I'm developing so I can just kill and restart them quickly. I do all of them at once so there's no links or anything leftover. That means I kill my maildev container.

[mkweick]

Any plans to include this feature? I too would like to see some kind of persistence with emails after service restarts.

[oktapodia]

Sorry it's been a long time ago, we will look into it

[atapatel]

+1

[AmauryOrtega]

Looking forward to this 🔥

[ghost]

+1

[Phlegethonyarre]

+1