This project would integrate Cpanel, WHMCS, and the Enom module of WHMCS. The project has two phases:

1.

First, to enable the hosting company to sell individual mailboxes and forwarders within professional and vanity domains that it owns. (Sales pitch: "Why have an address like m_kramer_314@gmail.net when you have a name like Mark@Accordionist.org or Mary@DanceTherapist.com?")

Clients would have to be able to check the availability of the addresses they want, subscribe for periods of years, check expirations, receive renewal invoices automatically from WHMCS when due, renew, and log in to control their redirection destination (in the case of forwarders). (In the case of real POP mailboxes they would just use the host's webmail and/or their own client.)

When clients look at their product list, histories of WHMCS emails, and invoice histories in WHMCS, their forwarder-related stuff should be included.

The host would have to be able to specify reserved addresses within each domain; and manage these products and clients in WHMCS integrated along with their other clients and products. See all the purchased addresses, etc. to analyze what's popular, trends, etc.

The modified Enom and cpanel modules of WHMCS should do all the provisioning of the POP accounts and forwarders automatically, from a client's WHMCS control panel; so that the client has complete control over his particular forwarders, but no control over the domain.

The system would have to check to make sure that any domain was already registered for at least as long as the forwarding period being offered. (The hosting company intends to keep them all registered a full ten years out, to help sell the addresses by guaranteeing that your address won't change when you change your ISP, and so on.)

2.

In phase 2, the hosting company's domain registration customers could elect to earn money by making forwarders and mailboxes available within their domains. This would be ideal for domainers who are already earning PPC income from their sites, but earning nothing from their email addressing capability.

The hosting company would be handling all the sales, client management, billing, etc. The registrant and the hosting company would split the revenue, based on configuration settings within WHMCS.

In this case, the domain registrant would have to be able to log in to the WHMCS client support area and elect to make some domains available, and could maintain their own list of reserved addresses within each, and can review their income. BUT CAN NOT SEE THE CUSTOMER INFO of those using addresses within their domains; the host (and not the registrant) owns the customer relationship.

Perhaps the registrant should be able to set the prices individually for the addresses within their domains, or perhaps the host should control that globally for all the domains available. Not decided on that.

Once an address is sold, the registrant cannot have complete control over their own domain. There needs to be a lock on some Cpanel features, because the host must be able to guarantee delivery of the forwarding service it has sold, even if the registrant is flakey.

The registrant still has access to the features of cpanel that can't screw up the forwarding and POP accounts sold to others; and can amend the list of reserved addresses, and can provision any unsold forwarders and POP accounts for himself at no charge.

WHMCS would indicate how much the host should pay the registrant each month, just as it already does for the hosting affiliates program.

The domainer who makes his domain name available for sale of email forwarders, does not have to register the domain for years in advance until a forwarder is sold.

If the forwarding service that got sold was for longer than the domain's registration period, WHMCS should automatically renew the registration as needed, deducting the registration fees from the registrant's forwarding income.

My contact info:
support@trupod.com
Based on some email exchanges with programmers, I am posting some clarifications:

1.

In phase 1, the domains are already registered to the hosting company, which owns a large portfolio of names like TopTeachers.net, and DollCollectors.org, and DanceTherapist.com.

Prospective customers browse the list of domains and decide that they would like to control a virtual address (an email forwarder) in one (or more) of the domains -, or that they want to have a POP mailbox in one (or more) of them.

The prospective customer needs to check (via an SQL query against a table of already-sold addresses) to see if their-desired-name...at...the-desired-domain is still available. If so, they can subscribe to it for some period of years.

The host needs to provision the forwarder/mailbox without giving the customer control over the domain. Other customers will subscribe to other forwarders/mailboxes within the same domain! Each customer needs control over the forwarding destination of their subscriptions and no others.

(So we need additional new data table to contain all the sold addresses. I suppose it needs to be related to the domains product table and to the clients table, and to the orders and invoices in WHMCS.
Notice that in phase 2, one WHMCS client could buy a forwarder in a domain that is owned by another WHMCS client.)

2.

WHMCS is already being used to sell domains and webhosting, and to provide customer support ticketing system -, and for impromptu invoicing for hours for simple web site development projects.

Purchasers of these email forwarders might include existing domain & hosting customers-, and in phase 2, some of the domain customers are the source for the "mailbox product" I am selling.

So I think this would be easier to do through addons to WHMCS rather than a separate script from scratch. But if you can show me otherwise, I'm open to listening...

[-, = a semi-colon] BTW, am I the only person who thinks it's stupid that this website blocks semicolons? And that it blocks at-signs when appending descriptions to this FEATURED listing that already contains contact info?3.
Let's suppose one of my customers already logs into my WHMCS site to manage his domains, his account with me, order hosting options and upgrades, etc. Also suppose that he might also be an affiliate of mine, earning extra money via referrals to my hosting company on his website, and assume that he checks on that income stream also via my WHMCS site.

If I'm going to get that person to make addresses within his domains available for me to sell, wouldn't he expect to find it all summarized and managed in my WHMCS site, just like everything else? After all, shouldn't the mailbox income go to his account balance just like his referral income does, and be available to pay for his hosting with me? 4.
Curently the Linux host is running php 5.2.8 and MySQL 5.0.51a-community.

At the moment, the hosting company (me) is an Enom domain reseller, and a reseller of hosting provisioned at Hostgator (via WHM) and SiteGround (manual interface, no API available), and perhaps soon elsewhere as well.

WHMCS provisions new orders for domain registrations and hosting automatically, via Enom and Hostgator respectively.

All the domains for which I'd sell forwarders/mailboxes are (or will be) registered and managed (by WHMCS) via Enom's API.

All the mailbox provisioning is currently done manually via Cpanel 11.23.6-STABLE(x3 theme). My hosting customers do this for themselves, but if they let me list for sale some addresses in their domains, I need to take some controls away from them.
5.
No, the customer does not see a list of available addresses, only available domains. Within each domain, there is no list of addresses for sale.

There may be over a thousand domains available. The catalog must organize them by categories and subcategories. Those two levels should be enough.

The customer's "check availability" form should let them enter their first several choices of Name (e.g., Mike, Michael) and check off several choices of domain (e.g., HebrewTutor.org, TorahTutor.org).

Some might enter the names of different family members (Mike, Carol) at one suitable domain (GarciaFamily.com).

Anyway, the application should make all the combinations, and then query to find which are available.

The application must check the Cpanels of those domains (both mailboxes and forwarders) to avoid any names that already exist, and should check the exclude-list (maintained by the domain's registrant via a WHMCS client page that must be programmed as part of this project), and also check against a "global reservations list" (more about this below).

The customer is presented with a list of available addresses that can be ordered. He checks off the ones he wants, picks a radio button for each to specify if each is
a mailbox or a forwarder, and clicks the Place Order button to review the total invoice and enter initial destinations for the forwarders.

WHMCS needs to process the PayPal payment response just like it does now for domains and hosting, provision the forwarders, provision the mailboxes, and send an appropriate instructional welcome mail for forwarders and a welcome mail for mailboxes.

Provisioning the forwarders/mailboxes includes extending the registration periods of the domains, as needed to support the term of the sale, and invoicing the registrant as may be needed.

The Domain Management Screen of WHMCS needs to be modified (or replaced) by one that adds the options for the client to make his domain available for address-selling, and for specifying a reserved addresses list.

In addition, I want a screen where I can specify a global set of reserved names, that none of my domain registrants can accidentally leave available (like support-at, help-at, webmaster-at, expletive-at, and so on.

These forwarder/mailboxes need to show up in the buyer's product screens in WHMCS, and they need to be able to redirect their forwarders from there, and to specify autoresponder or other (usually cpanel) options, but for their one mailbox only.

Conversely, the domain registrants should be able to see screens of how many mailboxes and forwarders are sold in their domains, how much money they are earning from this, etc. And since you will see to it that they no longer have access to make mailboxes and forwarders themselves via Cpanel, you need to give them a way to do it in WHMCS. WHMCS should let them do it as long as nobody has ordered the address they now want. WHMCS won't care if the address is on my gloabel reserved list nor their reserved list. If they want it, they have it.

I need to see a screen where I can set a default pricing and default revenue share for the forwarders, and a default pricing and revenue share for the mailboxes. Also the term options for the mailboxes.

I also think it would be good to have similar fields on each client's details page, where I can override those prices and shares for all the domains made available by this client -- to negotiate special deals where needed.

Or would it be better to set up several bins, and assign domains indivually to each pricing/payouts bin. I don't know. You tell me what you think.
When a customer types in requested name(s) and some are NOT available, the application could suggest alternates (just like the domain name registering application does).

I would need to have a way of specifying for each domain some backup domain(s) to offer. In some cases these substitutes are not domains that were originally listed at all. So this is not the same as the usual "related products" function of shopping carts. For example: If ArmyVeterans.us starts running out of popular names, I would offer ArmyVets.us, but I don't want both in the published catalog at once.

The application should pre-check the availability of the name in the suggested substitute domains befor suggesting them.


An idea: Instead of letting the customer type in anything for an address, and then checking it against a global reserved list-, why not copy the free list of names from the census beaureau and use it as a product list. See http://www.census.gov/genealogy/names/names_files.html
Then the registrant only need to reserve a few things from that list, and I don't need a global list at all.