jakartaee / jakartaee/mail-api
MimeBodyPart RFC2231 Outlook issue: Allow to override internal static fields encodeFileName in constructor instead of SystemProperties
- Dominant language
- Java
- Stars
- 285
- Forks
- 109
- Avg merge
- 15h 19m
- Merged PRs (30d)
- 1
Description
**Is your feature request related to a problem? Please describe.**
Some background: The reason behind this issue is our attempt to make it possible to send an Attachment to "Outlook client which has problems displaying filenames with german umlauts (ä, ü, ö etc.) correctly. Search the internet for "outlook rfc2231 rfc2047".
In the past we were using JavaMail 1.4.3 which worked out of the box with outlook. But now we are on 1.6.2 (yes, JavaMail, but we consider switching to JakartaMail. But JakartaMail still has the same problem as JavaMail 1.6.2)
Currently MimeBodyPart uses static variables for certain customisations like this:
```
private static final boolean encodeFileName =
PropUtil.getBooleanSystemProperty("mail.mime.encodefilename", false);
```
**The problem:**
SystemProperties are global for the whole application.
We would like to use this only in some very specific cases where a customer can e.g. pass a flag to decide wether or not to encode the filename etc.
The magic currently happens in [#setFileName(part, name) ](https://github.com/eclipse-ee4j/mail/blob/db4f348b8de82670c90d921f26b66ccad6610673/mail/src/main/java/jakarta/mail/internet/MimeBodyPart.java#L1294) which unfortunately is package private so it hard / impossible to customize it.
You can see it in the comments like:
```
/*
* Also attempt to set the Content-Type "name" parameter,
* to satisfy ancient MUAs. XXX - This is not RFC compliant.
*/
```
**Describe the solution you'd like**
Is it possible to make the private static fields such as `encodeFileName`, `setContentTypeFileName` actual class members _add a new_ constructor where you can pass the fields?
```
public class MimeBodyPartCustomizable extends MimeBodyPart{
private boolean encodeFileName = PropUtil.getBooleanSystemProperty("mail.mime.encodefilename", false);
private boolean setContentTypeFileName = PropUtil.getBooleanSystemProperty("mail.mime.setcontenttypefilename", true);
public MimeBodyPartCustomizable(boolean encodeFileName, boolean setContentTypeFileName) {
this.encodeFileName = encodeFileName;
this.setContentTypeFileName = setContentTypeFileName;
}
...
```
This would allow us to use this constructor if we want to have full control over all parameters.
Otherwise we just use the default constructors which work as it is.
e.g. example pseudo code:
```
// special handling for outlook which cannot handle RFC2231 which leads to broken attachment names
boolean encodeAttachmentsWithRFC2047 = isSpecialHackForOutlookRFC2047Enabled();
MimeBodyPart attachFilePart = encodeAttachmentsWithRFC2047 ? new MimeBodyPart(encodeFileName, setContentTypeFileName) : new MimeBodyPart();
```
I assume this would also be backwards compatible when this is a _new constructor_.
**Describe alternatives you've considered**
An alternative was to create a customized version in our own `package jakarta.mail.internet;` and override `javax.mail.internet.MimeBodyPartSynesty.setFileName(String)` Unfortunatelly then we have to copy lots of code from [#setFileName(part, name) ](https://github.com/eclipse-ee4j/mail/blob/db4f348b8de82670c90d921f26b66ccad6610673/mail/src/main/java/jakarta/mail/internet/MimeBodyPart.java#L1294)
We have not used this alternative yet, it was just a POC.
e.g.
```
package jakarta.mail.internet;
import java.io.UnsupportedEncodingException;
import jakarta.mail.MessagingException;
import jakarta.mail.Part;
import com.sun.mail.util.MimeUtil;
public class MimeBodyPartCustom extends MimeBodyPart{
private boolean encodeFileName;
private boolean setContentTypeFileName;
public MimeBodyPartCustom(boolean encodeFileName, boolean setContentTypeFileName) {
this.encodeFileName = encodeFileName;
this.setContentTypeFileName = setContentTypeFileName;
}
public void setFileName(String name) throws javax.mail.MessagingException {
// all code from https://github.com/eclipse-ee4j/mail/blob/db4f348b8de82670c90d921f26b66ccad6610673/mail/src/main/java/jakarta/mail/internet/MimeBodyPart.java#L1294 which uses the new class members from the constructor
}
}
```
**Additional context**
Add any other context or screenshots about the feature request here.
Contributor guide
Research direction
Start with mail/src/main/java/jakarta/mail/internet/MimeBodyPart.java, especially the package-private setFileName logic around the linked source location. Review open pull request #578 and the existing SystemProperties behavior before deciding how configurable construction should preserve defaults. Done means the requested per-instance filename encoding options work without changing default behavior, with corresponding tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100