ERMailDelivery.sendMail() does not allow for null returned from Message.getAllRecipients() #954
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The issue here is that
ERMailDelivery.sendMail()
checks for zero recipients by looking at the length of anAddress[]
array:That's fine, except the ultimate origin of that array is a call to
javax.mail.Message.getAllRecipients()
, where the Javadocs explicitly state that "This method returnsnull
if none of the recipient headers are present in this message." If that array isnull
, this check obviously throws aNullPointerException
.Presumably you could trigger this on purpose by setting no recipients and calling
sendMail()
, but you can run into it simply by using the features of ERJavaMail.framework. Specifically, set the black list to exclude addresses inexample.com
:And then try to send a message to an address in that domain. The address is correctly excluded from recipients, then you have zero recipients, then you get the
NullPointerException
. My argument is that this blacklist feature should be usable just like this, where I'm just trying to suppress outgoing mail to a domain even for single-recipient messages.Aside from my use case here,
getAllRecipients()
is documented as potentially returningnull
, so this should be fixed regardless.