Hi Sebastian,

Just to be sure we're talking about the same thing... There are two issues regarding portal email addresses and smtp servers (and sorry for hijacking the thread like this):

One issue is that multi-portal DNN instances with multiple domains all have to use one email server to send emails. This causes emails to be tagged as spam because the sender address doesn't match the sending server in all but one of the portals. I'm not aware of any way to get around this right now, although there are one or two modules (e.g. Datasprings' Opt-in Email") that make the effort and provide per-module smtp settings as a workaround.

The other issue is that the sender address for portal emails currently has to belong to an account that is the assigned portal administrator, and that is inappropriate in a business environment.  All portals I run have business owners, and those businesses usually have a person assigned to deal with emails delivered by the portal and various modules, but that person is not supposed to be a DNN administrator because that is not their job; they are not the webmaster. More often than not, the person who deals with the emails is what we call a personal assistant or business admin and giving that person full control over the portal is out of the question.

I wrote up a gemini issue about it a while ago (and another one 2-3 years back) but Alex closed it stating that is was all either on the cards or should be discussed in the forums.

Do you think either of these things likely to be fixed up somewhere along the roadmap? All it really needs is per-portal smtp (as the originator of this thread requested) plus the ability to specify any user as the sender - not just the portal admin.

Rob

Upon reflection, I guess I more or less agree with Sebastian ... here's why ... modules really do need to allow "from" and "reply-to" options that default to but allow override default admin email address.

Since there can be many in the administrator role, the default admin role can be a non-person who never logs in or does anything - just primarily establishes the default portal email address to use. Though - in a way that's a questionable practice, too, requiring us to consider the default admin primarily from a "what email address do we want to use for system emails?" perspective rather than "who should be the default admin?" So I guess I can see it both ways.

Final analysis, it seems more intuitive and cleaner to have a sysadmin email value that is not related to default admin user, though it is workable enough as is.