Sending channels – system description
Fields of the channel table, the provider whitelist, the connection check, the deletion rule and the gaps in content-scope checking.
Overview
Sending protocol and sender per client (and optionally per module); without a channel sending stops. Table names carry the installation's own prefix in the database; the table is mail_channel.
Fields and saving
- Permission:
canSave(channel, id); status changecanAction(edit). - Valid sender e-mail; provider from the whitelist (
ChannelModel::PROVIDERS); gmail and ms365 require an API account (error_api_account). - Fields: client, module, sender name, maximum attachment MB, hourly limit, SMTP host, port, user, password, encryption, timeout, send mode, delay, attempts, retry interval, sort order; newer columns are written with a column guard.
Other endpoints
clientchannels: the active channels of a client with content filtering; a warning when none exists (error_no_channel).channel.check:dlbtmail->checkChannel()per provider (gmail, ms365, smtp – host required, prefix for ssl –, mail). Permission:canAction(check).
Deletion
Permanent with delete and zero usage; otherwise status 9 with statusdelete; else error_in_use.
Permissions
Keys: list, add, edit, delete, statusdelete, check, debug; not classified in the seeds, in practice UNMAPPED.
Known limitations
The content scope of company_client_id is not checked on save.