Enhancement: add native support for overriding envelope-level receiver(s)

[andrus]

I am trying to upgrade Bootique integration of SJM from 7.4.0 to 8.x, but the custom mailer can no longer obtain the preconfigured SJM Mailer. Somewhere along the way MailerRegularBuilderImpl.buildServerConfig() started returning null when there is a custom mailer present. So that code that worked previously stopped working.

An earlier issue #375 expalins the motivation for this particular custom mailer. Its goal is not to have a fully custom transport, but rather to override recipients at the transport level without changing to/cc/bcc of the original message. So I would very much want to reuse SJM transport. Having said that, I do feel like using a custom mailer for my purpose is too fragile, and I'd rather there was an option in the EmailBuilder to provide "recipient override" address for testing.

[bbottema]

Thanks for reporting @andrus. Let's have a look.

I am trying to upgrade Bootique integration of SJM from 7.4.0 to 8.x, but the custom mailer can no longer obtain the preconfigured SJM Mailer. Somewhere along the way MailerRegularBuilderImpl.buildServerConfig() started returning null when there is a custom mailer present. So that code that worked previously stopped working.

Well, since Simple Java Mail is not the one sending the mail anymore, there is no relevant server config. In fact, that method used to validate the data like mandatory host, which makes no sense if you use your own implementation (aside from that, this method is documented as for internal use).

However, I understand you have a use case here, so let's look at that.

An earlier issue #375 expalins the motivation for this particular custom mailer. Its goal is not to have a fully custom transport, but rather to override recipients at the transport level without changing to/cc/bcc of the original message. So I would very much want to reuse SJM transport. Having said that, I do feel like using a custom mailer for my purpose is too fragile, and I'd rather there was an option in the EmailBuilder to provide "recipient override" address for testing.

So really, your custom implementation wants to send it with Simple Java Mail still, so why not just use a separate Mailer and move the server config there?

[andrus]

Thanks for the quick reply!

So really, your custom implementation wants to send it with Simple Java Mail still, so why not just use a separate Mailer and move the server config there?

This may actually work! Instead of fighting with CustomMailer and related lifecycle, I might decorate / subclass a Mailer, overriding its sendMail. Let me try it.

[bbottema]

Ok, that's not what I intended :D - I thought you might just configure two mailers separately. One properly configured for everything but sending, but with custom mailer allowing you to do any overrides. And then a dumb sender that you relay the modified Email to (possibly configured as a cluster).

But still, let me know how your experiment turns out :)

[andrus]

And then a dumb sender that you relay the modified Email to (possibly configured as a cluster).

Unfortunately, Email object does not have a "recipient override" property. With Email, I can wipe out "to/cc/bcc", and replace them with the "override" address, but that does not allow the recipient of the "overridden" message (e.g. a QA team member) to inspect how the original email would have looked like without the override. That's why I need to mess with the transport directly.

[bbottema]

Can you share the code you used before this? I'm not sure I follow the semantics of your override use-case.

[andrus]

Here is the CustomMailer written against SJM 7.4.0:

https://github.com/bootique/bootique-simplejavamail/blob/c8d4606eddbcf80d9390953adaee302f3e341bc2/bootique-simplejavamail-jakarta/src/main/java/io/bootique/simplejavamail/MailerWithOverriddenRecipients.java#L60

[andrus]

Essentially, I am taking advantage of the difference between the SMTP "envelope" destination addresses and the addresses in the message itself. Overriding the former, and preserving the latter allows to create a nice test experience.

[bbottema]

Hhm, the current version of TransportRunner doesn't even support recipients separately, so this won't even fly. I'd have to think deeply about allowing some way of interception or overriding behaviour. The Custom Mailer concept wasn't designed or meant for affecting existing internal behaviour; it was meant to replace it with your own.

[bbottema]

Thinking out loud, the problem with this is that 'overriding' behaviour can apply to every step of the mailing process. So do I devise some kind of step-filter concept, where each step a filter can be inserted. Or do I approach this from very specific use cases (such as your) and devise a solution for that.

[andrus]

I have only a superficial familiarity with all the mail RFCs, but it seems like providing a model that describes all possible properties (e.g. explicit properties of the SMTP "envelope" on the Email object) is more beneficial than extra override hooks. Though one approach does not preclude the other.

[bbottema]

I think I have a clear understanding now and I'm looking at some solutions, but I'm still a little confused as to why you need MailerRegularBuilderImpl.buildServerConfig(). If I understand correctly, you provide your own CustomMailer which goes to TransportRunner.sendMessage() with your own recipients. Where does the server config come into play?

[andrus]

Good question. It didn't fail before. I just pushed a branch with my attempt to upgrade the existing code base to 8.x, and if you run mvn clean verify on it, there will be a failure.

https://github.com/bootique/bootique-simplejavamail/tree/8

[bbottema]

I'm not able to build it with Maven 3.8.6. What version are you on? Actually, just a stacktrace will do for me.