Mario Fetka
69 lines
3.6 KiB
Markdown
69 lines
3.6 KiB
Markdown
# SMTP extensions
|
|
|
|
Bongo keeps the classic `HELO`/`MAIL`/`RCPT`/`DATA` path for old clients and
|
|
advertises ESMTP extensions after `EHLO`. The server advertises `8BITMIME` and
|
|
`SMTPUTF8` only when the corresponding configuration is enabled. `SMTPUTF8`
|
|
is accepted as a `MAIL FROM` parameter only after `EHLO`; non-ASCII envelope
|
|
addresses require it and are validated as UTF-8.
|
|
|
|
`BODY=8BITMIME` is recorded with the queued message and is sent to a remote
|
|
peer only when that peer advertises `8BITMIME`. Bongo implements bounded
|
|
`BDAT` chunks and advertises `CHUNKING`; chunk and complete-message limits are
|
|
enforced before a message is committed. `BINARYMIME` remains unsupported, so
|
|
`BODY=BINARYMIME` is rejected explicitly instead of silently treating binary
|
|
data as a normal `DATA` message.
|
|
|
|
Outgoing SMTP uses the peer's advertised `SIZE`, `8BITMIME` and `SMTPUTF8`
|
|
capabilities. Bongo normalizes internationalized domain names with IDNA2008
|
|
and stores and transmits the resulting lower-case A-label. The local part is
|
|
left untouched; only a non-ASCII local part therefore requires `SMTPUTF8`.
|
|
The same normalization is applied to hosted domains, aliases, TLS names,
|
|
DKIM/DMARC material, MX lookup, queued envelopes, Web composition and
|
|
external SMTP relays. Invalid or transitional-only domain spellings are
|
|
rejected instead of being mapped differently by individual components.
|
|
|
|
For example, `user@bücher.example` is persisted and sent as
|
|
`user@xn--bcher-kva.example`. Configuration files may contain either the
|
|
Unicode spelling or its A-label; synchronization writes the canonical
|
|
A-label to the configuration store.
|
|
|
|
Relevant standards are [RFC 6531](https://www.rfc-editor.org/rfc/rfc6531.html),
|
|
[RFC 3030](https://www.rfc-editor.org/rfc/rfc3030.html) and
|
|
[RFC 3461](https://www.rfc-editor.org/rfc/rfc3461.html).
|
|
|
|
## Trusted downstream proxy metadata
|
|
|
|
Bongo can preserve the original SMTP client's connection address when it
|
|
delivers mail to a trusted downstream SMTP or LMTP service. All three options
|
|
below are empty by default. Their entries match an exact transport hostname,
|
|
an exact IPv4 address, or an IPv4 CIDR such as `172.16.11.0/24`:
|
|
|
|
```json
|
|
"xclient_trusted_destinations": ["smtp-filter.example.test"],
|
|
"xforward_trusted_destinations": ["172.16.11.20"],
|
|
"proxy_header_trusted_destinations": ["172.16.11.0/24"]
|
|
```
|
|
|
|
`xclient_trusted_destinations` and `xforward_trusted_destinations` permit the
|
|
Postfix `XCLIENT` and `XFORWARD` protocol extensions. Bongo still sends either
|
|
command only when the connected peer advertises the extension and its
|
|
supported attributes. These options name destination servers, not networks
|
|
from which SMTP clients are accepted.
|
|
|
|
`proxy_header_trusted_destinations` is the compatibility fallback for servers
|
|
which cannot negotiate either extension. For a matching destination Bongo
|
|
adds `X-Client-Addr` and `X-Forwarded-Addr` to that delivery only. The fallback
|
|
headers are suppressed when the original address was already transferred by
|
|
`XCLIENT` or `XFORWARD`. User-supplied copies of these headers are removed on
|
|
SMTP input, so the downstream service receives only Bongo-generated values.
|
|
|
|
Do not configure Internet destinations or a catch-all network such as
|
|
`0.0.0.0/0`. The metadata exposes the original client address and downstream
|
|
software may treat it as trusted. This fallback applies to Bongo's direct
|
|
SMTP/LMTP delivery path; authenticated external-account relay providers never
|
|
receive these headers.
|
|
|
|
These outgoing metadata options are independent of incoming HAProxy PROXY
|
|
protocol. See [proxy-protocol.md](proxy-protocol.md) when a TCP load balancer
|
|
must preserve the client address before Bongo accepts the SMTP connection.
|