Disabling local mail until the account creation e-mail is sent out

B

Bastille

Verified User
Joined
Mar 25, 2013
Messages
98
Is there a way to delay the handling of the anything related to e-mail for the domain until the account creation e-mail is sent out? Every now and then, we have users who are switching over to our hosting service and the information we pass into DA will use an e-mail address which is at their domain. The e-mail address will obviously exist at the old host but, once the account is created, DA will think it is handling all e-mail for the domain and attempt to send it locally.

Given the presence of the local mail toggle on the MX Records page, I presume the most straightforward solution would likely just involve switching it off and then on using user_create_pre/post.sh. Is that correct or is there an easier/better approach?
 
I don't know of any way you can do this because DirectAdmin, as part of the creation process DirectAdmin adds the domain name to the /etc/virtual/domains file, which is how exim knows if email should be delivered locally or not.

Perhaps DirectAdmin could be modified to send out the email before it creates the entry in the domains file. I've moved this thread and I've made it a Feature Request. However I'm not sure if there could be collateral damage.

Any comments on this from the community?

Jeff
 
Or add the ability to optionally use an external SMTP for these things, that way, you can rest assured they'll get sent
 
Adding that functionality would be a little messy/complicated... however, we strongly discourage the use of a local domain email for your "contact" info for the account.
The purpose of the contact email, is to contact clients when needed... like when the server is down, or their account is suspended, billing issues, etc..
If the E-Mail used is on the domain that is disabled, you won't be able to contact them.
That's the main reason I'm not really pushing to make the requested workaround into a feature.

John
 
As long as it's only strongly discouraged, rather than outright prevented, people will still do it. We just had one customer view it as too much work to set up another e-mail address besides the one at their domain. They had (perceived, at least) reasons to not want to use that e-mail address but, even though I suggested they create a Gmail address, they didn't wind up changing anything in the end. If a user won't do it for a more legitimate concern than being unable to notify them of hosting issues, it stands to reason most users would also ignore us putting forth a mere recommendation that they use a different e-mail.
 
Sending before creation would be a bad idea, as there are numerous reasons why creation would fail.

But, even if we had DA wait 1 minute before adding the domain to the /etc/virtual/domains file, there is nothing that says the email can't be sitting in the spool waiting to be delivered.
Any number of reasons could cause that.. and if there is a delay in sending, then DA might add the domain to the domains file before it's done sending, and the message would never arrive.
I think that would be unreliable and confusing if that event happened. E-Mail is allowed to be slow (grey-listing for one example)

The only real solution I can think of, would be to have DA notice the E-Mail domain is the same, and not add the domain to the /etc/virtual/domains file.
No cron or anything like that is used to add it later, but a user.conf tag like
Code: 
delayed_domains_addition=yes
could be set for the User.
A notice could be added by DA on the completed User creation message on the next page, telling the creator telling them what's up.

Then... upon the first login by the User (or creator with login-as), and if delayed_domains_addition is yes, only then would DA add it to the domains file, and then we're all on our merry way for normal usage.
The assumption is that since they've not yet logged in, no emails accounts are created yet, and possibly they shouldn't be receiving emails.
Also, they don't login until they get their welcome email, so we'll know they got it (assuming the creator doesn't mess it up all up by logging in straight away)

I'm still not a huge fan.. but it's probably what would satisfy all of the issues with it.

Let me know if that sounds good, and I can add it to the versions system for future implementation.

John
 
The majority of our users log in by means of a login key which is generated when they sign in to their primary account with us. As such, they generally log in quickly after their account is created. Would that qualify as logging in straight away?
 
If they got an email from the server, then it doesn't matter about any delays.. because the email to them was what they were waiting for.
Even if it's a different email from the welcome message, the whole point is to ensure they gain access to their accounts.. so if they've already received their login method, there is no longer any need for the delay.
Them logging in implies they got their access message, so DA can stop stalling, and can then add the domain to the /etc/virtual/domains file.

John
 
DirectAdmin Support said:
If they got an email from the server, then it doesn't matter about any delays.. because the email to them was what they were waiting for.
Even if it's a different email from the welcome message, the whole point is to ensure they gain access to their accounts.. so if they've already received their login method, there is no longer any need for the delay.
Them logging in implies they got their access message, so DA can stop stalling, and can then add the domain to the /etc/virtual/domains file.

John
Click to expand...
Will the login to the account from the reseller level to the user account also qualify as a user login? Many of our customers have no knowledge about hosting or DirectAdmin, we send them their login details but create their emailaddress(es) ourselves by logging in to the user account from our reseller level. If it doesn't qualify it means the customer will never receive their login details (if i understand correctly).
 
I would say any login would count as the trigger to add the domain to the domains file.
The "Login As" feature doesn't imply that the message got out, but the moment anyone logs into the account, they have the ability to create an E-Mail account.. and for that, the domain must be in the domains file.
The whole design is not perfect (which falls back to the whole idea of not allowing the contact email to contain the domain being used)... but I think this is probably a decent workaround.
If anyone else has suggestions or ideas, please share :)

John
 
For us, the process goes as follows:

1. In their account (which holds the domains they have registered with us), they select that they wish to activate hosting for their domain.
2. They're taken to a page which asks for the hosting plan they want for their domain.
2a. If the plan is not our free plan, they're taken to a payment page.
3. The hosting setup is processed.
4. Upon completion, they're taken to a page which tells them setup is complete and they are sent a receipt
5. The moment they select to return to the main page (or the hosting page), a login key is generated for their account
5a. If they select to "manage" the hosting for their domain, the login key is used and the DA hosting panel is launched in a new window.

It's possible for them to be logging in to their account as quickly as 10 seconds of its creation. This is a "worst" case scenario, timing-wise.
 
Just a guess, if you're using the DA API for create the account, why dont you create the email address aswell during creation?

Regards
 
SeLLeRoNe said:
Just a guess, if you're using the DA API for create the account, why dont you create the email address aswell during creation?

Regards
Click to expand...

Well, the e-mail wouldn't technically go to the customer then, would it? They'd get it eventually, once they went into the control panel, modified the password for the e-mail address to one they know, and then connected to it, but that could be a while still.
 
You must log in or register to reply here.
Back
Top