I'm back with an email issue!

[AaronHildebrand]

Good Afternoon folks;

Here's the problem:

We have an exchange server set up and this code is tested and works fine with a different cart implementation (Non A.NET); however, when SIM is applied to the code the code runs properly, but no email is received from the webpage.

The standard A.NET transaction email goes through without a hitch, but the webpage confirmation email does not, is the SIM implementation blocking email requests to our exchange server?

It's using the Microsoft.Exchange.WebServices library to generate the correct handshaking and other requirements of Exchange emailing.

To make it clear, we are NOT sending the email from A.NET, but the email send request appears to be blocked by the API when it loads the confirmation page.

No error trips either, making me doubly curious as to what the cause may be.

[RaynorC1emen7]

Where is this confirmation page happened? Do you mean the relay response?

[AaronHildebrand]

In the cycle of the page it's supposed to happen in the model generation process for the confirmation page that loads within the relay response of A.NET.

[RaynorC1emen7]

Can you do a try catch block to capture the error message? Don't see how it would block your email from sending.

[AaronHildebrand]

That's just it, there's no error message, the entire thing passes through normally without a fault, page loads as normal, and everything's hunky-dorie...

ExchangeService service = new ExchangeService(ExchangeVersion.Exchange2007_SP1);

                    service.Url = new Uri("https://anywhere.exchserver.com/ews/Exchange.asmx");

                    service.UseDefaultCredentials = true;
                    service.Credentials = new WebCredentials("someone@somewhere.com", "someone");


                    EmailMessage message = new EmailMessage(service);

var body = "Some Body Text involving concatinating variables that are passed back from A.NET and from the order";

message.Subject = "Thank you for your order.";
                    message.Body = body;
                    message.ToRecipients.Add(order.Name.First + " " + order.Name.Last, order.Email);

DateTime tempday = DateTime.Now.AddYears(-25);
                    foreach (var payments in order.Payments)
                    {
                        if (payments.PaidOn > tempday)
                        {
                            tempday = payments.PaidOn;
                        }
                    }

                    if (tempday > DateTime.Now.AddDays(-1))
                    {
                        message.Save();

                        message.SendAndSaveCopy();
                    }

As you can see, the only logic that MIGHT get in the way is the test to prevent mail going out after 24 hours, but that code is perfectly functional as well within the other payment processor's actions.

I notice that this page that gets loaded by this module has Authorize.Net's URL rather than the website, could that have anything to do with it?

[RaynorC1emen7]

Maybe it doesn't like the Recipients email address? What is this PaidOn? So if it is PaidOn is today, it will not get send?

[AaronHildebrand]

Here's what happens:

Temppay gets set to 25 years in the past (to ensure that whenever the person paid, it would be able to be overridden, and yes, I understand that means this code needs to be maintained in 25 years, but they needed a fast solution.

Anyways

Then Temppay is compared against every single payment in the database's transaction date, the latest transaction date is taken after this process is done.

Then it tests to see if the last date there was a transaction for is Greater than or equal to one day prior to now (Yesterday).

If it is greater than Yesterday, then it saves the message, and sends and saves a copy (two backups for the order) to the orderer's email address.

In layman's terms, if the registration was made today, it will send an email, otherwise it won't, this is in response to a strange symptom that hasn't been nailed down (thus the slapdash nature of the 25 years) where the program will send emails out erratically well after the orderer completed their order, we have some people who've received over seven emails due to this particular bug that we haven't narrowed down yet, but that's just an aside.

Anyways, this code works fine with a different gateway solution, lending the thought to being one of two things, either the mail system blocking A.Net as the referrer for the message request, or A.Net itself blocking the message request to the server.

[RaynorC1emen7]

So, can you log tempday just before

if (tempday > DateTime.Now.AddDays(-1))
                    {
                        message.Save();

                        message.SendAndSaveCopy();
                    }

[AaronHildebrand]

Alright, got it all squared away, it appears that the website was communicating using secure.authorize.net's IP, an IP that hadn't been whitelisted yet with the email server.

It's been whitelisted and all is good, though I find it odd that it's transmitting from that IP.