Expand RelyOptions adding regexp evaluation to AllowedEmails

[MonDeveloper]

The requirement

The way we are using smtp4dev (in dev/uat/stress environment) would require this kind of (oversimplified) logic: "If the target of the email is a customer/supplier please go to smtp4dev, otherwise (mail for internal colleagues) send it for real".

The current solution

This kind of logic seems to be addressable with the RelyOptions, unfortunately that option requires a list of all the destinations [AllowedEmails] to serve in such way.

The proposal

Do you think there could be room to add a property (or change the actual one in a backward compatibility manner) to allow the usage of a regex (or a list of regex) with the aim to identify those addresses? In our scenario we would rely to a real SMTP all the mail sent to our internal domains.

The icing on the cake

This kind of approach will address also another requirement: visibility segregation: it could be enough to set up several smtp4dev chained in a tree structure with the proper RelyOptions configured on each of them and at time zero any "visibility Group" will have a dedicated smtp4dev site where they will find just the emails they are interested into. Other idea could be not limiting the "selector" of the emails to be relied on the destination address filter but let the configuration play also with other email fields like: subjects, sender and body.

[jafin]

If the app were to allow regex patterns, and existing emails (for backwards compatibility). Then I think it would be helpful if the regex can be represented/encoded in a way that still allows it to be specified as a string alongside literal email addresses. So the app can pattern match a literal email address or a regex pattern.

If the regex addresses were represented like how they are in javascript, enclosed in forward slashes, would that work? ie given an array of literal and regex matches it could be shown as

"AllowedEmails": ["[email protected]","/.*@baz\\.com/"]

So that would match:

• [email protected]
• *@baz.com

Thoughts? @rnwood

[rnwood]

@jafin

In my mind I'd like to augment this system so it can match on other aspects of the message (e.g. subject, headers). I think this system of filters/matching would then be possible to use for other functionality like auto-forwarding (relaying but changing the recipient), or ability to define and save different views (mailboxes?) for different people on the message list. It would need OR and AND etc. Something along these lines of the schema this uses: https://github.com/CacheControl/json-rules-engine

At that point, I think the AllowedEmails would be obsoleted.

Despite this I think doing what you suggest is a good short-term option to add some flexibility. I like the simple syntax and I can't see how it would be ambiguous encoded like that.

[SeSeKenny]

Until the PR linked to this gets merged (your project, your prerogative :P ), I have forked and modified Smtp4devServer.cs to a quick and dirty implementation just changing AutomaticEmails to be a list of include regex's instead. My build system experience is pretty basic and I couldn't get it working so I just took the single artifact that effects the change and placed it here https://github.com/SeSeKenny/smtp4dev/blob/master/Rnwood.Smtp4dev.dll . This is working fine for me. Might be instances where this is a breaking change (plus addressing), but most email addresses in this entry should continue working as well, just not exact matching with '.' etc.

[rnwood]

This kind of logic is now possible. See AutomaticRelayExpression in the appsettings file.