Message receiving rarely breaks, and almost always with a home-grown submitting program; the most common error is lines ending with a single LF instead of a CRLF pair.
It is diagnosed with a session recording of one source: a <source> block for the submitting program’s address with log-connections and log-commands shows at which step the transfer fails, and log-data shows every byte with its hexadecimal code. After a reload, the submission is reproduced, the log is read and the block is removed.
Recording levels:
| Line | What it shows |
|---|---|
| log-connections | connections and their end |
| log-commands | at which command the failure happens, for example RCPT |
| log-data | bytes: a lone LF, non-printable characters |
<source 127.0.0.1> log-connections yes log-commands yes log-data yes</source>
6 relations
log-connections<source>The directive this step sets. § 4.2.4log-commands<source>The directive this step sets. § 4.2.4log-data<source>The directive this step sets. § 4.2.4Apply a changed configuration without stoppingThe command that performs the step. § 4.2.4
How the node selects a source and combines its settingsThe mechanism this step relies on. inference
The line ending requirementThe mechanism this step relies on. § 4.2.4
pmta reload tail -100 /var/log/pmta/log
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.◇How a message gets into the engineSix described submission methods: extended SMTP, four language bindings and a directory the node watches on disk.◇Two inbound report processors and what to do with themBounces by message and complaints are parsed by two identically structured blocks; each has its own address list and its own pair of decisions about the message’s fate.