This note uses a dedicated Postfix receiving instance and FoxBox's documented base scripts_mail path. It is a configuration review and offline lab, not a report of a live Linux appliance deployment. The completed checks used native Postfix 3.2.2 utilities on macOS; no SMTP server, email, API call or SMS was sent.

Disclosure: this guide was prepared with AI assistance for FoxBox Integration Notes. Davide Cantaluppi is associated with Mindly / FoxBox. The examples are original illustrative configuration; they do not imply certification or a delivery guarantee.

Choose the receiving mode first

The FoxBox manual, chapters 21–22 describes a base path of Postfix → local nas account → Procmail → email-to-foxbox.sh → API queue submission. SMS numbers come from /etc/foxbox-numbers.txt; they are not extracted from the email recipient. The parser uses the first five body lines. Its format differs from the username/PIN mailbox-polling workflow. Use one consumer per message stream.

For this example, ops@... and power@... are two permitted email entry points for the SAME fixed SMS recipient list. They are not two different phonebook groups. Group routing requires its separately reviewed implementation.

The examples use the reserved .invalid suffix and documentation network 192.0.2.0/24. Replace them only in an isolated, reviewed installation. Do not paste this fragment over an existing corporate mail server configuration.

Route one domain from the upstream relay

On the existing authorized upstream Postfix relay, the conceptual transport-table entry is:

# Add to the appropriate existing transport table after review.
sms.example.invalid smtp:[192.0.2.20]:25

The brackets select this next hop without an MX lookup. A transport entry chooses a destination; it does not authorize a sender or recipient. Preserve the relay's other routes. Check its parent_domain_matches_subdomains value: transport_maps must not be included if this domain entry is intended to match only that domain. Do not add * or .sms.example.invalid as convenience fallbacks. See the Postfix transport table documentation.

Put independent restrictions on the receiving instance

The receiving host in this example has a reviewed local nas account and the appropriate Procmail rule. Its SMTP listener is reachable only from the approved upstream relay. Retain network filtering and use an authenticated, protected transport if this connection crosses an untrusted network. The fragments below are not a TLS deployment recipe.

# main.cf fragment — dedicated, receiving-only instance
myhostname = sms-ingress.example.invalid
mydomain = example.invalid
mydestination = $myhostname, localhost.$mydomain, localhost
inet_interfaces = 192.0.2.20
inet_protocols = ipv4
mynetworks = 127.0.0.0/8
recipient_delimiter =

virtual_alias_domains = sms.example.invalid
virtual_alias_maps = hash:/etc/postfix/sms_virtual
smtpd_relay_restrictions = reject_unauth_destination
smtpd_client_restrictions = check_client_access cidr:/etc/postfix/sms_clients, reject
smtpd_recipient_restrictions = check_recipient_access hash:/etc/postfix/sms_recipients, reject
smtpd_reject_unlisted_recipient = yes

mailbox_command = /usr/bin/procmail -a "$EXTENSION"
default_transport = error:5.1.1 Remote delivery disabled on SMS ingress
relay_transport = error:5.1.1 Remote relay disabled on SMS ingress

# /etc/postfix/sms_clients — CIDR table; do not run postmap to compile it
192.0.2.10/32 OK

# /etc/postfix/sms_recipients — indexed table
ops@sms.example.invalid OK
power@sms.example.invalid OK

# /etc/postfix/sms_virtual — indexed table
ops@sms.example.invalid nas@localhost
power@sms.example.invalid nas@localhost

Three decisions remain separate: the client address must be approved; the recipient domain must be a legitimate destination for this instance; and the full recipient must be in the explicit table. There is no broad permit_mynetworks or SASL permit ahead of these checks. The network boundary still matters: a permitted relay must enforce which of its own applications can use this route. A forged From header proves nothing.

Leave sms.example.invalid out of mydestination, because it is a virtual alias domain. Do not add @sms.example.invalid, a domain-wide OK, or a bare local-part alias. Empty recipient_delimiter prevents an address such as ops+anything@... from falling back to ops@.... Indexed Postfix maps are case-insensitive, so “exact” here means the complete normalized address, not case-sensitive spelling. Review existing canonical, BCC, alias and content-filter rules too: this fragment cannot neutralize other configuration silently.

The receiving-only error transports deliberately prevent ordinary remote outbound mail. Plan monitoring and delivery-status notifications through a separate reviewed path. This instance is not automatically an SMS-to-email outbound relay. Postfix SMTP access controls explain why relay permission and access restrictions are different checks.

Validate maps before enabling the route

Build the two indexed maps in the isolated target configuration after inspecting the text files. Use the map type supported by that installation; this example uses hash:

