FoxBox Administration
and User Manual

1 Getting started

FoxBox connects applications and operators to an SMS gateway. This manual explains how to configure the Ubuntu network, administer the FoxBox web application, manage contacts, send and receive messages, operate campaigns, and connect email systems through mailbox polling or Postfix. It is intended for appliance administrators, messaging operators and system integrators.

Start with the network chapter when commissioning a new appliance. Operators can begin with the dashboard and sending chapters. Administrators should also read account configuration, inbound routing, email integration, backup and troubleshooting before enabling automated traffic.

The example web credentials for this manual are username admin and password foxbox. These are the requested documentation credentials; they do not represent the password of the reference website. Ubuntu, the web console, the database, the mail account, the API token and the email-to-SMS PIN are separate credentials. Do not assume that admin / foxbox authenticates to those services.

Open the appliance HTTPS address in a browser. The reference interface is https://sms.foxbox.it/index.php?app=main&inc=core_welcome. After login, verify the displayed account and credit balance before composing a message. Use Logout when leaving a shared workstation.

Screenshots show the reference website. Counts, dates, account names and example values are snapshots, not recommended production settings. Menu visibility depends on account permissions and the installed modules. All configuration examples use illustrative addresses and must be adapted to the target appliance.

System components

- Ubuntu provides network interfaces, DNS, time synchronisation, host services and device access.

- The FoxBox web application provides accounts, contacts, sending tools, routing, reporting and integration settings.

- Background workers process queues, scheduled work and enabled mailbox polling.

- The selected SMS gateway, such as Kannel, connects the application to the modem or an upstream SMS service.

- SMTP sends email; IMAP or POP3 reads a mailbox. These are different protocols and normally use different ports.

Commissioning sequence

1. Record the interface name, management IP, subnet, default gateway, DNS servers and hostname.

2. Configure and verify Ubuntu networking from a local console.

3. Check web access, server time, modem registration and gateway configuration.

4. Configure operator accounts, credits and the correct default SMSC.

5. Add one controlled test recipient and verify outbound SMS and inbound routing.

6. Configure the required email integration and trace a test through every stage.

7. Back up the working configuration and record the resulting service and device names.

2 Ubuntu network configuration from the console

Use a local keyboard and display, hypervisor console or other independent console for the first network change. An SSH session and the web console can disconnect when their network address changes. The FoxBox web account is not an Ubuntu account; log in with the operating-system user supplied for the appliance and use sudo when required.

Inspect the existing configuration

Run these read-only commands on the Ubuntu appliance, not on an administrator's laptop. Record the current output before editing anything.

cat /etc/os-release
hostnamectl
ip -br link
ip -br address
ip route
resolvectl status
ls -l /etc/netplan/
sudo netplan get
systemctl is-active systemd-networkd NetworkManager

Interface names vary: examples include enp1s0, ens18 and eth0. Identify the connected interface from its link state and current address. Netplan merges YAML files, so inspect the existing files and modify the configuration that already owns the interface. Do not blindly add a second, conflicting definition. Cloud images may generate network settings through cloud-init; preserve the appliance's management method.

Back up before changing an address

sudo cp -a /etc/netplan /root/netplan-before-foxbox
sudo netplan get

Use a unique backup directory if that name already exists. Obtain an unused address or a DHCP reservation from the network administrator. In the following example, enp1s0 is the interface, 192.168.10.50/24 is the appliance address, 192.168.10.1 is the router, and 192.168.10.10 and 192.168.10.11 are internal DNS servers.

Static IPv4 example

Edit the existing YAML file with sudoedit. For a new installation without a competing interface definition, a descriptive filename such as /etc/netplan/60-foxbox.yaml is suitable. YAML indentation uses spaces, never tabs.

network:
  version: 2
  renderer: networkd
  ethernets:
    enp1s0:
      dhcp4: false
      addresses:
        - 192.168.10.50/24
      routes:
        - to: default
          via: 192.168.10.1
      nameservers:
        addresses:
          - 192.168.10.10
          - 192.168.10.11
        search:
          - example.org

Keep the existing renderer if the appliance uses NetworkManager. This IPv4 example does not prescribe an IPv6 policy; retain or configure IPv6 according to the deployment. With multiple interfaces, avoid unintentionally adding competing default routes. See the official Netplan static-address guide in the references.

Validate and apply with rollback

sudo chmod 600 /etc/netplan/60-foxbox.yaml
sudo netplan generate
sudo netplan try --timeout 120

Substitute the actual edited filename. Resolve YAML errors before proceeding. During the trial, verify reachability from another machine and accept the configuration at the console only when checks pass. Netplan try can roll back an unconfirmed change, but rollback has documented limitations; verify the resulting address and on-disk configuration after a timeout. Keep console access available. Use netplan apply only when deliberately applying the validated configuration.

DHCP example

For an interface that should obtain an IPv4 lease, replace its static-address, route and DNS settings with an appropriate DHCP definition. Do not leave the old static settings underneath it.

network:
  version: 2
  renderer: networkd
  ethernets:
    enp1s0:
      dhcp4: true

Use a DHCP reservation when other systems must consistently reach the appliance. After applying, inspect ip -br address and the DHCP server's lease table. The web address can change if the lease is not reserved.

Verify the complete network path

ip -br address
ip route get 192.168.10.10
ping -c 3 192.168.10.1
resolvectl query mail.example.org
curl -I https://foxbox.example.org/
timedatectl status
sudo ss -lntp

A successful gateway ping checks only part of the path; some networks also block ICMP. Verify DNS separately and test the actual HTTPS and mail endpoints. The HTTPS name must match the certificate. Correct time matters for certificates, scheduled messages and log correlation. Changing the appliance IP can also require updates to DNS records, upstream mail connectors, API clients, reverse proxies and gateway callback URLs.

NetworkManager managed appliances

When the installed appliance is managed through NetworkManager, inspect the active connection profile before choosing the configuration method.

nmcli device status
nmcli connection show
nmcli connection show --active

Retain the established Netplan and NetworkManager integration instead of configuring the same interface through competing tools. A console administrator should know the current connection profile and a rollback method before activating a changed profile.

Ports and access paths

Permit only the paths the deployment uses. In particular, a mail gateway should accept SMTP only from the intended upstream relays. Do not expose the database or internal Kannel administration ports as ordinary public web services.

Recover from a failed change

At the local console, inspect ip -br address, ip route and netplan get. Compare the active YAML with the backup. Restore the original edited files and remove only the new conflicting file introduced by the change, if any. Run netplan generate, then netplan apply. Recheck the address, route, DNS and HTTPS access before resuming application commissioning.

