4.19.1 Action Statements

An action statement instructs mailfromd to perform a certain action over the message being processed. There are two kinds of actions: return actions and header manipulation actions.

Reply Actions

Reply actions tell Sendmail to return given response code to the remote party. There are five such actions:

accept

Return an accept reply. The remote party will continue transmitting its message.

reject code excode message-expr

reject (code-expr, excode-expr, message-expr)

Return a reject reply. The remote party will have to cancel transmitting its message. The three arguments are optional, their usage is described below.

tempfail code excode message

tempfail (code-expr, excode-expr, message-expr)

Return a ‘temporary failure’ reply. The remote party can retry to send its message later. The three arguments are optional, their usage is described below.

discard

Instructs Sendmail to accept the message and silently discard it without delivering it to any recipient.

continue

Stops the current handler and instructs Sendmail to continue processing of the message.

Two actions, reject and tempfail can take up to three optional parameters. There are two forms of supplying these parameters.

In the first form, called literal or traditional notation, the arguments are supplied as additional words after the action name, and are separated by whitespace. The first argument is a three-digit RFC 2821 reply code. It must begin with ‘5’ for reject and with ‘4’ for tempfail. If two arguments are supplied, the second argument must be either an extended reply code (RFC 1893/2034) or a textual string to be returned along with the SMTP reply. Finally, if all three arguments are supplied, then the second one must be an extended reply code and the third one must give the textual string. The following examples illustrate the possible ways of using the reject statement:

reject
reject 503
reject 503 5.0.0
reject 503 "Need HELO command"
reject 503 5.0.0 "Need HELO command"

Used without arguments, reject is equivalent to

reject 550

and tempfail to

tempfail 451

In literal notation, the values of code and extendended code (if supplied) must be literal strings. The third argument (textual message) can be either a literal string or MFL expression that evaluates to string.

The second form of supplying arguments is called functional notation, because it resembles the function syntax. When used in this form, the action word is followed by a parenthesized group of exactly three arguments, separated by commas. Each argument is a MFL expression. The meaning and ordering of the arguments is the same as in literal form. Any or all of these three arguments may be absent, in which case the corresponding default value will be used¹⁶. To illustrate this, here are the statements from the previous example, written in functional notation:

reject(,,)
reject(503,,)
reject(503, 5.0.0)
reject(503, , "Need HELO command")
reject(503, 5.0.0, "Need HELO command")

Notice that there is an important difference between the two notations. The functional notation allows to compute both reply codes at run time, e.g.:

  reject(500 + dig2*10 + dig3, "5.%edig2.%edig2")

Header Actions

Header manipulation actions provide basic means to add, delete or modify the message RFC 2822 headers.

add name string

Add the header name with the value string. E.g.:

add "X-Seen-By" "Mailfromd 9.0"

(notice argument quoting)

replace name string

The same as add, but if the header name already exists, it will be removed first, for example:

replace "X-Last-Processor" "Mailfromd 9.0"

delete name

Delete the header named name:

delete "X-Envelope-Date"

These actions impose some restrictions. First of all, their first argument must be a literal string (not a variable or expression). Secondly, there is no way to select a particular header instance to delete or replace, which may be necessary to properly handle multiple headers (e.g. ‘Received’). For more elaborate ways of header modifications, see Header modification functions.