I have the same situation as Brian described. What was the solution?

HEY CORE TEAM ! PLEASE READ --


OK, after lot's of troubleshooting we have narrowed down the issue and it looks like it might be a bug in the source code(though we have not looked at the code yet). We looked at the logs in the Exchange relay server and found that DNN is sending the sender's email address as 'admin@mycompany.com/sub' thus the reason for the 501 error message from the exchange server.

So it would appear that there is 4 issues here:

1) The host email account was NOT admin, however, DNN sent it to the Exchange server as admin. (when changing a user's roles)

2) Our DNN instance is located as a virtual directory and in the portal aliases it is entered as a virtual directory. However, DNN sends across the virtual directory name as part of the email. It should strip off any sub-directories, or see #3.

3) If you have multiple portal aliases, DNN picks the top Alias to send as the sender's email, It would seem that DNN should not be getting this value from the alias at all. Why doesn't DNN grab the value from the HTTP setting in the Host Settings Page?

4) If you delete the top alias (assuming more than one exists). Then do something that causes an email to be sent, it sends the deleted alias. Like it is cached somewhere.

To recreate this:

Create a DNN instance on a virtual directory of an IIS web site. Email address placed in the Host Setting Page is a valid email address, the SMTP is annoymous and has been verified via DOS. The email account is a know working account.

If you click the "Test" link, an email is sent correctly. If you try to send a copy of the DNN Log to user, it works. However, if you change the role of a user, the email fails with a 501 error (invalid sender address).

I have the exact same issue as Hiramk. About registring new users. If you have a user named Brian.Peal you can not create another user call Brian.Smith or you will get the errors Hiramk is discribing.

This is another show stopper for the corporate roll-out!

These post about this issue should be moved to a new thread though.

Brian ~

Quickly... the 'admin@mycompany.com/sub' email address is just the Host Email field on the Host Settings page. When DotNetNuke installs, it just creates a quick entry here based on information read during setup. That is an invalid email address though and a trivial bug that should be logged. You'll need to update your Host Email address as that must be a valid address on your SMTP server for any Host level email that is sent.

1) Haven't looked, but that does not sound surprising. You were probably logged in as Host when you updated the Portal users roles. It might be that these emails should always be sent using the official Portal Administrators email address. That sounds like a bug (unintended behavior) to me.

2) See my note above.

3) It SHOULD use either the Portal Administrators email address or the Host Email address, depending upon the scope of the email being sent... again, this sounds like unintended behavior to me.

4) Secondary problem that would be fixed by 3.

Thanks for the level of detail, its helpful in understanding what you are seeing. I'll be passing this on as appropriate.

Cheers,
Scott

Hey Scott,

Looks like I will have to eat crow :-)

I noticed a post on this thread about the admin account. Sure enough the email address in the admin account is admin@mycompany.com/sub

So this may discount everything I stated earlier. Or may not??

Either case, I changed the admin account email address. Then changed a role on a user and there was no errors logged in the DNN Logs. However, the receipant did not receive the email.

I just called my Exchange Administrator and we will look at the Exchange logs to see the next step.

Yes, I am doing all of this as the host, not admin. Do you recommend we do this testing as a normal user? I will update you with our findings. Happy Coding!

Logged: Issue #1028 & Issue #1029

After changing the admin user account from the defaulted admin@mycompany.com/sub to a valid email account and waiting about 1 hour the email works now.

We are guessing the 1 hour wait was due to pooling or caching on the IIS server? Not sure, could someone confirm?

Thanks,

Brian Peal

FYI for everyone testing your SMTP:

When you click the 'Test' link in the HOST SETTINGS page, you are sending email from the email address that is set in the Host Email Field.

When you authorize a user or change their roles, you are sending email from the administrator account you selected on the SITE SETTINGS page. By default, this is the user account called 'admin'. And by default, the email address of the admin account is 'admin@hostURL/virtualDirectory' OR 'admin@PortalAlias/virtualDirectory'. Not sure which one of these it is at the moment. Important thing is to verify the admin account's email address is the correct one!

Hope this helps others,

Brian Peal

First these issue are NOT due to the Host email address but the Portal Administrators Email address.

There may be some real issues in this behaviour, but the email address "admin@mycompany.com/sub" is the default administrator address for the alias mycompany.com/sub which is created automatically on portal creation if no admin email address is provided.

Note in the default install the Administrator is defined as:

<administrator>
<firstname>Administrator</firstname>
<lastname>Account</lastname>
<username>admin</username>
<password>admin</password>
<email></email>
</administrator>

so the auto-generated email address is created.

As Test works in Host Settings, there is nothing wrong with the SuperUser Account's email address. This also explains why sending a Log works (as this also uses the Host email account) .
However most messages (like changing a users role) are sent from the Portal Administrator accounts email address. This can be changed by logging in as admin/admin and clicking on the "Administrator Account" link and entering a valid email address for the Administrator.

I had tons of "Could not create CDO....". After googling a while I found just on hint. And that did exactly solve my problems. After regsvr32 cdosys.dll everything worked well. But I had the "Could not create" not the "Could not open" problem.

http://www.dotnet247.com/247reference/msgs/27/139389.aspx

But I agree with the core team: This is most likely a problem of the smtp config of the local machine.

THANK YOU....THANK YOU...THANK YOU I finally got this up running successfully but reading from the link below and using the regsvr32 cdosys.dll to register the cdosys.dll

From the link "http://www.dotnet247.com/247reference/msgs/27/139389.aspx"

 "Could not create 'CDO.Message' object" most likely means the CDO object is
not properly registered or installed or both. On my Win2k workstation,
checking the registry, the CDO.Message refers to the cdosys.dll located in
the win sys32 directory.

regsvr32 cdosys.dll

Thanks again

Hi!

I've read this thread to see if I could get my DNN-portal working when it comes to email, but I still get the message "Could not access CDO.Message Object".

In the smtp field of the host settings I've tried my ISP smtp relay server, localhost, my computername, 127.0.0.1 and my internal ip-number but nothing works. I've tried to re-register the CDO object as described above but that doesnt work either.

My setup is the following:

Im using a windows xp sp2 computer with MSDE sql server. I've configured the virtual smtp-server so that it works just fine sending email through outlook with just providing the computer name as outgoing server. What can be wrong, what more should I try?

Are the host and admin email addresses valid email addresses?

mikeh36 wrote:

Are the host and admin email addresses valid email addresses?

What is a valid adress, the adresses work fine but the accounts are not located on my server.

What I meant was with the default install of DNN on a system it'll set the admin address as something like admin@localhost/DotNetNuke which most email servers will reject but they'll accept admin@localhost.com. It sounds like yours are fine seeing as they work. Because they don't reside on your server I wonder if that might be part of the problem. More and more mailserver admins are locking down their servers to only allow emails from known usernames to pass through them so that their servers aren't being used as a spam relay.

Can you try this? Setup the DNN host email and admin email addresses with the email address your ISP gave you (the one you use for your regular correspondence). Then setup the SMTP settings to point to your ISP smtp server. That should work perfectly and will give us a better starting point for trying to get it to work.