3 Dashboard and navigation

The Dashboard is the operational starting point. It displays modem registration, signal level, shortcuts to text campaigns and the phonebook, a Quick Send SMS form, SMS counters and recent campaigns. The embedded BI panel provides a separate analytical view.

Before sending, check that the modem is connected and registered to the expected operator. Registration and signal strength are useful health indicators, but neither proves that a message has reached a handset. Use outgoing reports and delivery receipts for that.

The sidebar contains Configuration, Settings, Incoming SMS, Contacts, Send SMS, Features, Reports and LOGS. The Administrator menu also provides Profile, My email to SMS and Schedule messages. Some report labels lead to the same underlying page; always read the page heading and account scope.

The account selector supports delegated account operation where permitted. Confirm the effective account before opening contacts or sending. Credit, contact groups and API permissions belong to an account, so changing account context can change what is available.

4 Send an SMS

Open Send SMS > Send SMS for the full composer. The dashboard Quick Send form is a shorter route for an immediate message.

1. Enter a mobile number with its international country code, select a saved contact, or enter # followed by a phonebook group code such as #OPS.

2. Review the resolved recipients. A group can expand to multiple billable sends.

3. Choose an available Sender ID if applicable to the gateway.

4. Write the message and any footer. The full composer supports contact placeholders such as #NAME# and #NUM#.

5. Review the character counter and Unicode or Flash options.

6. Set the intended date and time when scheduling is required. Check the account timezone.

7. Select Send only after reviewing recipients, content and timing. Open Outgoing messages to follow processing and delivery status.

A sender ID is a requested identity, not a guarantee that a mobile operator will display it. A physical SIM often sends using its assigned mobile number. Flash-message handling also depends on the receiving device and network. Use Unicode for characters outside the supported GSM alphabet, and test the actual text and gateway.

The character counter estimates message segmentation. Footers, substitutions, extended GSM characters and Unicode can affect the number of segments. The configured Maximum SMS count can restrict message length. Application credits are separate from SIM balance, operator billing and delivery confirmation.

5 Campaigns Wizard

Open Send SMS > Campaigns Wizard to see campaigns and their statuses. The interface exposes All, Draft, Scheduled, In Progress, Completed and Failed views. Use the campaign title and owner to distinguish jobs before opening their details.

Create a campaign

1. Start a new campaign and enter a descriptive title in Definition.

2. Select the appropriate country. Review available credits.

3. Use Contacts to choose lists or individual contacts, upload a list, or add a contact as offered by the wizard.

4. At Message, enter the SMS text, sender ID and footer. Review Flash and Unicode options.

5. Choose Immediate or Planned. Planned mode exposes start and end dates.

6. Use Save Draft when available to preserve unfinished preparation. The final Send action submits the campaign for processing.

Do not assume that a completed campaign means every handset received an SMS. Compare campaign counts with the outgoing-message records and DLRs. Before resubmitting a failed job, identify which destinations already succeeded to avoid duplicate delivery.

Review and edit existing campaigns

Open an existing campaign from the list to inspect the available editing view. Review the complete message and recipients before saving or sending again. Treat the currently displayed fields as the source of truth; do not infer that a form is prefilled simply because an existing record was opened. Scheduled work depends on the background processing services and server time.

6 Send from a file

Send SMS > Send From File accepts CSV or XLSX. The page specifies columns in this order: destination number, message, username. This is different from the Phonebook Import format.

Prepare mobile numbers as text so spreadsheet software does not remove a leading plus sign or convert long numbers to scientific notation. Save CSV as UTF-8. Quote messages containing commas or quotation marks using standard CSV escaping. Use a small test file before a production import and inspect the resulting recipients and account assignments.

393000000001,"Maintenance starts at 18:00",admin
393000000002,"Maintenance starts at 18:00",admin

The numbers above are placeholders, not test destinations. Replace them with controlled recipients. Choose the file and select Upload file. Review the reported valid and invalid entries and available credit before proceeding to sending; uploading is not evidence of final handset delivery.

The local parser reads comma-separated rows directly and removes duplicate destination entries within an upload. Use data rows without a header for this path. For administrators, a valid username in the third column selects the sending account; a missing or unrecognised username falls back to the current account. Non-administrators send as the current account. Verify that account assignment is correct before submitting. XLSX uses the first worksheet in this implementation; use CSV if conversion validation fails.

7 Phonebook contacts

Contacts > Phonebook provides searchable contacts and shortcuts for groups, import, export, reminders and adding a record. A contact stores a name, mobile number, email, group membership and tags. The contact form also supports birthday or reminder data.

1. Select Add and enter a recognisable name.

2. Enter the mobile number with the international country code and an email address if needed.

3. Select the appropriate group. Group codes are used by the SMS composer and integrations.

4. Add comma-separated tags and any extra tag field required by the deployment.

5. Configure birthday or reminder options if applicable, then save.

6. Search for the saved record and verify the number and group before using it in a campaign.

Editing a group member can change the recipients of a future group send. Establish the correct account ownership before importing or maintaining contacts. Use Export for a portable copy, and protect it as contact data.

8 Groups and contact imports

Phonebook groups

Open the Groups action in Phonebook. Define a name and a stable group code. The composer addresses a group with a leading #, for example #OPS. A group belongs to an account context; an API integration must use an account that can resolve that group.

The group list shows its name, code, creation time and whether it originated from a file. Available actions include filtering contacts, editing and opening an SMS composer for the group. Review membership before sending to the entire group.

Import contacts

Phonebook Import accepts XLSX or CSV and displays the format Name, Mobile, Email, Group code, Tags. Keep the file layout distinct from Send From File, whose rows contain messages. Use a small sample to confirm how the installed version treats headers, existing contacts, group codes and tags before importing a large dataset.

Operations One,393000000001,[email protected],OPS,on-call
Operations Two,393000000002,[email protected],OPS,engineering

After importing, search for several records and confirm that numbers, accented characters and groups survived correctly. A successful import does not by itself establish consent, deduplicate all logical contacts or validate that a number can receive SMS.

9 Reminders and scheduled messages

Contact reminders

The contact form offers Recurring every year or Single reminder, an event date, and an offset in days. An offset of zero means the event date; a positive value requests an earlier notification. User configuration also exposes Enable Reminder, an offset and reminder text.

Check the resulting calendar under the Phonebook schedule action. It distinguishes event dates from reminder send dates and also shows scheduled SMS or campaigns where supported. Use month or list view and the date navigation buttons to inspect the intended period.

