Mail Manager question

[ids]

Background:
I had found this issue with the Emporium Plus module Customer Account Manager. When the store was switched to the 3rd party email service provider, Miva email was switched off, the CAM mod couldn't send emails. At the time (2 years ago -- ish) Brennan helped confirm what was going on. It was determined that the module wasn't using the Miva Sendmail API.

I personally don't have experience with the EP Mail Manager. Has anyone that has switched to a 3rd party email service provider and is running Mail Manager had an issue sending emails from that module? If so, what is/was the resolution? Or is there no problem sending emails from this module with 3rd party email and obviously the latest Miva update?

Scott

[ILoveHostasaurus]

If the module does not honor the domain settings for mail delivery, then it should have its own mail server settings. If it does not, and it's hard coded to localhost, for example, then that should still work, in theory, if the domain's SPF record accommodates email originating in that manner. Probably would need to send all the specifics as a support ticket so we can confirm what is going on with the module.

[ids]

Thanks David. This makes sense if I had the source of the module. I cannot check this, obviously, at this point. Miva has control of the Emporium Plus modules and source code. I was hoping to get any experience of anyone that has butted up against this issue. The client's store is getting moved to the new server soon and we need a plan if it the module doesn't send emails. And, yes, I've already submitted a ticket. But I haven't heard back. I have a feeling this issue is going to slip through the cracks, just trying to prevent as much spillage as possible.

Scott

[ILoveHostasaurus]

Bill provided us with the code before he passed in case we needed to patch for security reasons in the future, but the modules should be considered unsupported, end of life, and generally removed from any store using them at this point as they were never built for Merchant 10, often create performance issues in later versions, and will ultimately all fail to work since they have not been updated in over seven years.

Now that I think more about it though, I am pretty sure I remember this issue. That module uses code that only looks at the store's mail server setting, because it pre-dated Merchant having SMTP authentication functionality (i.e. its code is over a decade old), then sends the email itself instead of using store functions. If a store is configured to use a remote SMTP server, which almost universally requires authentication, the module will no longer be able to send email. It also has no ability to override the mail server setting back to localhost since it wasn't built that way.

The only options are:

• Switch the store back to sending via localhost to get the module working. That will work regardless of where a domain's email is hosted, however, appropriate measures must be in place to allow the server with us to send emails on behalf of the domain the store is set to send from.
• No longer use the module.

[ids]

Again, Thanks David.

I've actually fixed a couple of custom modules from other developers with this issue because the client had the source. I was able to incorporate the Miva Sendmail API. I am pretty sure they were using "localhost" settings in those stores.

What is involved in getting the setting back to localhost? The store I mentioned using the CAM module was always "localhost" in the domain settings. The usage was technically replaced with built-in functions (but not without some kicking and screaming.) Was lucky on that one. But this store with Mail Manager is also "localhost" in the domain settings => Mail Settings. My assumption is that MM won't work in the store. Is there something that a support engineer can adjust? Something I could adjust?

Scott

[ILoveHostasaurus]

Hmm, if the store itself is still localhost without auth, then that module should also be working. You can email me the ticket and I can have a look at what's been done. Maybe it's so old it's doing something weird with the SMTP headers that is invalid.

[lesliekirk]

Bill provided us with the code before he passed in case we needed to patch for security reasons in the future, but the modules should be considered unsupported, end of life, and generally removed from any store using them at this point as they were never built for Merchant 10, often create performance issues in later versions, and will ultimately all fail to work since they have not been updated in over seven years.

Now that I think more about it though, I am pretty sure I remember this issue. That module uses code that only looks at the store's mail server setting, because it pre-dated Merchant having SMTP authentication functionality (i.e. its code is over a decade old), then sends the email itself instead of using store functions. If a store is configured to use a remote SMTP server, which almost universally requires authentication, the module will no longer be able to send email. It also has no ability to override the mail server setting back to localhost since it wasn't built that way.

The only options are:

• Switch the store back to sending via localhost to get the module working. That will work regardless of where a domain's email is hosted, however, appropriate measures must be in place to allow the server with us to send emails on behalf of the domain the store is set to send from.
• No longer use the module.

Yes, you helped me with an issue with the module. I think this was also when I learned that the store mail setting could be set back to localhost even when the store is using a separate email host.