Provide option to auto-relay

[obrienmd]

It would be useful to have an option in MailHog config to auto-relay all messages.

[ian-kent]

Thanks @obrienmd

I'd be interested in understanding your use case? Adding that option wouldn't be too difficult, but MailHog isn't designed to work as a real MTA and doesn't make any SMTP delivery guarantees - the existing implementation (being a manual thing) makes a delivery failure less important.

[obrienmd]

Thanks for the feedback and question - makes perfect sense.

In some cases as we move a change to a staging environment, we would love to have both the e-mail captured in MailHog (for immediate checks) and allowed through to a group of test end-users (for more delayed but wider feedback). MailDev has a pattern-match option for auto-relay, which would be ideal, but full-bore auto-relay would be perfectly fine (and probably much easier), as we can just manage the users in the staging environment.

[obrienmd]

To further expand on this, it would be for large groups of users on a staging environment where manual relay via MailHog would be difficult.

[ian-kent]

Thanks for the info! I'll add something 👍 not 100% sure what yet, but something!

[obrienmd]

Cheers - honestly, just a boolean config / cli option for "autorelay" would be awesome :)

[Morgon]

For me, I'd just like a button that auto-releases. In other words, not for every message (although no reason not to do so), but instead of having to re-type (or copy/paste) the To: field, just have a button that ships the entire message to the defined SMTP server

[mdaguete]

Hi All,

MailDev has an auto-relay-mode with a json config file to deny or allow the recipient.

Regards

[obrienmd]

Yep - unfortunately, I'm unable to use the node runtime in this situation due to silly policies :)

[touchardv]

Hello,

Such a feature would be indeed nice to have. Even better if it could be turned on/off based on some condition e.g. "auto release all emails for recipients not in domain "example.com".

Regards,

[chines]

Hello,

We have historically used mailcatcher in our dev and QA environments, but it's not sufficient to handle production pass through (without a feature such as auto-relay).

The use cases are:

1. We send thousands of emails daily (not spam or ads, these are all opt-in edoc delivery of individuals insurance policy documents). These emails are generated by pulling data from different middleware, dbs, and 4GL appserver wackiness, and once in a blue moon there are mixups that cause issues. It would be great to be able to validate when a user calls in by looking in the "pass through catcher" to see what they are seeing (asking a user to forward an email without mangling it can be a chore with our user population).

Helpdesk case #2: When a user calls in and says that they have not received their one time password that expires in 15min for 2FA because they are on some ISP that spam checks everything so delays mail delivery by that much, the helpdesk can review the email to them and provide the 2FA code.

Helpdesk case #3: When a insured calls in and wants help viewing their inspection or other attached document to their account, the helpdesk can open up what was sent to them and walk them through the exact process.

I understand this would also allow users to capture forgot password kinda emails. To prevent this kind of abuse, we currently lockdown access to mailcatcher (on dev and qa as stated above) with https on an internal network and unique named user proxy access only. The applications that we want to catch email from are not high on the risk level for a third party accessing (some risk from PII disclosure, but you can't do anything financial other than pay someone's policy premium, and we don't save financial creds, so a malicious user would have to pay with their own CC or ACH). The users on the HD who would have access to view these outbound emails in the pass through have WAY more access with their internal policy modification tools.

Again, thanks for a great tool (demoing now to replace mailcatcher) and +1 to this use case.

[chines]

Also, I've tested maildev extensively(since as mentioned above, it does provide this) but I've not found it as stable as mailcatcher.

[ian-kent]

So it sounds like there's two distinct use-cases here, with subtle differences:

1. To be able to release the message as-is to another mail server - MailHog would send the message to one mail server, and that mail server would be responsible for delivering to all recipients (MailHog is a proxy)

2. To be able to release the message to its intended recipients - MailHog would need to parse the message, group recipients by MX server, and deliver the message to the correct recipients individually (MailHog is an MTA)

The first one is a possibility - and is easy to add - since MailHog just forwards the raw data as-is to another server.

The second one is unlikely to be supported, since it requires complex mail delivery rules and would be nearer a real MTA at that point.

So I'm happy to add support for the first - though I'm not sure how soon I'll be able to get around to it. But I don't think the complexity etc of the 2 is really worth it, when 1 is an option.

@chines that's impressively outside the scope of what MailHog was designed for, and I'd recommend against using MailHog in a production environment like that even if the auto-relay functionality was available

[chines]

Option 1 is the one I was describing, just forwarding the raw message along to another mail server.

Thanks for the suggestion against using it in a production environment, and I hear that loud and clear. I'm going to test it for a few months and see if it's stable enough.... ;) The benefit would be pretty high and as long as I have a fairly simple recovery plan for failure scenarios, I think it would be workable.

[obrienmd]

Option 1 would be fantastic with SMTP auth to the relay :)

[waynew]

Option 1 is the kind of thing I need. @chines I think in your other situations you want an entirely different approach - I'd probably just configure your tool/existing MTA to BCC every email to a research box or something.

[cumuru]

+1 for option one. For my use case it would be enough to prefill the recipient field of release message modal dialog with the original recipient. Nonetheless another action to release to all original recipients (including CC and BCC) would cover far more use cases.

[rosscdh]

+1

[designermonkey]

Is there any movement on this feature? If I knew any golang, I would offer to help as it's a really good feature to have.

[raja-anbazhagan]

Can this feature also be extended to only allow or deny certain recipient email patterns?

[terion-name]

+1 needed feature
MailHog can be not an MTA, it can just forward mails to another SMTP
It is not very hard to write a script that will listen the SSE events with letters from mailhog and forward them via this script, but it would be nice to have this built-in