Repeating message schedules

The user menu > Schedule messages provides named scheduled-message definitions. Add a schedule, enter the text, and select Once, Annually, Monthly, Weekly or Daily. Open Manage schedule to maintain its List of destinations. Add a destination with a name, number and Schedule in YYYY-MM-DD hh:mm format. The form offers comma-separated destinations; use individual rows when separate names or execution dates are needed. Review the resulting destination list before operational use.

Repeating schedules, contact reminders and a one-off scheduled send are distinct workflows. Check the actual next occurrence and timezone rather than assuming the date displayed in one workflow controls another.

10 Incoming SMS and the sandbox

Incoming SMS opens the sandbox report. Use it to inspect inbound messages, including the sender, receiver, message text and time. The Sandbox link in Reports leads to the same route on the reference site.

An inbound SMS can be handled by a feature keyword or routing rule before it appears in a personal inbox. When investigating an apparently missing message, compare the sandbox with All feature messages, the target user's inbox settings and the gateway's incoming callback. A message visible in the sandbox has not necessarily been delivered to every configured email recipient.

Filtering and row actions depend on the report. Inspect the available actions carefully: a reply or reprocessing action may trigger new traffic, and Delete removes history. Use the record's timestamp and sender to correlate it with external systems.

11 Blacklist

Contacts > Blacklist manages numbers that must be excluded according to the application's stoplist behaviour. Search existing entries before adding another. Use the installed form to add or remove entries, then verify enforcement through the actual sending path in a controlled test.

A blacklist, a subscription cancellation and membership removal are different controls. For an opt-out process, identify which sending tools use each control and confirm that manual sending, campaigns and API integrations respect the intended restriction. Do not assume that every external gateway enforces the web application's list.

12 User profile and account configuration

Profile

The user menu > Profile opens Preferences. Login information includes name, password confirmation, email and mobile. Personal information includes address and location fields. The email and mobile are operational inputs for message forwarding, so keep them accurate.

To change a password, enter the intended replacement and matching confirmation through the account's normal process. Leave password fields untouched when only editing other details. The manual's admin / foxbox example is not a request to reset the reference account.

User configuration

Settings > User configuration contains account-level application settings. Review ACL, credit, Unicode billing, default sender, default SMSC, webservices access, API IP range, language, timezone, forwarding choices, number normalisation and reminders.

Enable webservices only for accounts used by an integration, then obtain the account's current token through the supported mechanism. Restrict its IP range to the actual calling systems where practical. Use the configured IP-range syntax; do not assume the field accepts every firewall or CIDR notation.

Forward message to inbox, Forward message to email and Forward message to mobile are independent options. Enabling email forwarding also requires a valid profile email, a working outgoing mail configuration and a route that delivers the received message to this user's inbox processing.

13 Manage accounts and credits

Accounts

Settings > Manage account separates Administrators, Users and Subusers. Select the appropriate view, then Add User. Supply the identity, account details and parent relationship required by the form. Configure the new account's ACL, credit and permitted sending route before handing it to an operator.

An administrator has broader application visibility. A subuser operates within a parent relationship. The reference UI exposes these named categories; do not use an undocumented numeric role mapping to assign access. Test the resulting account view before operational use.

Credits

Settings > Manage credit shows transactions and available management actions. Search by the offered fields, record adjustments with a useful reference, and verify the target account and balance. An application's credit balance does not replace the mobile operator's SIM or service balance.

Unicode settings and message segmentation can affect consumption. When an account cannot send, check credit together with account state, ACL, destination validity, gateway routing and the sending limits.

14 Sender IDs and message templates

Sender IDs

Settings > Sender ID lists configured identities. Add or edit a sender using the available actions, then assign or select it for the account or composer. Reusing the same visible label across several records can make selection ambiguous, so keep the catalogue deliberate.

The permitted sender format and what the recipient actually sees depend on the selected gateway and operator. Validate it on a controlled handset. Configuring an alphanumeric sender in the web UI does not override a SIM's physical sending identity.

Message templates

Settings > Message templates stores reusable message text. Give templates descriptive names, verify their content and reuse them in the sending tools that expose template selection. After inserting one, review the final text, substitutions, footer and character count.

Templates reduce repeated typing but do not automatically approve recipients or prevent outdated content. Check dates, contact details and any placeholders each time the template is used.

15 Main configuration

Configuration > Main configuration controls installation-wide defaults. Record existing values before editing and verify the impact on a test account. A default can coexist with account-specific overrides.

Default settings

The default-settings tab includes sender ID, timezone, username length, SMS rate, maximum SMS count, low-credit notification threshold, hourly sending limit, SMSC, country prefix, plus-sign handling, Unicode credit behaviour, brute-force detection and keyword separator.

Choose a reachable operational SMSC. Avoid changing number-prefix rules while a campaign is being prepared; the resulting destination may differ from what an operator entered. Timezone fields use the format expected by this application, which may be a fixed offset rather than an automatically adjusting regional timezone. Verify schedules across daylight-saving changes.

Default site configuration

This tab defines the website title and email, forwarded-email footer, main website name and URL, registration defaults, parent and ACL defaults, initial credit, public registration, password recovery, subuser privacy and branding options.

Set Website email to an address the outgoing mail system permits. Public registration and default credit have operational consequences: configure them intentionally. Keep the logo URL reachable by browsers and verify the login and information pages after a branding change.

Information page

The information tab provides a title and a rich-text editor for the site's information content. Review formatting, links and images before saving. This content is distinct from the application version and from the gateway configuration.

16 LDAP authentication

The LDAP tab supports enabling directory authentication, server and port, encryption, bind DN and password, base DN, user search filter, attribute mapping, a default email domain and automatic user creation. A test username and password are provided for the connection test.

1. Obtain the directory server, TLS mode, search base and filter from the directory administrator.

2. Use a bind identity with the required directory-read permissions.

3. Map the name, email and mobile attributes to the correct directory attributes.

4. Test with a dedicated account and inspect the returned result.

5. Decide whether automatic creation is appropriate, then verify the resulting account defaults and access.

6. Retain a documented local administrative recovery method before relying on directory login.

The test control checks the configured integration; it does not prove every user's membership, attribute or permission mapping is correct. Do not copy the empty or zero-valued demonstration fields as production LDAP settings.

17 Gateways and SMSCs

Configuration > Manage gateway and SMSC lists gateway modules and SMSC management. The reference installation lists blocked, dev, generic, kannel and smstools. A gateway is the integration driver; an SMSC is a configured sending route using a driver.

