On 5/24/22 08:24, Viktor Dukhovni wrote:
Milters learn about the role of the requesting MTA via a macro. Thus
in the stock master.cf for the submission-related ports:
-o milter_macro_daemon_name=ORIGINATING
Ah! Interesting. Thanks.
Yet note that this term "ORIGINATING" is nowhere to be seen in the Postfix "Milter
Readme" - let alone explained.
On 5/24/22 08:30, Matus UHLAR - fantomas wrote:
opendkim afaik does not use this macro (I don't know which milters do)
and how opendkim decides if it signs the mail is described in its manual page.
I was surprised to see this in man 5 opendkim.conf:
----
MacroList (dataset)
Defines a set of MTA-provided macros that should be checked to see if
the sender has been determined to be a local user and therefore whether or not
the message should be signed. ...
In order for the macro and its value to be available to the filter for
checking, the MTA must send it during the protocol exchange. This is either
accomplished via manual configuration of the MTA to send the desired macros or,
for MTA/filter combinations that support the feature, the filter can request
those macros that are of interest. The latter is a feature negotiated at the
time the filter receives a connection from the MTA and its availability depends
upon the version of milter used to compile the filter and the version of the
MTA making the connection. ...
----
This implies that this "in/out", "sign/verify", distinction can be, shall we say,
"complicated", though I suppose that this MacroList option is only needed in special circumstances.
finally, you can specify different milters if you use multi-instance setup
http://www.postfix.org/MULTI_INSTANCE_README.html
On 5/24/22 16:43, Benny Pedersen wrote:
in opendkim.conf its used
MTA=ORIGINATING
In man 5 opendkim.conf:
----
MTA (dataset)
A set of MTA names (a la the sendmail(8) DaemonPortOptions Name
parameter) whose mail should be signed by this filter. There is no default,
meaning MTA name is not considered when making the sign-verify decision.
----
Hmm - it took me a while to appreciate the difference between the Postfix options, literally
"milter_macro_daemon_name", versus "multi_instance_name". Thanks for pointing that out.
I wouldn't have thought that either of those names actually referred to Postfix itself, but they both do.
You just have to already know that the "daemon" being referenced is Postfix, and not the milter.
Again, no context is provided in the Postfix "Milter Readme". It's a case of "You
don't know what you don't know."
On 5/24/22 08:44, David Bürgin wrote:
As was suggested upthread, do check the sendmail milter documentation
for questions about the milter protocol. Technical design, API,
interaction of multiple milters, succession of milter callback stages,
it’s all there.
On Ubuntu or Debian install package sendmail-doc and start at
/usr/share/doc/sendmail-doc/libmilter/html/index.html.
Ah!
https://debian.pkgs.org/sid/debian-main-amd64/sendmail-doc_8.17.1-2_all.deb.html
http://ftp.de.debian.org/debian/pool/main/s/sendmail/sendmail-doc_8.17.1-2_all.deb
This can also be easily installed to Arch Linux using debtap.
However, I'd say that "it's all there" is an "overly generous" assessment - sort of like
"Luke, Read The Source". And the Milter Wikipedia page, describing the Milter Interface, offers a somewhat
different, tragically amusing, assessment, saying: "However, documentation of the protocol used for communication
between sendmail and milter processes is not provided."
Of course, thanks, nonetheless. It's an awkward learning curve, keeping in mind that I'm
not wanting to write a milter - I'm just wanting to configure Postfix, though not
"blindly".
Another milter overview I found related is in the "Milter API Operation" section and
following from "Filtering Mail with Milter",
https://web.archive.org/web/20210505215132/https://www.roaringpenguin.com/files/filtering-with-milter.pdf
What is still missing, though, is a real example of a conversation between Postfix and a milter. The article seems to imply that the interaction
between Postfix and a milter has the general form of, literally, a typical smtp client/server interaction, but with additional "mystery"
milter-related "macro" commands and responses interjected. If that is true, then I expect that Postfix would have to actually
"send" a mail message to the milter, where the milter might either "accept" or "reject" the message for delivery, or,
if the purpose of the milter was to modify the message, then subsequently, the milter would then also "send" the modified message back to
Postfix. The article only offers that "At various stages of the SMTP conversation, Sendmail sends a message over the socket to the milter."
The Sendmail libmilter documentation, under "Architecture: MTA - Filter communication"
and under "Technical Overview: Control Flow" is equally opaque about this interaction.
Is that what actually happens, between Postfix and a milter, literally "sending" and
"receiving" mail messages, using SMTP? If anyone actually knows the form of that conversation
between Postfix and a milter, and what form these "mystery macro commands" might take there, please
share.
James
