#### 5.7.1 Built-in Actions ¶

The GNU libmu_sieve supports the following built-in actions:

- stop
- keep
- discard
- fileinto
- reject
- redirect

Among them the first three actions do not need to be explicitly required by a `require` statement, while the others do.

These actions are described in detail below.

Action: stop ¶

  The `stop` action ends all processing. If no actions have been executed, then the `keep` action is taken.

Action: keep ¶

  The effect of this action is to preserve the current message in the mailbox. This action is executed if no other action has been executed.

Action: discard ¶

  `Discard` silently throws away the current message. No notification is returned to the sender, the message is deleted from the mailbox.

  Example:

      if header :contains ["from"] ["idiot@example.edu"]
        {
          discard;
        }

Action: fileinto [:permissions mode] folder ¶

  Required arguments:

  folder

    A string representing the folder name

  Tagged arguments:

  `:permissions mode`

    Specifies the permissions to use, if the mailbox is created.

  The `fileinto` action delivers the message into the specified folder. If the folder is local, it is created using permissions ‘`0600`’, for regular files, and ‘`0700`’ for directories. This default can be changed by using the `:permissions` tag. Its argument is a mode specification, similar to that used by `chmod` shell utility. It is a list of permissions settings separated by commas. Each setting begins with one of the following letters:

  g

    Set permissions for the users in the file group.

  o

    Set permissions for users not in the file’s group.

  This letter must be followed by either ‘`+`’ or ‘`=`’ and the list of permissions to be set. This latter list is a string containing any one or both of the following characters:

  r

    Grant permission to read.

  w

    Grant permission to write.

  For example, the following instruction creates the mailbox `~/shared` which will be world readable and writable for the group:

        fileinto :permissions "g=rw,o=r" "~/shared"

  Notice that:

  1. The `:permissions` setting are affected by the current umask value.
  2. Only `r` and `w` permissions can be set, since other permissions do not seem to be useful for mailboxes. However, for mailboxes that have a directory structure (such as maildir and MH), any settings in ‘`g`’ and ‘`o`’ sets imply setting the executable bit.
  3. Owner’s permissions cannot be set. The owner always has all permissions on the mailbox he created.
  4. The `:permissions` settings apply only to local mailboxes. They are ignored for remote mailboxes.

Action: reject reason ¶

  The optional `reject` action refuses delivery of a message by sending back a message delivery notification to the sender. It resends the message to the sender, wrapping it in a “reject” form, noting that it was rejected by the recipient. The required argument reason is a string specifying the reason for rejecting the message.

  Example:

  If the message contained

      Date: Tue, 1 Apr 1997 09:06:31 -0800 (PST)
      From: coyote@desert.example.org
      To: roadrunner@acme.example.com
      Subject: I have a present for you

      I've got some great birdseed over here at my place.
      Want to buy it?

  and the user’s script contained:

      if header :contains "from" "coyote@desert.example.org"
        {
          reject "I am not taking mail from you, and I don't want
                  your birdseed, either!";
        }

  then the original sender <coyote@desert.example.org> would receive the following notification:

      To: <coyote@desert.example.org>
      X-Authentication-Warning: roadrunner set sender using -f flag
      Content-Type: multipart/mixed; boundary=----- =_aaaaaaaaaa0
      MIME-Version: 1.0
      ----- =_aaaaaaaaaa0
      The original message was received at
      Tue, 1 Apr 1997 09:07:15 -0800 from
      coyote@desert.example.org.
      Message was refused by recipient's mail filtering program.
      Reason given was as follows:

      I am not taking mail from you, and I don't want your
      birdseed, either!

      ----- =_aaaaaaaaaa0
      Content-Type: message/delivery-status

      Reporting-UA: sieve; GNU Mailutils 0.1.3
      Arrival-Date: Tue, 1 Apr 1997 09:07:15 -0800
      Final-Recipient: RFC822; roadrunner@acme.example.com
      Action: deleted
      Disposition: automatic-action/MDN-sent-automatically;deleted
      Last-Attempt-Date: Tue, 1 Apr 1997 09:07:15 -0800

      ----- =_aaaaaaaaaa0
      Content-Type: message/rfc822

      From: coyote@desert.example.org
      To: roadrunner@acme.example.com
      Subject: I have a present for you

      I've got some great birdseed over here at my place.
      Want to buy it?
      ----- =_aaaaaaaaaa0

  If the reason argument is rather long, the common approach is to use the combination of the `text:` and `#include` keywords, e.g.:

      if header :mime :matches "Content-Type"
                [ "*application/msword;*", "*audio/x-midi*" ]
        {
          reject text:
      #include "nomsword.txt"
          .
          ;
        }

Action: redirect address ¶

  The `redirect` action is used to send the message to another user at a supplied address, as a mail forwarding feature does. This action makes no changes to the message body or existing headers, but it may add new headers. It also modifies the envelope recipient.

  The `redirect` command performs an MTA-style “forward” — that is, what you get from a `.forward` file using `sendmail` under UNIX. The address on the SMTP envelope is replaced with the one on the `redirect` command and the message is sent back out. Notice, that it differs from the MUA-style forward, which creates a new message with a different sender and message ID, wrapping the old message in a new one.