Bump com.sun.mail:jakarta.mail from 1.6.7 to 1.6.8 and migrate from com.sun.mail to org.eclipse.angus

[henricook]

Summary

• Migrate commons-email2-jakarta from com.sun.mail:jakarta.mail:2.0.2 to org.eclipse.angus:jakarta.mail:2.0.4 - the patched successor of the EOL com.sun.mail implementation
• Bump commons-email2-javax from com.sun.mail:jakarta.mail:1.6.7 to 1.6.8

Both versions prior to this change are vulnerable to CVE-2025-7962, an SMTP injection flaw allowing attackers to inject arbitrary SMTP commands via \r\n characters in UTF-8 encoded input.

Context

The com.sun.mail:jakarta.mail implementation has been superseded by Eclipse Angus, which is described as the "direct successor of JavaMail/JakartaMail". The CVE fix was only released under the Angus coordinates (org.eclipse.angus:jakarta.mail:2.0.4), while the old com.sun.mail 2.x line remains unpatched.

For the commons-email2-javax module, a backported fix is available at com.sun.mail:jakarta.mail:1.6.8.

Confusing package naming in the CVE

From https://eclipse-ee4j.github.io/angus-mail/

August 18, 2021 - Jakarta Mail moves to Eclipse Angus
To break tight integration between Jakarta Mail Specification API and the implementation, sources of the implementation were moved to this project and further development continues here. Angus Mail is the direct successor of JavaMail/JakartaMail."

It might be wise for a future change to move away from the discontinued com.sun.mail:jakarta.mail namespace altogether.

References

• https://nvd.nist.gov/vuln/detail/CVE-2025-7962
• GHSA-9342-92gg-6v29
• https://eclipse-ee4j.github.io/angus-mail/

[henricook]

It'd be amazing if anyone had information to help me figure out how to backport this to the 1.6.x series - and maybe get it released as a patch?

[garydgregory]

Hello @henricook

For 1.x, keep in mind that we can't break binary compatibility.

[henricook]

Hello @henricook

For 1.x, keep in mind that we can't break binary compatibility.

Thanks Gary, would I raise a PR to the 1.x branch to propose a patch to it if binary compatibility was ok?

[henricook]

I'm reasonably confident that 1.6.7 -> 1.6.8 doesn't include any binary compatibility breaking changes.

The internals of SMTPTransport.java were changed, and the only other non test changes were:

• Internal: Fix to NTLM auth
• Internal: Logging improvements
• Version bumps in POMs

[garydgregory]

Hello @henricook
For 1.x, keep in mind that we can't break binary compatibility.

Thanks Gary, would I raise a PR to the 1.x branch to propose a patch to it if binary compatibility was ok?

I'd like to see a PR before I make any promises 😉

[garydgregory]

Hello @henricook
Odd, the build here fails on Java >= 25 due to test failures:

Error:  Failures: 
Error:    MultiPartEmailTest.testAttachFile:138 Expected org.apache.commons.mail2.core.EmailException to be thrown, but nothing was thrown.
Error:    MultiPartEmailTest.testAttachPath:181 Expected org.apache.commons.mail2.core.EmailException to be thrown, but nothing was thrown.
[INFO] 
Error:  Tests run: 200, Failures: 2, Errors: 0, Skipped: 3

[garydgregory]

Why not use the current version 2.0.5? See https://central.sonatype.com/artifact/org.eclipse.angus/jakarta.mail/versions

[henricook]

Because I must be blind 😢 - on the way

[henricook]

Pushed now @garydgregory

[sebbASF]

The tests that fail in Java 25 and 26 have code like the following:

// test bad file
attachment.setPath("");

Maybe an empty Path is now allowed?

[henricook]

The tests that fail in Java 25 and 26 have code like the following:

// test bad file
attachment.setPath("");

Maybe an empty Path is now allowed?

I think that File("") has different semantics in Java 25. Rather than being false it is the primary working directory. Here's an example. Which means this test is probably failing on master? Is there a scheduled run of tests on master or similar I could check? Or I could open a new PR with no changes.

# Java 21
echo 'System.out.println("Java " + System.getProperty("java.version") + ": new File(\"\").exists() = " + new java.io.File("").exists());' | docker run --rm -i eclipse-temurin:21-jdk jshell -s -                                          
   
# Java 25
echo 'System.out.println("Java " + System.getProperty("java.version") + ": new File(\"\").exists() = " + new java.io.File("").exists());' | docker run --rm -i eclipse-temurin:25-jdk jshell -s -  

gives:

~ ❯ echo 'System.out.println("Java " + System.getProperty("java.version") + ": new File(\"\").exists() = " + new java.io.File("").exists());' | docker run --rm -i eclipse-temurin:21-jdk jshell -s -
Feb 11, 2026 3:58:08 PM java.util.prefs.FileSystemPreferences$1 run
INFO: Created user preferences directory.
Java 21.0.10: new File("").exists() = false

~ ❯ echo 'System.out.println("Java " + System.getProperty("java.version") + ": new File(\"\").exists() = " + new java.io.File("").exists());' | docker run --rm -i eclipse-temurin:25-jdk jshell -s -
Feb 11, 2026 3:58:24 PM java.util.prefs.FileSystemPreferences setupUserRoot
INFO: Created user preferences directory.
Java 25.0.2: new File("").exists() = true

[garydgregory]

Hm, the code in master should probably be redone using NIO instead of IO...

[garydgregory]

@henricook
Please rebase on git master and I'll kick off another build.
TY!

[henricook]

Done, thanks @garydgregory

[garydgregory]

@henricook

PR merged, thank you 👍