The blocked and development routes should not be treated as evidence of real mobile delivery. Generic and SMS Server Tools deployments require their own corresponding backend configuration. Select the route appropriate to the appliance rather than changing drivers only to make a test appear successful.

Kannel configuration

The Kannel management page includes the gateway username and password, module sender ID and timezone, Bearerbox host, sendsms host and port, DLR mask, additional URL parameters, Highwayweb URL, optional custom DLR URL and incoming-time interpretation.

Match these values to the installed Kannel configuration. The sendsms endpoint must be reachable from the application runtime. The Highwayweb and DLR URLs must be reachable from the gateway runtime. In a container deployment, 127.0.0.1 refers to the current container or host namespace, not automatically the other component.

Do not expose the gateway password in screenshots, tickets or URLs shared with operators. After a configuration change, test one outbound SMS and one inbound SMS, and inspect whether the corresponding delivery update returns to FoxBox.

18 Modem status

LOGS > MODEM status provides the modem snapshot, registration, operator, signal and LTE-cell details exposed by the installation. Use it to distinguish a web-application problem from a disconnected or unregistered mobile device.

Check the expected SIM and operator, registration state and signal. Compare the snapshot time with the current time before relying on the values. A stale snapshot can appear healthy even when a background collector has stopped.

If sending fails, check the SIM's ability to send, carrier restrictions and gateway logs as well as signal strength. Record timestamps and message IDs before restarting services, so useful diagnostic context is not lost.

19 SMS to email

The standard user-forwarding path is: incoming SMS > gateway callback > FoxBox inbound routing > target user inbox processing > outgoing mail service > the user's profile email. It is not a blanket guarantee that every raw modem message is emailed to the administrator.

Configure account forwarding

1. In Profile, set the destination email for the account that should receive the SMS.

2. In User configuration, set Forward message to email to yes. Enable inbox forwarding too when operators need a web copy.

3. Ensure the incoming routing or Group inbox feature actually delivers the message to that account.

4. In Main configuration > Default site configuration, set the website email and forwarded-email footer.

5. Configure the outgoing SMTP transport in the application runtime.

6. Send a controlled inbound SMS and trace it through the modem, incoming report, user delivery and recipient mailbox.

The standard forwarded subject begins with Message from and the sender identity. The body includes the website title, receiving number, reception time, sender, SMS text and configured footer. A log line indicating that the forwarding code ran is not proof of mailbox delivery; check the outgoing mail result and the destination mailbox.

Outgoing SMTP settings

The local sendmail implementation uses SMTP host, port, username and password, with configuration constants such as _SMTP_HOST_, _SMTP_PORT_, _SMTP_USER_ and _SMTP_PASS_ as fallbacks. This code also falls back to the mailsms server settings in some cases. That coupling must be checked when configuring mailbox polling: an IMAP server on port 993 is not an SMTP submission service.

Confirm where the installed image defines the SMTP constants and how it persists configuration before editing. Use a relay compatible with the application's mail library. Do not assume that selecting Use SSL in the incoming mailbox page also configures SMTP STARTTLS or implicit SMTP TLS.

Troubleshooting forwarding

- SMS absent from incoming records: check the modem, Kannel callback and inbound route first.

- SMS present but no email attempt: confirm the target user's profile email and forwarding flag, and whether a feature consumed the message.

- SMTP connection failure: check DNS, runtime network access, host, port and the library's supported encryption mode.

- SMTP accepts but mailbox remains empty: inspect relay logs, quarantine, recipient address and delivery policy.

- Repeated copies: inspect overlapping routes and prevent email-to-SMS and SMS-to-email loops.

For a keyword-specific board forwarding address, see SMS board. For SIM-to-phonebook-group email routing, see the optional package appendix; it is a separate extension.

20 Email to SMS using mailbox polling

Settings > Manage email to SMS configures a mailbox polled by the FoxBox background service. The administrator supplies the receiving email address, fetch enablement and interval, sender-check option, IMAP or POP3 protocol, SSL and certificate-validation options, server, port and mailbox credentials.

1. Provision a dedicated mailbox for SMS requests.

2. Enter its real server and protocol-specific port. Typical encrypted ports are 993 for IMAP and 995 for POP3; use the provider's values. The reference screen's 443 is not a general IMAP or POP3 default.

3. Enable SSL when required and keep certificate validation enabled with a trusted certificate.

4. Set a fetch interval greater than 10 seconds; 60 seconds is a practical starting value supported by the form.

5. Configure the user PIN under My email to SMS.

6. Enable fetching, verify that the background service and PHP mailbox extension are available, then perform a controlled test.

User PIN and message format

Open the user menu > My email to SMS to view the receiving address and configure the PIN. This PIN is separate from the web password and the API token. Use a dedicated PIN in real deployments.

The code parses the email subject as username, PIN and SMS text. The body contains comma-separated destination numbers. The optional @ prefix on the username is removed. The example below uses an illustrative PIN; replace it with the user's actual configured PIN.

To: [email protected]
From: Operations <[email protected]>
Subject: admin 482731 UPS alarm in server room
Content-Type: text/plain; charset=UTF-8

393000000001,393000000002

The resulting SMS text is UPS alarm in server room. The subject's first two items are credentials, not part of the SMS. Keep requests simple and plain-text, without HTML signatures or attachments. The implementation fetches unseen messages and reads the first body part; complex MIME and encoded body content require explicit testing. It strips a conventional signature separator when parsing recipients.

When Check email sender is enabled, the implementation compares the account email with an address extracted from the From header. Test the exact sender-header format, including Name <address> formatting. A matching From header alone is not strong sender authentication; enforce trusted mail submission upstream.

Expected result and failure checks

Allow for the fetch interval and SMS queue processing time. Check the account's outgoing report, then final delivery status. If nothing appears, verify unseen mailbox state, protocol and authentication, username and PIN, sender checking, recipient format and available credit. Do not repeatedly resend the same email without first checking the queue.

21 Email to SMS with Postfix

The repository also supplies a host-level SMTP path in scripts_mail. It is independent of the web mailbox-polling module:

Approved mail relay
  -> Postfix SMTP recipient routing
  -> local mail user and Procmail
  -> email-to-foxbox.sh
  -> HTTPS API op=pv
  -> FoxBox queue and SMS gateway

Procmail also archives the original email in Maildir.

In the base scripts_mail implementation, all accepted mail routes to the local nas account and SMS recipients come from /etc/foxbox-numbers.txt. The script takes the first five body lines, joins non-empty content and limits it to FOXBOX_MAX_LENGTH, whose default is 765. It does not use the web module's username/PIN subject syntax, and it does not choose a mobile number from the email recipient address.

