Enhancement: make client sided validation optional, turning off address validation and CRLF injection detection

[jllanes3]

The library performs client side validation and fails client side if any of those validations fail (opinionated client). For example, library will fail if the scanForInjectionAttack(...) in MailerHelper.java throws an exception if client passes a subject with containing a \n string. The same applies to many other cases even on the email address format.

Whereas this is "good" thing to have in general, some client have uses cases where a lot of this sanitation and error handling is done server side (server helps clients in some sense).

Detecting on client side is excellent, but failing to send is a huge back-compat issue for clients moving to use this library, but whose server has traditionally done most of the checks/cleanups up to now (i.e. server accepts a subject with a \n and sanitizes for clients).

This can trigger failures on client side that were not there before and that the server was handling up to now, and client ends up with emails that simply cannot be sent using this library, whereas before they could be sent with the issues present.

The ask is to expose the validator as a class that clients can run on their own to detect this issues and fix them reactively, while also allowing them to disable such validation when sending the email to the server so that emails can continue to flow to a server that accepted them before.

[bbottema]

Fair point, I think offering API to reduce the strictness sounds reasonable. With the address validation this is already possible and in the past I've already made previously-mandatory fields optional, but CRLF detection is not optional. Is that the only thing thing left?

Providing api to fix emails seems backwards to me though. You can make sure to build a proper email before trying to send it with Simple Java Mail. As a library user you are completely free to fix that, the CRLF exceptions are a different matter and could be made to only log warnings (or ignore completely).

[jllanes3]

I would say that any client side validation can be troublesome for existing applications trying to move to use this library, specially if the server is not owned by such apps, and has accepted certain inputs before (helped clients), and the content is not owned by the apps either.

I think this entire class should be thought off in the same category (using 6.6.1 references):
MailerHelper.java

It does:

• recipient validations
• subject validations
• header validations
• email address validations (I think this one is optional)
• etc.

I think its great to have visibility into this, but failing to send is the trouble I have because there is not way to recover from it other than reverting back to older library or "trying" to help with the input, which an application may have zero control over (they don't own the input and may have allowed bad input to go through and servers accepted).

[bbottema]

Released in 7.5.0.

You can now disabled client-side validation (which override any email address configuration), like so:

currentMailerBuilder.disablingAllClientValidation(true);

Not that this disables address validation and CRLF injection scans, but completeness checks are still performed. But unless you use the API wrong, this should never trigger and exception.