-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ParseException with mail received over internet via SMTP #143
Comments
For the record:
|
Do you know what email client generated the email via X-Mailer header or User-Agent header? |
Looks like Outlook-Express: |
I'll have to run your test case but, it seems that setting system property (not session property)
|
@jmehrens thank you so much for your response and the tip that I tried:
However, I still get the same exception. I have verified it in debug mode and all mails are parsed using this single code function so I can confirm this is not yet the solution to close this issue. |
My mistake. The mail.mime.address.strict is documented as session property. The rest are system properties. In your example you set everything as a session property so the properties don't do anything. I would set mail.mime.address.strict as a system property too. Here is the source: I think you'll want to set |
@jmehrens thank you very much for pointing this out and for the link to the source. Very helpful. @Named
@ConfigurationProperties("mail")
public class MailMimeConfigProperties {
private Map<String, String> mime;
private Properties properties;
public Map<String, String> getMime() {
return this.mime;
}
public void setMime(Map<String, String> mime) {
this.mime = mime;
}
public Properties getProperties() {
if (this.properties == null) {
Properties p = new Properties();
for (Entry<String, String> entry : mime.entrySet()) {
String key = "mail.mime." + entry.getKey();
String value = entry.getValue();
p.setProperty(key, value);
System.setProperty(key, value);
System.out.println("Set " + key + "=" + value + " for session and system property");
}
this.properties = p;
}
return this.properties;
}
} And in my
And to verify I see this output:
However, I still get the same exception when parsing the mail so it seems these properties do not solve the actual problem. |
There is a danger setting system properties in code in that they have to be set before the class loads. Try setting system properties on the command line or if you are using a web container like Tomcat you'll have to consult the documentation on setting system properties. I should be able to verify your test case in a week or so and come up with plan for this ticket. Thanks for testing. |
Sorry for the late response.
So that is great news. The code implementation already can handle the problem I was reporting. Feel free to take this as a feature request to consider allowing to override the system properties also as session properties. |
That is good news. We have another ticket for system vs. session properties so that issue will still be worked on but I will close this as a duplicate |
Dupe of jakartaee/mail-api#513 |
Describe the bug
When I read emails that have been sent over the internet and arrived their destination from EML format using JakarataMail, for some edge-cases, I get strange errors like this:
To Reproduce
Steps to reproduce the behavior:
Expected behavior
I do not know what the initial design decisions from Sun may have been when all this code was initially born, but from my PoV reading a mail with JakartaMail should be as robust as possible. Also retrieving attributes (using
getFrom()
,getTo()
,getDisposition()
, etc.) should ideally give me back what has been in the mail.In a perfect world, validation should be separate from reading and accessing the data.
I am very aware that the API of JakartaMail cannot be changed very easily (also using
java.util.Date
seems to be a crime nowadays after having JSR310). But at least avoiding unnecessary ParseErrors should be a reasonable goal.In the concrete example it would be easy to tokenize using the expected semicolon without complaining about the coma in the date value.
I do not want to judge if the value of the cited
Content-Disposition
header is valid according to relevant RFCs or not.Maybe it is not using the correct date/time format.
However, the mail clients and relay servers out there in the wild may just do such things and it would be awesome if JakartaMail does not get in the way here.
Environment:
The text was updated successfully, but these errors were encountered: