Using external Mail Settings slows down checkout

[lancermedia]

We are looking to move a client with a Miva store over to mail hosted at Microsoft with Exchange Online. Because of this, we need to instead of using localhost to send mails from Miva, use the Mail Settings in Domain Settings to use an external SMTP account.

What I'm finding is the following:

- When using the Microsoft account, it takes approximately 14-18 seconds once I click on Complete Purchase before the INVC page is shown. This is unacceptable.

- When using a Rackspace account, it takes approximately 4-6 seconds.

So clearly there is a delay in Exchange online....but there is still a delay using another service. For comparison, using the localhost, it's almost instant (under 2 seconds) for the INVC page to show.


Why is Miva taking so long? Is it waiting for responses from the external mail servers? I notice that the order does actually get placed immediately once the button is pressed.....it's just I think the external mailing that is causing the hang before the INVC page loads.

Also, does anyone use any jQuery code to make the Complete Purchase button go away and be replaced by a processing message (so people don't try to click the button again).

-Kevin

[ILoveHostasaurus]

Re: Using external Mail Settings slows down checkout

Hosting email elsewhere should not necessitate having the store send through that external service, with two exceptions:

1) If the store is sending merchant order notifications as being "from" the customer's email address. This should not be an exception though because in reality it's not a good idea to be doing this to begin with. The reason is that if the email is undeliverable for any reason, the bounce is going to go back to the customer and make the store look unprofessional at a minimum.

2) If the domain has an SPF record that is explicit, only permitting the mail host's servers to deliver mail for the domain, and whomever is in charge of the SPF is unwilling to alter it to not be explicit or to include the server where the website runs.

Other than those two, the local server, or a mail server local to the host, should still be able to be used for outbound relay by the store.

Regarding the delay, many large mail providers intentionally add delay to frustrate spammers who are connecting repeatedly trying to brute force passwords. From a normal email client, this goes unnoticed since it occurs behind the scenes, but from Merchant obviously it is a visible issue. Not much way around that type of issue.

[lancermedia]

Re: Using external Mail Settings slows down checkout

David,

Are you talking about just unauthenticated email relaying locally? I'm being told that the main reason is PCI compliance is trying to harden servers and unauthenticated SMTP sending is not going to be allowed?

EDIT: we are also sending AS an email in our domain with a reply-to as the customers email address.

-Kevin

[ILoveHostasaurus]

Re: Using external Mail Settings slows down checkout

Unencrypted and unauthenticated SMTP exposed externally are both not permitted, so the presence of either, or both, will result in a failure. However, my understanding is that unauthenticated smtp that is only exposed internally to the payment application is not an issue.

[ILoveHostasaurus]

Re: Using external Mail Settings slows down checkout

EDIT: we are also sending AS an email in our domain with a reply-to as the customers email address.

-Kevin

Reply-to is okay, just setting the Return-Path, aka "envelope sender" to the customer's address is a bad idea.

[lancermedia]

Re: Using external Mail Settings slows down checkout

David,

Thanks. I'm trying to get Remik over at dotcomhost (our Host) to respond directly to this ticket as I'm getting conflicting answers.

-Kevin

[ILoveHostasaurus]

Re: Using external Mail Settings slows down checkout

If the server is running Plesk version 12, it disables localhost relaying by default, so that is likely the issue. The reason is not related to PCI though, it's related to Plesk 12's new features of outbound anti-spam and limiting what accounts can send (messages per hour per mailbox, per hour per domain, per hour from an entire subscription, etc.) Without authentication of all email, there's no way to apply those features. The issue you run into is if mail is hosted elsewhere, AND you want to use those features, then there's not a local domain to authenticate off of.

One workaround is to add a bogus domain to the local server whose only purpose is to let mail authentication occur. So you could add test.com to the server with an email account named test, and then set the store to authenticate off that, and recipients of the email would never know since the From is still what you expect. If you're on dedicated, this would be a free solution, it just means you could never email an actual person on the test.com domain, so pick one that doesn't exist or you don't care about mailing.

[lancermedia]

Re: Using external Mail Settings slows down checkout

Yes, running Plesk 12.

So sounds like the only real option is adding another domain to be able to use in Miva's Mail Settings to authenticate to? That would solve the issue of the delay as well since technically it would be using a local account on the same machine?

-Kevin

[ILoveHostasaurus]

Re: Using external Mail Settings slows down checkout