Choose the correct integration mode

Choose one receiving path for each mailbox or route. Running multiple consumers against the same message stream can generate duplicate SMS.

Installation preparation

Use a dedicated gateway host or a reviewed appliance configuration. The supplied installer changes Postfix, Dovecot, Procmail, Fetchmail and logging, and the repository package contains deployment-specific domains, API defaults and mail-account credentials. Review and replace these values before running it elsewhere. Do not distribute the original embedded credentials as customer defaults.

Prepare the appliance API URL, a dedicated FoxBox API account and token, the approved SMTP source addresses, a receiving mail domain, a local mail account and a numbers file. Verify that the API account has webservices enabled, a usable SMSC and sufficient credit.

The following installation commands are a procedure for the target appliance. They are not required on the workstation used to read this manual.

# Copy the reviewed package to the target appliance.
scp -r scripts_mail [email protected]:/home/ubuntu/
ssh [email protected]
sudo /home/ubuntu/scripts_mail/install-email-to-foxbox.sh

The installer creates timestamped backups under /root/email-to-foxbox-backup-*. Its API account and token-handling logic must be adapted to the deployment; do not assume admin / foxbox is an API account/token pair. Validate the resulting settings rather than treating installer completion as proof of delivery.

Core Postfix configuration

The following is an illustrative local-delivery configuration for a dedicated mail-to-SMS appliance. Merge it with the reviewed installation; do not replace an existing corporate mail server configuration wholesale.

myhostname = foxbox.example.org
mydestination = $myhostname, localhost.$mydomain, localhost
inet_interfaces = all
inet_protocols = all
mynetworks = 127.0.0.0/8, [::1]/128
virtual_alias_domains = hash:/etc/postfix/virtual_domains
virtual_alias_maps = hash:/etc/postfix/virtual
mailbox_command = /usr/bin/procmail -a "$EXTENSION"
smtpd_relay_restrictions = permit_mynetworks, reject_unauth_destination

Do not list the same receiving domain in both mydestination and virtual_alias_domains. For a virtual domain, define the accepted domain and route its recipients to the actual local mail user. Prefer exact addresses when only a small set of alert destinations is needed.

# /etc/postfix/virtual_domains
sms.example.org OK

# /etc/postfix/virtual
[email protected] [email protected]

A catch-all entry such as @sms.example.org routes every address in that domain. Use it only when this is the intended behaviour. The base package uses catch-all domain maps and a fixed recipient list; all such accepted messages can therefore trigger SMS to the same numbers.

sudo postmap /etc/postfix/virtual_domains
sudo postmap /etc/postfix/virtual
sudo postfix check
sudo systemctl reload postfix
sudo postmap -q sms.example.org hash:/etc/postfix/virtual_domains
sudo postmap -q [email protected] hash:/etc/postfix/virtual

The map files must be rebuilt after edits. Confirm that the final local address resolves to the intended local account. Configure the upstream mail server to route the dedicated SMS domain to the appliance on TCP 25, using the correct DNS or connector arrangement for the organisation.

Relay restriction is not sender restriction

reject_unauth_destination prevents arbitrary relaying but still permits delivery to accepted local or virtual domains. It does not, by itself, restrict who can trigger an SMS addressed to those domains. Restrict inbound TCP 25 to the approved mail relays at the network firewall and, when required, through Postfix client restrictions.

The base installer sets default_transport = error and relay_transport = error. This is suitable for a receiving-only local-delivery design, but it also prevents ordinary remote outbound mail through that Postfix instance. If the same appliance must send SMS-to-email externally, provide a separately configured outbound SMTP relay path or deliberately revise the mail architecture. Do not assume both directions work automatically after installing the receiving-only package.

API configuration file

/etc/foxbox-sms.conf is a protected shell-assignment file read by the parser. The following values are examples only. The API token is not the web password.

FOXBOX_URL="https://foxbox.example.org/index.php"
FOXBOX_USER="sms-api"
FOXBOX_TOKEN="REPLACE_WITH_ACCOUNT_API_TOKEN"
FOXBOX_INSECURE="0"
FOXBOX_MAX_LENGTH="765"
FOXBOX_NUMBERS_FILE="/etc/foxbox-numbers.txt"
FOXBOX_LOCK_FILE="/home/nas/email-to-foxbox.lock"
FOXBOX_DRY_RUN="1"

Make the file readable only by root and the mail-processing account or group, commonly root:nas with mode 0640. Treat it as executable configuration because the shell sources it. With a trusted HTTPS certificate, keep FOXBOX_INSECURE at 0. The supplied installer uses a deployment-specific insecure setting; review that setting when commissioning a new appliance.

Fixed SMS recipient list

# /etc/foxbox-numbers.txt
# Replace these placeholders with controlled recipients.
393000000001
393000000002

The base parser removes non-digit characters, checks that the result has 8 to 15 digits, removes duplicates and submits the list in one API request. It accepts comments and empty lines. Because normalisation discards characters, inspect every source entry instead of relying on syntax checking to prove that it is the intended number.

Procmail and message handling

The supplied .procmailrc sends a copy of messages containing a Subject header to /usr/local/sbin/email-to-foxbox.sh, waits for its result and archives the original in the user's Maildir. A parser failure causes a temporary delivery failure so Postfix can retry. A message without a Subject can be archived without triggering the SMS rule.

The parser checks both HTTP status and the API JSON status. An HTTP 200 response can still contain an application error. Successful API acceptance means queue submission, not final delivery. Its retry behaviour and the absence of an end-to-end idempotency guarantee mean that an uncertain HTTP response can result in duplicate sends; check logs and message IDs before replaying mail.

The base parser is intended for simple text/plain messages. It does not perform a complete MIME decoding of HTML, multipart bodies or attachments. The five-line extraction and character truncation are not equivalent to a guaranteed number of SMS segments, especially with Unicode.

22 Postfix testing and operations

Dry-run test

Start with FOXBOX_DRY_RUN=1 in the protected configuration. Submit a plain-text message to the accepted destination through the approved SMTP path. A dry run validates parsing and recipient loading without sending an SMS through the API. It does not prove API authentication, gateway operation or handset delivery.

From: [email protected]
To: [email protected]
Subject: FoxBox commissioning test
Content-Type: text/plain; charset=UTF-8

FoxBox commissioning test.
This text should be parsed by the mail gateway.

For a local delivery test on the appliance, save a controlled sample as /tmp/foxbox-test.eml and use the reviewed local mail route:

