The manual lists six ways to submit a message: extended SMTP, four language bindings (C/C++, .NET, Perl, Java) and a submission directory that the node watches on disk.
It lists them — and does not describe them. The bindings get a chapter of their own, the submission directory lives among the advanced features. At this level the shape of the list matters, not the details.
And the shape is this: everything except SMTP requires something on the submitting side. A binding is a library that has to be installed and called from code; a submission directory is an agreement to put files where the node looks. SMTP requires nothing: every platform has a mail client.
Hence the choice for platforms. Every mailing system the Hub connects comes in through one of these doors, and in the vast majority of cases it is SMTP — simply because it can do it without modification.
This is deliberate: every platform can do SMTP, while a binding would require changes in every connected platform. Control headers cover what a binding is taken for — above all, selecting the sending address. The job header X-Job, on the contrary, the Hub turns off in login-based submission sources (process-x-job false): neither warm-up nor a platform sets a job tag.
We do not use the submission directory either. It would be handy where messages are dropped off by a third-party system with no network path to the node, but we have no such setup.
What to submit with and why:
| Method | What it requires from the submitter | When to use |
|---|---|---|
| SMTP | nothing — any platform can do it | our choice, and almost always the right one |
| binding | install a library and write code | only for merging with many recipients |
| submission directory | put files where the node looks | when there is no network path to the node but the disk is shared |
Submission decisions are the same for all doors. The sending address, the job, the encoding are chosen by the submitting side, whatever method it submits with (submission-model). The form of expression changes, not the set of decisions.
The submission directory is the only method without a network. That is its real advantage, not a convenience.
# submission over SMTP: the same decision a binding would make X-Virtual-MTA: mta-news-1X-Job: campaign-4417
what people get wrong and how it ends3 mistakes▶
§ 1.3
§ 1.3
§ 7
2 relations
Accept, route, deliverWhere all six doors lead: the message’s path inside the node. § 1.3
pickupGlobalOne of the submission methods alongside SMTP and HTTP. § 1.3The line ending requirementA related mechanism: they work together. inferenceLatency on receptionMeasures the submission path by which messages arrive at the node. inferenceWhat the submitting system assembles before sendingThe same submission method among the others: bindings are one of the doors into the node. § 7Submitting a message by writing a file into a directoryOne of the submission methods alongside SMTP and HTTP — only without a network. § 11.20
grep -o ',smtp,\|,api,' /var/log/pmta/acct-*.csv | sort | uniq -c pmta show status
3 articles
◇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.◇Five ways for a queue to hand off a messageA queue does not have to use SMTP: it can write to a file, run a program, call over HTTP or discard.