Reject RFC 2047 encoded-words in address validation

[bbottema]

A private report pointed out that RFC 2047 encoded-word syntax can be placed in an email address local-part and currently passes Simple Java Mail's default send-time address validation, for example:

String address = "=?utf-8?q?=40evil.com=00?=@microsoft.com";

Triage result:

• RFC 2047 encoded-words are explicitly forbidden inside an addr-spec; they are only valid in selected header text/name positions such as a display-name phrase.
• Current Simple Java Mail validation delegates address validity to the configured validator, which lets this form pass.
• Angus/Jakarta Mail sends the SMTP envelope recipient literally as RCPT TO:<=?utf-8?q?=40evil.com=00?=@microsoft.com>; I could not reproduce the reported claim that Simple Java Mail or Angus Mail decodes this into delivery to the embedded domain.

Even though the routing claim is not reproduced, Simple Java Mail should reject RFC 2047 encoded-word syntax in address fields because the address is invalid and can confuse downstream domain-policy code that inspects Recipient#getAddress().

Scope:

• Reject encoded-words in sender, recipients, reply-to, bounce-to, DSN, and receipt address fields during validation.
• Keep encoded-word/display-name handling untouched; the restriction only applies to the address spec value.
• No API shape change.

[bbottema]

Released in v9.0.4 and available from Maven Central.

Simple Java Mail now rejects RFC 2047 encoded-word syntax inside email address specs during address validation. Encoded display names remain valid; the guard only applies to the actual address value.

Email email = EmailBuilder.startingBlank()
    .from("sender@example.com")
    .to("=?utf-8?q?=40evil.com=00?=@microsoft.com")
    .withPlainText("test")
    .buildEmail();

mailer.validate(email); // throws MailInvalidAddressException

This closes the validation-hardening gap reported against 8.12.4.