Introduce interfaces for validation and sending, so these steps can be customized

[bbottema]

Currently, the email validation is fixed to email-rfc2822-validator (but can be configured or even turned off completely). And sending emails is restricted to the internal JavaMail logic with SMTP servers.

It would make Simple Java Mail more flexible if these choices could be replaced with a user choice by means of interfaces. For example, have validation replaced by a call to Mailgun's email validation service or whatever. Or have the sending completely replaced by an implementation that uses SendGrid to do the actual sending.

This way Simple Java Mail still acts as accelerator for populating emails, validating email (not addresses), producing an RFC compliant MimeMessage and multi-threaded batch sending, but the address validation and actual sending can be replaced.

Currently Simple Java Mail internally already has two way of sending: sending as normal and logging instead of sending. It might even be possible to abstract proxy / batchprocessing into separate implementations, making the MailSender class much simpler.

Here's what I have in mind for the API:

MailerBuilder
		.withSMTPServer(...)
		.withAddressValidator(new MailgunAddressValidator())
		.withMailSender(myCustomLoggingSender)
		.buildMailer();

class MailgunAddressValidator implements AddressValidator {
	validateAddress(String emailAddress) {
		// call to webservice
	}
}

[bbottema]

Current status: unsure where to add the functional splits. Basically this issue is about managing email-processing-life-cycle, so what parts should be replaceable? Haven't figured this out yet...

[bbottema]

I'm keeping it simple for now and focused on the core use case, which is to be able to switch out the default behavior for just sending emails.

In 6.0.0 you will be able to do:

MailerBuilder
		.(...)
		.withCustomMailer(myCustomMailer)
		.buildMailer();

Which has the following interface:

/**
 * By default, Simple Java Mail handles the ultimate connection and sending of emails. However, it is possible to replace this last step
 * by a custom implementation.
 * <p>
 * The benefit of this is that Simple Java Mail acts as an accelarator, providing thread pool, applying email content-validation, address validations,
 * configuring a {@code Session} instance, producing a {@code MimeMessage}, all with full S/MIME, DKIM support and everything else.
 *
 * @see MailerGenericBuilder#withCustomMailer(CustomMailer)
 */
public interface CustomMailer {
	void testConnection(@Nonnull OperationalConfig operationalConfig, @Nonnull Session session);
	void sendMessage(@Nonnull OperationalConfig operationalConfig, @Nonnull Session session, final Email email, @Nonnull MimeMessage message);
}

Note that in this mode, proxy support is turned off assuming it is handled by the custom mailer as well.

[bbottema]

Released in 6.0.0-rc1.

[bbottema]

6.0.0 has released as well, finally.

[sebastian-schmitt]

When implementing a CustomMailer, is there a way to modify the given MimeMessage from within the sendMessage method and then fall back to the actual (non-custom) Mailer afterwards?

[bbottema]

@sebastian-schmitt: No, a CustomMailer completely replaces the last step. What would you like to change about the MimeMessage? The point of this library is to help you easily produce a properly configured MimeMessage, so if you are missing something, I'm interested to know.

/edit: nevermind, I realize this is about the filename issue.