Access blocks
Access blocks refuse sign-up, sign-in and/or opening support tickets by who is asking. They cover Zappocity accounts and Mailocity mailboxes alike. Use them for a known bad actor: a throwaway email service, a network that keeps creating fake accounts, or someone who floods the help desk.
Find them in either admin panel under Settings → Access blocks, or with corpsuite access-block ....
What a rule matches
| Kind | Matches | Example |
|---|---|---|
| Email address | That address. A +tag is ignored, so amy+x@example.com is amy@example.com. | amy@example.com |
| Email domain | The address's domain and every domain under it. | spam.example |
| IP address or network | Where the request comes from. | 203.0.113.0/24, 2001:db8::/48 |
| AS number | The network (autonomous system) the IP address belongs to. | AS64500 |
| Country | The country of the IP address's network. | NL |
| Mail servers (MX) | The mail servers of the address's domain, and hosts under the name. This catches a throwaway service with many domains on the same servers. | mx.disposable.example |
| Name servers (NS) | The name servers of the address's domain, and hosts under the name. | ns1.bad-dns.example |
AS number and country rules need an IPNetDB file, set under Abuse protection. Without one they match nothing, and the page says so.
If a DNS lookup fails, the rule matches nothing. A block is meant to stop known bad actors, and a DNS outage elsewhere must not lock everyone out.
What a rule refuses
Tick any of the three:
- Sign-up: Zappocity account sign-up, Mailocity sign-up, team join pages and sign-up verification codes. Checked against the address (for Mailocity, the new mailbox's address, and the verification address when the code is sent by email) and the IP address.
- Sign-in:
- Zappocity accounts, by password, security key or passkey.
- Every mailbox sign-in: webmail, mail apps (IMAP, SMTP), ManageSieve, and calendars and contacts (CalDAV/CardDAV).
- Checked against the address signing in and the IP address.
- Sessions already open are not ended; suspend the account for that.
- Admin panel staff sign-in is never blocked, so a rule can't lock the staff out.
- New support tickets:
- Opening a request on the Zappocity account page or in webmail.
- Mail to a help desk queue that would open a ticket. Mail is checked by its sender's address only, since there is no IP address to check. Refused mail is filed under Not accepted.
- Replies on existing tickets still arrive.
People are told only that this is not allowed from where they are, not which rule refused them. A refused sign-in is answered like a locked account. It is recorded in the sign-in history as "blocked", and it does not count towards locking the account.
Ending, replacing and testing
- For how many days: the rule ends by itself after that. Empty means until you remove it.
- Adding a rule with the same kind and value replaces the old one.
- Hits counts how often a rule refused something; hover to see the last time.
- Test says whether an address or IP address would be refused, and by which rule. A match counts as a hit.
Changes take effect within 30 seconds on every server.
Command line and API
corpsuite access-block
corpsuite access-block add kind=mx value=mx.disposable.example 'applies:=["signup","tickets"]' note="Throwaway addresses"
corpsuite access-block add kind=ip value=203.0.113.0/24 'applies:=["signin"]' days:=30
corpsuite access-block test action=signup email=someone@disposable.example ip=203.0.113.9
corpsuite access-block remove IDIn the admin API: GET and POST /v1/access-blocks, DELETE /v1/access-blocks/{blockId} and POST /v1/access-blocks/test (settings permission to change them). See api/openapi.yaml.
Access blocks are separate from domain blocking, which refuses or files incoming mail, and from the reputation checks under Abuse protection, which score sign-ups.