Use user provided message-id

[venkatsc]

Currently, the API generates message-id and
uses it overriding the user provided message id.
#432

This fix should be used with setHeader method.
addHeader method has the following issue
#433
leading to the override despite this fix.

Signed-off-by: Venkat [email protected]

[venkatsc]

Build fails with:
[main] ERROR org.apache.james.cli.ServerCmd - Error on command: {}
java.lang.Exception: Domain does not exist in DomainList
at org.apache.james.user.lib.UsersRepositoryManagement.addUser(UsersRepositoryManagement.java:66)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)

any idea?

[pzygielo]

With this change, this method will no longer update message id, as only non-exisitng header will be set. I hope that @bshannon can review this as well.

[venkatsc]

@pzygielo it updates message-id if it is not set from the API user. The default value for message-id is null.
https://github.com/eclipse-ee4j/mail/blob/4c092797479f6fb05576e723a6855a7e116ed027/mail/src/main/java/javax/mail/internet/InternetHeaders.java#L301

I was able to send mail with custom message-id with setHeader and generated unique message-id by not setting any value.

[bshannon]

I understand why you might want this behavior, but I fear that this change in behavior
will break other use cases. For example, if you create a MimeMessage object, send it,
then change the recipients and send it again, you want the Message-Id to be updated,
but with this change it would not be updated.

I think you're stuck using the technique described in the FAQ if you want to set your own
custom Message-Id: https://javaee.github.io/javamail/FAQ#msgid

[bshannon]

As I said above, I fear that the compatibility impact of this change is too large,
so I'm rejecting this pull request. Sorry.

[venkatsc]

First of all, thank you for the explanation and pointing me the right resources.

For example, if you create a MimeMessage object, send it,
then change the recipients and send it again,

I understand that, but as a API user one must be aware of that and can set the new message-id while changing the recipient, cannot they?. When user sets the message-id, I would expect user to be aware of the consequences.

I think this does not break any existing behavior with the current API but gives the opportunity for API user to choose (setHeader and manage it for each send) or fall-back to the API override (let API generate without setting the header).

The problem with current behavior is, API silently overriding the setHeader. Probably, API throwing an exception when setHeader("message-id", "value") is invoked at least gives user some idea that it is not allowed.

[bshannon]

I understand that you think your use case is more important than other existing use cases,
but I'm not going to risk compatibility with existing programs by making this change in behavior.
If you'd like to submit a request for enhancement, I would be willing to consider adding a new
"overrideMessageId" or similar method to better support your use case, but that would need
to wait for a future API release.

Generally there's no need to override the default Message-Id. Why are you finding it necessary
to override it in your application?

[venkatsc]

I understand that you think your use case is more important than other existing use cases,

It is not that, the earlier workaround of extending MimeMessage works for me.

but I'm not going to risk compatibility with existing programs by making this change in behavior.

I was just letting you know that, this change does not change any of the existing behavior but adds little more flexibility for custom message-id.

If you'd like to submit a request for enhancement, I would be willing to consider adding a new
"overrideMessageId" or similar method to better support your use case, but that would need
to wait for a future API release.

okay

Generally there's no need to override the default Message-Id. Why are you finding it necessary
to override it in your application?

For mail threading based on the message headers we wish to utilize custom Message-Id, In-Reply-To and References to thread the conversations ( (some clients, such as Gmail do threading based on message subject). As Java Mail API generates random unique Message-Id within the library, it is impossible to achieve this.

[bshannon]

I was just letting you know that, this change does not change any of the existing behavior but adds little more flexibility for custom message-id.

It does change existing behavior. As I explained, if you send the same MimeMessage
object twice, you'll get the same Message-Id twice, instead of a new Message-Id for
each message.

Generally there's no need to override the default Message-Id. Why are you finding it necessary
to override it in your application?

For mail threading based on the message headers we wish to utilize custom Message-Id, In-Reply-To and References to thread the conversations ( (some clients, such as Gmail do threading based on message subject). As Java Mail API generates random unique Message-Id within the library, it is impossible to achieve this.

Most clients do threading without depending on the Message-Id, since you can't control
the Message-Id used by replies. Depending on being able to parse the Message-Id just
seems like asking for trouble.

In any event, you clearly need more control of the MimeMessage object, so creating a
custom subclass to embed your behavior seems appropriate.