SendGridMessage creates BadRequest when using both AddCc and AddBcc

[ctbhavius]

No description provided.

[ctbhavius]

Never understood the design lumping in the cc's and bcc's with "personalizations"; seems to me a confounding of issues with other kinds of "personalizations" and therefore prone to error --- as is apparently the case; in my opinion, the basic mail parameters of "from", "to", "cc" and "bcc" are all fundamentally different from other kinds of "personalizations" and should be addressed directly in the code without obfuscating them behind another layer of "personalizations"

[thinkingserious]

Hi @BHAVIUS,

I was not able to reproduce the error, here is my code:

var msg = new SendGridMessage()
{
    From = new EmailAddress("[email protected]", "Example User"),
    Subject = "Hello World from the SendGrid CSharp Library Helper!",
    PlainTextContent = "Hello, Email from the helper [SendSingleEmailAsync]!",
    HtmlContent = "<strong>Hello, Email from the helper! [SendSingleEmailAsync]</strong>"
};
msg.AddTo(new EmailAddress("[email protected]", "Example User1"));
msg.AddBcc(new EmailAddress("[email protected]", "Example User2"));
msg.AddCc(new EmailAddress("[email protected]", "Example User3"));

var response = await client.SendEmailAsync(msg);
Console.WriteLine(msg.Serialize());
Console.WriteLine(response.StatusCode);
// The following line will get you the actual error.
Console.WriteLine(response.Body.ReadAsStringAsync().Result);
Console.WriteLine(response.Headers);
Console.WriteLine("\n\nPress any key to continue.");
Console.ReadLine();

With regards to personalization, I think this content has a good explanation. If you don't agree, I would love to explore further with you to understand how we can improve. I think that discussion might be better served on the phone though. If you are open to that, please email me at the address above. Otherwise, I'm happy to continue the conversation here as well.

I hope this helps!

With Best Regards,

Elmer

[ctbhavius]

It seems that a lot of things DO work when tested in a simple console app, but then do NOT work when tested in an actual ASP.Net web app…. That is the case for me. I continue to experience difficulties, so I would like to see an example with a basic standard asp.net web app that just submits an email from a contact form. Also in my web app C# code, I use the following to assist with debugging: var sgc = new SendGridClient(adminApiKey); var request = sgc.SendEmailAsync(msgMail); var response = request.GetAwaiter<Response>().GetResult(); var headers = response.Headers; var body = response.Body; var status = response.StatusCode; And unfortunately I get flaky results sometimes a status of “OK”, and sometimes “Accepted” and sometimes “BadRequest”, so why the OK versus Accepted when I have forced SandboxMode.Enabled = false, and why the BadRequest if not because of the addition of the AddBcc in the setup of my msgMail variable? I continue to disagree with the explanation and justification of “personalization”. I should be able to send a basic email with the basic fields for SMTP including the “from”, “to”, “cc” and “bcc” without considering any of that fancy personalization either conceptually or technologically. And I should be able to test the basics to make sure the basics are working BEFORE even worrying or testing any kind of personalization!!! So I will continue to argue that it just does not make any sense to me because “personalization” implies “fancy extras” and because you implemented with an extra layer of complexity which makes testing and debugging more difficult.

[thinkingserious]

Thanks for the detailed response @BHAVIUS!

1. I like the idea of having a ASP.NET web app example. I have opened an issue for that here.

2. You should only get an "OK" on the mail/send endpoint if you have SandBox Mode set to true. If you still get this response when SandBox Mode is set to false, then there is a bug. Could you please share the results of msgMail.Serialize() just before you pass it into SendEmailAsync in the case where the result in unexpected so I can attempt to debug with you?

3. When you get a BadRequest, what is the error message from Console.WriteLine(response.Body.ReadAsStringAsync().Result);? For example, when I was testing, I received an error when I had duplicate emails, like this:

{
    "errors": [
        {
            "message": "Each email address in the personalization block should be unique between to, cc, and bcc. We found the first duplicate instance of [[email protected]] in the personalizations.0.bcc field.",
            "field": "personalizations.0",
            "help": "http://sendgrid.com/docs/API_Reference/Web_API_v3/Mail/errors.html#message.recipient-errors"
        }
    ]
}

4. You are correct regarding personalization, in that it is designed for more advanced use cases and for simple emails you should not worry about them. I was hoping our Mail Helpers would sufficiently hide their complexity for the basic cases. Can you please provide an example of how personalizations are getting in the way of your current use case? Hopefully, I could use your example to further simplify. Also, I will pass your feedback to our Product Manager for further review.

With Best Regards,

Elmer

[RossAndrewMcLeod]

I am also have a similar issue with the following code (BadRequest) which doesn't happen when I use the AddTo() rather than the AddBcc()

As with previous comments from @BHAVIUS I to am have an asp.net web application Framework 4.6.1 Sendgrid 9.0.12

public async Task SendToUsers(EmailAddress from, string subject, string message, IEnumerable users)
{
// create the client (new SendGridClient...)
var client = CreateClient();

// create the message
var msg = new SendGridMessage()
{
    From = from,
    Subject = subject,
    PlainTextContent = message
};

// add the to's
foreach (var user in users)
{
    //msg.AddTo(new EmailAddress(user.Email, user.Name));
    //msg.AddCc(new EmailAddress(user.Email, user.Name));
    msg.AddBcc(new EmailAddress(user.Email, user.Name));
}

// send the message
Response response = await client.SendEmailAsync(msg);

if (response.StatusCode >= System.Net.HttpStatusCode.BadRequest)
    throw new Exception(response.StatusCode.ToString());

}

