Skip to main content

Licensing Blocklist

A license switches on lists, one by one​

There are no editions that decide anything by themselves: what a license carries is a set of features, and each public list and the mail-domain check has its own. The console's License page lists every feature with its code and whether it is Enabled here.

Capability, as the License page names itFeatureWhat it switches on
Licensed checks and the public listsblocklist-apiThe base: the installation is licensed at all. Every other feature needs it as well
Checking that a domain receives mailblocklist-mail-domainThe mail-domain check
Throwaway mail domains, kept up to dateblocklist-disposableDownloading disposable-email-domains, rather than relying on the copy built into the release
FakeFilter's throwaway mail domainsblocklist-fakefilterFakeFilter
Burner mail providersblocklist-burnerburner-email-providers
Hijacked network rangesits code is shown on the License pageThe hijacked network ranges list
Tor exit addressesblocklist-tor-exitsTor exit list

A list whose feature the license does not carry is not shown on the Blocklists and Maintenance pages, never downloaded and never checked against. The built-in list of throwaway domains is the one exception: it is always shown, and checked from the copy built into the release; see The built-in list.

A list feature without the base feature switches nothing on.

Nothing is refused for want of a license​

Every check answers on an unlicensed installation. POST /api/v1/check and POST /api/v1/check/batch return their answers with or without a license, and nothing on the service answers 403 because a feature is missing. An integration written against this service keeps running when a license lapses or lacks a list.

StateWhat the service does
Unlicensed (no license, or one that does not validate)Answers every check from your own entries, the deployment's and the built-in list of throwaway domains, with "unlicensed": true on every answer. Downloads no list and makes no mail-domain check. The dashboard and the License page say so
LicensedDownloads, refreshes and checks against every list the license carries, and makes the mail-domain check when it carries that
Lapsed (expired, removed, refused by the license server, or out of its check-in window)The same as unlicensed, from the moment the service sees it. See When a license lapses

GET /license reports the same: licensed, mode (direct, sponsored or unregistered), and features, one entry per feature with its name, its capability and whether it is granted.

Getting and keeping a license​

Where to buyantelao.io
Bound toOne host. A license is activated for the hardware challenge shown on the License page, which is why the compose file mounts /etc/machine-id: without it every recreated container looks like a different machine. A license bound to another machine is refused
ActivationOn the License page, Activate online with the license key and the e-mail address it was issued to, or Install a license file with the .lic file you were sent. A license file that has never been activated works for 14 days from the moment it is first seen, so the service runs while activation is arranged
Check-inThe service re-reads its license every hour, and checks in with the Antelao license server once a day and straight after a license is installed. It needs outbound internet access for that
When a check-in failsThe service keeps working on its last successful check-in for 14 days, unless the license states another period, and then runs unlicensed until a check-in gets through: it answers from your own entries and the built-in list only
Offline useNot available in the container. A license issued for a machine with no route to the license server needs attested TPM hardware, and the container has no TPM, so such a license is refused

Moving a license to another host​

A license runs on as many installations as it allows, one unless it says otherwise. The console has no move of its own: Remove on the License page deletes the license file on this host, and the installation keeps its place with the Antelao license server. Activating the license on another host while that place is taken is refused as already in use, so write to support@antelao.io with the license key to move it.

Recreating the container is not a move. With /etc/machine-id mounted, as in the compose file, a recreated container is the same machine and keeps its license.

Instead of a license of its own, the service can be licensed by an Odoo Host Manager license: that product offers its license to the service (POST /license/sponsor), and the service accepts it as proof that it is covered. The License page then says sponsored, and names the product it is sponsored through.

  • The sponsoring license decides list by list too. Its features say which lists and whether the mail-domain check this service may use, exactly as a license of its own would.
  • Only the Odoo Host Manager may sponsor this service. An offer from any other product is refused, and the License page shows the refusal with the product's name and when it was made.
  • A license of its own and a sponsorship can both be present. A feature then counts when either of them carries it, and the License page names the service's own license first.
  • A sponsorship is checked again on every use, so a sponsoring license that expires stops licensing this service by itself. A stored sponsorship that no longer grants anything is shown on the License page with the reason. DELETE /license/sponsor removes it.

What an unlicensed check returns​

POST /api/v1/check with {"email": "someone@discard.example", "ip": "203.0.113.7", "mailDomain": true} on an unlicensed service:

{
"listed": true,
"reason": "domain on disposable-email-domains",
"email": { "normalized": "someone@discard.example", "ownBlock": false },
"domain": {
"value": "discard.example",
"lists": ["disposable-email-domains"],
"ownBlock": false,
"mail": null
},
"ip": { "value": "203.0.113.7", "ownBlock": false, "lists": [] },
"unlicensed": true
}

The domain is held by the built-in copy of disposable-email-domains; no other public list is consulted, and mail is null because the mail-domain check is not made. A program reading the JSON never has to infer any of this: unlicensed says it.

When a license lapses​

A license that has ended - expired, removed, refused by the license server, or past its check-in window - is not bridged by anything further. From the moment the service sees it:

  • the lists it no longer covers disappear from the Blocklists and Maintenance pages, are not refreshed, and are not checked against;
  • the mail-domain check stops, and answers carry "mail": null;
  • every answer says "unlicensed": true once the base feature is gone.

Your own entries, the deployment's and the built-in list keep answering throughout, so a lapse never stops a form from getting answers. It only narrows what the answers are made of.

Managing the license​

On the console's License page, or through GET/POST/DELETE /license and POST /license/activate.

A license installed or activated on the License page or through the API applies at once. A license that arrives by restoring a backup archive is the exception: the restore writes it to the license directory and tells you to restart the container, and it takes effect then. Everything else in that archive applies at once.

Remove on the License page deletes the installed license files and drops back to unlicensed: every check goes on answering from your own entries and the built-in list, and the public lists are no longer downloaded or consulted.

The start-up log says how the service is licensed: by its own license, sponsored by the product that offered it (a sponsorship is kept on the volume and holds across restarts), or running unlicensed with the reason - a sponsorship that no longer holds, or the last offer that was refused.

An unlicensed start says so in one line, with the reason in brackets, and that your own entries and the built-in list keep working while the public lists and the mail-domain check require a license.