<source>set by the Hub
The default is true. If an address arrives in the SMTP conversation whose domain consists of a single part (user@host), the engine completes it by appending the domain suffix: on the machine mail.foo.com the address becomes user@host.foo.com.
The completion applies to both addresses of the conversation — both MAIL FROM and RCPT TO.
The suffix is set separately, with the domain-suffix line at the root of the file. If it is not set, it is taken from the machine’s own name.
The second edge: the default suffix is taken from the machine name. So on a node whose name you did not choose, addresses are completed with a domain you did not think about.
Why it was turned off. Completion was invented for internal mail systems, where user@host is a legitimate notation. Here submission comes from sending platforms with address lists, and an incomplete domain there means an error in the list. The right reaction to an error is a rejection at submission, so that the list gets cleaned; completion instead makes the address “correct”, the message goes nowhere and brings a bounce into the receiver’s statistics.
As a side effect, a second case is closed too: a completed address could end up in the message’s return path where rewriting is not enabled.
What to set. The question is whether you trust the addresses that arrive at submission:
| Value | When |
|---|---|
| true (default) | local old-style scripts submit, and addresses without a domain are legitimate |
| false | submission comes from a platform that always gives a full address — then an incomplete one is a typo, and rejecting it is more honest |
The second is stricter and almost always more correct for mailings: a message sent to a completed address complains to no one — it simply goes to the wrong recipient.
# an incomplete address is a sign of a typo, not an abbreviation <source 0/0> auto-qualify-domain false</source>
what people get wrong and how it ends2 mistakes▶
§ 3.3.7.73
§ 3.3.1.34
1 relation
grep -n 'auto-qualify-domain\|^domain-suffix\|^host-name' /etc/pmta/config
3 articles
◇How a message gets into the engineSix described submission methods: extended SMTP, four language bindings and a directory the node watches on disk.◇Who is allowed to submit mail and for whom to accept itOut of the box, the node accepts submission only from the machine itself; two different questions — “who can send through us” and “for whose addresses we accept mail” — are answered by different directives.◇Headers the sender uses to control deliverySix control headers let the submitting side choose a stream, tag a message with a job, set signing options and the key, the envelope identifier and the schedule; each is allowed separately and per source.