<source>
The default is false. The manual describes the directive as a convenience: it enables at once all SMTP permissions and capabilities needed for our submission APIs.
And right there it says what this equals currently: the value yes is equivalent to allow-mailmerge yes. With no the question is decided by the other settings individually.
That is, the line is not a switch for a single capability but a shortcut for a set, and the vendor reserves the right to change that set. Today it contains one directive; the next version may have more.
Hence the rule: if you need one capability from the set, enable it with a direct line. Keep the shortcut for when you really submit through the vendor API.
Why it was removed. The Hub does not use HTTP submission at all, there is no <transmissions-api> block in the configuration, and the merging the line currently enables is not needed. The deciding argument was the manual’s word “currently equivalent”: the vendor reserved the right to expand the directive’s content, and the permission had been granted to all addresses at once.
If HTTP submission is needed, it is enabled by its own block with a key, and at that point you consciously decide whom to open it to.
What to set. The question is whether you submit through the vendor API:
| Value | When |
|---|---|
| false (default) | submission goes over regular SMTP — our case |
| true | submission really goes through the vendor API, and there is no point listing permissions one by one |
There is a third path between them: enable the needed capability with a direct line. It is preferable to the shortcut wherever the set is known — because it does not change when the engine is upgraded.
# the shortcut is justified where submission really goes through the vendor API <source 10.0.0.0/24> always-allow-api-submission true</source>
what people get wrong and how it ends2 mistakes▶
§ 3.3.7.72
our experience
1 relation
grep -n 'always-allow-api-submission\|allow-mailmerge' /etc/pmta/config /etc/pmta/virtualhost.txt printf 'EHLO test\r\nQUIT\r\n' | nc <node-address> 2525
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.