Correct, should be local and fast. That may be easier than trying to get that setting backed out (it's a one line change to the Postfix mail server config file).

[Ron Frigon]

Re: Using external Mail Settings slows down checkout

Hey Kevin,

We are also at Dotcomhost, on Plesk 12 and we host our own email on Microsoft Exchange inhouse.

The setting I use in Plesk under Mail Settings, "Activate mail service on this domain", is set to Off. I think this was pretty key. Just uncheck the box.

Our spf record does include the ip address of the website.

Miva settings are set to localhost, and emails are sent "From" the sites domain.

This may not apply to your situation... But maybe it will help.

[lancermedia]

Re: Using external Mail Settings slows down checkout

One workaround is to add a bogus domain to the local server whose only purpose is to let mail authentication occur. So you could add test.com to the server with an email account named test, and then set the store to authenticate off that, and recipients of the email would never know since the From is still what you expect. If you're on dedicated, this would be a free solution, it just means you could never email an actual person on the test.com domain, so pick one that doesn't exist or you don't care about mailing.

David,

Curious as to your statement above in bold....not that I would want to, but why technically wouldn't it be possible to email a user on that new domain? Isn't that domain just setup as a standard domain locally?

Thanks!

-Kevin

[lancermedia]

Re: Using external Mail Settings slows down checkout

Hey Kevin,

We are also at Dotcomhost, on Plesk 12 and we host our own email on Microsoft Exchange inhouse.

The setting I use in Plesk under Mail Settings, "Activate mail service on this domain", is set to Off. I think this was pretty key. Just uncheck the box.

Our spf record does include the ip address of the website.

Miva settings are set to localhost, and emails are sent "From" the sites domain.

This may not apply to your situation... But maybe it will help.

Ron,

Thanks for letting me know. I passed this along to ask dotcomhost.

Are you on the cloud server platform?

-Kevin

[Ron Frigon]

Re: Using external Mail Settings slows down checkout

Are you on the cloud server platform?

Yes we are, with 6 domains. We have the mx records for each domain set to our mail server. The spf record includes the ip address for the mail server and the website.

Ron

[ILoveHostasaurus]

Re: Using external Mail Settings slows down checkout

David,

Curious as to your statement above in bold....not that I would want to, but why technically wouldn't it be possible to email a user on that new domain? Isn't that domain just setup as a standard domain locally?

Thanks!

-Kevin

This is because mail service has to be active for the domain in question for you to be able to authenticate off of an account on it, but if mail is active, any email generated to that domain locally will try to be delivered locally. I'd just use something like outboundemail.com and you should be fine.

Hey Kevin,

We are also at Dotcomhost, on Plesk 12 and we host our own email on Microsoft Exchange inhouse.

The setting I use in Plesk under Mail Settings, "Activate mail service on this domain", is set to Off. I think this was pretty key. Just uncheck the box.

Our spf record does include the ip address of the website.

Miva settings are set to localhost, and emails are sent "From" the sites domain.

This may not apply to your situation... But maybe it will help.

Correct, it has to be off for email to leave the server to go to where the MX records point it. Having the SPF record include the website IP and possibly the server's first IP is also critical, but that part depends on the setup. If your site is on the server's primary IP then it's one in the same.

If your server began as a version lower than 12, normally the rule allowing relaying through localhost will still be there unless removed manually.

[lancermedia]

Re: Using external Mail Settings slows down checkout

This is because mail service has to be active for the domain in question for you to be able to authenticate off of an account on it, but if mail is active, any email generated to that domain locally will try to be delivered locally. I'd just use something like outboundemail.com and you should be fine.

Guess I still don't fully understand.

We would have:

primarydomain.com =
MX records set to Exchange Online and mail service turned off for the domain.
SPF record set to: v=spf1 include:spf.protection.outlook.com -all

newmailonlydomain.com =
MX records local to the machine and mail turned on for the domain.


For the Miva store on the primary domain, the settings in the Mail Settings would be to use a [email protected] to send mail. This would use that new account to send the mail. When sending that account would see the MX records being Exchange and deliver mail there.

Now is someone outside either of these domains emails [email protected]'t that email account receive that mail?

And if something in the primarydomain.com went to send mail to [email protected], wouldn't that get delivered as well.

I guess isn't setting up this new local domain just like if I was using a 3rd party service like Rackspace? The only difference is the mail server is hosted locally, so the checkout is quick?

I really do appreciate you taking the time......I know a bunch of stuff but mail always confuses me!!!

-Kevin