0

We have a custom script that sends emails based on comments added to a page. We use SharePoint's SendEmail API to do this. At launch this was working fine though we had to sort out some issues with the recipient of the email not being mail-enabled security groups, but otherwise it worked fine and emails were being delivered.

Now, we've had complaints from users that the comments are not sending emails. Upon troubleshooting, there seems to be an issue with the API itself.

Upon trying to submit a comment, the browser console shows the following error "#####.min.js:8 POST #####/_api/SP.Utilities.Utility.SendEmail 400 (Bad Request)" with no other information, just the stack trace but nothing jumps out.

When I browse to /_api/SP.Utilities.Utility.SendEmail from my browser, the following is displayed:

enter image description here

This leads me to believe that there is something wrong with the API? Outgoing email is configured correctly based on my understanding.

Is there anything that would cause this API to fail? A service not running correctly perhaps?

5
  • 1
    Please, is it possible to check the outgoing e-mail configuration at Central Admin? Jun 21, 2021 at 18:49
  • 1
    We use SendEmail endpoint. I just checked and ours is still working. I tried putting the endpoint into the browser and got the same message you got. So I don't think that is very "diagnostic" or will help find the solution. Sorry I don't have anything more I can offer -- I'm not a central admin, just regular site owner.
    – Rothrock
    Jun 21, 2021 at 20:28
  • I've verified with our sys admin team that the outgoing e-mail config is the correct SMTP server name and port. Jun 22, 2021 at 4:10
  • Are there any entries in the ULS logs? Start a ULS session and try to invoke an email action and see what info is printed in the logs
    – jimas13
    Jun 22, 2021 at 4:36
  • First of all, /_api/SP.Utilities.Utility.SendEmail is an endpoint, which means that it accepts certain Verbs. When you try to browse the endpoint and get an UnknownError, might mean that the endpoint will not handle a GET request. Secondly, you get a 400 response code, which means that the requests is processed. You will have to check the ULS Logs and get a bit more info about the error. here is an example : social.msdn.microsoft.com/Forums/Lync/en-US/…
    – jimas13
    Jun 22, 2021 at 9:15

2 Answers 2

1
+150

One simple reason (and therefore probably wrong because you already tried this!) might be that I'm pretty sure the API requires the recipient be in the user information table of the site collection where the site resides.

To verify, grant the recipient access to something in that site (you can immediately revoke it if you want). Doing that adds the recipient's identity into the UIT, which you can see at /_layouts/15/people.aspx?MembershipGroupId=0.

I assume all other outbound mail on your farm works fine. Ignore the rest of these suggestions if that's true because they'll definitely not be the cause of the problem. In central admin verify outbound mail settings - correct relay, TLS setting, etc.

I've run into a scenario where outbound smtp settings were correct, but the mail relay server had changed TLS encryption versions and eliminated an older version, which happened to be the version our SP server was using. If you run a packet capture on the SP server(s) with a display filter for the email server's relay address, you can see whether or not the TLS encryption handshake is resetting (failing) and which version of TLS its using. If it's failing on TLS 1.2, and you are running a server OS version that doesn't support TLS 1.2 by default, like Win 2012R2, you may need to enable it.

Beyond that, I'd look for a correlation between when this started happening & when you last applied Windows/SharePoint updates. I know Micro$oft never messes up stuff like that, but...

4
  • I've tried it with my user as the recipient, and I am Farm Admin as well as a regular domain user with an Exchange email. When you say run a packet capture, you mean like with Fiddler or something and then run it while I attempt to use the SendEmail function? What would the success/fail look like exactly? Sorry, packet inspection is not really in my wheelhouse. Jun 22, 2021 at 4:09
  • 1
    I looked closer at the call with the browser console and when I try to send the email this is the message that is returned:{error: {code: "-1, Microsoft.Data.OData.ODataException", message: {lang: "en-US",…}}} error: {code: "-1, Microsoft.Data.OData.ODataException", message: {lang: "en-US",…}} code: "-1, Microsoft.Data.OData.ODataException" message: {lang: "en-US",…} lang: "en-US" value: "A null value was detected in the items of a collection property value; non-streaming instances of collection types do not support null values as items." Jun 22, 2021 at 22:11
  • Okay well after debugging in the browser and comparing it between our QA (working) and Prod (not working) environments, it turns out the issue was the user we had set for the CC on the email in prod was not a proper user. After setting to my user, it worked fine. I knew the recipients had to be valid users but I neglected to check who was configured in the CC. I'll mark yours as the answer since it led me down the right path. Thanks! Jun 22, 2021 at 23:12
  • Glad you got it figured out! At least it wasn't something crazy-complex, right?! To fill out my packet capture comment, i meant something like WireShark or NetMon, where you're seeing the packets that come in & out of the network adapter on the server. However, you can also see the version of TLS in Fiddler on the TextView tab if you look in a "Tunnel to" line. Jun 23, 2021 at 14:01
1

One reason of bad request can be existence of special character in the comment text. Sometime we just copy paste content from word/excel/pdf which also copies hidden Unicode characters which cause the bad request. If that is the case then you have to use regex to find and replace all unwanted Unicode characters.

1
  • At this point I'm testing with very simple test like "test comment" so that is not the case but this is good to know, thank you. Jun 22, 2021 at 17:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.