/usr/sbin/sendmail -i [email protected] < /tmp/foxbox-test.eml
sudo tail -n 50 /var/log/email-to-foxbox.log
sudo tail -n 50 /var/log/procmail.log

A local injection tests local routing, not the remote firewall or corporate mail connector. Then send a test through the real upstream relay to verify that path as well. Once dry-run results are correct, set FOXBOX_DRY_RUN=0 and send exactly one controlled live test. Match the email queue ID, parser log timestamp, FoxBox outgoing record and received handset message.

Service and queue checks

sudo systemctl --no-pager --full status postfix dovecot
sudo systemctl --no-pager --full status fetchmail rsyslog
sudo ss -ltnp
sudo postqueue -p
sudo journalctl -u postfix --since "30 minutes ago"
sudo tail -n 100 /var/log/mail.log
sudo tail -n 100 /var/log/email-to-foxbox.log

Check only services actually installed in the selected design. Traditional /var/log/mail.log requires the appropriate logging configuration; otherwise use the journal or the configured log destination. Do not flush a large deferred queue before identifying why delivery failed and whether earlier attempts reached FoxBox.

Dovecot and Fetchmail

Dovecot provides access to the local Maildir through POP3 or IMAP. Remote access should use the configured trusted TLS service. The historical base package also runs Fetchmail against localhost and delivers to root; root must not execute a second SMS submission for the same message.

A local loopback polling exception is different from transmitting a password unencrypted across a network. If an external mailbox is polled, configure the correct TLS validation and credentials for that server. For the optional HA package, Fetchmail is disabled by default to avoid reinjection; do not combine the two package defaults indiscriminately.

Incremental recipient-list update

The base package includes update-numbers-recipients.sh for an existing compatible installation. It updates the mail-to-SMS script while preserving an existing numbers file. Review the target package and back up the current script before using the update.

sudo /home/ubuntu/scripts_mail/update-numbers-recipients.sh
sudoedit /etc/foxbox-numbers.txt

Failure interpretation

23 SMS webhook

Configuration > SMS webhook forwards parameters received by kannel_proxy.php to an HTTP endpoint while retaining delivery to FoxBox. It is a gateway-level integration, distinct from a keyword-specific SMS custom service.

Enable forwarding, set the destination URL and choose POST or GET. Use a receiving endpoint under the organisation's control. POST avoids placing message text in the destination query string, although server and application logging must still be configured appropriately.

The visible configuration exposes enablement, URL and method. It does not expose a general-purpose custom-authentication-header editor. Implement endpoint protection through the supported integration architecture rather than assuming such a field exists.

Additional gateway parameters can be passed through. Preserve the distinction between q and Q. Test an inbound SMS and compare the receiver's captured parameters with the FoxBox report. Do not assume a guaranteed retry queue or exactly-once delivery without verifying the deployed proxy implementation.

24 Group inbox

Features > Group inbox routes inbound messages using a receiving number and keyword. Create a rule with Receiver number, Keywords and Description, then configure members, catch-all handling and status through its management view.

The members are FoxBox user accounts. Their inbox forwarding preferences determine whether their received copy is also sent to email or mobile. This is different from an outbound Phonebook group of contacts.

Use a specific keyword and a controlled receiving number for a test. Check member delivery, catch-all delivery and disabled-rule behaviour separately. In the local implementation, forwarding contains checks involving member mobile numbers and the original sender, so populate account profiles consistently and test the real route rather than assuming every configured member receives every message.

25 SMS board

Features > Manage board creates a keyword-driven SMS board. The form includes the board keyword, reply message, an email forwarding address, optional CSS URL and SMSC choice.

1. Choose an unused keyword and enter a concise acknowledgement if required.

2. Set Forward to email when board messages should also reach a mailbox.

3. Configure appearance only if the board is intended to be displayed through its board view.

4. Choose the reply route: supplied incoming SMSC, routed SMSC or an explicit SMSC as offered.

5. Save, send a controlled message containing the keyword and verify the board entry, acknowledgement and email forwarding independently.

Board forwarding is separate from the user's general SMS-to-email flag. Avoid overlapping rules that cause multiple notifications unless that is intentional.

26 SMS custom services

Features > Manage custom maps a service name, keywords and optional receiver number to a custom URL. The URL can contain placeholders populated from the incoming message.

The supported placeholders shown in the form are {SERVICENAME}, {SMSDATETIME}, {SMSSENDER}, {SMSRECEIVER}, {CUSTOMKEYWORD}, {CUSTOMPARAM} and {CUSTOMRAW}. Use the keyword and remaining message content to implement a narrowly defined external service.

Make return as reply asks the feature to use the external service's response as an SMS reply. Select it only when the endpoint produces the intended short message. A reply can consume credits and must use the chosen SMSC. Validate encoding, timeouts, error responses and empty replies before enabling it for users.

Example design: an incoming STATUS A123 message calls an internal service that looks up the status of reference A123. The service returns only the text intended for the recipient. Avoid returning an HTML error page or sensitive internal diagnostics as an SMS.

27 SMS quiz

Features > Manage quiz provides a keyword, question, expected answer, separate replies for correct and incorrect answers and an SMSC selection. The list exposes quiz status and answer records.

Create a unique keyword, a clearly worded question and the expected answer. Configure both feedback messages and the reply route. Test correct, incorrect and malformed answers. Review the answer list before using it for any operational decision; accepted text formats and comparison behaviour should be confirmed with the installed version.

Enable or disable the quiz through the provided status action as appropriate. Treat status changes as operational changes because they affect future incoming messages. Quiz responses and replies can generate message traffic and credits.

28 SMS subscriptions

Features > Manage subscribe maintains a keyword-based subscription service. The form defines subscribe and unsubscribe parameters and replies, a forward parameter, subscription duration, expired-subscription reply, unknown-format reply, already-member reply and SMSC.

For example, configure keyword NEWS, subscribe parameter JOIN and unsubscribe parameter STOP, then test NEWS JOIN and NEWS STOP with a controlled handset. These are example choices, not universal built-in commands. Ensure the published instructions match the actual configured values.

Subscription duration may be unlimited or one of the durations offered by the form. Test expiry handling before relying on it. The forward parameter, shown as BC by default in the reference form, concerns message-forwarding behaviour; verify who is allowed to use it and the audience it reaches.

Review subscriber records and the service's sending actions. A subscription database is separate from a general phonebook group or blacklist. Confirm how opt-out is enforced in each intended campaign and integration.