[thinkingserious]

Hello @RossAndrewMcLeod,

My guess is that you have duplicate emails in the to, cc and/or bcc fields.

You can find out for sure by reading the value from Console.WriteLine(response.Body.ReadAsStringAsync().Result);

I hope that helps!

Thanks!

Elmer

[RossAndrewMcLeod]

Hi Elmer

No I don't have duplicate email address. I just used the other commented out lines to test. The response body you suggested revealed the following error.

{"errors":[{"message":"The to array is required for all personalization objects, and must have at least one email object with a valid email address.","field":"personalizations.0.to","help":"http://sendgrid.com/docs/API_Reference/Web_API_v3/Mail/errors.html#message.personalizations.to"}]}

I'm not sure where the ToArray() should be but is this error message also suggesting that I need to have at least one valid AddTo() EmailAddress to make the Bcc work?

If I comment out the AddBcc() and un-comment the AddTo() line it works.

Ross

[RossAndrewMcLeod]

Just as a matter of interest the AddCc() used by itself also produces the same error message

[thinkingserious]

@RossAndrewMcLeod,

Currently, our API requires that there be at least one valid To email address, which is achieved with the AddTo() method.

Perhaps we need to create a SendGridMessage constructor that enforces the minimally required parameters.

With Best Regards,

Elmer

[ctbhavius]

As I have commented before, the SendGrid API could readily benefit from adherence to basic design principles of consistency, not just internal consistency with regard to the present design, but consistency with regard to past user experience over the past decades with basic internet mail. For example, I am not aware that mail systems in the past have "bombed and crashed" just because a user puts the same email address in the to, cc, and/or bcc fields. If SendGrid wishes to impose efficiency by only sending one copy of the email to each email address, then SendGrid can easily do that at the SendGrid servers WITHOUT impacting the user experience!!! And as I have argued before for the sake of clarity and consistency, the basic set of properties including "from", "to", "cc", and "bcc" should all be exposed at the same level withe same consistent user interface in the API again WITHOUT some but not all being buried under the misleading additional layer of complexity called "personalizations" with lower level access under that hierarchy. In the absence of these common sense changes, then SendGrid should dramatically improve its error reporting and messaging for the sake of users such as myself and others who have reported concerns in this thread.

[thinkingserious]

Hello @BHAVIUS,

Thank you for taking the time to provide further feedback and we would love to dig deeper with you to understand the specific issues you are experiencing.

1. With regards to exception handling, we agree. I have added your vote (and the votes of the others in this thread) to this issue. In the mean time, you can grab the error message as described here. Those votes help that issue rise in our backlog.

2. Personalizations are designed for more advanced use cases. For simple emails, you should not need to worry about the concept of personalizations. The personalization model was created in collaboration with our users who have need for such complexity. Our Mail Helpers in this SDK should sufficiently hide their complexity for the basic cases. Can you please provide an example of how personalizations are getting in the way of your current simple use case? Hopefully, I could use your example to further simplify.

3. Another option to help with validation that is new with v3 of the API, is the sandbox mode. You can use the sandbox mode to test your payloads before you send any live emails.

With Best Regards,

Elmer

[RossAndrewMcLeod]

Hi Elmer

Thanks for the clarification. Yes I agree if an interface has definite requirements then it should be enforced in the constructor. However, I don't think that this is the case here. It's my contention that BCC (Blind Carbon Copy) is intended for anonymity and by enforcing that the user places an address in the TO might break the users intentions of concealment.

In my opinion the library should only be checking for valid address in (TOs || CCs || BCCs). There are no constraints like this in my email client and it doesn't even bother to tell me that I was silly enough to place multiples of the same email address.

It seems to me that the only way around this for me is to send individual emails to each of my users. OR I could place a sacrifice address in the TOs. Either way it just seems like a bit of a waist to me.

Thanks again for your help, I hope you don't mind me speaking my mind here.

Regards Ross

[thinkingserious]

Hello @RossAndrewMcLeod,

Thank you for the great feedback, I now understand your specific use case. Unfortunately, we can not implement the behavior you require at the SDK level.

I will reach out to our API product team on your behalf. Thanks again for providing additional detail!

With Best Regards,

Elmer

[RossAndrewMcLeod]

Thanks Elmer

1. For your help
2. For your empathy & understanding

For anybody else out there I have solved this problem by simply adding a dummy EmailAddress (that looks real) to the TOs and it works now.

Thanks again for your help

Ross

[thinkingserious]

Thank you for the kind words @RossAndrewMcLeod and for sharing your solution with the community!

[thinkingserious]

Reference RFC: https://tools.ietf.org/html/rfc2822#section-3.6.3

[thinkingserious]

Hello everyone,

The error handling has now been improved with this PR: #434, now available in version 9.1.1

[warrenkc]

Before using SendGrid to send an email to multiple recipients worked fine. This is how it would look before.

Now it shows this extra information to the user. Anyway to get the result needed?

[thinkingserious]

This should be the function you need. Thanks!