Hi,

This would require changes in mojoPortal to do that. I'll add a wish list item for it in our project tracker but can't promise it will happen in the near term since there are many higher priorities. I guess for now if you must use GoDaddy then you will need to use what they make available for sending mail and you won't be able to use Elastic Mail if they don't allow you to relay smtp.

Best,

Joe

Hi Chad,

For your solution to be included would require it to be a very clean solution like implementing a provider model for sending mail where the default provider would use our Email class and additional providers could be plugged in so it would be open for other solutions like MailChimp not just Elastic Mail. It would require code changes in many places after the provider model was implemented so this is not going to be some small thing to tackle. You are free to try to implement the provider model and a plugin for Elastic Mail but it will not be trivial to make a solution that meets my approval and if it requires much help from me to guide you then I would just as soon do it myself on my own timeframe so I can stay focused on my own current priorities.  While having these options would be good and at some point I plan to implement them one way or another, its still a lot of work just to compensate for GoDaddy imposed limitations vs just using a host that doesn't impose such limitations.

It would also require a signed contributor agreement.

Best,

Joe

Hi Chad,

Sounds good. Some of the existing email code in Email.cs is a bit messy because at one time we had an option to use DotNetOpenMail instead of the System.Net.Mail classes. I would implement it cleaner if I were doing it today but have been reluctant to remove some of the method names and signatures because it may break custom code that others have written against it.

I will give a little guidance on what I would like this to look like. I would implement the provider model and interfaces in the mojoPortal.Web project in a new folder at /Components/Email

I posted recently that I was thinking of moving the code from the mojoPortal.Net project, but again decided that would be too risky of breaking other people's code. But if we are going to have a provider model I would implement a new cleaner set of classes in the mojoPortal.Web project. Then after its working I'd be willing to make the changes in included features to use the new provider model. We can leave the existing stuff in the mojoPortal.Net project for backward compatibility with custom features but mark them as obsolete so that new development would be encouraged to use the new approach.

Best,

Joe