[Suggestion] Be more liberal when parsing email addresses

Is your feature request related to a problem? Please describe. When an email address in the EMAIL parameter contains a dot at the end, the whole event can’t be parsed because

1. the EMAIL parameter is parsed,
2. which calls InternetAddress(<email address>),
3. which throws an AddressException when the email address ends with a dot.

While this seems to be syntactically correct, it causes problems when users accidentally add a trailing dot: https://forums.bitfire.at/topic/2648/domain-with-dot-at-the-end/

Describe the solution you’d like I don’t know if there’s a good solution to that. However, I think that parsing events should be as liberal as possible and single more-or-less invalid parameters should not stop ical4j from parsing the whole event. Ideas about possible solutions:

1. Invalid parameters should be ignored in relaxed mode. (If mode is relaxed → catch parsing exceptions and turn them into warnings.) I think this is a big change, but would solve the most problems.
2. The EMAIL parameter could somehow be empty when the value is illegal.
3. In the specific case of email addresses, there could be some kind of EmailHelper.checkEmail() function that removes common problems like a trailing dot at the end. This function could be called always before passing the email address to InternetAddress() (at least in relaxed mode).

Additional context See forum link above. The problem occurs when a mobile client (DAVx5) synchronizes events from the server, which contain email addresses with a trailing dot.

[benfortuna]

I noticed there is a flag for strict mode on InternetAddress.parse(), so I’ve set strict=false if RELAXED_PARSING is enabled. This still doesn’t fix the issue with trailing dot, so we’ll also remove the trailing dot when relaxed parsing is enabled.

There may be other issues, but we can add to it as required, and review later if a different solution is needed.

New release just published (3.1.2) includes this change.

[benfortuna]

Thanks, I had another look at the EMAIL parameter, which is a bit different to other address params where we use URI to store the value. However the spec is quite explicit that this parameter should be an address (not a URI):

https://www.rfc-editor.org/rfc/rfc7986.html#section-6.2

So as you suggest we could clean up invalid values in relaxed mode, which I think we have done before. We do try to fix problems like this so we are lenient on parsing but strict on outputting.

I think probably a replacement for InternetAddress that supports lenient parsing may be the best approach, as we may also be able to remove the Javamail dependency (I don’t think it used elsewhere).

I’ll have a look for some other libraries or look at how to implement internally.