This issue has left me stumped. This question may need to be migrated to Server Fault, but there is a programming component, so I figured I'd start there. Also, our infrastructure team ardently believes everything is fine on their end, but that doesn't always mean anything.
Anyways, I've got a simple GET-POST-Redirect action that sends two separate emails using the Postal nuget package, before redirecting to a success page -- pretty basic stuff. The action is async, and I'm using await email.SendAsync() from the Postal API.
When the form is submitted, the first email comes into my inbox instantaneously, but the code hangs on that await email.SendAsync() line for a good 15-20 seconds before it moves on to the next line (confirmed in debugger). Then, it gets to sending the second email, which again comes into my inbox instantaneously and again the code hangs on that line, regardless of the successful send, for 15-20 seconds before moving on to the line with the redirect. In production, this delay after sending the email, combined for the two emails, causes the connection to reset before the redirect response can be sent. Sure, I could just up the page timeout, but that doesn't really fix the problem as the user still ends up with a minute long delay before getting a response.
I've also tried sending the emails synchronously with just email.Send(), but the same behavior occurs. I've looked through the source for Postal, and although it does some custom wrappings around SMTPClient to send asynchronous email, there's virtually nothing other than standard old C# email sending with the synchronous Send method.
It's also not bound to the server where the site is running, as I can see the same behavior in both production and when debugging locally (both connecting to the same production Exchange server, though).
It's acting like it's waiting for the Exchange server to send some sort of "finished" response, but from what I know about SMTP, it doesn't work like that. It should just send the email to the SMTP server and continue merrily along, trusting that the SMTP server will actually do what it's supposed to do.
Any ideas would be greatly appreciated, because I'm not even sure how to continue debugging this at this point. What else could I test or try?
UPDATE
Thanks to @MichaelEvanchik's suggestion to try out Wireshark, I was able to clearly see that there's actually a 30 second delay caused by the Exchange server. It receives the last bit of the email to be sent and then 30 seconds later finally responds to the client with "Successfully queued for delivery". It's at this point that the client finally QUITs and the code resumes. So, I'm kicking it back to infrastructure.
UPDATE #2
So, apparently there was actually a 30 second delay put on the connector to allow for confirmation that the email had truly been sent and not just queued for delivery. Personally, I think that kind of defeats the point of "queued for delivery" in the first place, but regardless, I don't need confirmation that it's actually been sent, just that it was received by the Exchange server, so infrastructure is removing the delay.
