Make the use of 'filename' and 'name' as additional parameters within the content-type header optional

[sebastian-schmitt]

When adding an attachment, the Content-Type header of the corresponding mime-part gets the 'filename' and 'name' of the attachment appended as additional parameters (see link below).

Our remote party is pretty picky about this header and wants us to remove these extra parameters from this header.
I could not find a good way to do that - this is why I wish I could opt-out from this behavior:

simple-java-mail/modules/simple-java-mail/src/main/java/org/simplejavamail/converter/internal/mimemessage/MimeMessageHelper.java

Lines 264 to 267 in cb2f7b2

	ParameterList pl = new ParameterList();
	pl.set("filename", fileName);
	pl.set("name", fileName);
	attachmentPart.setHeader("Content-Type", contentType + pl);

[sebastian-schmitt]

alternatively I was looking for some hook to modify the intermediate MimeMessage at some point between being built and being sent. (maybe the CustomMailer?)

[sebastian-schmitt]

after digging deeper into our problem, I found that only one of those parameters (namely the "filename") causes the problems at the remote side:
They expect the "name" parameter within the Content-Type header and the "filename" parameter within the Content-Disposition header.
So basically, it's the line 265 only (see above) which I try to disable.
(for now we forked the repository to do this manipulation by hand, but it would be great to have some kind of tool to access and modify the resulting MimeMessage in more detail)

[bbottema]

I'm trying to remember why I left it in the Content-Type to begin with. Legacy? Backwards compatibility? I'm trying to figure out what I might break by simply removing it.

[rover886]

I also faced the kind off same problem and I am using local build by removing the line number 265.

@bbottema I don't think filename parameter is there for legacy or backward compatibility.

For historical context the name parameter was commonly used before the introduction of Content-Disposition. However, it was never formally standardized in an RFC for MIME email and has since fallen out of favor. Modern email clients rely on Content-Disposition for file naming and handling inline or attachment content.

So as per current standards we can say that the name parameter is deprecated in favor of the Content-Disposition: filename parameter. I feel it's safe to say that modern email clients and MIME parsers typically use the filename attribute within Content-Disposition to handle file names.

So, I feel filename in Content-Type header doesn't really makes sense, the RFC 2045 and 2046 never mentioned about filename in that header; where as name could be there even today. So we can say that name parameter is there for Backwards compatibility.