https://gitlab.synchro.net/main/sbbs/-/commit/b8332a4618efd80300b671d6
Modified Files:
docs/v322_new.md src/sbbs3/mailsrvr.cpp mailsrvr.h
Log Message:
Treat the submission ports as an MSA, not as port 25 (#1221)

The message submission ports (587, and 465 for implicit TLS) ran the same
code path as the SMTP transfer port, so nothing downstream could tell the
two apart. Three consequences, all reported by Deuce:

- An authenticated user submitting an original message to an external
recipient was judged by the port-25 rule and refused as an illegal
relay unless the sysop enabled ALLOW_RELAY, a server-wide option.
- The submission ports accepted unauthenticated mail, contrary to
RFC 6409 section 4.3, which requires a 530 error response to MAIL on
an unauthenticated session.
- Once ALLOW_RELAY was set, every sender check was skipped for an
authenticated session, so a user could submit with any From: address,
including one at a domain the system does not own. The SMTP envelope
sender was already derived from the user record, but the RFC822 From:
header is emitted verbatim, and is now also DKIM-signed.

Listening sockets previously passed their protocol name through xpms as
the callback data, and the accept loop recovered each socket's properties
by comparing that pointer against the name it was created from. Those comparisons work only because the names differ: the compiler pools
identical string literals, so the transfer and submission agents, both
named "SMTP", share one pointer and cannot be told apart. Pass a
descriptor instead, carrying the display name alongside the properties
the accept loop wants, so identity no longer depends on the name.

An authenticated user sending to an external address via a submission
port is a submission rather than a relay and no longer consults
ALLOW_RELAY, which continues to govern the transfer port. The G and M restrictions still apply on every port, so a sysop retains per-user
control over outbound mail.

A sender address is authorized when its domain is one of this system's
and it resolves to the authenticated user. Both questions are answered by smtp_resolve_user(), extracted from the RCPT TO handler, so any address
that reaches a user -- alias, real name, alias.cfg entry, sub-address
tag, user number -- also works as their sender address, and stays correct
as the sysop edits alias.cfg. An alias resolving off-system is a forced
relay rather than a local address, so it authorizes nobody, and the
DefaultUser catch-all is suppressed: it exists to make unknown recipients deliverable, and honoring it would let that one account send as any
address at the system's domains. MAIL FROM and the From: header are both checked. A null reverse-path is accepted, per RFC 6409 section 3.2.

A refusal suggests the account's own address rather than prescribing it,
since several addresses may be acceptable and the likeliest cause is a
mail client configured with a misspelling of the sender's own address.

The transfer port is unaffected in every respect, so only sysops who have deliberately enabled a submission port see any change.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net