mailhog / MailHog

Web and API based SMTP testing
MIT License
13.87k stars 1.05k forks source link

[Feature] ACLs #173

Open mkrsn opened 7 years ago

mkrsn commented 7 years ago

Hi,

not sure if this is useful for the majority but it would be nice to have something like ACLs, TransportRules or something else to separate Mails from various Dev-/Test-Platforms (e.g. based on recipient or Subjects).

Example: @dev.platform1.local -> Mailhog-user1 @test.platform1.local -> Mailhog-user1 (root|webmaster)@test.platform1.local -> Mailhog-user2 *@dev.platform2.local -> Mailhog-user3

This would "fix" the need to have several MailHog Instances - one for each Plattform (which isn't that beautiful).

Thanks :)

Best Regards

Matthias

allangood commented 5 years ago

Hi @mkrsn, In my experience, is better to keep all environments isolated from each other, this will prevents users from sending e-mail (wrongly) to other mailboxes and interfering with others work.

Personally, I use Mailhog because it's lightweight and I can run multiple instances to build isolated environments.

A setup like you suggested, can be achieved with postfix and multiple catch-all mailboxes (and roundcube for webapi). it's an regular e-mail server with shared resources, IMHO.

mkrsn commented 5 years ago

Hi @allangood,

I dont know what kind of people you work with but normal users should not use this Project. This is imho a tool for Admins & Devs, they should know what they do and they should also able to troubleshoot mistakes.

Apart from that, handling with meaningless ports should be more error-prone than one clear socket with some rules to isolate the ENVs. It's maybe handable if you only have 1-3 Instances. But if you have 8,12 or more this is painful to maintain.

Like i wrote above, mailhog is a tool for Devs. It offers features which postfix isn't able to offer (e.g. the Chaos Mokey or JSON-API). So a Postfix-Setup is not a suitable replacement for a testing-tool like mailhog.

allangood commented 5 years ago

Hi @mkrsn, I work with devs and here we count with a devops team (my team). The whole thing is just a matter of using different tools instead of adding a lot of functionalities to one single project. This is one of the concept of the Unix ecosystem (KISS principle). Meaningless ports is your problem? You can avoid it using a different configuration, try to use macvlans instead of bridge standard networks. Problems with many IP addresses? Use dynamic DNS. BTW, that's exactly my setup. Every developer can spin a new docker instance in a central location (k8) and Consul exposes the container name in it's DNS server (e.g. dockername.mailtrap.local). Also, I have Prometheus and Graylog to collect metrics and logs and exposes statistics to all developers. Also, I'm using MongoDB to store message to keep memory usage low. On my dashboard is possible to see one of my +67k messages Mailhog container using just a few MB of RAM. Indeed, I have way more than one mailtrap docker instance running.

My point is that ACL/Sieve protocol is something very difficult to implement and maintain what can introduce new bugs and it can be achieved by something that already exists, same thing for encryption with stunnel. The Prometheus project uses this same principle.

If 8-12 containers is painful to maintain, probably is a matter to use a better tool like swarm or k8.

Anyway, I'm not the Mailhog maintainer, and this decision is not up to me.

mailtrap_dash

LubosRemplik commented 5 years ago

+1 for this feature