Configurable failure types for rejected mail.

[angerer]

The new options for whitelisting/blacklisting and exceptions are great! Thank you.

We would like to be able to test for different types of rejections, as our systems track and report on things that are permanent (e.g., bad address) or temporary (e.g., mailbox full) issues causing email rejections. Within those, there is some capacity for us to track the reason for the temporary or permanent bounce (address, spammy content, remote server issues, etc).

Happy to contribute here, but I thought it would be helpful to discuss with you about approach, rather than just forking and going off on my own, as I suspect this would be helpful to some others.

Thanks. We love the project!

[jhillyerd]

This is similar to #52

I'm still thinking about how this should be accomplished, but right now am leaning towards it being a service outside of Inbucket that could handle common dev/test/QA mail routing scenarios, random failures.

[angerer]

Thanks for responding.

Fair enough on the design. Just to be clear, you mean some other service that inbucket would relay smtp requests to? Or do you mean some dependent module that would plug into inbucket? I assume the former.

[jhillyerd]

Similar to the former, but reversed, the new server would act as a relay, and you could configure it to relay mail into Inbucket, or any other SMTP server.

My general thinking is that current SMTP servers (Postfix, Sendmail, etc) make hard things, like running a whole domain full of email accounts, easy. But they make conceptually easy things hard, like:

• Route all emails from this IP range to Inbucket, otherwise send to a real email server.
• Reject all mail from this IP range.
• Prefix subject line subject with [Environment X] if from this IP range
• Randomly reject mail (chaos monkey)
• NSA mode: send all email to Inbucket AND relay it to a real mailserver

I think this is because they are configured in a declarative manner, and are very concerned with not losing email. My idea is to provide an imperative configuration (aka scripting language), and have no compunctions about losing email if you configure the thing wrong. :)

At some point I will do a more exhaustive search and make sure I'm not re-inventing the wheel.