create domain: chicken and egg problem

Submitted by aitte on Mon, 02/18/2013 - 00:42

when you create a domain, you have the option to set administrator email to either "administrator account" (same as the domain owner) or "other address".

imagine that we are adding example.com to our host, and that the admin account will be "example" and that the admin's primary email account will be "admin at example.com"

if you enter "administrator email: admin at example.com" during the domain creation, then you have a chicken and egg problem: the signup email cannot be sent out because the account does not exist yet

if you instead created it with "administrator email: administrator account (example)" and then edit the users for the domain to add "admin at example.com" and then edit the server to make the contact address "admin at example.com" then you end up with pretty much the correct behavior (all further "user has been created" / "here are your account details" type emails will be sent to the new mailbox) except that the signup email is still stored in the old "example" account's mailbox, and any auto-created "${EMAILTO}" mail aliases for the domain will have the incorrect address value since they were created before the change.

i propose this code:

if "administrator email == other address && other_address ends in the domain we are setting up (i.e. admin at example.com)" then create that user immediately after creating the domain, using default settings for email-only users (can always be edited later in "edit users") and then send the signup email to "admin at example.com" which now exists.

considering how awesomely modular virtualmin is, the code would probably be as simple as:

send_signup_email{
  if mailbox does not exist
    virtualmin -> createmailuser -> defaultsettings
  send email to recipient
}

only issue I can see is that the "create email user" function sends a details email to both the admin of the domain and to the newly created mailbox; and they'd be identical, so I guess two emails would be sent to the same mailbox (the admin address and the newly created address being the same), both saying "hey you got a new mailbox account, here are the details"

Status: 
Active

Comments

Submitted by JamieCameron on Mon, 02/18/2013 - 09:27

So in that case, what would the password of this extra automatically created user be? If it is the same as the domain owner, why not just use the default behavior of having the new domain email sent to the domain owners address (like example@example.com) ?

Submitted by aitte on Mon, 02/18/2013 - 10:17

the reason i uncovered this is that it's not a very smooth process currently:

create a server, leaving it on "administrator address"
create a new mailbox named "admin@example.com"
edit the server, setting the contact address to "admin@example.com"
edit all auto-created "${EMAILTO}" aliases, setting each individually to "admin@example.com"
manually move the email file from the administrator's inbox to the newly created inbox (via a unix
  file move)
give the person their email account's ("admin@example.com") login details so that they can log in
  and see their signup email with the main admin account's password etc listed, for SFTP/panel access.

smooth? not at all.

but you bring up a good question: what about the password. well, obviously we cannot do this automatically after all (i.e. no "detect that they're on the same domain and auto-create it" feature).

instead, i propose this:

contact address:
  administrator: uses the admin username (the default)
  new mailbox: lets the user type a [username]@example.com name and password and quota (the 3 most common 
     options; the rest can be changed with "edit user" later)
  other address: lets the user type "foo@bar.com" or "somesystemuser"

if they selected other address, do a tiny bit of sanity checking so that it's either a unix username
  or a completely different domain. if it ends in "@example.com" (the site we're setting up), then
  deny it and tell them to use the "new mailbox" radio button instead, since otherwise the mailbox
  won't exist yet.

Submitted by JamieCameron on Mon, 02/18/2013 - 12:04

I like the idea of preventing entering of an address in the domain being created - I'll add that.

However, adding a new section to the creation form for adding a new account seems overly complex to me. That form is already pretty large, and the new account can be added by the user after creating the domain if they wish.

Submitted by aitte on Mon, 02/18/2013 - 13:20

sure, the form is large, but you simply use javascript, so that if they tick the "new mailbox" radio button, they see 3 easy text fields appear (name, password, quota).

simply create that email account as soon as the server has been created, and just before the signup email will be sent out.

seriously, how often do admins use "virtualmin at virtualmin.com" (as an example)? i have never met a single admin that wanted that as their main email account on the domain. they all want something like "ricky at virtualmin.com".

in fact, it's bad for security to use the main sftp/shell username/password combo as a mailbox too, so even for my own domains, i make sure to set up a new mail-only user for all admin addresses.

there's a heck of a lot of steps to fix things after creating each domain and it's tiring. particularly the process of editing all email aliases to point to the new admin address.

in the interest of a smooth and polished product, this is one of those logical things (alternative admin address) that should "just work" and not require a lot of tedious extra steps.

Submitted by JamieCameron on Mon, 02/18/2013 - 19:26

I'll look into adding this when I get the chance, if I can keep the form simple.

By the way, there is already a field for setting a custom admin username, instead of using the default like example@example.com

Submitted by aitte on Mon, 02/18/2013 - 22:17

thanks, glad to hear that you are willing to consider it. you can still keep the form extremely simple with javascript:

    <radio name="emailto" value="newmailbox" onclick="document.getElementById('newmailbox_subform').style.display = 'block';" />New mailbox
    <div id="newmailbox_subform" style="display:hidden;">
      Username: <input type="text">@newdomain.com
      Password: <input type="text" value="random pre-created password as a suggestion">
      Quota: <input type="text"><select for MB, GB, etc>
    </div>

the above code is pretty much what you'd do, except there'd have to be a handler which shows it on checking the box and hides it on unchecking the box. i think you can insert a property-change handler on the main radio-button-group to be able to easily detect which box is the currently checked one. there is some sort of "onpropertychange" event, which is better to use than onclick. google will no doubt have full tutorials and solutions.

as for the alternative admin username, i'd be all for that except that it causes confusion, so i stick to username equaling the identifying part of main hosted domain.

makes sense: admin = greatwebsite, /home/greatwebsite/public_html = greatwebsite.com

does not make sense: admin = ricky, /home/ricky/public_html = greatwebsite.com

heck, if there was a way to only create the admin, and not create a default domain (no /home/ricky/public_html), and instead store every single hosted domain under "/home/ricky/domains", then I would be all for allowing any admin username. but with how the system works, it becomes too confusing to do that. ;)

i like the current system, and find it great as long as i enforce admin username consistency, and was just noting this as an aside.

Submitted by JamieCameron on Mon, 02/18/2013 - 22:36

You could do a setup something like that already, by creating a top-level "domain" with only a directory, unix user and webmin login enabled. All the actual websites are then created as sub-domains.

I agree that this is kind of a hack though, as it requires that a bogus domain name be created for the top-level server.