29 Reports and delivery status

Reports provide operational evidence at different scopes. Read the page heading and active account before comparing totals. A submitted message, a processed queue item and a delivery receipt describe different stages.

Outgoing messages

The Outgoing messages page is headed My sent messages for the current account. Use its search fields and available row details to inspect destination, text, time and status. Compare the application message ID with gateway logs when investigating a failure.

All sent messages

The administrative all-sent view provides broader history. Filtering and export or row actions depend on the installed view. A record may have a send status before a final DLR arrives. Do not label a message delivered only because an API call returned OK.

All feature messages

This report shows messages handled by feature workflows. Use it with the sandbox when checking keyword processing. An empty feature report can be normal if no configured feature handled the test message.

Global statistics and user reports

On the reference site, Global statistics and LOGS > All users report share the route whose heading is My report. It compares selected months and years. Reports > Report all users opens a separate All reports page. Confirm the heading and scope instead of relying only on the sidebar label.

30 Queue and campaign monitoring

Reports > Campaigns overview shows queue information, including future scheduled queues. LOGS > Campaign overview opens a related My queue report. These reports complement the campaign wizard's campaign list.

Check intended execution time, active account and queue status. A future queue is not a failure. A growing current backlog can indicate a stopped worker, slow modem, upstream throughput limit or repeated gateway errors. Do not delete or recreate queues until the existing recipients and submitted messages are understood.

Use the report's available detail controls to inspect the actual records. Pause, resume, retry or deletion actions should be used only when exposed by the installed version and after considering duplicate sends. The presence of a plugin directory does not guarantee that every possible queue action is enabled in the UI.

31 BI analytics

The Dashboard embeds a Metabase analysis view and Reports includes a BI analytics link. The reference dashboard presents total submitted SMS, incoming SMS, submissions by user, daily traffic and a detailed data table.

Use BI for trends and cross-account analysis, and use the operational message reports for individual troubleshooting. Differences can arise from query scope, time boundaries, refresh timing or filters. Record those parameters before comparing totals.

A shared or public dashboard view can have fewer capabilities than the authenticated Metabase administration interface. Do not assume that the analytics link grants database or dashboard-editing privileges. Review the data included before exporting or sharing a report.

32 Logs and background processing

System notifications

LOGS > System notifications displays internal application notifications. Search or review recent entries around the time of an incident. Notification records are useful context but do not replace the host, mail or gateway logs.

Background tasks report

Background Tasks exposes work tracked by the application. A quiet page can mean there is no current work; it does not independently prove that every worker is healthy. Check host or container processes when scheduled messages or mailbox polling stop progressing.

Banned users and online sessions

Banned users report helps investigate blocked access. Determine why a user was blocked before changing the record. Main configuration contains the login brute-force detection setting. Who's online lists active session information; it is a current operational view, not a complete audit history.

33 Data policies and backups

Features > Data Policies (GDPR) is a guide to the data-retention tools. It links to Main configuration > Erase data. The feature name does not by itself establish compliance with any legal requirement; apply the organisation's approved data-handling policy.

Export and restore

The Erase data tab can dump contacts and messages to JSON. Store the export securely and verify that it can be read. Restore accepts JSON created by that panel and replaces existing contacts and messages. It is not a full backup of Ubuntu, mail routing, gateway credentials or every application setting.

Before restoring, create a fresh backup of the current state and confirm the exact replacement scope. Test restore procedures in a separate environment. Do not use a production restore as a way to preview an export.

Manual deletion

The tab exposes separate deletion actions for phonebook contacts and groups, sent messages and DLRs, and received messages. These are broad deletion operations. Review the scope and export first.

Automatic erase timer

The timer enables periodic full erasure of selected resource categories. Run every (days) is the interval between wipes, not a promise to keep records younger than that age. For example, wiping outgoing history every 30 days is not the same as deleting only messages older than 30 days.

The UI requires a cron job to execute php protected/cli/auto_erase.php in the appropriate application environment. Enabling the checkbox alone does not install a host cron job. Confirm the CLI script's configuration and credentials and use the correct runtime/container. Leave unwanted categories disabled and intervals at zero.

Full appliance backup scope

- Application database and any separate analytics database needed for recovery.

- Application and gateway configuration, including routing and protected credentials.

- Contact imports, templates and other required persistent application data.

- Netplan, DNS-related host configuration and service definitions.

- Postfix maps, Procmail rules, Dovecot configuration, Maildir and mail-to-SMS scripts.

- Container definitions, persistent volumes and device mappings when applicable.

Restore into a controlled environment and verify both email directions, outbound SMS, inbound routing and scheduled work. Prevent restored queues or mailboxes from replaying old messages during a recovery test.

34 Web console and database administration

Configuration > Network OS config opens the server console login. It uses a server account, separate from the FoxBox application account. For network changes, use the Ubuntu procedure in chapter 2 and retain an independent console path.

The reference console presents a separate login page. The screenshot documents that entry point; the network examples are command procedures, not screenshots of commands executed on the production host.

Configuration > Mysql Admin links to phpMyAdmin. Database administration requires separate service availability and credentials. Prefer the application UI for routine changes because direct database edits can bypass validation and create inconsistent records. Take a verified backup before database maintenance and know which database is the operational FoxBox store.

35 HTTP API integration

The FoxBox webservices endpoint uses index.php?app=ws. Typical authentication uses u for the account username and h for its webservices token. Enable the account's API access and verify the permitted source IP range before testing.

The following example sends an SMS when executed. Replace the destination with an authorised test handset and set the URL, username and token for the target system. Do not use the reference site's production credentials in documentation or scripts.

FOXBOX_URL='https://foxbox.example.org/index.php'
FOXBOX_USER='sms-api'
read -r -s FOXBOX_TOKEN
export FOXBOX_TOKEN

curl --get "$FOXBOX_URL" \
  --data-urlencode 'app=ws' \
  --data-urlencode "u=$FOXBOX_USER" \
  --data-urlencode "h=$FOXBOX_TOKEN" \
  --data-urlencode 'op=pv' \
  --data-urlencode 'to=393000000001' \
  --data-urlencode 'msg=Controlled commissioning test'

Protect tokens from logs and shell history. GET-based APIs can appear in HTTP access logs; configure those logs appropriately. URL-encode every parameter, including #group codes, plus signs and message text. Validate TLS with the target's trusted certificate.

API operation reference

The local webservices implementation and README_Api.md provide operation details for this codebase. Before relying on an operation, confirm its parameters and permissions against the deployed version. Administrative operations require the corresponding privileges.

