Prior to the advent of milter, an email filter was generally implemented as a program to which an MTA would hand the message once it has completely arrived, with most of the message's envelope information removed. That program could then analyze the header and body of the message and make a decision to accept the message (i.e. return a "success" status to the MTA) or reject it (i.e. return a "failed" status to the MTA). The MTA would then log a successful delivery or return a failure message to the sender as appropriate, and the filter would be responsible for affecting the delivery of the message (to the intended inbox(es) as-is, or modified to remove unwanted content, or to specific folder(s), etc.). An MTA that is milter-capable instead notifies filters to which it is connected about each phase of the delivery of a message, from initial client connection through completion of transmission. At each phase of the
SMTP session, the filter is given data about the arriving message and then has an opportunity to terminate acceptance of the message early when appropriate. For very large messages, this can have an enormous impact when a decision to reject can be made as early as possible. Moreover, unlike the former model, a milter-capable MTA can connect to multiple filters in parallel that serve specific purposes such as anti-virus, anti-spam, message authentication, flow regulation, etc. Finally, such filters can take special action on the message: add or remove recipients in the envelope; alter the body prior to delivery; add, change or remove header fields in the message, etc. The Sendmail Consortium includes a special thread-based library in the sendmail distribution that provides the milter
API. ==MTAs==