postmap hash:/etc/postfix/sms_recipients
postmap hash:/etc/postfix/sms_virtual
postmap -q ops@sms.example.invalid hash:/etc/postfix/sms_recipients
postmap -q ops@sms.example.invalid hash:/etc/postfix/sms_virtual
postmap -q 192.0.2.10 cidr:/etc/postfix/sms_clients
postmap -q ops+extra@sms.example.invalid hash:/etc/postfix/sms_recipients
postmap -q unknown@sms.example.invalid hash:/etc/postfix/sms_virtual

Expected results are OK, nas@localhost, OK, then no match for the last two queries. No match is meaningful because the restriction list subsequently ends in reject. A map query alone does not run the SMTP restriction engine.

Our offline fixture checked allowed and unknown recipients, plus addressing, subdomains, lookalike suffixes, foreign domains, case folding, source addresses, the transport entry and parsed configuration settings. A separate response-loss model demonstrated the retry problem below. All 34 checks passed. The fixture substitutes loopback for the documentation listener address and uses Apple's service-account names only in its temporary macOS configuration. It does not start Postfix or modify system files.

The remaining commissioning work is explicit: on the target Linux version, run configuration validation, then test allowed and rejected SMTP transactions into a sink. Check both approved and unapproved source networks. Verify the exact Procmail account and parsing behaviour while the API transport is disabled. No map-only result proves that the deployed listener is not an open relay.

Treat an uncertain submission as its own state

The base parser checks HTTP and application status; HTTP 200 alone is insufficient. Its failure path can cause Postfix redelivery, and an uncertain API response can create duplicate submissions. API acceptance is not handset delivery. The supplied parser is for simple text/plain mail rather than complete MIME decoding, so reject unsupported formats upstream or use a separately reviewed normalizer.

There is also an earlier ambiguity: the upstream MTA can lose the final SMTP response after the receiving MTA accepted the message. Postfix explicitly documents possible duplicate delivery after smtp_data_done_timeout. Shortening timeouts does not provide idempotency. See the Postfix parameter reference.

Use an incident identifier stable across retries, with a distinct notification revision when content or state changes. A Message-ID is useful correlation data, but does not by itself guarantee uniqueness or authorization. Record the upstream queue ID, local queue ID, application attempt and returned gateway identifiers separately.

Before enabling unattended SMS, review every retry layer: the source application, SMTP relay, local delivery, parser HTTP client and any operator replay. Define these outcomes:

A durable outbox can record intent before a submission and preserve accepted/unknown outcomes across process restarts. It also needs atomic ownership, retention, operator decisions and a policy for a crash before the request leaves the host. This is an architectural requirement, not a feature installed by the configuration above. The offline model shows why: its fake gateway accepts once and loses the response; blind retry accepts twice, while retaining unknown prevents a second attempt. Preventing replay can also leave an unsent event awaiting investigation. It is not an exactly-once claim.

For an existing ambiguous queued message, an administrator can contain future attempts with a targeted postsuper -h QUEUE_ID after verifying the queue ID. Holding a queue entry cannot recall a delivery process already running. Held mail does not expire under the normal queue-lifetime settings, so give it an explicit review deadline. Do not flush or requeue the whole deferred queue. Reconcile against available gateway records before any deliberate replay, and monitor held/expired items through a separate operational path.

Finally, set an explicit freshness policy for alerts. A six-hour-old power event may be misleading even if the queue can still deliver it. The base mapping shown here does not implement event expiry or deduplication. Keep the live transport disabled until the deployment's retry, ambiguity and expiry behaviour has been verified against an isolated sink.

A monitoring job can finish successfully while nobody owns its alert. HTTP success, application acceptance, network delivery and human acknowledgment are separate observations. Store them separately: a green transport check should not silently close an incident.

1. Define acceptance before connecting a sender

The reviewed HIGHWAY v1 interface receives web-services requests at /index.php. Its existing Node-RED example uses a form-encoded POST with app=ws, op=pv, format=json and runtime fields u, h, to and msg. Authentication belongs in protected runtime configuration, never a tutorial or exported flow.

For a single recipient, the reviewed acceptance shape has one object in data, with status=OK, error=0 and a nonzero queue or SMS-log identifier. This means acceptance for processing. The separate ds operation concerns stored status; it does not establish human acknowledgment.

These observations refer to public source revision a6794b602d858d95a8131ad54cbb25057b5a2226. Check your installed interface before adapting the example. A repository does not establish the configuration of every deployed appliance.

2. Run four synthetic outcomes

Save this complete example as alert_contract_demo.py. It contains no network client or send function. The license covers this original teaching example.

# SPDX-License-Identifier: GPL-3.0-or-later
# Offline teaching example: no networking, credentials, recipients or sends.
import json


def error_code(value):
    if type(value) is int and value >= 0:
        return value
    if isinstance(value, str) and value.isascii() and value.isdecimal():
        return int(value)
    return None