For a non-sending connectivity check, use the same authenticated request pattern with op=cr and omit to and msg. For a delivery lookup, use op=ds and the relevant returned smslog_id or queue. Do not use an incoming-message injection as a harmless ping: it can activate replies and forwarding workflows.

Keep the returned queue/message identifiers. A transport success is not an application success, and an application acceptance is not a final DLR. Handle errors, partial recipient failures, timeouts and uncertain responses explicitly. Avoid automatically resending an entire multi-recipient request after some destinations have already succeeded.

MCP endpoint in the source package

The repository documents mcp.php as an optional JSON-RPC integration with sms.send and sms.incoming.list, authenticated by a webservices token. Deployment and access must be verified separately. Treat sms.send as a real sending operation, with the same account, credit and delivery constraints as the HTTP API.

36 Optional modules and mail-routing extensions

The following components are present in the local source tree or packaged extensions. Availability depends on installation and permissions; they are not all exposed in the reference website's menus. Use the installed module's own configuration and verify its behaviour before introducing it into production.

Do not infer visual flow design, AI services, approval workflows or detailed analytics from the existence of a module directory. The visible interface and deployed code determine the actual feature set.

Email address to phonebook group variant

The foxbox-mail2sms-group-variant package adds exact email-to-group mappings. Its configuration uses entries such as the following:

FOXBOX_GROUP_ROUTES="[email protected]=OPS;[email protected]=NET"

Create OPS and NET in the phonebook of the API account and maintain the recipients there. Review the variant's fallback routing and allowed-sender-domain controls. Back up the current parser before replacing it, preserve ownership and permissions, test dry-run parsing, then verify one live message and group expansion. This configuration does not apply to the unmodified fixed-numbers parser.

HA mail routing package

The foxbox-ha-mail-routing package combines exact recipient-email-to-phonebook-group sending with incoming SIM/modem-to-group-email delivery. It contains shared routing configuration, node-local modem bindings, an installer, validation scripts and the sim2email_group feature.

Use identical shared routes on both nodes, while recording each node's own USB serial and device-interface mapping. Stable logical modem identities allow inbound routing to distinguish SIMs. The package expects the Kannel callback to preserve the actual SMSC identifier, rather than a constant that hides which modem received the message.

Install and validate on the passive node first, then repeat on the peer. The package defaults to dry-run for mail-to-SMS and disables an existing Fetchmail service to prevent reinjection. Confirm the approved SMTP sources and the virtual-IP routing with the network team.

The package adds routing support; it does not by itself prove that the complete cluster, virtual IP, database replication or failover orchestration is installed and correct. Test failover while checking for missed or duplicate messages and consistent contact-group data. The supplied checker and README define the package-specific installation procedure.

37 Troubleshooting playbooks

Cannot open FoxBox

1. Confirm the appliance IP from its local console.

2. Check link state, subnet and default route.

3. Resolve the HTTPS hostname and inspect certificate validity.

4. Check the reverse proxy or web service and its listening ports.

5. For containers, inspect the published ports and application health.

Web login fails

Verify the intended instance, account and password. Check account state, banned-user records and whether LDAP is enabled. Confirm the directory connection if applicable. Keep web, server-console and database credentials distinct. The admin / foxbox pair in this manual is an example, not evidence that the live server accepts it.

SMS remains queued

Check scheduled time and timezone first. Inspect the background tasks and queue views, then the worker process and gateway connection. Verify the selected SMSC, SIM registration, credit and operator limits. Before replaying work, determine whether the gateway already accepted it.

SMS is submitted but not delivered

Inspect per-destination status and DLR information. Verify country code and number normalisation, sender restrictions, operator rejection and handset availability. Where DLRs are unsupported or absent, report the state as submitted or unknown rather than inventing delivery confirmation.

Incoming SMS is missing

Check the receiving SIM and gateway logs, then the callback URL and actual receiver/SMSC parameters. Inspect sandbox and feature messages. Check keyword routing, Group inbox membership and per-user inbox settings. A webhook is an additional forwarding path; it does not replace the need to deliver the callback to FoxBox.

Email to SMS fails

Identify which integration is in use before troubleshooting. For mailbox polling, inspect unseen mail, account/PIN subject syntax, sender checking and the poller. For Postfix, inspect the SMTP queue, alias maps, local mail user, Procmail result, parser log and API response. The two formats are not interchangeable.

SMS to email fails

Verify the target user's inbox processing and forwarding flag, then profile email and outgoing SMTP. Check whether incoming-mail settings are overriding SMTP defaults. If using the receiving-only Postfix configuration, remember that its error transport blocks ordinary remote mail delivery.

Safe host diagnostics

date -Is
df -h
free -h
systemctl --failed
sudo ss -lntp
ps -ef | grep -E 'playsmsd|kannel|bearerbox|smsbox'
docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'

Docker commands apply only where Docker is installed. Service and container names are deployment-specific; discover them before running restart commands. Gather relevant log excerpts without credentials or unrelated personal message contents.

38 Acceptance checklist

Use this checklist when commissioning or after a significant change. Record the date, operator, appliance version, test account, timestamps and message IDs.

Run only the tests relevant to the selected deployment. Sending tests generate real traffic; use controlled recipients and verify counts before proceeding to a production audience.

39 Reference sources and terminology

Product sources

The interface reference is https://sms.foxbox.it/. Product behaviour was cross-checked against the corresponding local modules: core/user, core/recvsms, core/sendmail, core/main_config, core/gateway, feature/mailsms, feature/phonebook, feature/inboxgroup, feature/hcnx_text_campaigns, the other feature directories, inc/app/webservices.php and protected/cli/auto_erase.php.

The Postfix base integration is defined by scripts_mail/email-to-foxbox.sh, install-email-to-foxbox.sh and procmailrc.email-to-foxbox. Optional group and HA integration instructions are in the README files under output/packages/foxbox-mail2sms-group-variant and output/packages/foxbox-ha-mail-routing.

Official platform references

- Ubuntu Server networking: https://ubuntu.com/server/docs/explanation/networking/configuring-networks/

- Netplan static addresses: https://netplan.readthedocs.io/en/stable/using-static-ip-addresses/

- Netplan trial and rollback: https://netplan.readthedocs.io/en/stable/netplan-try/

- Postfix basic configuration: https://www.postfix.org/BASIC_CONFIGURATION_README.html

- Postfix virtual domains: https://www.postfix.org/VIRTUAL_README.html

- Postfix SMTP access control: https://www.postfix.org/SMTPD_ACCESS_README.html

Glossary