Wholesale provider requirements...

5 views
Skip to first unread message

Rick Yazwinski (Principal Engineer - Tucows Inc.)

unread,
Sep 9, 2009, 11:32:39 AM9/9/09
to ISP Configuration Database
Hey Folks, super quiet group so let me try to seed some discussion.

At Tucows we sell wholesale email services. Completely whitelabel and
brandable for our customers needs.

It's be great if as part of our provisioning of a new customer we
could manage their data in the ispdb through a json call or some other
api.

Essentially we'd want to be able to add (or update) an entry and
eventually be able to delete that entry if the customer moved away
from us.

Will this be available in the new ispdb setup?

Ludovic Hirlimann

unread,
Sep 10, 2009, 12:38:09 PM9/10/09
to Rick Yazwinski, ISP Configuration Database
On 9/10/09 5:22 PM, Rick Yazwinski wrote:
There'd definitely need to be some SSL and some auth portion and
probably the concept of "owership" of entries.

Remove vs. change if/when a customer leaves: I'm assuming they don't
tell us the new data.   In fact, most situations the customer would
have to tell us the hostname's they've cname'd to our service anyhow
and these probably would never change, so it'd have to be up to the
customer whether to deprovision the ispdb or to update it (or just
leave it be) if they left us.

  

OUPS  I meant to have this conversation on the mailing list.

On Thu, Sep 10, 2009 at 10:44 AM, Ludovic Hirlimann
<ludovic....@gmail.com> wrote:
  
On 9/9/09 5:32 PM, Rick Yazwinski (Principal Engineer - Tucows Inc.) wrote:

Essentially we'd want to be able to add (or update) an entry and
eventually be able to delete that entry if the customer moved away
from us.

Will this be available in the new ispdb setup?


So for now I don't think we have plans for an API yet - The idea is
interesting and would probably be a very interesting idea to explore
specially on the security aspect. Ultimtely Mozilla messging will be
responsible for the users experience, what would happen if someone decide to
mass remove your entries via those API calls ? how could we ensure the
security of the data - make sure that someone doesn't changes the setting to
sniff passwords and logins.

For now I think that the worflow need human validation from the entries that
will be posted via the ispdb webpages. I do think the api idea interesting -
we just need to figure out rules.

Why would you remove the entry when the customer leaves ? and why wouldn't
you utpdate the settings to match it's new email provider ?

Ludo
--
Ludo
    


--
Ludo

David Ascher

unread,
Sep 17, 2009, 2:05:25 AM9/17/09
to ISP Configuration Database
On Sep 9, 8:32 am, "Rick Yazwinski (Principal Engineer - Tucows Inc.)"
<rick.yazwin...@gmail.com> wrote:
> Hey Folks, super quiet group so let me try to seed some discussion.

Thanks Rick, and sorry for being so late in answering.

> At Tucows we sell wholesale email services. Completely whitelabel and
> brandable for our customers needs.
>
> It's be great if as part of our provisioning of a new customer we
> could manage their data in the ispdb through a json call or some other
> api.
>
> Essentially we'd want to be able to add (or update) an entry and
> eventually be able to delete that entry if the customer moved away
> from us.
>
> Will this be available in the new ispdb setup?

As Ludovic said, our approach at first is going to focus on manual
steps, and making sure that the basics work. But I'd very much like
this system to scale to a long-tail of domains, and I expect that
facilitating cooperation with wholesalers such as yourselves would be
a good way to do that.

It'll take some crypto and API work, but in principle, as long as we
can get comfortable that the system is secure, it seems fine too.

Note that there are other possibilities which might be easier to do
from your perspective -- for example we've thought about doing a
variation of the exchange autodiscovery system, which, IIUC, means
that for a domain foo.com, we could do a query on autoconfig.foo.com
(or some variation) and get data there directly, w/o going through our
central DB. That has the advantage of being decentralized, but there
are technical challenges to doing that (DNS may not be secure enough,
DNSSEC isn't deployed enough, plain HTTP wouldn't be secure enough,
HTTPS is more work to setup, it might not even work for you if you
only handle MX records and not domains, etc. etc.).

--david
Reply all
Reply to author
Forward
0 new messages