Milter operation

Milter is implemented as a client-server protocol, with Messaging Server in client role and any of a wide variety of software packages in the server role. Most, but not all, milter servers are written on top of the libmilter library that is provided as part of sendmail.

Unfortunately, the milter protocol provides no authentication, privacy, or integrity protection facilities. As such, it is essential that milter protocol connections be restricted to protected networks, and under no circumstances should they be operated over the open Internet.

The libmilter library is multithreaded and supports a limited amount of threading configuration. Even so, multiple milter servers are often required in large configurations. The Messaging Server milter client does not provide any load balancing capabilities beyond those provided by the DNS (i.e., multiple A/AAAA records), so the use of a load balancer may be required in large, high performance milter configurations.

The milter protocol allows for interaction at every stage of the SMTP protocol. The following diagram illustrates the relationship between a typical SMTP/SUBMIT dialogue and milter protocol commands:



Note that this simplified diagram omits:



 Negotiation of SMTP transport security, 

 SUBMIT authentication, 

 optional milter macro commands (Macros can precede CONNECT, HELO, MAIL, and RCPT), 

 multiple message transfers in the same SMTP/milter session (not used by the MS MTA), 

 use of the QUIT_NC command to process multiple connections in the same milter session, 

 interactions between multiple milters operating in parallel, 

 due to the ability to activate milters based on source or destination channel, milter connect may be deferred to as late as the RCPT TO step in the SMTP diaglogue, and 

 if enabled, unknown commands sent by the SMTP will cause the MTA to send UNKNOWN milter commands to the milter server independent of protocol state, and </li>

 PROGRESS responses may be sent by the milter server at any time. These are ignored by the MTA. </li>

</ul>

The milter Accept/Reject actions are:

<ul>

 SMFIR_ACCEPT - Accept message unconditionally. No further milter commands or responses will be exchanged. </li>

 SMFIR_CONTINUE - Accept command and continue processing </li>

 SMFIR_DISCARD - Tells the MTA to discard the message. No further milter commands or responses will be exchanged. </li>

 SMFIR_REJECT - In response to a RCPT command, indicates that the recipient should be rejected with a permanent error. In any other context this indicates that the entire message should be rejected with a permanent error and that no further milter commands or responses will be exchanged. </li>

 SMFIR_TEMPFAIL - In response to a RCPT command, indicates that the recipient should be rejected with a temporary error. In any other context this indicates that the entire message should be rejected with a temporary error and that no further milter commands or responses will be exchanged. </li>

 SMFIR_REPLYCODE - In response to a RCPT command, indicates that the recipient should be rejected with the specified error. In any other context this indicates that the entire message should be rejected with the specified error and that no further milter commands or responses will be exchanged. </li>

</ul>