def valid_id(value):
    if type(value) is int:
        return value > 0
    if not isinstance(value, str) or not value or not value.isascii():
        return False
    if value.isdecimal():
        return int(value) > 0
    return all(c.isalnum() or c in "-_" for c in value)


def classify(http_status, body):
    if http_status is None:
        return "transport_unknown"
    if type(http_status) is not int:
        return "unverified"
    if http_status in (401, 403, 429):
        return "rejected"
    if not 200 <= http_status < 300 or not isinstance(body, dict):
        return "unverified"
    top_status = body.get("status")
    if "status" in body and top_status not in ("OK", "ERR"):
        return "unverified"
    top_error = error_code(body["error"]) if "error" in body else None
    if "error" in body and top_error is None:
        return "unverified"
    if top_status == "ERR" or (top_error is not None and top_error > 0):
        if top_status == "OK" or not top_error or body.get("data"):
            return "unverified"
        return "rejected"
    rows = body.get("data")
    if not isinstance(rows, list) or len(rows) != 1:
        return "unverified"
    row = rows[0]
    if not isinstance(row, dict):
        return "unverified"
    status, error = row.get("status"), error_code(row.get("error"))
    if status == "ERR" and error is not None and error > 0:
        return "rejected"
    if status != "OK" or error != 0:
        return "unverified"
    if valid_id(row.get("queue")) or valid_id(row.get("smslog_id")):
        return "accepted_for_processing"
    return "unverified"


CASES = {
    "accepted": (200, {"data": [{"status": "OK", "error": 0,
                                "queue": "DEMO-QUEUE"}]}),
    "authentication": (403, {}),
    "malformed": (200, {"data": []}),
    "timeout": (None, None),
}

if __name__ == "__main__":
    for name, (http_status, body) in CASES.items():
        print(json.dumps({"case": name, "outcome": classify(http_status, body),
                          "simulation": True, "transport_attempted": False,
                          "delivery_verified": False,
                          "human_acknowledged": False}, sort_keys=True))

Run python3 alert_contract_demo.py. In order, the four outcomes should be accepted_for_processing, rejected, unverified and transport_unknown. Every record keeps transport, delivery and human acknowledgment false because the exercise is simulated. These teaching labels are not the full Node-RED flow's result schema.

Change the queue identifier to 0, omit status or error, or use a boolean or fractional error. These incomplete or invalid responses must remain unverified, not become proof of rejection. Positive integer application errors support rejection only when consistent with the response. An HTTP success code alone does not establish acceptance. This conservative teaching classifier is not a production client.

3. Inspect the existing Node-RED flow safely

Import the published Flow Library example into an isolated workspace. Its exported tab is disabled and Inject has no repeating schedule. Keep FOXBOX_ENABLE_SEND unset or exactly false. Enable the tab for inspection, deploy and press Inject manually: expect a redacted dry_run result with reason sending_disabled and no HTTP request.

This check needs no credentials or recipient. Inspect the Function nodes before attaching real events. The operator configures the destination; incoming messages cannot supply it. The flow verifies TLS certificates, disables redirects and performs no automatic retry.

The recorded isolated test of this existing flow passed 22 checks with 13 localhost mock requests on Node-RED 5.0.8. That evidence applies to that flow and environment, not hardware, a carrier or handset delivery.

4. Preserve uncertainty after a timeout

A gateway may accept a request before its response is lost. Calling that outcome “not sent” and immediately retrying can create duplicates. Retain an event ID and attempt number, record the unknown outcome and use the installation's status facilities before deciding on another attempt.

Log the timestamp, classification and next review action. Exclude message bodies, full telephone numbers, tokens and raw responses from routine logs. Keep reconciliation identifiers in restricted operational records.

The existing flow's interval guard uses one Function-node context. With Node-RED's default in-memory store, that state is lost on restart. It is not durable deduplication, a global quota or a delivery queue.

5. Give ownership its own deadline

Until an authorized responder accepts the correct incident, ownership remains unconfirmed. Delivery evidence cannot prove that someone understood the alert or started work.

Bind any future acknowledgment mechanism to the incident and an authenticated responder. Decide what happens to late acknowledgments, duplicate replies and recovery events. Acknowledgment, authority to remediate and resolution are separate transitions. This lab implements no authentication service or incoming-SMS parser.

For OTP, leave code generation, expiry and verification with the identity system. This notification example implements none of them. NIST treats SMS out-of-band authentication separately from phishing-resistant methods; selecting a transport does not establish a deployment's authentication strength.

For CRA or NIS2 reviews, retain versions, configuration assumptions and test boundaries as technical evidence. This lab makes no conformity or certification claim. It provides an inspectable acceptance rule and a visible place for uncertainty and ownership.

References:

• Public HIGHWAY source
• Existing Node-RED flow
• Gateway account configuration, chapter 12
• NIST authentication guidance